That's true, you can force scalarization like that, but that requires you to know that trick which not everyone knows. I only learned this recently

By default would be a performance degradation on some vendors, you wouldn't want that. That's why they opted for it. But I think it'd have been better if instead of the value deciding it, there would be a function loading from the array (e.g. myDescriptors.nonUniform(123))

(Also, just in case it seems like the raytracing pipelines are redundant or removing them would only cause 30% perf decrease on amd; the more divergent your shaders and resources, the more it impacts. I've seen it get 3x-12x slower because of it)

There's also a little typo in
```cpp
while (running)
`
```
Guessing it should be a curly

Other than that a lot of valid points and important stuff that needs to be fixed definitely and doesn't touch on the mess that shaders are right now which would make this even longer :^) good stuff

(www.evolvebenchmark.com/blog-posts/i...)

No2 They patched this tho, but in the classic vulkan way where it's not always available :^) so you need a fallback if it's not available

No1 One thing that is important is that the RT pipelines as they are today do allow more efficient scheduling, something hard to do with inline RT (though maybe not entirely impossible). Which we couldn't have with intrinsics only. I've seen this matter a lot on AMD and ofc on Lovelace with SER

Also a few inaccuracies:
Some notes on the following (1/N):
> We recently got more intrinsics: .. I am hoping that this is the new direction...

> However, there’s a design flaw in Vulkan: You have to create your texture/buffer object first. Then you can ask .. compatible with the new resource..

They used gigi as a way to prototype and said thanks