AMD FSR and Unity

I just finished watching the Digital Foundry video covering AMD FSR and I find it thoroughly amusing that Epic's TAAU (Temporal Anti-Aliasing Upsampling) is higher quality while only very slightly more demanding. AMD FSR meanwhile looks about as good as I expected it to. That is to say I would never turn it on for standalone.

Spoiler: Digital Foundry - AMD FSR

 

Dunno about DF in this case.. other places are saying different things.

 

DF is consistently the only group actually putting the analytical work in while many, many others are little more than thinly veiled tech hype machines. Like, Linus Tech Tips will put the effort into performance analysis but they've always had terrible frame analysis as an example, but they're hardly unique in the space.

The reality is that this is only slightly more performant than the existing hardware agnostic competition at the cost of looking worse than all of the game scaling solutions out there. This really does look like it's barely a hair above DLSS 1.0

 

Analytical work doesn't really work so well when the goal is to judge perceptually. Also it's a big win for lower resolutions too, not just 4K.

The reality is this is all we're (potentially) getting in Unity that runs on AMD and Nvidia cards. I also don't see Unity rushing to add DLSS 2 to URP any time soon.

"looking worse than all of the game scaling solutions out there" -- I keep reading this from people but people seem to forget the Unity context.

Unity right now:

• DLSS2 on HDRP only, on high-end GPUS only
• HDRP upscaler with lanczos or cubic or just bilinear

vs

• Nothing for URP

 

We've both been here long enough to know that Unity isn't rushing to add anything if they can't add it without half the functionality missing.

 

And here I was trying to be nice to Unity.

 

With the latest beta release I started playing around with DLSS. I'm very happy with the results so far and I'm hoping they do an equally impressive job implementing FSR.

Spoiler: Full Render Resolution

Spoiler: Half Render Resolution - DLSS Quality

 

Judging from Unity's history here's what's likely to happen.

Unity will implement FSR, but they will implement only the Performance profile, because of *reasons*.

People will complain that it looks like ass and comparisons with Unreal's custom solution will start. Certain forum regulars will start huffing and scoffing, blaming the community for being entitled and not trusting Unity's decisions, because big corporations always know better.

Years will pass, it will become a big issue. Here on the forums we'll be so tired of it that every time someone mentions it, we'll go "ugh, this again, Performance mode is fine, you don't need FSR to make a good game anyway!" complete with examples of other games that look pretty good without upsampling at all.

Soon, threads about it will start to get locked.

But after some high profile dev on Twitter slams Unity about it and Unity's stock takes a small dive (although, I guess this doesn't matter that much any more, because the higher echelon of Unity people have already gotten rid of their stock), Unity will make a blog post saying how dedicated they are to quality and stability and how implementing an industry standard upscale algorithm is their highest priority.

A tidbit about "researching upsampling" will be added to the roadmap. Reddit and the forums will be flooded with surveys asking questions like "If you could upsample your resolution by 2x, 3x, 5x but not by 4x, how would you feel?" and "How would you feel if you could not only see, but also smell the pixels".

Finally, a few more years later, Unity will release their new upsampling algorithm. It will be pretty buggy and kinda slow, but it's a start. People will say it's okay, it's a first release, surely they will improve it soon. They won't.

Eventually, graphics cards will be powerful enough to render at 16k at native res and upsampling will not matter and everyone will be happy(?).

 

This reads like a grim Ragnarok prediction told by vikings holding horns of mead over fires in long wooden halls at night while the wind howls outside like the beasts of myth.

 

Except in the case of Unity, Jormungandr stops eating its own tail and vomits poison onto the land and sea every few months, which is why the vikings talk like that.

 

AMD partners with Epic Games in Unreal Engine 5 Ea... - AMD Community

I assume FSR also comes to UE , together with DLSS (currently avialble on UE4 and UE5, u need to download teh plugin thoo) and UE5's Temporal Super sampling solution. Btw UE has only one render pipeline.

As i said in other thread, DLSS, FSR those are too good of a features to just pass on URP. Not neccesarily someone has to use HDRP to create a PC / Console game, ppl can also use URP why cut them off from the tech.

Secondly yes FSR is rough around the edges atm, but do u remember DLSS 1.0 ? So if ppl gonna use FSR (and they will, they don't need RTX card to use it) AMD definetly will invest resources to improve it.

 

Have you used an AMD GPU? It wasn't that long ago that AMD would release a driver and everyone would meme about it because their drivers were legitimately that bad with all sorts of problems being introduced assuming the update worked at all. AMD will invest resources but I wouldn't hold my breath for significant improvements.

Spoiler

 

I want to be optimistic about it , true that AMD has to up their game with GPUs, but watching how Ryzens turned out there is hope for them to step up their game eventually.

We all should hope AMD gets better with GPUs, that would cause a healthy competition with Nvidia that should benefit us, users.

 

TL;DR: My speculation about AMD next year

The next series of GPUs from AMD are likely going to be on TSMC 5nm, as are Ryzen 6000 series CPUs. You're going to see significant efficiency boosts just from the node shrink, which means they can do more work with the same power budget as today. NVidia is probably going with whatever the best Samsung has again for the next generation, which is either 8nm or 7nm. NVidia has a bit superior engineering so will be more competitive than it might otherwise look, but I'm expecting this next generation is going to be the first time AMD's flag ship greatly outclasses NVidia's. But also the first time AMD charges more money for their's than NVidia.

Since AMD is again going to share the same TSMC supply for both of their major product lines, you'll also probably see a repeat of this generation where AMD simply can't supply enough product to leverage their advantages to really capture significant market share from either Intel or NVidia.

 

I've used AMD GPUs since 2014 and this has not been my experience at all. I have never had any kind of driver issue whatsoever. You're exaggerating.

 

WORKSFORME WONTFIX

 

OMG, you were on the dev team at my last job weren't you?

 

My post is based off of the statements of hardware reviewers (who have dealt with a wide range of hardware as well as driver releases) and the users of said hardware in communities like /r/AMD. If you have evidence proving your statement I'm willing to listen to it but I'm going to disregard one person's anecdotes.

https://en.wikipedia.org/wiki/Anecdotal_evidence

 

Their video driver issues are well known, and have a history which predates even the AMD acquisition of ATI. My personal experience goes all the way back to the ATI Rage series, which had unstable garbage drivers. The first Radeon R100 series, again unstable garbage drivers, etc, etc. It seemed like AMD decided not to break such a well established tradition until relatively recently.

 

Well, look at AMD and Nvidia's patch notes. They are BOTH filled with issues all the time. Such is life with technology.

 

AMD/ATI's driver situation was/is so bad that it has been used as a point in nvidia's favour when making purchase comparisons.

 

People say that and then you also see people complaining about their $1000 Nvidia card being bugged in the latest game. Bugs happen.

 

"Bugs happen" at different scales at different manufacturers. This has been a specifically known issue of AMD/ATI for longer than you know.

 

We're not saying complaints don't exist on the NVIDIA side. We're saying the ones on the AMD/ATI side vastly outnumbered the ones on the NVIDIA side. I think it's often lost on people that NVIDIA's strength is with their software not their hardware. If you stripped out all the optimizations they've done their cards would be slower.

 

Yeah, I swapped from ATI to nVidia cards ages ago both individually and across the studio I was running because we kept having issues with the ATI stuff and research showed that it wasn't just us. For general gaming there wasn't really an issue, but we'd regularly get crashes in content creation software. And when you're paying people to make stuff that's not just an irritation, it's lost productivity.

Indeed, nVidia aren't perfect either, but there's a far cry between "not perfect" and "a noticeable impact on productivity". I strongly suspect that things have improved since, as negative reputations are hard to shake. I've had no reason or opportunity to find out first hand, though.

 

I always buy nvidia now because of DLSS2+ and more apps are hardware accelerated for nvidia cards. It's simple: stuff is faster, more stable and more expensive but I'll live with that.

AMD is hardly hurting: they are in a couple of entire console generations and doing fine.

 

Some part of which is likely due to the console manufacturers having feedback into the design of the chips.

 

For a console product, I'm sure it is very attractive to be able to get both the CPU and GPU as a single deliverable from 1 company. AMD is probably the only company which could do that at this time, outside of a handheld product.

 

nvidia has big plans for arm, and it'll be interesting to see what next.

 

Genuinely excited to see if they've got any plans for high-performance consumer/prosumer desktop chips with proper expansion support. RISC devices (as opposed to the RISC-like we kinda have with x64 if you squint) have shown a lot of potential in the consumer space lately, well beyond the theoretical ideas people had back 20 years or so.

 

Yep, but they were too slow for the recent console refresh. If they stay on track, maybe AMD will have stiff competition for the next console cycle though. More competition = more better

 

If only there was a successful console using both arm and nvidia ...

Also dlss 2.0 is basically a tsr, tge neural don't do the upsampling directly, but manage the policy of pixel rejection.

That explains why unreal 5 solution is getting close, they just use human expertise rather than neural networks.

For those who don't know, tsr jitter the camera position in subpixel over time, and use the data of the previous frame, which is a subpixel apart, to blend with current frame, and thus recover fine details and edges data, using a pixel rejection policy on the gbuffer, trying to discard obsolete pixel, which is why bad implementations had trail artifacts, which dlss 2.0 occasionally have. In some way it can be seen as the child of accumulation buffer and checkerboard rendering. They key is to develop the rejection policy by identifying the correct pixel to blend, the motion buffer help but so is any data to identify relevant information.

Why is that relevant? Fsr don't do that, it takes the input of the final frame and try to guess details from basically nothing, which in case of arbitrary shape, can't work, because it's... arbitrary! If we were able to inject more data in fsr, like sub pixels information, it would probably do a much better job.

Using a vanilla upscaler i have no idea how to do that, it would mean redesigning the process, but maybe some ingenious dev can hack current implementations with some tsr idea to improve it?

 

I made a post for using FSR with HDRP Pipeline (Already available on beta of Unity 2021.2)
https://forum.unity.com/threads/uni...and-change-between-modes-and-quality.1136395/

 

Is it available for URP/VR ?

 

Are you sure it's already available?
I've noticed they just made a pull to merge it into master: https://github.com/Unity-Technologies/Graphics/pull/5152

https://forum.unity.com/threads/amd-fidelityfx-super-resolution-fsr-preview-now-available.1141495/ < today

 

Unity right now:

• DLSS2 on HDRP only, on high-end GPUS only
• HDRP upscaler with lanczos or cubic or just bilinear
• AMD FSR for HDRP

vs

• Nothing for URP

 

This is actually stupid. I hope Unity realizes URP can also be used to make a frickin PC and Console games too -.-.

But that is what You get with two completly separate teams working on rendering system -.-

 

Add to this TAA Upscaler soon

 

Indeed, and that is why we smile with mild Stockholm like insanity

 

Unless I'm missing something, the pipelines are supposed to be hackable.

So it should be theoretically possible to fork URP and wire in the upscaler.

 

It's theoretically possible for me to just switch to O3DE and beat URPs performance in under 6 months and have a reliable engine on top. But I use Unity because I only have time for gameplay programming or control programming rather than engine programming.

 

It shouldn't take 6 months to hack in an upscaler assuming Nvidia/ATI provide an SDK. And it is not exactly an engine-level task either.

And possible losses from an engine switch would be higher.

So I'm genuinely wondering why nobody has attempted that yet.

 

6 months does include me becoming familiar with the engine enough to replace URP as a whole. I expect FSR would take a few hours for a first draft test.

The reason I mention going to another engine rather than implement it myself in Unity with a custom SRP is because it will break every update, and I'll have to maintain it all the time. That is why we pay Unity to do it instead.

Creating a custom SRP is an invasive and time consuming project which for me, given Unity's 4 years on it so far, is worth porting to another engine for instead. I would be much more trusting if there was a track record to support it.

 

But I'm not talking about a custom SRP.

Isn't entire source of HDRP on github? In that case, you can fork it. It is under Unity Companion license, so that is allowed.

Then you can make minimal changes necessary to accomodate for your feature and either ride the upstream while maintaining your fix, or attempt to submit the fix to the upstream.

That's not even remotely the same thing as maintaining your own SRP made from scratch.

 

Basically, what I'm describing can be done through version control, like git.

You fork stable branch of HDRP (if there is one). You base your feature branch off that. You implement the feature.
When the upstream updates, you update your "cloned upstream" branch to match upstream (git fetch/git pull), and then REBASE whatever you did in the feature branch on top of that. That will cause the version control software to apply your fixes on top of the new state of the source tree.

Depending on what did you do, this can be completely painless, as in you'll never have to fix anything, or painful, meaning there will be a ton of conflicts. Painless change would be adding new files, or a line or two to existing files. Painful would be making changes in some sort of binary blob.

In general, this kind of thing should be feasible, although you won't be using the package manager for your pipeline.

I mean the point of scriptable pipeline was to make it hackable. Why not hack it?

 

Maybe because its pain in the ass and produces more problems than benefits?...i guess.

 

Because:

a) I didn't ask for SRP or hackability or anything
b) I now have to pay dev time costs for it

c) I shouldn't have to beg for URP when HDRP has 4 different upscalers (including this) without any need for what you're saying.


If it's replacing built-in why isn't it the same amount of work? So far I end up doing more work throughout Unity when I go near SRP even peripherally if I care about performance.

 

Speaking of which here is the current draft for AMD FSR.

https://github.com/Unity-Technologies/Graphics/pull/5152

 

Pain in the ass with problems would be rolling out your own SRP from scratch.
That's not what I'm describing, at all. What I'm describing is making a SMALL adjustment. That's not the same thing, at all.

Well, the point of having pipeline SCRIPTED would be making it easier to extend. Because there are things you cannot shoehorn into builtin. Two basic examples would be
1. Order independent transparency (because directional lights use depth buffer)
2. Unusual shadow techniques like Shadow Volumes.
So the idea would be to make comlex tasks take less work.

Also, people on those forums are also often saying that it would be nice if unity provided source code for the engine.

Well, here's a subsystem with source code. Why isn't anyone hacking it?