DirectX Developer Day 2020

It's funny that you assume that Microsoft speaks for every hardware vendor out there so here's the important disclaimer about Microsoft's recommendation:

It's also funny that you guys assumed that inline ray tracing was somehow inherently tied to "simple shaders" when "complex shaders" can be implemented with inline ray tracing too so it doesn't make a difference to the visual feature set either way.

Case in point, inline ray tracing is better on AMD hardware with either 'simple' or 'complex' shaders so a massive uber-shader for ray tracing is the way to go for AMD.

 

This is probably because AMD's RT h/w is simply slower than NV's. So let's wait for the actual h/w before making bold claims?

 

Lol, defense mechanism triggered much ? I didn't even mention about Nvidia in my last post and here you are getting worked up so easily ...

Unlike you I don't need to wait for actual hardware when I can interpret IHV advice especially with a presentation that's littered with their logo.

Enjoy participating in the graphics vendor hardware wars while you and the others who are endlessly parading for an IHV will never truly understand or enlighten themselves with how any hardware works.

I guess this will be my last response to the likes of you since our interests lie elsewhere. Playing warrior is of no interest to me since I only have desire to seek more technical knowledge out of self-interest rather than using as a means to an end like you probably would.

 

I think we can do without the insults.

Oversimplification:
dxr 1.0 = driver does the ray scheduling/reordering
dxr 1.1 = developer does the ray scheduling/reordering

They both have pros and cons. 1.1 does not make 1.0 "obsolete". 1.1 is easier to integrate into existing engines (in fact you could claim in certain circumstances 1.0 was impossible to integrate without blowing everything up). 1.0 makes it "easier" (this is loaded/oversimplified/etc.) for the developer to achieve higher performance across a broad range of hardware (i.e. the developer can efficiently fire rays without really having to know the inner workings of a client's GPU). I bet some PC games will even use both techniques. I bet console games will only use the "1.1 technique".

That last sentence is key because I suspect what AMD is really saying is "look you're going to be doing the developer driven technique exclusively for consoles anyways and for RT to actually be feasible on consoles you need to be doing the scheduling "right". Thus assuming the dev scheduled the rays relatively efficiently, any extra performance benefit from rearranging your engine just to support 1.0 is simply not worth it. You can get a bigger performance wins by focusing your resources somewhere else". That may or may not be true (and it may or may not be true only for RDNA2!). But to suggest dxr 1.0 is "wrong" or "slower" is just inaccurate.

 

I don't think only using 1.1 will work, unless developers intend to avoid using complex shaders. I think console developers will still need to use dxr 1.0.
It also sounds like the visual quality between dxr 1.1 and dxr 1.0 implementations would be noticeable, but the boat is still out on that .

Microsoft outlines exactly when inline raytracing would and would not be used.

https://devblogs.microsoft.com/directx/announcing-directx-12-ultimate/

 

Sure if the developer's are OK with hitting potential slow-paths on major platforms. DXR 1.1 is 'less' of a lie than DXR 1.0 on consoles relatively speaking so in that sense DXR 1.0 is wrong in terms of it's 'abstraction' on other hardware.

 

Microsoft did mention for complex shaders massive use of inline ray tracing is less efficient that dynamic-shader based ray tracing. I would think only relying on dxr 1.1 would potentially have more performance issues.
If anything it sounds like inline ray tracing would be used in conjunction with dynamic-shader based ray tracing to primarily fine tune problem areas.

 

Microsoft is supposed to play the role of 'solomon' which is to be the neutral party as much as possible so they do not necessarily always give the best advice possible advice for each IHVs. On AMD hardware it is encouraged that developers take the one shader fits all approach as much possible even for complex shaders. In their demo, they had nearly 100 materials in their single shader.

They do not ever recommend taking the multiple shader approach and in fact they dissuade developers from ever considering it.

 

I am afraid you initiated the platform wars when you used phrases like deprecated pathway, and IHVs lies, and the rest of the conspiracy theories, despite AMD never using such language, or stating that DXR 1.0 is deprecated.

In fact the demo AMD showed, was running both DXR 1.0 code and DXR 1.1 code on top of it.

 

Because DXR 1.0 is a lie on their hardware and I made no mention of any other vendors in relation to performance until you and others got defensive about it. As far as their hardware is concerned, DXR 1.0 is obsolete to them since they don't use it's main junk like shader tables or do dynamic dispatch with ray tracing shaders. Inline ray tracing by comparison is a different programming model and it's a major change in comparison to the previous standard.

DXR 1.1 is the future otherwise Microsoft would've called it DXR 1.0 version B instead but nope DXR 1.1 signifies an absolute step forward in comparison to DXR 1.0 and they fully expect programmers to adopt it's latest standard instead of adopting an outdated standard.

 

You have to admit this sounds a bit like you do not even need to implement different options, profile them on different HW, and finally select the faster paths.
Ofc. people will point out assumptions are not necessarily true - even if they are likely. And after describing initial DXR 1.0 as 'deprecated crap' for AMD you can expect a heated discussion, i would say.

I would agree if 1.1 would add something significant like programmable traversal or exposing BVH, but unfortunately it doesn't.
It starts to look messy and both might become deprecated at the same time later on.
I'm non convinced 1.1 is a lasting step forwards because it does not address things still missing. It may prevent a global HW reordering solution while still not giving the option to implement it in software.

 

The only one who's constantly on a defensive here is you, mate.

 

Why do you think dynamic dispatch is "junk" and "crap" when neither Microsoft, Nvidia or AMD has said so? I'm still searching for an explanation of why dynamic scheduling is better for complex shaders. Is it a state management thing?

Actually 1.1 implies the exact opposite. It's a minor extension of 1.0 features and certainly doesn't imply it's deprecated or obsolete.

 

I respectfully disagree. He came with an agenda starting from his first post here containing this "hot take":

Under a video which has this slide in it:

 

Please stop being "colored-blind"! There is nothing neutral about the following

 

Based on the video, the issue doesn't seem to be raytracing performance itself but the overhead of switching shaders. With one big branching shader you can interleave work from threads taking different paths in different warps which leads to higher hardware utilization. This is true on all hardware, not just RDNA.

This is where I think the simple vs complex distinction comes in. Clearly if you have a very complex renderer then one uber shader would be a nightmare to code & debug as well as being less flexible. But for simpler renderers the trade-off could be worth it.

That's why inline is perfect for simple passes like shadows.

 

Try reading the developer responses following his post and tell me if you're still not colored-blind.

 

There is nothing implying anywhere that "DXR 1.0 is deprecated", for AMD or any other vendor, as well as that 1.1 is a "fast path" for AMD RT. 1.1 is an extension of 1.0 with additional options which may provide more efficiency depending on where and how they are used. It's very possible that some h/w will be more efficient doing things through 1.1 in the same place where the other h/w will be more efficient with 1.0 - but it may as be the opposite for the same respective h/w in some other case.

It's basically impossible to say something like what he has said before seeing this h/w in action on your own code.