FSR4 running on RDNA3 in Linux via hack.

[_roman_]

hrough FP8 emulation in FP16

I did not check the details.

It loos like floating point 8 is used for floating point 16 instructions. I'm quite sure a 16 bit instruction is broken down to at least two, more likely 3 - t bit intructions.

there would be a lot more possible when the information would be more public available.

AMD just disappoint me as a very long time gnu userspace with linux kernel user. It took more than 4 years to get any fan speed support, zero fan mode for any of those cards mentioned. Radeon 6600xt, radeon 6800 non xt and the newest 7800xt. (i talk about August 2021 till February 2025 -> https://www.techpowerup.com/gpu-specs/radeon-rx-6600-xt.c3774)

 

[R-T-B]

What does it matter if it's intercepting DLL calls, how do you think driver updates work when they fix bugs and optimize games ?

Through established APIs usually. Dll intercepts outside of neccesity (like modding a closed source game) are usually frowned upon. As the link he provided establishes, even Microsoft essentially says "please don't do this."

 

[Vya Domus]

Through established APIs usually

This is using established APIs. Not that it would matter.

 

[R-T-B]

This is using established APIs. Not that it would matter.

Established APIs are not dll intercepts. That's just a nono. That said I don't know enough about the nitty gritty of AMDs implementation to say how bad it is, I'm just assuming this guy knows what he is talking about. That may or may not be true.

 

[Vya Domus]

Established APIs are not dll intercepts. That's just a nono. That said I don't know enough about the nitty gritty of AMDs implementation to say how bad it is, I'm just assuming this guy knows what he is talking about. That may or may not be true.

What do APIs have to do with DLLs ?

 

[R-T-B]

What do APIs have to do with DLLs ?

I wasn't the origin of that discussion, but APIs can certainly be provided by dlls, if you are asking. What's frowned upon is substituting dlls to replace an existing applications code with your own.

Whether that's happening here? No idea anymore it's been a long discussion that kind of spun out of control.

 

[Vya Domus]

I wasn't the origin of that discussion

I didn't bring that up, you said it needs to be done through established APIs, which it is via DirectX/Vulkan, I guess I am confused. What does a "DLL call intercepting API" even supposed to mean ?

What's frowned upon is substituting dlls to replace an existing applications code with your own.

It isn't though ? That's literally the point of having DLLs, to have an easily replaceable modular piece of code that can be shared by applications. The only thing that's actually "frowned upon" is trying to use DLLs to hot patch code in running processes but that's not what's happening here. And even that is done plenty in a ton of popular applications people use.

 

[R-T-B]

It isn't though ?

It totally is. I don't know if you are understanding this frankly. There was reading material from Microsoft earlier in this thread, but it's targeted pretty deeply at programers. Basically, I'm not even sure if AMD is doing this, but theres no question that throwing third party dlls in other applications runtime environment to alter behavior is considered a bad practice. It's tolerated for mods and that's about it.

 

[Dr. Dro]

What does it matter if it's intercepting DLL calls, how do you think driver updates work when they fix bugs and optimize games ? They intercept calls/shaders from the application and replace/modify the code, makes no difference whether it's from a DLL or executable.

You can replace DLLs in anything btw, whether you intercept the calls or simply replace the DLL make no difference to the application.

Replacing (and even injecting) is not intercepting, there's a key difference there. As I've mentioned before, what they're doing is essentially hotpatching live memory. It's very unsafe to do.

Really there's no use trying to justify this, and I'll go a step beyond... Any AMD fan worth their salt at this point in time should be questioning why the heck is FSR 4 missing from GPUOpen, why is AMD doing this lazy implementation instead of using a documented, readily accessible API, why is engine-side FSR 4 support missing months after launch... and why are they backpedaling on their commitment to openness the moment they get something that actually holds its own.

It's OK to make proprietary software but it's always a bad taste when you close a historically open one, refuse to provide documentation, refuse to actually implement it with respect to good programming practices and don't even lift a single finger to help the Linux community as they've historically done (for example, no shims or DLLs provided to developers).

This upgrade in visuals is hardly worth the downgrade in... everything else

 

[Vya Domus]

what they're doing is essentially hotpatching live memory

It literally isn't.

why is AMD doing this lazy implementation instead of using a documented, readily accessible API

Nvidia when everything is proprietary : wholesome chungus
AMD when something is proprietary : lazy, sewage, bad

throwing third party dlls in other applications runtime environment to alter behavior

That's not what this is doing. The application's code is untouched, it's behavior stays the same, this is all on the driver's side and the DLLs that it calls from.

It's clear everyone engaged in this discussion doesn't actually know how any of this works nor have they bothered to look it up.

EDIT:

Just to make this 100% clear for everyone reading this :

The application has the FSR DLL, this DLL then calls another DLL which is shipped with the driver which is not part of the application. Nothing gets hot patched into the application's code, nothing even close to that.

 

[Dr. Dro]

You're not being honest in your argument, nor did I say it was amazing, wholesome for Nvidia to have proprietary software. Quite contrary, I said it was fine for AMD to have proprietary software as long as the same standards of quality are met.

Now if we're wrong (and interpreted the article incorrectly) at least make an argument in good faith. The author of the article explains the DLL redirection process and flow, if FSR 4 replacement is enabled in the driver, the FSR 4 DLL will be shoehorned in during context creation, without the application being directly aware of it.

"DLL calls another external DLL" is... exactly what I've mentioned and in direct violation of DLL best practices guidance.

 

[Vya Domus]

Now if we're wrong (and interpreted the article incorrectly) at least make an argument in good faith. The author of the article explains the DLL redirection process and flow, if FSR 4 replacement is enabled in the driver, the FSR 4 DLL will be shoehorned in during context creation, without the application being directly aware of it.

I edited my comment, I explained it, it's explained in the article as well. None of you bothered to read it.

The application has the FSR DLL, this DLL then calls another DLL which is shipped with the driver which is not part of the application. Nothing gets hot patched into the application's code, nothing even close to that.

without the application being directly aware of it.

Because it's not part of the application. The DLL calls which are modified are not part of it.

 

[Dr. Dro]

I edited my comment, I explained it, it's explained in the article as well. None of you bothered to read it.




Because it's not part of the application.

I'm posting on the phone, just read and edited my own reply - I read the article, it's a man in the middle insertion during the FSR 3 initialization flow. Really dude, I get it that to the end user this probably doesn't really mean anything at this point in time, I'm with you in that. But it's not something that we need normalized.

It's dirty, it's lazy, and a big regression from FSR 3's documented, standardized implementation and I really hope that AMD offers a proper API for it. They probably will once all RDNA 4 products release anyway, which will render this friction largely moot and the override to be used only in games that were never updated.

 

[Vya Domus]

But it's not something that we need normalized.

What do you mean, all vendors do this. They ship DLLs with their drivers, their implementation is subject to change, this is outside the scope of whoever develops the application, if the implementation of those DLLs is changed because the DLL itself is changed or because those calls are redirected to something else by the driver that's something completely opaque to the application.

Nvidia driver replaces the DLLs to force transformer model and multi frame generation as far as I know, how is replacing files any better or worse than this.

 

[Event Horizon]

What do you mean, all vendors do this. They ship DLLs with their drivers, their implementation is subject to change, this is outside the scope of whoever develops the application, if the implementation of those DLLs is changed because the DLL itself is changed or because those calls are redirected to something else by the driver that's something completely opaque to the application.

Nvidia driver replaces the DLLs to force transformer model and multi frame generation as far as I know, how is replacing files any better or worse than this.

This is a good thing. It allows for seamless fixes and updates and version control. Nvidia has done it thus way forever. AMD were a bit late to the party (FSR 3.1). The overrides are still signed, controlled, and checked by the driver. No good faith argument could single out AMD on this. I would move on if they persist with bad faith slop.

 

[Dr. Dro]

This is a good thing. It allows for seamless fixes and updates and version control. Nvidia has done it thus way forever. AMD were a bit late to the party (FSR 3.1). The overrides are still signed, controlled, and checked by the driver. No good faith argument could single out AMD on this. I would move on if they persist with bad faith slop.

For someone who's actively making things up (I nearly fell off my chair with that signed and controlled argument, this is not how DLLs work), you're one to talk about "bad faith slop". Please read the Microsoft documentation I've provided and stop running defense for billion dollar corporations, thanks. AMD isn't your friend, they don't even know you exist.

What do you mean, all vendors do this. They ship DLLs with their drivers, their implementation is subject to change, this is outside the scope of whoever develops the application, if the implementation of those DLLs is changed because the DLL itself is changed or because those calls are redirected to something else by the driver that's something completely opaque to the application.

Nvidia driver replaces the DLLs to force transformer model and multi frame generation as far as I know, how is replacing files any better or worse than this.

Did you miss the point? The difference is that DLSS has an entire API (Streamline) that expressly allows for DLL version upgrades and downgrades, as well as the addition and removal of components in separate libraries (for ray reconstruction and frame generation). Not only the driver, but the software is completely aware and designed for this - the DLSS versions do not even have to match. When you replace a library, you are loading only it, when you are intercepting and redirecting things, you're essentially hijacking the code functions and replacing them with something else, which can lead to all sorts of whack conditions and program issues.

This is already starting to be an attempt to defend the indefensible, the least that they could have done is document it and provide developer resources.

 

[Vya Domus]

you're essentially hijacking the code functions and replacing them with something else

You're essentially not doing that, I don't know how many more times I have to explain this, there is no hijacking of code/hot patching/whatever. The DLL that's shipped with the game is left untouched, it's calls have to go through the driver anyway, like it's the case with everything else GPU related, that's not "hijacking".

Nothing that you write as a developer runs natively on the GPU, everything is "replaced" at the driver level, that's why bugs/issues can be amended by GPU makers without modifying anything on the game's side or why you can force rendering changes, as opposed to other types of applications, it's because every graphics API call/shader IS interpreted.

 

[R-T-B]

I nearly fell off my chair with that signed and controlled argument, this is not how DLLs work

Small aside as I am mostly out of this now, but you actually can sign dlls. But it'd be up to the calling dll to check and like no one does.

 

[Dr. Dro]

Small aside as I am mostly out of this now, but you actually can sign dlls. But it'd be up to the calling dll to check and like no one does.

I know you can, and I'm also out, I said everything I had to say... it's that being signed or not has literally 0 bearing on how they work. Signing it simply means the library wasn't tampered with and is the original, but it's still a dynamic link library and its function is still exactly the same. We have some miscommunication going on that at this point, to me, seems intentional, so there's really not much to add anymore.

 

[R-T-B]

I know you can, and I'm also out, I said everything I had to say... it's that being signed or not has literally 0 bearing on how they work. Signing it simply means the library wasn't tampered with and is the original, but it's still a dynamic link library and its function is still exactly the same

Yeah I kind of got the same vibe here. All good, thanks for the earlier productive discussion at least.

 

[blinnbanir]

What Dr.Dro forgets is that the 7900 series are that fast that you do need need to use FSR. This is obvious with how much effort he has taken into defending his position. Meanwhile I tried Total Conflict Resistance and as usual everything was set to Epic I turned off Vsync and 100+ FPS at 4K. It is what the fan boys forget that native is still fine for PC gaming

 

[Dr. Dro]

What Dr.Dro forgets is that the 7900 series are that fast that you do need need to use FSR. This is obvious with how much effort he has taken into defending his position. Meanwhile I tried Total Conflict Resistance and as usual everything was set to Epic I turned off Vsync and 100+ FPS at 4K. It is what the fan boys forget that native is still fine for PC gaming

Where did that come from? Forget... what, exactly? What are you even talking about lol. A 7900 XTX damn better run an UE4 indie that's a couple of years old at 100 fps, it better, because if it won't what will

 

[blinnbanir]

Where did that come from? Forget... what, exactly? What are you even talking about lol. A 7900 XTX damn better run an UE4 indie that's a couple of years old at 100 fps, it better, because if it won't what will

You used the word sewage to describe AMD's software then accused them of being ignorant teens. This is not the only thread where you have waxed negatively on AMD. Look how you are talking about DLSS being some technical tour de force when Hyper RX works in every single Game.

 

[Hecate91]

You used the word sewage to describe AMD's software then accused them of being ignorant teens. This is not the only thread where you have waxed negatively on AMD. Look how you are talking about DLSS being some technical tour de force when Hyper RX works in every single Game.

They'll take every chance possible to bash on AMD while tiptoeing around actually criticizing Nvidia, it's all roses and sugar when it comes to team green. It isn't worth the argument with someone when they keep voting with their wallet to support the jacket man like they have some agenda in supporting a company even though said company doesn't care about the gaming market.
I think calling AMD software sewage is an interesting take while the multi trillion dollar company has repeatedly launched drivers causing crashing and all sorts of issues.

 

[blinnbanir]

They'll take every chance possible to bash on AMD while tiptoeing around actually criticizing Nvidia, it's all roses and sugar when it comes to team green. It isn't worth the argument with someone when they keep voting with their wallet to support the jacket man like they have some agenda in supporting a company even though said company doesn't care about the gaming market.
I think calling AMD software sewage is an interesting take while the multi trillion dollar company has repeatedly launched drivers causing crashing and all sorts of issues.

There are videos from the biggest Youtubers confirming what we have known about Nvidia for years.