Vulkan could very well be a different story, it doesn't have OpenGL's shortcomings.
If it's available, it'll certainly be a tempting target for those who have lower budget and those who need to port it faster.
http://develop.scee.net/wp-content/uploads/2014/11/ParisGC20...
Starts on slide 32 for the graphics part.
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.
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.
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?
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.
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.
With the PS4 hardware is locked so their API is more like assembly (or maybe inline assembly in a C program) where you're doing specific hardware operations.
They also provide a second graphics API that wraps that one, working basically at the same level as Direct3D 11 or OpenGL.
This article might be of interest: http://www.eurogamer.net/articles/digitalfoundry-inside-play...
Consoles had a distinct need for assembly like level APIs - their hardware had very long update cycle (7+ years), so it used to quickly become outdated, and developers had to go to insane lengths to squeeze performance out of it. It's not only very costly to do it, it can't be reused (it's all platform specific). Currently consoles are moving away from these long cycles (under competitive pressure), so need for that will be less as well.
The same concept applies to Vulkan / DX12. The hardware manufacturers will know better than any developers about per-device shortcuts to put into their drivers, and if they do not need to maintain millions of LOCs of OpenGL state machine and validation layers they might find time to optimize the shader compiler to be in the same class of "the compiler is smarter than you" reasons not to use a hard ASM language.
In the case of consoles, all of them are using AMD based graphics, and when the next generation comes out they will all be on a similar cadence of GCN. I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM.
Good point. Today not to provide Vulkan on consoles is a political diversion (to make cross platform development more costly by taxing developers with doing the same thing multiple times).
I agree. In fact, the fact that it's not even a good idea in most situations to write in assembly on x86 CPUs proves the point even more. GPUs are less willing to spend die space on things like sophisticated branch prediction, complex superscalar architectures, register renaming, and so forth. This effectively means that GPUs punish naive codegen (which is the kind of codegen that humans without in-depth knowledge of the architecture tend to produce with their brains) significantly worse than x86 CPUs do. For an extreme example, look at the vector part of the low-power VideoCore IV architecture [1]: compared to a compiler, I don't trust myself for a second to program this optimally.
[1]: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
It's like saying that assembly is better than higher level languages. So propose writing everything in assembly as the next step? Everything has its trade-offs.
Hacker folklore: http://www.catb.org/jargon/html/story-of-mel.html
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.
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.
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.
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
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.
That is kind of the point of Vulcan.