Like another user has commented, the PS4 low level API is like Assembly in terms of hardware control, whereas the higher level, is is similar to Vulkan in API surface, is a bit more like C in terms of control.
Another area where the PS4 APIs are better is infrastructure, meaning graphical debuggers, libraries and OS integration.
Also the amount of production code experience that both Sony and licensed developers have with the whole stack.
So why would Sony throw all this away, just to make some Reddit and HN users happy, that wouldn't anyway make games for the PS4?
And as I've argued here, that isn't a plus. I don't believe that game developers are producing better GPU assembly than an optimizing backend can.
> Another area where the PS4 APIs are better is infrastructure, meaning graphical debuggers, libraries and OS integration.
That isn't part of the API. That's part of the tooling.
> Also the amount of production code experience that both Sony and licensed developers have with the whole stack.
That isn't part of the API either.
> So why would Sony throw all this away, just to make some Reddit and HN users happy, that wouldn't anyway make games for the PS4?
Er, nobody is talking about "throwing all of this away". I'm simply questioning your claim that Vulkan is worse than what Sony created for the PS4.
They won't have to discard their API - they can support Vulkan and their current API and make everyone happy. In this case 'everyone' includes people who would like to port their Vulkan games to PSNext as well as Vulkan-based graphics/game engines.
I am not sure how. I do not use Vulkan, I use GNM. I asked this because implementing SRT does not seem possible in a platform independent API. So I checked the docs again and the descriptor layout is the same thing I remember - a set of bindings you manage through a bunch of API calls. On the other hand SRT is a plain c-structure. You pass a pointer to structure to a shader as a parameter. Exactly as same as you pass a structure to a function in C/C++. You don't need APIs to create sturctures, you can store them in a file, you can write them from another shader etc. etc.
> It is unclear to me what exactly DispatchDraw is for, because back-face and offscreen culling are standard features of any graphics pipeline.
It's pretty clear what is it for if you actually wrote real-time graphics. JFYI - it's "index shader" essentially. Having control over indices you can implement much faster culling.
This sounds like indirect draw, which has been standard for years and is supported by Vulkan.
You combine it with a Compute Shader to create the indices. Indirect draw is how you make those indices available to the drawing functionality.
The presentation is from 2014, so when they claim "better than DirectX", they're referring to pre-DX12. It certainly doesn't back up your claim that it's "much better" than Vulkan.