We don't really have enough experience to compare GPU assembly vs. SPIR-V. For pjmlp's claim that the PS4 API is "much better" than Vulkan to hold up, as far as I can tell you'd have to show that the codegen (i.e. passes after IR-level optimizations) of the driver's SPIR-V compiler can't match what game developers regularly do. I'm doubtful (instruction scheduling, for example, is too much to keep in your head to regularly beat a compiler), and especially so without data.

As I replied on another comment, besides the lower level control of pushing pixels around, there is the whole tooling part and OS integration.

Vulkan like OpenGL is leaving to the developers the effort to bring their own math library, OS integration and graphical debuggers.

For the rest most of it is hidden behind NDA walls, so you need to sign one to see the codegen examples.

Leaving math library and OS integration to developers is a good thing. Mandating them is already too limiting.

Graphical debuggers on the other hand are useful indeed. LunarG stopped working on Glave: https://github.com/LunarG/VulkanTools/commit/87220f80a643860...

Not sure what happened there. Valve were sponsoring Glave development.

Renderdoc is active (not Linux UI yet however): https://github.com/baldurk/renderdoc

> As I replied on another comment, besides the lower level control of pushing pixels around

I haven't seen any "lower level control" here, except assembly vs. SPIR-V.

> Vulkan like OpenGL is leaving to the developers the effort to bring their own math library, OS integration and graphical debuggers.

A math library is trivial (and it seems odd that you would claim that not having a math library is a significant downside when your entire premise is "low level, minimalist APIs are better"). "OS integration" and "graphical debuggers" are not part of the API.

> For the rest most of it is hidden behind NDA walls, so you need to sign one to see the codegen examples.

Given that none of the presentation you linked was relevant (it was comparing against pre-DX12, not Vulkan), I doubt that signing an NDA would show me anything more.

What I've been repeatedly asking for is the specific technical advantage that the PS4 API has over Vulkan—in other words, what did Sony do right that Khronos did wrong? I'm interested from the perspective of a compiler writer and a graphics programmer. I haven't heard anything, and at this point I'm inclined to believe that no such thing exists.

I'm also doubtful that developers can regularly beat optimizing compiler by a big margin. It's theoretically possible, but I'd expect it to be far from trivial, and as result require substantial effort every time it's needed.

Hacker folklore: http://www.catb.org/jargon/html/story-of-mel.html

I disagree. I regularly stomp all over the optimizing compiler, and it's not a massive amount of effort. It doesn't come for free though, and requires some upfront planning. The best way to think of it, IMHO is rather than thinking of "beating the compiler", think about working _with_ the compiler to help it do it's job.

I don't always agree with what he says, but Mike Acton has some good words and examples of this. https://www.youtube.com/watch?v=GPpD4BBtA1Y - a youtube talk where he talks about working with the compiler. The slides are at http://www.slideshare.net/cellperformance/gdc15-code-clinic In particular take a look at slide 69 and the few following it for an example of things the compiler can't figure out (for various reasons) that we can help it along with.

That presentation is talking about IR-level optimizations, not codegen-level optimizations. Remember that SPIR-V is an IR, so you are free to manually do IR-level optimizations to your heart's content just as you can on the PS4.

Where IR-level optimizations are concerned, I agree that you can often do in areas like aliasing (where you, the programmer, have more knowledge than a compiler can easily prove). I'm much less convinced that you can beat a compiler at codegen-level optimizations: instruction scheduling, isel, register allocation, etc.

As I said, it should be possible in theory. It boils down to details. I.e. how good the compiler is and how hard is to do better than automatic optimization for given hardware. It's not a uniform yes / no situation.