DirectX 12 is Windows only and Metal is iOS/macOs only.
Hopefully we'll get a standard API for graphics one day. Lack of it is holding us back.
Maybe Vulkan can be the TCP of graphics APIs. Something that provides stable foundations for building fancy graphics stacks on top.
That is kind of the point of Vulcan.
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.
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.
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.
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.
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.
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.
I suspect that'll change. Sony and Microsoft are both using more or less standard AMD GPUs, and game (engine) developers will demand it.
AAA studios are doing quite fine with the current API that are even lower than Vulkan.
Indies with FOSS background seem to have a hard time to grasp how the games industry works in terms of IP, technology stacks and outsourcing for platform ports.
> No, indies will demand it.
> AAA studios are doing quite fine with the current API that are even lower than Vulkan.
Meaning of "AAA" is totally mixed up, so there is no point to use this term without explaining what you mean. Indie might mean independent indeed, but what AAA stands for is completely ambiguous. You might mean projects with big budgets, but they can be independent as well (Star Citizen), so you can't use it as some universal category. For the reference Star Citizen is going to use Vulkan.
Regardless of what "AAA" is supposed to mean, they will use whatever will cut their costs to do the job well enough. And cross platform options surely will, if they'll be available.
It makes me think of a big budget game made by a company that makes big budget games and primarily publishes them through mainstream channels. It makes me think "opposite of Indie". I don't think that there's an indisputable, unambiguous definition of either term.
Yes, when they have a choice and resources. It's not even the case here. I.e. it's not like developers simply prefer lock-in when dealing with some of the walled garden platforms. They simply have no choice - the likes of MS, Sony and others don't leave them that choice. It's not a discussion on technical merits. You could use your logic if developers could actually choose.
And if you don't have resources to ask/communicate than just use something like https://github.com/bkaradzic/bgfx/ which is an awesome API agnostic rendering library.
What would be the point for them to use the benefit of cross platform API, if they need to write their own? It won't be any cheaper than using the existing lock-in.
What's big and bulky - shaders themselves, but there are solutions to translate them between different available languages.
Those solutions aren't really ready yet: https://github.com/KhronosGroup/glslang/issues/200
Yes, that's what I meant too. It's not ready (translation to SPIR-V from HLSL). GLSL → SPIR-V should be in better shape.
Vulkan is mostly certainly cross-platform and it's only Apple stopping it from being available on their closed platform.
Or maybe they're just focusing on the Metal -implementation, and iOS more specifically.
Currently the OpenGL stack is years behind on OS X compared to Windows or Linux, Os X supports only version 4.1 (released in 2010) with some 4.2 extensions thrown in.
I've yet to come across a good reason. If somebody knows, would be nice to know also.
It's not a good reason, but a reason nevertheless: it's fair to say Apple likes to lock in developers to its platform[1]. Encouraging the use of Metal and discouraging OpenGL increases the lock-in effect.
1. My Google skills are failing me, but a few years ago there was a blog-post by an app developer who used to get lots of support from Apple while their featured app was iOS-exclusive. The day the app was ported it to Android, Apple stopped responding to their queries.
I would scratch the fully, it's not on iOS or macOS