DirectX Developer Day 2020

[Lurkmass]

That's funny considering that official MS recommendation is to use 1.0 capabilities (which are a part of 1.1 now btw so saying that 1.0 is "crap" means that 1.1 is also "crap" in like 90% or so) when you're actually doing a lot of RT and use inline trace ray when you're doing just a little of it.

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:

The basic assumption is that scenarios with many complex shaders will run better with dynamic-shader-based raytracing. As opposed to using massive inline raytracing uber-shaders. And scenarios that would use a very minimal shading complexity and/or very few shaders might run better with inline raytracing.

Where to draw the line between the two isn’t obvious in the face of varying implementations. Furthermore, this basic framing of extremes doesn’t capture all factors that may be important, such as the impact of ray coherence. Developers need to test real content to find the right balance among tools, of which inline raytracing is simply one.

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.

 

[DegustatoR]

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?

 

[Lurkmass]

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.

 

[willardjuice]

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.

 

[pharma]

I bet console games will only use the "1.1 technique".

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.

When to use inline raytracing
Inline raytracing can be useful for many reasons:

• Perhaps the developer knows their scenario is simple enough that the overhead of dynamic shader scheduling is not worthwhile. For example, a well constrained way of calculating shadows.

• It could be convenient/efficient to query an acceleration structure from a shader that doesn’t support dynamic-shader-based rays. Like a compute shader or pixel shader.

• It might be helpful to combine dynamic-shader-based raytracing with the inline form. Some raytracing shader stages, like intersection shaders and any hit shaders, don’t even support tracing rays via dynamic-shader-based raytracing. But the inline form is available everywhere.

• Another combination is to switch to the inline form for simple recursive rays. This enables the app to declare there is no recursion for the underlying raytracing pipeline, given inline raytracing is handling recursive rays. The simpler dynamic scheduling burden on the system can yield better efficiency.

Scenarios with many complex shaders will run better with dynamic-shader-based raytracing, as opposed to using massive inline raytracing uber-shaders. Meanwhile, scenarios that have a minimal shading complexity and/or very few shaders will run better with inline raytracing.

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

 

[Lurkmass]

But to suggest dxr 1.0 is "wrong" or "slower" is just inaccurate.

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.

 

[pharma]

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.

 

[Lurkmass]

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.

 

[DavidGraham]

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 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.

 

[Lurkmass]

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.

 

[JoeJ]

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.

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.

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.

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.

 

[DegustatoR]

Lol, defense mechanism triggered much ?

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

 

[Kaotik]

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

His first post was neutral, someone thought it said something it really didn't and it started rolling from there both "sides" getting more defensive post by post. Could you all now stop bickering and move on?

 

[trinibwoy]

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.

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?

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.

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.

 

[DegustatoR]

His first post was neutral, someone thought it said something it really didn't and it started rolling from there both "sides" getting more defensive post by post. Could you all now stop bickering and move on?

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

Treat the practices from DXR Tier 1.0 as being effectively 'deprecated'.

Under a video which has this slide in it:

 

[pharma]

His first post was neutral, someone thought it said something it really didn't and it started rolling from there both "sides" getting more defensive post by post. Could you all now stop bickering and move on?

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

Treat the practices from DXR Tier 1.0 as being effectively 'deprecated'.

 

[trinibwoy]

AMD is trying to encourage developers to use as little shaders as possible in their RT implementation to use the inline DX1.1 features. Most likely because otherwise RT will be slower on AMD hardware. Maybe significantly slower as well. I guess it will depend on the nature of the game and the required achieved look, some games will do fine with minimalistic shader approaches, some simply don't.

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.

 

[Kaotik]

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

He mentioned several times he's talking about AMD there. The same post also mentions he has no idea if said "fast path for AMD" has any relevance for NVIDIA or if they even need such "fast path". How is that downplaying or praising either camp? I'm not the colorblind in this conversation.

 

[pharma]

He mentioned several times he's talking about AMD there. The same post also mentions he has no idea if said "fast path for AMD" has any relevance for NVIDIA or if they even need such "fast path". How is that downplaying or praising either camp? I'm not the colorblind in this conversation.

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

 

[DegustatoR]

He mentioned several times he's talking about AMD there. The same post also mentions he has no idea if said "fast path for AMD" has any relevance for NVIDIA or if they even need such "fast path". How is that downplaying or praising either camp? I'm not the colorblind in this conversation.

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.