Is the current DXR situation similar to DX12 situation from before?
I never used DX11, but i remember the whining about draw call costs with OpenGL. People complained and tried all kinds of hacks to get improvements. The API evolved multiple times, some legacy staff was deprecated, but the problem never was really solved.
Now it is solved, but only with Vulkan. It added support for prerecorded command buffers, which combined with indirect draw calls allows proper GPU driven rendering. So, in the extreme case, whole graphics engine with one draw call.
It also added support to generate multiple command buffers using multiple CPU threads in parallel, while former OpenGL only gave gfx context to one thread, and the others could not help with turning API commands into actual GPU commands, preparing pipelines, etc.
Just like DX12 Vulkan originated from Mantle. We could discuss some details, e.g. it's said that DX12 way of barriers suits AMD HW better, while Vulkan more follows NV HW. I'm not sure about this. The difference seems, DX12 has split memory barriers. In a first step, you say there is going to come a sync point on resources X and Y, then you may dispatch unrelated work, then comes the second part of the barrier which enforces the sync right before you actually need to co continue work on synchronized data. Makes perfect sense, because the driver could optimize with flushing caches earlier, so work is already done when the barrier is enforced.
But Vulkan lacks this split feature. There is just one piece barrier. Still, the driver could eventually analyze to command buffer to figure the potential optimization out.
So i'm not sure if this barrier example really indicates any vendor preferences. But it's the only interesting 'NV vs. AMD' related example i came across.
We could also discuss how many devs have issues with complexity of low level APIs, which i can confirm to be true. I did only work out the bare minimum of Vulkan rendering so i can display GUI and simple visualizations, but the complexity is at least 10 times that of former OpenGL. There is more uncertainty, more to read and learn, more to forget after that.
It's a burden. But the speedup is worth it. I got a speedup of twofor my compute stuff, so i don't take complaints about complexity as an indication of an actual problem. Rather it seems the devs just whine about the necessary extra work to confirm each other they are not alone. Considering number of engine devs shrinks, that's not really a problem increasing costs, nor can it be the reason many AAA studios switch over to UE.
Some struggle with low level, others achieve great speedups and are happy. Mostly it's both of it in that order. That's expected, not a problem.
I remember you seemingly dislike low level APIs, as you often point out devs complaining, or early ports of engines gave no benefits, etc.
But no. Low level is the way to go if we want to push the HW. That's the goal, and it works much better that it did with high level APIs.
If you still disagree, what you want to discuss is actually adding RT support to DX11 and OpenGL? Imo this should be done indeed.
Now, i often say DXR is not low level, and should have been added to DX11 instead, due to lack of flexibility.
But that's more sarcasm and rant than meant seriously. I do not complain about how DXR works, i only complain about what it is missing: Access to BVH.
Otherwise it does not look bad to me. And since we have both options regarding inline tracing / ray query or abstract shader stages, i do not see the preference towards NV as
@Lurkmass may have meant. But he has to clarify this himself, if he's still willing. I can't comment on his quoted details about static descriptors.
I only think that API complexity makes it hard for IHVs to work out the drivers. And i also think that the convenience exposed to devs, e.g. depicting recursion as a standard pattern, is neither meaningful nor helpful for games.
So the complexity is not really worth it, and surely a reason why we may need a new API earlier than expected, because iterating the current may at some point no longer work out well.
An API should be about simple concepts first, but not about ease of use first. But i don't complain about this. My own request is not about the traceRay function at all, and necessary extensions are tangent to what already exists.
That just said to give some feedback. I think it's not really clear yet what you want to discuss.
wth?-. Too bad it didn't translate into more DX12 usage from developers. Curiously enough, this past november, the mythical creature, the GTX 1060 got surpassed as the most used GPU in Steam by the GTX 1650. Tbh I didn't check but I wonder whether the GTX 1650 is more powerful than the GTX 1060 or not.