Hacker News Reader

Comment by bitL | Hacker News Reader

Can someone from AMD/NVidia please jump in and explain the difference between Radeon Rays (2016?) and RTX (2018)? Thanks!

View on HN

Radeon Rays is more comparable to OptiX (2009), in that both are GPU accelerated ray tracing libraries. RTX (2018) differs in that it uses special purpose ray tracing units on the GPU, rather than running only on the SMs/CUs.

Dedicated hardware to accelerate BVH traversal and ray triangle intersections. Previous GPU accelerated ray tracing implementations have just used existing hardware for programmable shaders for these but that hardware isn't ideally suited to the task.

So in that case is this going to be a "G-Sync"/"Freesync" or "Gameworks"/"No, I like my framerates" thing? If developers begin supporting the RTX hardware is there a way AMD can get on board, or is this another one of NVidia's patented industry hurting moves?

I can't answer the question, but I'm curious how you think NVIDIA should have introduced real time raytracing to the industry? They can make it proprietary at the API level, or proprietary at the ISA level, but at some point you're stuck with the fact that their hardware can do something AMD's cannot.

Is it industry hurting to make the GPU they sell have any exposed new capability, other than making the same old thing slightly faster?

NVidia actively denies others the ability to interact with their "Gsync" platform - an AMD card will never be able to take advantage of a Gsync monitor. I'm getting the answer that this is a Vulkan/DirectX Api, and assuming that's the case, that's great. But if it was a proprietary API (like Gameworks), that could only possibly run on proprietary hardware, I'd have a problem. As long as everyone can leverage those API calls at the same time I'm perfectly happy.

It's a OpenGL/Vulkan/DX12 API.

It is up to the other vendors to produce their own hardware and respective OpenGL/Vulkan extensions.

And maybe Khronos eventually gets to standardize them.

As far as I know, both Vulkan (with extensions, for nvidia VK_NV_raytacing) and DirectX (with DXR) have ray-tracing capabilities in their standard. Their shouldn't be any patent that deny AMD from providing an implementation in their drivers.

Developers support RTX via DirectX's DXR raytracing API. AMD can put whatever hardware they want on their cards to accelerate those calls and implement the appropriate drivers.

For games most will access the functionality via the new DirectX ray tracing APIs (or perhaps the Vulkan equivalent in the future) so there's nothing stopping AMD or Intel from adding hardware to accelerate those APIs too.

Ah, excellent. Then I support this future. I thought this would be a gameworks version 2.0 problem.

And if someone from Game development communities could explain how hard is it to do RTX or DirectX RT on current games? Would companies now have to do two set of graphics, design, and code path? One that does it with DirectX RT the other doing it with all the Rasterisation technique such as Shadow mapping etc.

Basically I am interested in the Cost of such Direct X RT implementation. And what sort of time frame could we see these on the market.

It's a big step, both assets and codepath have to change to make full use of it. It's possible to change some effects to work in a forwards-compatible way, but this isn't a free lunch. As an traditional GPU, the RTX is only slightly better than the existing 10-series.

Since AMD continues to hold console developers with their semi-custom chips, this is only likely to impact a limited set of titles in the near future.

Naturally multiple code paths are required, as always.

Yes but it means another set of path to test and optimise. Another set of Graphics design asset for RT. As if the current AAA titles budget are not expensive enough. Instead of making quality games cheaper, we are making graphics intensive games even more expensive to build. And I don't think it is healthy at all.

Reply on news.ycombinator.com