5 ms·

It's disappointing to have this whole business go inside the driver / dx runtime. I'm sure the vast majority of it could be done from user code (CPU code & com

by obl 8y ago

It's disappointing to have this whole business go inside the driver / dx runtime. I'm sure the vast majority of it could be done from user code (CPU code & compute shaders) and it would be much more profitable for everyone if they'd expose the couple driver hooks they needed to achieve peek performance. As it is now, it's super opaque and bundled (do you even know what kind of acceleration structure you're using ?) and seems to be going the exact opposite way that GPU programming has been going (more general & programmable). Haven't tried it yet, but AMD has gone the open-source library way on this. I sure hope it works out well for them. (also this seems like a nightmare for the wine people)

dogma1138 8y ago
It’s because there are a lot of “hacks” behind including a CNN denoising module that runs to make it anywhere near useable in real time.
monocasa 8y ago
Yeah, that's sort of Nvidia's shtick: putting a ton of work into the more proprietary parts of their drivers, and getting third parties stuck on Nvidia hardware. You'd see this in games where Nvidia would put custom code in to support individual broken games before they came out. Then consumers see that the game works on Nvidia but not on AMD and blame AMD even though they generally have the more standards compliant driver. That's sort of the whole shtick behind CUDA as well. IMO, that's half the point of why AMD made Mantle. The layering part of the API means that consumers (and third parties like the media) can run validation layers to see if a game not working is the drivers fault or the game's.
- dogma1138 8y ago
  That's everyone's shtick, the CP portions of Gameworks are 100% standard DX API calls whilst AMD optimizations are "Radeon Shader Intrinsics" which are pre-compiled binaries that bypass the compiler in the driver and cannot run on any other hardware at all. "GPUOpen" is also heavily vendor locked much more so than Gameworks which is nearly 100% cross platform, in fact besides the SLI/VR stuff and RTX there isn't a single part of Gameworks which is proprietary.
  - monocasa 8y ago
    I mean, yeah it's everyone's shtick, but it makes sense for the underdog to take a more standards based approach. And I'll throw out there that you can still tie code to a particular vendor while still using only the public API. I'd call AZDO a case of this.
    - dogma1138 8y ago
      What standard based approach? "Shader Intrinsics" are non-standard by definition these are pre-compiled binaries that bypass the API, and only AMD uses them for graphics. And i know what you are talking about but both OpenGL and Vulkan support extensions but this isn't what we are really talking about.
corysama 8y ago
The thinking is that right now no one knows what the best API model for this should be. But, they do know that if the drivers today expose low-level features intended for ray-tracing, those features will be locked-in to be supported for ever and ever. After some real-world experience has been built up it will make sense to open up the model.

by obl 8y ago

dogma1138 8y ago

It’s because there are a lot of “hacks” behind including a CNN denoising module that runs to make it anywhere near useable in real time.

monocasa 8y ago

Yeah, that's sort of Nvidia's shtick: putting a ton of work into the more proprietary parts of their drivers, and getting third parties stuck on Nvidia hardware. You'd see this in games where Nvidia would put custom code in to support individual broken games before they came out. Then consumers see that the game works on Nvidia but not on AMD and blame AMD even though they generally have the more standards compliant driver. That's sort of the whole shtick behind CUDA as well. IMO, that's half the point of why AMD made Mantle. The layering part of the API means that consumers (and third parties like the media) can run validation layers to see if a game not working is the drivers fault or the game's.

dogma1138 8y ago
That's everyone's shtick, the CP portions of Gameworks are 100% standard DX API calls whilst AMD optimizations are "Radeon Shader Intrinsics" which are pre-compiled binaries that bypass the compiler in the driver and cannot run on any other hardware at all. "GPUOpen" is also heavily vendor locked much more so than Gameworks which is nearly 100% cross platform, in fact besides the SLI/VR stuff and RTX there isn't a single part of Gameworks which is proprietary.
- monocasa 8y ago
  I mean, yeah it's everyone's shtick, but it makes sense for the underdog to take a more standards based approach. And I'll throw out there that you can still tie code to a particular vendor while still using only the public API. I'd call AZDO a case of this.
  - dogma1138 8y ago
    What standard based approach? "Shader Intrinsics" are non-standard by definition these are pre-compiled binaries that bypass the API, and only AMD uses them for graphics. And i know what you are talking about but both OpenGL and Vulkan support extensions but this isn't what we are really talking about.

corysama 8y ago

The thinking is that right now no one knows what the best API model for this should be. But, they do know that if the drivers today expose low-level features intended for ray-tracing, those features will be locked-in to be supported for ever and ever. After some real-world experience has been built up it will make sense to open up the model.