DX12 Ray Tracing Tutorials | Hacker News Reader

DX12 Ray Tracing Tutorials

news.developer.nvidia.com

35 pointspjmlp8 comments

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)

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.

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.

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.

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.

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.

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.

Dear green team: Could we please have less tutorials and more documentation?

Reply on news.ycombinator.com