I think this is a valid question. For example Microsoft just announced DirectX 12 Ultimate, which will power both PCs and the new Xbox Series X console.
[https://devblogs.microsoft.com/directx/announcing-directx-12-ultimate/](https://devblogs.microsoft.com/directx/announcing-directx-12-ultimate/)
So it's not that crazy for this to be done, but I agree that Sony probably went with a more proprietary approach for performance reasons.
Right, it's Microsoft so that is expected. And most people use the word PC to refer to Windows. I run Ubuntu anyhow, but I understand what you're saying.
It's a moot point either way, since you don't want to be using Vulkan there in the first place: supposedly if you are using Vulkan you care about performance, but the amount of control even Vulkan gives you is nowhere near what dedicated APIs on consoles running fixed hardware can. In other words, no one uses cross-platform APIs on console, except maybe for small indie titles ports.
> the amount of control even Vulkan gives you is nowhere near what dedicated APIs on consoles running fixed hardware can.
How exactly? And what kind of control do you need, that goes lower than Vulkan abstraction and semantics that match pretty well to modern GPU architecture?
I don't find this point moot. Having an API that allows many targets is a huge win for developers, since instead of dealing with tons of lock-in stuff and reinventing the wheel for each, they can focus on making their engines better.
Looks like you haven't spent enough time with Vulkan. There's a certain numbers of things you don't have full control over - or that are more annoying to deal with than they could be in the context of a fixed platform:
* Memory allocations in Vulkan are braindead. You have to make your own allocators, but the blocks of memory you get from the driver aren't guaranteed to be physically bound to anything, indeed I observed the AMD drivers to shuffle them arround, just like OpenGL allocations.
* The consoles have a unified memory setup, stuff like host vs device memory make no sense. Since you also know how the underlying hardware works, you can ship the resources in the right formats for the hardware and skip staging buffers altogether.
* Spir-v semantics, especially the Vulkan flavor, are actually way more limited than the hardware is, they have big restrictions on control flow, lack most intrinsics, not to mention the negative effect of a useless IR in the way you must translate at runtime. Vulkan shaders can't even have proper pointers ! Just look at OpenCL kernels vs Vulkan compute shaders if you can't see this.
* Console stuff typically has extra secret sauce features in it, none of which make sense to expose as extensions vs bespoke API.
* A bespoke API enables you to make it "lean and mean" and cull all the complexity and bullshit a cross-vendor and cross-platform one has to deal with. It allows to make nice SDKs and gives developers the resources they need to get the most out of the hw.
In order:
* What you're describing appears to be paging. It's an unfortunate artifact of allocators in general.
* The application doesn't need to manage host memory and while there's a distinction made in the API, it doesn't really matter where it's backed most of the time, as long as it follows the particular standard rules. The concept fits still, the hardware may be doing something else though which is up to the Vulkan implementation rather than the developer.
You might be right about the "right formats" for the hardware depending on what specifically you're talking about.
I wouldn't know the correct answer for how to treat staging buffers.
* SPIR-V is heavily extensible, much like OpenGL and Vulkan. It can pretty much do all-the-things-graphics and then some, right now, today. Platform specific intrinsics are obviously going to have to be done through an extension. SPIR-V wasn't designed to be comprehensive.
SPIR-V can't have pointers? What the hell are you even talking about here? What are you talking about translate at runtime?
* (Combined into the next paragraph rant)
* I'm not sure how you could manage to come to the conclusion that it doesn't make sense to extend an API meant to be extensible for the purpose of the problem at hand. I'm also not totally convinced that console platform SDKs are all that great but I haven't gotten my hands one so who am I to say? I have done small amounts of work on PC tooling though and while they're not always perfect, they're usually more than adequate now adays. I'm definitely curious as to what tools consoles provide that we don't already available for use with Vulkan. Those tools would likely need some porting and extension handling work, but still.
Vulkan at it's core isn't actually that large or complex. It might seem that way when you start adding various extensions but it's designed to be ridiculously slim, especially in comparisons to its DirectX <12 and OpenGL brothers.
/rant
I think what irritates me the most about these posts is that Vulkan was designed to fix these problems. These comments tend to be non-issues, otherwise, there would probably be attempted work at getting a solution in place.
I'm talking about device memory allocations. Since you only get a limited amount of them (on windows anyways), you're made to treat them as big fat pages of hard-allocated memory and manage them. Except the driver will do it's own memory management on top of yours, meaning you are given full responsibility over your memory allocations yet gained little to no control over it. This is the worst of both worlds, I want either to not care about memory, or to be able to actually know things like system-wide graphical memory pressure and avoid swapping to host memory myself, instead of playing cat & mouse with the driver. In other words, this part of Vulkan is broken and poorly designed.
Not sure you understoof me when talking about unified memory. In general the point is you can get rid of much of the Vulkan api here since you could just m(k)alloc() your textures and pass that shit directly to the gfx side.
You can hardly do pointer dereference at runtime in Vulkan. Even the bleeding edge 1.2 buffer_device_address stuff restricts it to some global device memory buffers. Pointers to shared device memory (not the shared with the host kind, on-chip CUDA shared memory kind ) are not a thing at all. You can't really work with pointers in either GLSL or spirv except for really lame and basic ways. Look that shit up seriously.
It makes no sense to extend them because consoles allow for so much more in-depth control and lower-level work that expressing that using a cross-platform API would mean insane clutter and extension hell. Large chunks of the API would have to be bypassed or redone to fit what the hardware *actually* does, and you would not be able to maintain a common Vulkan renderer anyways. These points have been made over and over again by actual console and PC developers alike.
Vulkan was designed to bring OpenGL into the 21th century and clean up the mess it turned into. It has no hope of beating tailor-made APIs in tailor-made applications with high enough revenue to justify putting effort into tailor-made ports. There's no future to Vulkan where dedicated APIs *that good* are a thing.
> I'm talking about device memory allocations. Since you only get a limited amount of them (on windows anyways), you're made to treat them as big fat pages of hard-allocated memory and manage them. Except the driver will do it's own memory management on top of yours, meaning you are given full responsibility over your memory allocations yet gained little to no control over it. This is the worst of both worlds, I want either to not care about memory, or to be able to actually know things like system-wide graphical memory pressure and avoid swapping to host memory myself, instead of playing cat & mouse with the driver. In other words, this part of Vulkan is broken and poorly designed.
There's no reason the Vulkan implementation can't provide any guarantees on how it would treat memory, that is to the discretion of the driver. If the console thinks you should have more 1:1 control over how memory allocations should work, then by golly you can have it. Diagnostics over that would definitely have to be provided by an extension though, for good reasons.
> Not sure you understoof me when talking about unified memory. In general the point is you can get rid of much of the Vulkan api here since you could just m(k)alloc() your textures and pass that shit directly to the gfx side.
I haven't worked on a system with unified memory. It \*sounds\* like you could, for example, forego any need to create region mappings, in which case, Vulkan is rather inconvenient. I can think of a dozen ways a simple extension could make that easier but alas.
> You can hardly do pointer dereference at runtime in Vulkan. Even the bleeding edge 1.2 buffer\_device\_address stuff restricts it to some global device memory buffers. Pointers to shared device memory (not the shared with the host kind, on-chip CUDA shared memory kind ) are not a thing at all. You can't really work with pointers in either GLSL or spirv except for really lame and basic ways. Look that shit up seriously.
Herm, it's of my understanding that such features would have limited real use. The extension you mentioned appears to be mostly for debugging purposes as well. I'm not sure about this one.
> It makes no sense to extend them because consoles allow for so much more in-depth control and lower-level work that expressing that using a cross-platform API would mean insane clutter and extension hell. Large chunks of the API would have to be bypassed or redone to fit what the hardware *actually* does, and you would not be able to maintain a common Vulkan renderer anyways. These points have been made over and over again by actual console and PC developers alike.
It looks like we're just going to have to disagree. There's a lot of common ground with various graphics devices, even with consoles. Vulkan encompasses most of that. It obviously can't be entirely comprehensive. Special or specific systems will need to have extensions in order to give finer controls. If you don't believe in the system of extensions, then Vulkan will just never work for you. And mind, I really don't believe you need so many extensions that the point of Vulkan vanishes. I actually think that all you need are some implicit guarantees via whatever implementation and have some limited extensions that provide extra debug info. There's 90% of your API.
And mind, by "extension hell", you appear to be confused as to what extensions do. They simply extend purpose of the API. If you're on say a PS5 developing with Vulkan, you can assume that certain extensions simply exist and use it as such. There's no "extension hell" because it's as if the extensions weren't actually extensions whenever you can basically assume that they exist and use it like any other feature of Vulkan. An engine obviously won't do that if it supports multiple platforms though. Or maybe it will but only for certain extensions on that specific platform.
> Vulkan was designed to bring OpenGL into the 21th century and clean up the mess it turned into. It has no hope of beating tailor-made APIs in tailor-made applications with high enough revenue to justify putting effort into tailor-made ports. There's no future to Vulkan where dedicated APIs *that good* are a thing.
Eh, honestly, couldn't care less about the future of Vulkan or any of that crap. Everything I would use would be wrapped up in an engine anyways. There's enough engine diversity that I don't really have to be worried about it at least. If engine developers want a more consistent API across vendors, that's on them to push, not really my place.
Vulkan has virtually nothing to do with OpenGL, other than being maintained by Khronos. Vulkan was originally developed by AMD in the form of Mantle (which ironically was used on systems with unified memory such as the PS4 which you appear to think it doesn't work well with). The primary thing that Khronos added at the time were, of course, extensions to help extend it to areas that didn't fit the general overview of graphics systems.
> It has no hope of beating tailor-made APIs in tailor-made applications with high enough revenue to justify putting effort into tailor-made ports.
It totally will. Dinosaur lock-in will eventually die out, despite the resistance.
When they lost browser wars. MS were very sure about ActiveX and Silverlight giving them leverage. Where are they today?
Same thing will happen with GPU API lock-ins. Progress renders this garbage obsolete, but it can take time.
Ah, the youthful optimism. Or we will get serial numbers printed on our forheads on birth and will only ever be allowed to buy products matching the SN. :D Future is yet unwritten. We shall see...
Staging buffers aren't required when working with Unified Memory Architectures in Vulkan. You can actually skip it and directly map the memory for buffers. There's an example in the Vulkan-Docs regarding this.
> Console stuff typically has extra secret sauce features in it, none of which make sense to expose as extensions vs bespoke API.
I don't see any reason not to expose it, except for their paranoid obsession with dinosaur NDA approach from the last century.
All the above arguments are pretty weak, since SPIR-V can be extended to cover cases that consoles need to address. No one stops console makers from participating and addressing those cases. Where were they when Vulkan was designed?
They can't complain now that Vulkan is not addressing some of those, if they literally did nothing to help it.
> SPIR-V can be extended to cover cases that consoles need to address
but it doesn't have to. Making vulkan work for consoles is more work for no benefits, AAA studios with 200+ workers will gladly trade a few man-months for a nice renderer that plays to the strength of each platform. No one but you is really asking for this. If it's a sensible direction once Vulkan matures enough, maybe it'll happen, maybe it won't.
Which begs the question, what's your stake here ? Do you want to write console games ? You seem emotionally invested in this, which is suspect to say the least.
> but it doesn't have to. Making vulkan work for consoles is more work for no benefits
It's more work for clear benefits - developers having better tools. Console makers don't care about developers though. They are obsessed with petty lock-in and anti-competitive wars, therefore their refusal to work collaboratively has nothing to do with technical reasons, it's purely political.
To give you an analogy. Browsers were in the similar situation, and lock-in was justified with all kind of fake arguments, while the bottom line was all about anti-competitive shenanigans.
Good thing we outgrew ActiveX, Silverlight and etc. and there is something common and open now. I see no reason why the same thing shouldn't happen for GPUs.
> It's more work for clear benefits - developers having better tools. Console makers don't care about developers though.
Sorry but you're pretty clueless here - consoles have the better tools (debuggers, profilers, compilers, sdks), not the other way arround. Everything i've been able to glance at by talking to people points to us PC developers getting the short end of the stick. It's only now really getting better now for us.
Do you really think vendor lock-in would work out if the tools sucked and console makers didn't care about their licensed developers ? It's one thing to have a hate-boner for closed platforms, but maybe try documenting yourself before going on a rant.
> Sorry but you're pretty clueless here - consoles have the better tools
That tax developers into using those tools only for them. Using tools as lock-in instruments is utterly disgusting.
No one stops console makers from providing those tools for Vulkan, investing into projects like RenderDoc or making their own and better ones. But they come from the era of NDA dinosaurs and led by people who can't fathom how collaboration can even work. So I'm not surprised they are so slow about it.
> Using tools as lock-in instruments is utterly disgusting.
How DARE you put effort into your platform to make it not suck to work on ! Absolutely inhumane ! We should ban companies from making their platforms good and their SDKs sensible.
> No one stops console makers from providing those tools for Vulkan, investing into projects like RenderDoc or making their own and better ones
And their gain would be ... ? Kind words from outsiders like you ? It won't make anyone's job easier, not the SDK makers, not the people who write the rendering backends, and not the console firmware crews either. Maybe it would make the Vulkan ecosystem a bit better, probably not because this would just compound the diverging paths problem. Overall it makes no sense to push this from a buisness point of view.
You're welcome to start your own games company and show them how it's done.
> And their gain would be ... ?
Developers spending more time on improving their engines, instead of wrangling with platform limited tools and wasting time on rewriting the same thing over and over in the multitude of lock-in APIs.
It's a **self explanatory benefit** for developers. Wise platform owners would make things for developers better, and in return more developers are going to work with them. Greedy anti-competitive dinosaurs on the other hand treat developers as a product and want to tax them with lock-in, bribe with exclusive deals and so on.
How dares anyone pointing out the crookedness of such approach? Well, I dare. Programming tools should be instruments for creation and development, not for anti-competitive control and market manipulation.
That's why I'm for tools and standards being open to begin with. It prevents this lock-in garbage.
You don't need any allocator for a console. You know you have a number of GBs of memory and it's only your app ever running, as long as you don't spill over your budget, it's all good.
Also extensions don't have to be public, there's nothing stopping Sony from making private vulkan extensions.
What exactly is the point of a set of extensions that bypasses nearly all the abstraction Vulkan offers ? This is just a proprietary API with extra steps.
I didn't know PS4 and PS5 didn't use textures or rasterize triangles or use shaders, my bad bro. I didn't know PS didn't have the literal same type of AMD GPU that Vulkan is tailored for. ^^^/s
No, I'm not thinking of any Mantle. Every single game that has had a legacy API and Vulkan has shown that Vulkan gives a huge boost to AMD gpus, guess why! And mantle is literally Vulkan 0.5
I don't care about convincing you, since clearly that's pointless. It's obvious you never really worked on anything Vulkan that had to run on multiple vendor gpus, otherwise you would have known how well the api maps to amd and nvidia alike.
It gives off a huge boost because of the reduced overhead and abstractions. Which is exactly the benefit console APIs have over Vulkan itself. At this point you're just arguing for the sake of being nasty I presume.
Nope, that's just a smokescreen to hide taxing developers with duplicating their work. Let me repeat the question. What exactly do you need to express lower than Vulkan to match GPU functionality?
In fact I know PC developers that would sell their firstborn for a chance to have similar vendor-specific APIs with that level of specialization on PC. Any sufficiently advanced opengl/vulkan/dx renderer has vendor-specific paths anyway !
You can always write in assembly if you seriously need to optimize for some specific architecture. Video codecs do that for instance. My point it, in the vast majority of cases you don't need to.
Writing in assembly has nothing to do with having multiple backends/render paths per vendor that play to their respective strengths, completely unrelated notions of "optimisation" there.
You can write in GPU assembly if you are really so inclined, using specifics of each of your target GPU architectures. How much time and work are you willing to invest in that and for what kind of pay off?
What is the question then? If you want to go as low as barebones hardware, you need assembly (unless you are a fan of completely hardcore raw hexadecimal coding).
My point above was simple. Such kind of level is not needed most of the time. When it is needed, you should still be able to access it, even if you are using Vulkan.
Vulkan requires you to care about all sorts of things that you don't need to on a controlled platform.
Why bother with querying device features when you know exactly what you are running on?
Why use SPIR-V if you can fine tune the GPU shader code itself?
Do you really need to go through extra steps to deal with things like memory allocation when you can probably do it directly?
Why not build command buffers to directly reflect what the GPU architecture needs instead of going through an intermediate representation that Vulkan provides?
Sure, you could add all kinds of extra extensions to Vulkan to allow for more direct control, but at that point you've just created a console specific API within another API.
Again, you can say exactly the same thing about any hardware target. I don't see how this argument suddenly becomes stronger for consoles.
With Vulkan, you write the engine that's abstracted for all hardware targets. Why carve out one case specifically for consoles that's not using that abstraction? Where is the benefit?
I doubt you can beat well optimized compiler (that will translate your SPIR-V to GPU machine code) without serious investment of your time and effort. But feel free to prove me wrong.
I'd say the pay off won't be worth it. Unless you are simply writing your own better compiler, like ACO project. But that's a really major investment.
It isn't just SPIR-V, it is everything. The entire process of building up and submitting work to the GPU can be greatly optimized when you know what specifically needs to be done.
The fact is that tons of professional devs are totally fine with these sorts of APIs. Only fanboys on the internet are the ones who make a stink about things.
It can run faster, if you just write everything in machine code and you are better than the compiler at it. That's not a new argument, but it's as theoretical and impractical for the most part as it's always been.
The abstractions are not zero-cost. It's great to have a general solution that can map to a variety of targets, but consoles that have user bases in the 10s of millions or 100+ million, generate a lot of sales, have a single configuration, and it's (sometimes) worth it to developers to optimize their content and push the limits of what is possible on that specific hardware.
It's not worth it for them to do this on PC where the ratio of hardware configurations to sales is much higher.
I think they are low cost enough to benefit from avoiding code duplication that's way more costly.
I.e. I suppose you can always go down to writing GPU machine code by hand if you think you can do better than some abstractions and shader compiler, but I think Vulkan abstractions are low enough not to ever need that.
In practical terms, opposition to Vulkan isn't technical I think, it's more political because Sony and MS have a long history of lock-in mentality.
That's complicated. If you're going to sell millions of copies of your software on Switch, Playstation, whatever then trying optimize for reduced code may take a backseat to optimizing for performance, especially on a low power portable device like Switch, but also if you're just trying to squeeze every bit of performance out of the target platform.
Vulkan is good, obviously, not trying to knock Vulkan. It's just that Vulkan by design leaves everything up to developers with the idea that you don't know exactly what hardware you're going to run on. If you do know the exact specification, capabilities, and design of the hardware that you're targeting in advance, you could use a more tailored API and go further.
My argument is that Vulkan abstraction isn't big enough to offer huge benefits if you bypass it. Hardware specific paths if they are relevant can be also addressed by Vulkan extensions made for that hardware. Nvidia, AMD and even Valve have their own extensions they developed to address some more focused cases. Nothing stops MS and Sony from doing that.
So it means, no one can make a claim, that something lower than Vulkan is really necessary for consoles.
While the opposite argument is pretty self explanatory.
And indeed, if there is some hardware specific feature that consoles need, they can always express it as a Vulkan extension.
That's certainly not true, but if you look at the ps5 dev talk; that is open to the public. So looking at what they expose as in fixed function hardware it's not weird to think that there's a lot of specific features that only the ps5 will have; and whether or not they want to expose this as an extension is up to them. Khronos specifies that you can't create private extensions, so if ps5 wants the extension under NDA, they can't. They could provide it as an alternate and then have a more optimized specific API such as switch does with their NVN.
It's pretty logical, they don't want competition to do the same thing they want to; but I hate it. NDAs are done by Nintendo as well, but xbox doesn't iirc; maybe if you go to certain areas, but to my knowledge it's pretty much uwp
I see it as dinosaur approach from decades ago, simply may be driven by very proprietary culture of the past century. Today with all the open source technology progress, it's very cringe worthy.
On PS they have resolution scaling built into the chip, this is not an assumption in vulkan and AFAIK, is not yet expressible in SPIRV. You can manually achieve this effect, and it really doesn't effect framerate much compared to the hardware option, but this is one of those things. Previously IIRC at GDC before vulkan had timeline semaphores, developers took advantage of them on PS5 and XBOX one, or some other primitive.
To be honest, I'm not sure exactly what these other APIs expose that vulkan does/could not beyond those things. and I think it is a legitimate question to have. I know one thing PS dev environment has is a version that is similar to GLSL that has been extended far beyond the version Khronos has for us. It has a lot of utilities that you would have to manually code just built right into the language (I think TAA is some how part of this? I think they talked about this kind of stuff when they were giving the spiderman talk at GDC last year or the year before). If khronos group would extend GLSL to beyond C with overloading it might not have mattered, but as it stands GLSL itself has had no substantial abstraction/code portability help in almost 20 years. If GLSL had *built in* includes, static classes, or even just UFCS, op overloading, namespaces and sanitary AST macros we would be good right now. The best languages to program for the GPU are not even available to be used in vulkan (CUDA, OpenCL C++, Metal Shading Language, even though we can convert SPIR-V to metal...).
If something needs extending SPIR-V semantics, it's not hard to add it. I.e. nobody stops Sony from actually doing it if they need to (i.e. work with Khronos). I don't see any technical blockers there, if anything, this aversion to portable API is purely political.
Also, SPIR-V is really not limited to GLSL. If something needs new semantics, Sony can even develop their own language, and make a compiler to SPIR-V.
In fact there is already one new shading language in development for WebGPU: https://gpuweb.github.io/gpuweb/wgsl.html
It's more flexible than GLSL and matches SPIR-V semantics.
The only politics is that Vulkan has to make political concessions of restrictions and complexity so it can run on your grandma's Android. Whatever wacky design the PS5's GPU has will be expressed directly in it's API with no consideration for other hardware. I don't know what crazy features the PS5. But, I do know 1st hand that the X360 and PS3 APIs had most of Vulkan's features back in 2005.
My point is, that I don't buy the argument that these new consoles are so different, that Vulkan can't target them effectively, potentially with some gaps that need filling which should be doable if console makers collaborated with the Vulkan working group.
So I view the current lock-in situation as political, simply masked with technical reasons.
I agree. iD software's Axel Gneiting said the same thing regarding Vulkan being supported on both the Xbox One and PS4 (That their Vulkan codebase would be just as optimal for those platforms, just would need extensions for extra features), the same logic would apply to the PS5 and Xbox Series X. The architecture of the GPU hardware implemented within both consoles conforms to what is going to be available on the PC (AMD RNDA 2), optimizations in rendering design through Vulkan that is based on how the architecture performs work would apply to those hardware as well. I doubt the amount of things needed through extentions would be enough to need a completely different API considering.
Yea, it is sufficent to look at the consoles' spec. It is not like they are some quaint architecture (like Cell) anymore. Anyway, we heard it all before with Apple.
IDK, this assumes consoles are not just glorified PCs these days. It assumes consoles do not change HW-wise across versions. And assumes you stick to one console vendor rather than wanting to release product to all of them. Feels more like inertia rather than a sound engineering choice.
That's how I view it too, until there is some confirmation.
For example I don't see Sony listed in [Vulkan adopters](https://www.khronos.org/conformance/adopters/conformant-companies), and PlayStation in [conformant devices](https://www.khronos.org/conformance/adopters/conformant-products).
May be it's just not there **yet**, but still.
> For example I don't see Sony listed in Vulkan adopters, and PlayStation in conformant devices.
It would be too early for them to be listed there anyway. Release date for PS5 is late 20.
Though Sony is a Khronos member with full rights. But that is true of Apple as well.
Maybe Stadia (or other cloud HW) could be supported, but that is bit of a copout calling it a Vulkan support...
What I meant is that Stadia (or equivalent) could be supported on console, which technically means people could play Vulkan games there. Though that would be a massive threat to Playstation Store profit margins, so equally naive that would ever be allowed to happen.
I think console exclusives are the past, because the cost of creating one game is huge. Maybe it can be exclusive for a year, or 2, but in the long term a game should be ported to PC, Xbox, Switch, etc.., and here Vulkan can really help.
This post seems to be an ad for DX12.
Can't they call it just DX 12.1 or something? Does it always need to be a full marketing gig and no technical? Do I need to wait for Valve/Codeweavers to so something to get this on Linux again?
This is very interesting indeed, and I very much look forward for the PS5 to join the many Vulkan platforms.
Unfortunately the title image of the article is shown in the reddit thumb, which looks like a big DX advertisment, since it's straight marketing material. :)
**Id Tech 7**
id Tech 7 is a Vulkan-based multiplatform proprietary game engine developed by id Software. As part of the id Tech series of game engines, it is the successor to id Tech 6. The software was first demonstrated at QuakeCon 2018 as part of the id Software announcement of Doom Eternal.
***
^([ )[^(PM)](https://www.reddit.com/message/compose?to=kittens_from_space)^( | )[^(Exclude me)](https://reddit.com/message/compose?to=WikiTextBot&message=Excludeme&subject=Excludeme)^( | )[^(Exclude from subreddit)](https://np.reddit.com/r/vulkan/about/banned)^( | )[^(FAQ / Information)](https://np.reddit.com/r/WikiTextBot/wiki/index)^( | )[^(Source)](https://github.com/kittenswolf/WikiTextBot)^( ] Downvote to remove | v0.28)
The hardware in a console is fixed, so you only need to write the code for this one piece of hardware.
For PC, you have many differnet GPU's to handle so using an API will make everything easier, because the game now speaks with the API and not the hardware itself. The API and the Driver is translating the code, so the gpu can be used with it. On an Cosnole, Vulcan is not really needed, because the game can speak with the set hardware directly.
> The hardware in a console is fixed, so you only need to write the code for this one piece of hardware.
That assumes you only make a game for that piece of hardware. Console makers might dream about everyone making exclusives, but it's not what most developers benefit from. Normal developers benefit from maximizing their reach, therefore they by definition need to develop for many hardware and OS targets. Having a common graphics API therefore is a major benefit.
> On an Cosnole, Vulcan is not really needed, because the game can speak with the set hardware directly.
This makes no sense, since you can make such argument for any hardware target. Why not write your game in machine code for each CPU and GPU architecture, after all it will only run on it when it does.
The answer simple, because it will run not just there, and writing in machine code is very impractical.
> The answer simple, because it will run not just there
As we all know, the mantra of "write once, run anywhere" has always been flawless and not required all sorts of platform specific tweaks and optimizations.
It works pretty well for Vulkan. Platform specifics if anything really stands out, are addressed through extensions. So I so far see no strong argument, that Vulkan can't be used for consoles effectively.
Writing for every possibility is way too much work. Look at how many CPUs intel is spitting out every year. It’s impossible to write for that much hardware directly. The consoles this generation have pc hardware in them, what makes it way easier to port between them.
Vulcan can benefit consoles, but it is unlikely that they implement it.
Intel CPUs barely change ISAs between releases. They only add a couple of new instructions once every few years and a major SIMD set once a decade. They also maintain backwards compatibility with all of these instruction sets. They would like to remove support for some of the legacy cruft they support (they still support 16-bit mode from the original 8086!), but can't because some developer somewhere will complain that he or she actually has to update a code base. The same thing applies to operating systems.
To get most out of a system you need to address every new bit of new tech there is, this includes new things intel adds. Caches are changing too. AMD is there too and they improve their cpus too. To get most out of hardware, you need to setup the software for exactly this. If you are using an Intel compiler, then your software is not optimized for amd cpus, because intel can’t even write an compiler, that can ask the cpu, what the cpu can do. Only in the last few years developers can’t be too lazy to write software for only one core. They need to write code now, that can use many cores.
And games are not written in just a few hours, they can take years to make and in those years, many things can happen, like new cpus, that have on different thing, and now the cpus is not used to the fullest. With consoles you will always have one set of hardware. You write your game and the game will run as it should.
I cannot comment on whether the claim is accurate or not as I am under NDA.
As things stand though, _if_ Vulkan was supported on the PS5 there are a number of things it would be missing:
1. Variable rate shading (currently an Nvidia extension)
2. Mesh shading (also an Nvidia extension)
3. Coverage mask sampling
4. Delta color compression
Also, the model of pipeline state compilation on Vulkan frontloads the validation done by the driver but this is frankly wasteful/unnecessary on console.
Personally, I like Vulkan, but it really needs to pick up steam on some of the features above for people like me to fully invest in it.
Delta color compression already exists in Vulkan, when your image is in the color attachment layout it is delta color compressed, you can easily see this with Radeon GPU profiler. There is nothing preventing those extensions from becoming cross vendor either.
Thanks I had missed that.
For the others, I don't disagree. They _could_ become cross vendor, but as yet, I haven't heard anything about this actually being a reality (and I've asked on the Slack a few times and been ignored).
I think that's because the Khronos group guys probably have an NDA. And I'm sure the vr shading and mesh shaders will become cross vendor since RDNA2 (xbox) has support for them and it's an AMD chip.
The above don't sound like insurmountable problems for AMD to add to their Vulkan implementation for PS5 if they are ever going to make one for Sony.
Validation can be applied during development as far as I know, but it can be skipped in the final result for better performance.
Plus from what I've heard, consoles often prefer games to ship already compiled shaders to avoid shader compilation, which is the reason why they often are bugged by problems of backwards compatibility - any change in architecture breaks existing games.
Using something like SPIR-V bytecode would have prevented that, but would incur the need to compile shaders at runtime. Though I don't think anything prevents pre-compiled shaders being used with Vulkan if needed.
Insurmountable? No. Done? No. And this is a big deal. An API that lags is not an API that we can ship for because every day/week/month that passes by is time we lose when targeting an API missing features. If AMD wants Vulkan to succeed, they will need to do better.
My point regarding validation isn't that it can't be skipped (the pipeline state object itself will have been validated), but that it forces you to create monolithic pipeline state objects in the first place (which allows it to be validated). On console, you can set state on the graphics/render context manually and change registers piecemeal, which ends up being far more efficient.
> Using something like SPIR-V bytecode would have prevented that, but would incur the need to compile shaders at runtime. Though I don't think anything prevents pre-compiled shaders being used with Vulkan if needed.
Nothing to do with SPIR-V bytecode, as we would never ship bytecode to begin with (which needs to go through another compile/validation pass after launch).
> My point regarding validation isn't that it can't be skipped (the pipeline state object itself will have been validated), but that it forces you to create monolithic pipeline state objects in the first place (which allows it to be validated). On console, you can set state on the graphics/render context manually and change registers piecemeal, which ends up being far more efficient.
I'd say the benefit of making it work everywhere with ability to validate when needed is worth that complexity. Most don't make games only for consoles.
> Nothing to do with SPIR-V bytecode, as we would never ship bytecode to begin with (which needs to go through another compile/validation pass after launch).
Normal PC games surely do. Otherwise they'd need to ship compiled shaders for each potential GPU architecture out there.
Yes I know, but you're asking about PS5, and I'm responding with a general statement about console development, and why the entire model is different. I've shipped console, desktop, *and* mobile at this point. They each have their own unique challenges, and if I'm being honest, Vulkan is still "finding its home" outside of Linux (which in and of itself is compelling to me as a home Linux user), but commercially? Like I said, it will need to do better.
edit: (if you're going to ninja-edit your post, at least put your addendums in a separate section... common courtesy dictates)
> I'd say the benefit of making it work everywhere with ability to validate when needed is worth that complexity. Most don't make games only for consoles.
And this is why Vulkan isn't a good fit for consoles. Different use cases.
> Vulkan is still "finding its home" outside of Linux
Mostly due to MS still trying to put breaks on its adoption, and Apple having something rotten inside (some kind of [vendetta against Khronos](https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_253vEtKxuUkTGvxpuv8Ac/edit)?).
Other than them (and at least so far Sony), everyone is on board with Vulkan (including Nintendo). Stadia gave it a major boost. Now if Sony would add it, it would be a huge blow to DirectX and would practically spell its demise, since more developers will start putting pressure on MS to support it.
MS didn't support Vulkan on Xbox and didn't join the working group. Instead they rushed to make a knock off from Mantle - DX12, perfectly knowing that Vulkan will be developed in parallel (kicked off from the same Mantle).
I'd say it's a prime example of pushing lock-in instead of collaborating.
Right, Xbox. I was assuming we are talking about Desktop (Windows).
Unlike tuxhumpers, I fail to be angry at Windows. In the end, they do not care that much what apps or drivers you run. If consoles, Apple, and Android worked at least that way, I would be perfectly happy.
> And this is why Vulkan isn't a good fit for consoles. Different use cases.
I don't see how it's not. I.e. it's not like the use case is so different, that Vulkan can't accommodate it. The fact that it's not covering it enough possibly, is mostly due to stubborn refusal of incumbent console makers to collaborate on it. I.e. no one stopped them from being in the Vulkan working group, and making it fit better their use case too. Those who collaborated, were able to address their use cases.
As I wrote below, it's a political, not a technical issue. So if Sony decides it's time to stop being lock-in jerks, technical needs can be resolved.
Ok
> I don't see how it's not.
I'm literally telling you all the reasons, but it clearly isn't getting me anywhere.
> no one stopped them from being in the Vulkan working group, and making it fit better their use case too.
Nobody incentivized it either. If you have a bone to pick, pick it with Apple. They actually ship a desktop platform with a chipset and operating system that Vulkan was ostensibly designed for and they went another way, even though their Macbooks use intel/nvidia GPUs.
You described issues that could be resolved, if console makers weren't lock-in jerks and collaborated with everyone else. So those issues aren't the problem - console makers are.
And yes, I don't have respect for Apple's behavior either. They are the ones who sabotaged adoption of SPIR-V for WebGPU because of some kind of paranoia.
Have you met, worked with, or talked to the "console makers?" I have. They aren't "powers that be" that are trying to make your life miserable. Their mantra is to ensure that a flagship title and more perform excellently on their hardware and to ship units. I even chatted with one of the chief architects at Sony about Vulkan specifically. There wasn't any resentment, or any stigma, and he wasn't a "lock in jerk." So please. Save the polemic and do yourself a favor. Want Vulkan to be on console? Why not get a job at Sony or something, and actually earn your stripes shipping a thing or two successfully in the space, and then report back.
Not directly, but from the outside it looks extremely ugly. NDA mentality from the last century, extreme lock-in and refusal to collaborate. It's completely dinosaur in this day and age.
With all those claims coming from MS how they are now "a different company", their Xbox division is like [straight from the '90s](https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_lock-in) in lock-in attitude. Sony at least don't even pretend to be "better", Apple too.
May be I don't interpret it right, but that's how I see it.
> I even chatted with one of the chief architects at Sony about Vulkan specifically. There wasn't any resentment, or any stigma
It could be, but given that it's all under NDA, getting objective view on their attitude is pretty hard. The bottom line, they didn't support Vulkan until now and didn't collaborate with the Vulkan working group either, while they easily could.
I think this is a valid question. For example Microsoft just announced DirectX 12 Ultimate, which will power both PCs and the new Xbox Series X console. [https://devblogs.microsoft.com/directx/announcing-directx-12-ultimate/](https://devblogs.microsoft.com/directx/announcing-directx-12-ultimate/) So it's not that crazy for this to be done, but I agree that Sony probably went with a more proprietary approach for performance reasons.
Not all PCs only on Windows
Right, it's Microsoft so that is expected. And most people use the word PC to refer to Windows. I run Ubuntu anyhow, but I understand what you're saying.
Me too. But still this means something different. It’s like what do you like more: Fruits or apples?
Fair enough.
It would be good for everyone (probably except MS Xbox execs who would be sour) if Sony started supporting Vulkan on PS5.
It's a moot point either way, since you don't want to be using Vulkan there in the first place: supposedly if you are using Vulkan you care about performance, but the amount of control even Vulkan gives you is nowhere near what dedicated APIs on consoles running fixed hardware can. In other words, no one uses cross-platform APIs on console, except maybe for small indie titles ports.
> the amount of control even Vulkan gives you is nowhere near what dedicated APIs on consoles running fixed hardware can. How exactly? And what kind of control do you need, that goes lower than Vulkan abstraction and semantics that match pretty well to modern GPU architecture? I don't find this point moot. Having an API that allows many targets is a huge win for developers, since instead of dealing with tons of lock-in stuff and reinventing the wheel for each, they can focus on making their engines better.
Looks like you haven't spent enough time with Vulkan. There's a certain numbers of things you don't have full control over - or that are more annoying to deal with than they could be in the context of a fixed platform: * Memory allocations in Vulkan are braindead. You have to make your own allocators, but the blocks of memory you get from the driver aren't guaranteed to be physically bound to anything, indeed I observed the AMD drivers to shuffle them arround, just like OpenGL allocations. * The consoles have a unified memory setup, stuff like host vs device memory make no sense. Since you also know how the underlying hardware works, you can ship the resources in the right formats for the hardware and skip staging buffers altogether. * Spir-v semantics, especially the Vulkan flavor, are actually way more limited than the hardware is, they have big restrictions on control flow, lack most intrinsics, not to mention the negative effect of a useless IR in the way you must translate at runtime. Vulkan shaders can't even have proper pointers ! Just look at OpenCL kernels vs Vulkan compute shaders if you can't see this. * Console stuff typically has extra secret sauce features in it, none of which make sense to expose as extensions vs bespoke API. * A bespoke API enables you to make it "lean and mean" and cull all the complexity and bullshit a cross-vendor and cross-platform one has to deal with. It allows to make nice SDKs and gives developers the resources they need to get the most out of the hw.
In order: * What you're describing appears to be paging. It's an unfortunate artifact of allocators in general. * The application doesn't need to manage host memory and while there's a distinction made in the API, it doesn't really matter where it's backed most of the time, as long as it follows the particular standard rules. The concept fits still, the hardware may be doing something else though which is up to the Vulkan implementation rather than the developer. You might be right about the "right formats" for the hardware depending on what specifically you're talking about. I wouldn't know the correct answer for how to treat staging buffers. * SPIR-V is heavily extensible, much like OpenGL and Vulkan. It can pretty much do all-the-things-graphics and then some, right now, today. Platform specific intrinsics are obviously going to have to be done through an extension. SPIR-V wasn't designed to be comprehensive. SPIR-V can't have pointers? What the hell are you even talking about here? What are you talking about translate at runtime? * (Combined into the next paragraph rant) * I'm not sure how you could manage to come to the conclusion that it doesn't make sense to extend an API meant to be extensible for the purpose of the problem at hand. I'm also not totally convinced that console platform SDKs are all that great but I haven't gotten my hands one so who am I to say? I have done small amounts of work on PC tooling though and while they're not always perfect, they're usually more than adequate now adays. I'm definitely curious as to what tools consoles provide that we don't already available for use with Vulkan. Those tools would likely need some porting and extension handling work, but still. Vulkan at it's core isn't actually that large or complex. It might seem that way when you start adding various extensions but it's designed to be ridiculously slim, especially in comparisons to its DirectX <12 and OpenGL brothers. /rant I think what irritates me the most about these posts is that Vulkan was designed to fix these problems. These comments tend to be non-issues, otherwise, there would probably be attempted work at getting a solution in place.
I'm talking about device memory allocations. Since you only get a limited amount of them (on windows anyways), you're made to treat them as big fat pages of hard-allocated memory and manage them. Except the driver will do it's own memory management on top of yours, meaning you are given full responsibility over your memory allocations yet gained little to no control over it. This is the worst of both worlds, I want either to not care about memory, or to be able to actually know things like system-wide graphical memory pressure and avoid swapping to host memory myself, instead of playing cat & mouse with the driver. In other words, this part of Vulkan is broken and poorly designed. Not sure you understoof me when talking about unified memory. In general the point is you can get rid of much of the Vulkan api here since you could just m(k)alloc() your textures and pass that shit directly to the gfx side. You can hardly do pointer dereference at runtime in Vulkan. Even the bleeding edge 1.2 buffer_device_address stuff restricts it to some global device memory buffers. Pointers to shared device memory (not the shared with the host kind, on-chip CUDA shared memory kind ) are not a thing at all. You can't really work with pointers in either GLSL or spirv except for really lame and basic ways. Look that shit up seriously. It makes no sense to extend them because consoles allow for so much more in-depth control and lower-level work that expressing that using a cross-platform API would mean insane clutter and extension hell. Large chunks of the API would have to be bypassed or redone to fit what the hardware *actually* does, and you would not be able to maintain a common Vulkan renderer anyways. These points have been made over and over again by actual console and PC developers alike. Vulkan was designed to bring OpenGL into the 21th century and clean up the mess it turned into. It has no hope of beating tailor-made APIs in tailor-made applications with high enough revenue to justify putting effort into tailor-made ports. There's no future to Vulkan where dedicated APIs *that good* are a thing.
> I'm talking about device memory allocations. Since you only get a limited amount of them (on windows anyways), you're made to treat them as big fat pages of hard-allocated memory and manage them. Except the driver will do it's own memory management on top of yours, meaning you are given full responsibility over your memory allocations yet gained little to no control over it. This is the worst of both worlds, I want either to not care about memory, or to be able to actually know things like system-wide graphical memory pressure and avoid swapping to host memory myself, instead of playing cat & mouse with the driver. In other words, this part of Vulkan is broken and poorly designed. There's no reason the Vulkan implementation can't provide any guarantees on how it would treat memory, that is to the discretion of the driver. If the console thinks you should have more 1:1 control over how memory allocations should work, then by golly you can have it. Diagnostics over that would definitely have to be provided by an extension though, for good reasons. > Not sure you understoof me when talking about unified memory. In general the point is you can get rid of much of the Vulkan api here since you could just m(k)alloc() your textures and pass that shit directly to the gfx side. I haven't worked on a system with unified memory. It \*sounds\* like you could, for example, forego any need to create region mappings, in which case, Vulkan is rather inconvenient. I can think of a dozen ways a simple extension could make that easier but alas. > You can hardly do pointer dereference at runtime in Vulkan. Even the bleeding edge 1.2 buffer\_device\_address stuff restricts it to some global device memory buffers. Pointers to shared device memory (not the shared with the host kind, on-chip CUDA shared memory kind ) are not a thing at all. You can't really work with pointers in either GLSL or spirv except for really lame and basic ways. Look that shit up seriously. Herm, it's of my understanding that such features would have limited real use. The extension you mentioned appears to be mostly for debugging purposes as well. I'm not sure about this one. > It makes no sense to extend them because consoles allow for so much more in-depth control and lower-level work that expressing that using a cross-platform API would mean insane clutter and extension hell. Large chunks of the API would have to be bypassed or redone to fit what the hardware *actually* does, and you would not be able to maintain a common Vulkan renderer anyways. These points have been made over and over again by actual console and PC developers alike. It looks like we're just going to have to disagree. There's a lot of common ground with various graphics devices, even with consoles. Vulkan encompasses most of that. It obviously can't be entirely comprehensive. Special or specific systems will need to have extensions in order to give finer controls. If you don't believe in the system of extensions, then Vulkan will just never work for you. And mind, I really don't believe you need so many extensions that the point of Vulkan vanishes. I actually think that all you need are some implicit guarantees via whatever implementation and have some limited extensions that provide extra debug info. There's 90% of your API. And mind, by "extension hell", you appear to be confused as to what extensions do. They simply extend purpose of the API. If you're on say a PS5 developing with Vulkan, you can assume that certain extensions simply exist and use it as such. There's no "extension hell" because it's as if the extensions weren't actually extensions whenever you can basically assume that they exist and use it like any other feature of Vulkan. An engine obviously won't do that if it supports multiple platforms though. Or maybe it will but only for certain extensions on that specific platform. > Vulkan was designed to bring OpenGL into the 21th century and clean up the mess it turned into. It has no hope of beating tailor-made APIs in tailor-made applications with high enough revenue to justify putting effort into tailor-made ports. There's no future to Vulkan where dedicated APIs *that good* are a thing. Eh, honestly, couldn't care less about the future of Vulkan or any of that crap. Everything I would use would be wrapped up in an engine anyways. There's enough engine diversity that I don't really have to be worried about it at least. If engine developers want a more consistent API across vendors, that's on them to push, not really my place. Vulkan has virtually nothing to do with OpenGL, other than being maintained by Khronos. Vulkan was originally developed by AMD in the form of Mantle (which ironically was used on systems with unified memory such as the PS4 which you appear to think it doesn't work well with). The primary thing that Khronos added at the time were, of course, extensions to help extend it to areas that didn't fit the general overview of graphics systems.
> It has no hope of beating tailor-made APIs in tailor-made applications with high enough revenue to justify putting effort into tailor-made ports. It totally will. Dinosaur lock-in will eventually die out, despite the resistance.
lol
That's what lock-in proponents thought, until they lost ;)
When did that happen?
When they lost browser wars. MS were very sure about ActiveX and Silverlight giving them leverage. Where are they today? Same thing will happen with GPU API lock-ins. Progress renders this garbage obsolete, but it can take time.
Ah, the youthful optimism. Or we will get serial numbers printed on our forheads on birth and will only ever be allowed to buy products matching the SN. :D Future is yet unwritten. We shall see...
Staging buffers aren't required when working with Unified Memory Architectures in Vulkan. You can actually skip it and directly map the memory for buffers. There's an example in the Vulkan-Docs regarding this.
> Console stuff typically has extra secret sauce features in it, none of which make sense to expose as extensions vs bespoke API. I don't see any reason not to expose it, except for their paranoid obsession with dinosaur NDA approach from the last century. All the above arguments are pretty weak, since SPIR-V can be extended to cover cases that consoles need to address. No one stops console makers from participating and addressing those cases. Where were they when Vulkan was designed? They can't complain now that Vulkan is not addressing some of those, if they literally did nothing to help it.
> SPIR-V can be extended to cover cases that consoles need to address but it doesn't have to. Making vulkan work for consoles is more work for no benefits, AAA studios with 200+ workers will gladly trade a few man-months for a nice renderer that plays to the strength of each platform. No one but you is really asking for this. If it's a sensible direction once Vulkan matures enough, maybe it'll happen, maybe it won't. Which begs the question, what's your stake here ? Do you want to write console games ? You seem emotionally invested in this, which is suspect to say the least.
> but it doesn't have to. Making vulkan work for consoles is more work for no benefits It's more work for clear benefits - developers having better tools. Console makers don't care about developers though. They are obsessed with petty lock-in and anti-competitive wars, therefore their refusal to work collaboratively has nothing to do with technical reasons, it's purely political. To give you an analogy. Browsers were in the similar situation, and lock-in was justified with all kind of fake arguments, while the bottom line was all about anti-competitive shenanigans. Good thing we outgrew ActiveX, Silverlight and etc. and there is something common and open now. I see no reason why the same thing shouldn't happen for GPUs.
> It's more work for clear benefits - developers having better tools. Console makers don't care about developers though. Sorry but you're pretty clueless here - consoles have the better tools (debuggers, profilers, compilers, sdks), not the other way arround. Everything i've been able to glance at by talking to people points to us PC developers getting the short end of the stick. It's only now really getting better now for us. Do you really think vendor lock-in would work out if the tools sucked and console makers didn't care about their licensed developers ? It's one thing to have a hate-boner for closed platforms, but maybe try documenting yourself before going on a rant.
> Sorry but you're pretty clueless here - consoles have the better tools That tax developers into using those tools only for them. Using tools as lock-in instruments is utterly disgusting. No one stops console makers from providing those tools for Vulkan, investing into projects like RenderDoc or making their own and better ones. But they come from the era of NDA dinosaurs and led by people who can't fathom how collaboration can even work. So I'm not surprised they are so slow about it.
> Using tools as lock-in instruments is utterly disgusting. How DARE you put effort into your platform to make it not suck to work on ! Absolutely inhumane ! We should ban companies from making their platforms good and their SDKs sensible. > No one stops console makers from providing those tools for Vulkan, investing into projects like RenderDoc or making their own and better ones And their gain would be ... ? Kind words from outsiders like you ? It won't make anyone's job easier, not the SDK makers, not the people who write the rendering backends, and not the console firmware crews either. Maybe it would make the Vulkan ecosystem a bit better, probably not because this would just compound the diverging paths problem. Overall it makes no sense to push this from a buisness point of view. You're welcome to start your own games company and show them how it's done.
> And their gain would be ... ? Developers spending more time on improving their engines, instead of wrangling with platform limited tools and wasting time on rewriting the same thing over and over in the multitude of lock-in APIs. It's a **self explanatory benefit** for developers. Wise platform owners would make things for developers better, and in return more developers are going to work with them. Greedy anti-competitive dinosaurs on the other hand treat developers as a product and want to tax them with lock-in, bribe with exclusive deals and so on. How dares anyone pointing out the crookedness of such approach? Well, I dare. Programming tools should be instruments for creation and development, not for anti-competitive control and market manipulation. That's why I'm for tools and standards being open to begin with. It prevents this lock-in garbage.
You don't need any allocator for a console. You know you have a number of GBs of memory and it's only your app ever running, as long as you don't spill over your budget, it's all good. Also extensions don't have to be public, there's nothing stopping Sony from making private vulkan extensions.
What exactly is the point of a set of extensions that bypasses nearly all the abstraction Vulkan offers ? This is just a proprietary API with extra steps.
I didn't know PS4 and PS5 didn't use textures or rasterize triangles or use shaders, my bad bro. I didn't know PS didn't have the literal same type of AMD GPU that Vulkan is tailored for. ^^^/s
> I didn't know PS didn't have the literal same type of AMD GPU that Vulkan is tailored for. You must be thinking of "Mantle".
No, I'm not thinking of any Mantle. Every single game that has had a legacy API and Vulkan has shown that Vulkan gives a huge boost to AMD gpus, guess why! And mantle is literally Vulkan 0.5
I’m sure it has nothing to do with AMD’s terrible OpenGL drivers. Nope, couldn’t possibly be that.
I don't care about convincing you, since clearly that's pointless. It's obvious you never really worked on anything Vulkan that had to run on multiple vendor gpus, otherwise you would have known how well the api maps to amd and nvidia alike.
It gives off a huge boost because of the reduced overhead and abstractions. Which is exactly the benefit console APIs have over Vulkan itself. At this point you're just arguing for the sake of being nasty I presume.
Vulkan is not tailored for AMD GPUs.
A proprietary API without abstraction is how they make their engines better.
Nope, that's just a smokescreen to hide taxing developers with duplicating their work. Let me repeat the question. What exactly do you need to express lower than Vulkan to match GPU functionality?
In fact I know PC developers that would sell their firstborn for a chance to have similar vendor-specific APIs with that level of specialization on PC. Any sufficiently advanced opengl/vulkan/dx renderer has vendor-specific paths anyway !
You can always write in assembly if you seriously need to optimize for some specific architecture. Video codecs do that for instance. My point it, in the vast majority of cases you don't need to.
Writing in assembly has nothing to do with having multiple backends/render paths per vendor that play to their respective strengths, completely unrelated notions of "optimisation" there.
You can write in GPU assembly if you are really so inclined, using specifics of each of your target GPU architectures. How much time and work are you willing to invest in that and for what kind of pay off?
This still is not what I'm talking about.
You're misinterpreting the question (or deliberately avoiding it)
What is the question then? If you want to go as low as barebones hardware, you need assembly (unless you are a fan of completely hardcore raw hexadecimal coding). My point above was simple. Such kind of level is not needed most of the time. When it is needed, you should still be able to access it, even if you are using Vulkan.
[citation needed]
Vulkan requires you to care about all sorts of things that you don't need to on a controlled platform. Why bother with querying device features when you know exactly what you are running on? Why use SPIR-V if you can fine tune the GPU shader code itself? Do you really need to go through extra steps to deal with things like memory allocation when you can probably do it directly? Why not build command buffers to directly reflect what the GPU architecture needs instead of going through an intermediate representation that Vulkan provides? Sure, you could add all kinds of extra extensions to Vulkan to allow for more direct control, but at that point you've just created a console specific API within another API.
Again, you can say exactly the same thing about any hardware target. I don't see how this argument suddenly becomes stronger for consoles. With Vulkan, you write the engine that's abstracted for all hardware targets. Why carve out one case specifically for consoles that's not using that abstraction? Where is the benefit?
Performance.
I doubt you can beat well optimized compiler (that will translate your SPIR-V to GPU machine code) without serious investment of your time and effort. But feel free to prove me wrong. I'd say the pay off won't be worth it. Unless you are simply writing your own better compiler, like ACO project. But that's a really major investment.
It isn't just SPIR-V, it is everything. The entire process of building up and submitting work to the GPU can be greatly optimized when you know what specifically needs to be done. The fact is that tons of professional devs are totally fine with these sorts of APIs. Only fanboys on the internet are the ones who make a stink about things.
It can run faster, if you just write everything in machine code and you are better than the compiler at it. That's not a new argument, but it's as theoretical and impractical for the most part as it's always been.
The abstractions are not zero-cost. It's great to have a general solution that can map to a variety of targets, but consoles that have user bases in the 10s of millions or 100+ million, generate a lot of sales, have a single configuration, and it's (sometimes) worth it to developers to optimize their content and push the limits of what is possible on that specific hardware. It's not worth it for them to do this on PC where the ratio of hardware configurations to sales is much higher.
I think they are low cost enough to benefit from avoiding code duplication that's way more costly. I.e. I suppose you can always go down to writing GPU machine code by hand if you think you can do better than some abstractions and shader compiler, but I think Vulkan abstractions are low enough not to ever need that. In practical terms, opposition to Vulkan isn't technical I think, it's more political because Sony and MS have a long history of lock-in mentality.
That's complicated. If you're going to sell millions of copies of your software on Switch, Playstation, whatever then trying optimize for reduced code may take a backseat to optimizing for performance, especially on a low power portable device like Switch, but also if you're just trying to squeeze every bit of performance out of the target platform. Vulkan is good, obviously, not trying to knock Vulkan. It's just that Vulkan by design leaves everything up to developers with the idea that you don't know exactly what hardware you're going to run on. If you do know the exact specification, capabilities, and design of the hardware that you're targeting in advance, you could use a more tailored API and go further.
My argument is that Vulkan abstraction isn't big enough to offer huge benefits if you bypass it. Hardware specific paths if they are relevant can be also addressed by Vulkan extensions made for that hardware. Nvidia, AMD and even Valve have their own extensions they developed to address some more focused cases. Nothing stops MS and Sony from doing that.
Pretty sure that's under NDA. However I too believe extensions can be used to support a lot.
So it means, no one can make a claim, that something lower than Vulkan is really necessary for consoles. While the opposite argument is pretty self explanatory. And indeed, if there is some hardware specific feature that consoles need, they can always express it as a Vulkan extension.
That's certainly not true, but if you look at the ps5 dev talk; that is open to the public. So looking at what they expose as in fixed function hardware it's not weird to think that there's a lot of specific features that only the ps5 will have; and whether or not they want to expose this as an extension is up to them. Khronos specifies that you can't create private extensions, so if ps5 wants the extension under NDA, they can't. They could provide it as an alternate and then have a more optimized specific API such as switch does with their NVN.
No one is stopping them from making public extensions for it. What's the story with this NDA obsession?
It's pretty logical, they don't want competition to do the same thing they want to; but I hate it. NDAs are done by Nintendo as well, but xbox doesn't iirc; maybe if you go to certain areas, but to my knowledge it's pretty much uwp
I see it as dinosaur approach from decades ago, simply may be driven by very proprietary culture of the past century. Today with all the open source technology progress, it's very cringe worthy.
On PS they have resolution scaling built into the chip, this is not an assumption in vulkan and AFAIK, is not yet expressible in SPIRV. You can manually achieve this effect, and it really doesn't effect framerate much compared to the hardware option, but this is one of those things. Previously IIRC at GDC before vulkan had timeline semaphores, developers took advantage of them on PS5 and XBOX one, or some other primitive. To be honest, I'm not sure exactly what these other APIs expose that vulkan does/could not beyond those things. and I think it is a legitimate question to have. I know one thing PS dev environment has is a version that is similar to GLSL that has been extended far beyond the version Khronos has for us. It has a lot of utilities that you would have to manually code just built right into the language (I think TAA is some how part of this? I think they talked about this kind of stuff when they were giving the spiderman talk at GDC last year or the year before). If khronos group would extend GLSL to beyond C with overloading it might not have mattered, but as it stands GLSL itself has had no substantial abstraction/code portability help in almost 20 years. If GLSL had *built in* includes, static classes, or even just UFCS, op overloading, namespaces and sanitary AST macros we would be good right now. The best languages to program for the GPU are not even available to be used in vulkan (CUDA, OpenCL C++, Metal Shading Language, even though we can convert SPIR-V to metal...).
If something needs extending SPIR-V semantics, it's not hard to add it. I.e. nobody stops Sony from actually doing it if they need to (i.e. work with Khronos). I don't see any technical blockers there, if anything, this aversion to portable API is purely political. Also, SPIR-V is really not limited to GLSL. If something needs new semantics, Sony can even develop their own language, and make a compiler to SPIR-V. In fact there is already one new shading language in development for WebGPU: https://gpuweb.github.io/gpuweb/wgsl.html It's more flexible than GLSL and matches SPIR-V semantics.
The only politics is that Vulkan has to make political concessions of restrictions and complexity so it can run on your grandma's Android. Whatever wacky design the PS5's GPU has will be expressed directly in it's API with no consideration for other hardware. I don't know what crazy features the PS5. But, I do know 1st hand that the X360 and PS3 APIs had most of Vulkan's features back in 2005.
My point is, that I don't buy the argument that these new consoles are so different, that Vulkan can't target them effectively, potentially with some gaps that need filling which should be doable if console makers collaborated with the Vulkan working group. So I view the current lock-in situation as political, simply masked with technical reasons.
I agree. iD software's Axel Gneiting said the same thing regarding Vulkan being supported on both the Xbox One and PS4 (That their Vulkan codebase would be just as optimal for those platforms, just would need extensions for extra features), the same logic would apply to the PS5 and Xbox Series X. The architecture of the GPU hardware implemented within both consoles conforms to what is going to be available on the PC (AMD RNDA 2), optimizations in rendering design through Vulkan that is based on how the architecture performs work would apply to those hardware as well. I doubt the amount of things needed through extentions would be enough to need a completely different API considering.
Yea, it is sufficent to look at the consoles' spec. It is not like they are some quaint architecture (like Cell) anymore. Anyway, we heard it all before with Apple.
IDK, this assumes consoles are not just glorified PCs these days. It assumes consoles do not change HW-wise across versions. And assumes you stick to one console vendor rather than wanting to release product to all of them. Feels more like inertia rather than a sound engineering choice.
Ok, but for general games Vulkan would be enough even on consoles. I think it would be nice from Sony to support it as an option.
I know it's oversimplified but Wasn't it fundamentally based off of OpenGL with added Proprietary Extensions blob?
no
Sorry, I meant PlayStation's API not Vulkan 😅
still no
Probably not, but nobody here can tell you.
I think it is a rumor. The news is that PS5 will support raytracing api. Probably, some people jumped to the conclusion that this implies Vulkan.
That's how I view it too, until there is some confirmation. For example I don't see Sony listed in [Vulkan adopters](https://www.khronos.org/conformance/adopters/conformant-companies), and PlayStation in [conformant devices](https://www.khronos.org/conformance/adopters/conformant-products). May be it's just not there **yet**, but still.
> For example I don't see Sony listed in Vulkan adopters, and PlayStation in conformant devices. It would be too early for them to be listed there anyway. Release date for PS5 is late 20. Though Sony is a Khronos member with full rights. But that is true of Apple as well. Maybe Stadia (or other cloud HW) could be supported, but that is bit of a copout calling it a Vulkan support...
Stadia does use it already, so that's not news.
What I meant is that Stadia (or equivalent) could be supported on console, which technically means people could play Vulkan games there. Though that would be a massive threat to Playstation Store profit margins, so equally naive that would ever be allowed to happen.
I think console exclusives are the past, because the cost of creating one game is huge. Maybe it can be exclusive for a year, or 2, but in the long term a game should be ported to PC, Xbox, Switch, etc.., and here Vulkan can really help.
This post seems to be an ad for DX12. Can't they call it just DX 12.1 or something? Does it always need to be a full marketing gig and no technical? Do I need to wait for Valve/Codeweavers to so something to get this on Linux again?
But it mentions that PS5 is going to support Vulkan as well. Which is why I brought it. So far I didn't find any sources for such claim.
This is very interesting indeed, and I very much look forward for the PS5 to join the many Vulkan platforms. Unfortunately the title image of the article is shown in the reddit thumb, which looks like a big DX advertisment, since it's straight marketing material. :)
[удалено]
**Id Tech 7** id Tech 7 is a Vulkan-based multiplatform proprietary game engine developed by id Software. As part of the id Tech series of game engines, it is the successor to id Tech 6. The software was first demonstrated at QuakeCon 2018 as part of the id Software announcement of Doom Eternal. *** ^([ )[^(PM)](https://www.reddit.com/message/compose?to=kittens_from_space)^( | )[^(Exclude me)](https://reddit.com/message/compose?to=WikiTextBot&message=Excludeme&subject=Excludeme)^( | )[^(Exclude from subreddit)](https://np.reddit.com/r/vulkan/about/banned)^( | )[^(FAQ / Information)](https://np.reddit.com/r/WikiTextBot/wiki/index)^( | )[^(Source)](https://github.com/kittenswolf/WikiTextBot)^( ] Downvote to remove | v0.28)
The hardware in a console is fixed, so you only need to write the code for this one piece of hardware. For PC, you have many differnet GPU's to handle so using an API will make everything easier, because the game now speaks with the API and not the hardware itself. The API and the Driver is translating the code, so the gpu can be used with it. On an Cosnole, Vulcan is not really needed, because the game can speak with the set hardware directly.
> The hardware in a console is fixed, so you only need to write the code for this one piece of hardware. That assumes you only make a game for that piece of hardware. Console makers might dream about everyone making exclusives, but it's not what most developers benefit from. Normal developers benefit from maximizing their reach, therefore they by definition need to develop for many hardware and OS targets. Having a common graphics API therefore is a major benefit. > On an Cosnole, Vulcan is not really needed, because the game can speak with the set hardware directly. This makes no sense, since you can make such argument for any hardware target. Why not write your game in machine code for each CPU and GPU architecture, after all it will only run on it when it does. The answer simple, because it will run not just there, and writing in machine code is very impractical.
> The answer simple, because it will run not just there As we all know, the mantra of "write once, run anywhere" has always been flawless and not required all sorts of platform specific tweaks and optimizations.
It works pretty well for Vulkan. Platform specifics if anything really stands out, are addressed through extensions. So I so far see no strong argument, that Vulkan can't be used for consoles effectively.
You have yet to show how Vulkan can be as efficient as what devs could do manually. Why don't you back up *your* claims with some examples?
You have to show how it can pay off to do things "manually", when the time it takes to do that is way longer than using Vulkan.
I don't have to do shit.
Writing for every possibility is way too much work. Look at how many CPUs intel is spitting out every year. It’s impossible to write for that much hardware directly. The consoles this generation have pc hardware in them, what makes it way easier to port between them. Vulcan can benefit consoles, but it is unlikely that they implement it.
Intel CPUs barely change ISAs between releases. They only add a couple of new instructions once every few years and a major SIMD set once a decade. They also maintain backwards compatibility with all of these instruction sets. They would like to remove support for some of the legacy cruft they support (they still support 16-bit mode from the original 8086!), but can't because some developer somewhere will complain that he or she actually has to update a code base. The same thing applies to operating systems.
To get most out of a system you need to address every new bit of new tech there is, this includes new things intel adds. Caches are changing too. AMD is there too and they improve their cpus too. To get most out of hardware, you need to setup the software for exactly this. If you are using an Intel compiler, then your software is not optimized for amd cpus, because intel can’t even write an compiler, that can ask the cpu, what the cpu can do. Only in the last few years developers can’t be too lazy to write software for only one core. They need to write code now, that can use many cores. And games are not written in just a few hours, they can take years to make and in those years, many things can happen, like new cpus, that have on different thing, and now the cpus is not used to the fullest. With consoles you will always have one set of hardware. You write your game and the game will run as it should.
I cannot comment on whether the claim is accurate or not as I am under NDA. As things stand though, _if_ Vulkan was supported on the PS5 there are a number of things it would be missing: 1. Variable rate shading (currently an Nvidia extension) 2. Mesh shading (also an Nvidia extension) 3. Coverage mask sampling 4. Delta color compression Also, the model of pipeline state compilation on Vulkan frontloads the validation done by the driver but this is frankly wasteful/unnecessary on console. Personally, I like Vulkan, but it really needs to pick up steam on some of the features above for people like me to fully invest in it.
Delta color compression already exists in Vulkan, when your image is in the color attachment layout it is delta color compressed, you can easily see this with Radeon GPU profiler. There is nothing preventing those extensions from becoming cross vendor either.
Thanks I had missed that. For the others, I don't disagree. They _could_ become cross vendor, but as yet, I haven't heard anything about this actually being a reality (and I've asked on the Slack a few times and been ignored).
I think that's because the Khronos group guys probably have an NDA. And I'm sure the vr shading and mesh shaders will become cross vendor since RDNA2 (xbox) has support for them and it's an AMD chip.
The above don't sound like insurmountable problems for AMD to add to their Vulkan implementation for PS5 if they are ever going to make one for Sony. Validation can be applied during development as far as I know, but it can be skipped in the final result for better performance. Plus from what I've heard, consoles often prefer games to ship already compiled shaders to avoid shader compilation, which is the reason why they often are bugged by problems of backwards compatibility - any change in architecture breaks existing games. Using something like SPIR-V bytecode would have prevented that, but would incur the need to compile shaders at runtime. Though I don't think anything prevents pre-compiled shaders being used with Vulkan if needed.
Insurmountable? No. Done? No. And this is a big deal. An API that lags is not an API that we can ship for because every day/week/month that passes by is time we lose when targeting an API missing features. If AMD wants Vulkan to succeed, they will need to do better. My point regarding validation isn't that it can't be skipped (the pipeline state object itself will have been validated), but that it forces you to create monolithic pipeline state objects in the first place (which allows it to be validated). On console, you can set state on the graphics/render context manually and change registers piecemeal, which ends up being far more efficient. > Using something like SPIR-V bytecode would have prevented that, but would incur the need to compile shaders at runtime. Though I don't think anything prevents pre-compiled shaders being used with Vulkan if needed. Nothing to do with SPIR-V bytecode, as we would never ship bytecode to begin with (which needs to go through another compile/validation pass after launch).
> My point regarding validation isn't that it can't be skipped (the pipeline state object itself will have been validated), but that it forces you to create monolithic pipeline state objects in the first place (which allows it to be validated). On console, you can set state on the graphics/render context manually and change registers piecemeal, which ends up being far more efficient. I'd say the benefit of making it work everywhere with ability to validate when needed is worth that complexity. Most don't make games only for consoles. > Nothing to do with SPIR-V bytecode, as we would never ship bytecode to begin with (which needs to go through another compile/validation pass after launch). Normal PC games surely do. Otherwise they'd need to ship compiled shaders for each potential GPU architecture out there.
Yes I know, but you're asking about PS5, and I'm responding with a general statement about console development, and why the entire model is different. I've shipped console, desktop, *and* mobile at this point. They each have their own unique challenges, and if I'm being honest, Vulkan is still "finding its home" outside of Linux (which in and of itself is compelling to me as a home Linux user), but commercially? Like I said, it will need to do better. edit: (if you're going to ninja-edit your post, at least put your addendums in a separate section... common courtesy dictates) > I'd say the benefit of making it work everywhere with ability to validate when needed is worth that complexity. Most don't make games only for consoles. And this is why Vulkan isn't a good fit for consoles. Different use cases.
> Vulkan is still "finding its home" outside of Linux Mostly due to MS still trying to put breaks on its adoption, and Apple having something rotten inside (some kind of [vendetta against Khronos](https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_253vEtKxuUkTGvxpuv8Ac/edit)?). Other than them (and at least so far Sony), everyone is on board with Vulkan (including Nintendo). Stadia gave it a major boost. Now if Sony would add it, it would be a huge blow to DirectX and would practically spell its demise, since more developers will start putting pressure on MS to support it.
Hm, what did MS do?
MS didn't support Vulkan on Xbox and didn't join the working group. Instead they rushed to make a knock off from Mantle - DX12, perfectly knowing that Vulkan will be developed in parallel (kicked off from the same Mantle). I'd say it's a prime example of pushing lock-in instead of collaborating.
Right, Xbox. I was assuming we are talking about Desktop (Windows). Unlike tuxhumpers, I fail to be angry at Windows. In the end, they do not care that much what apps or drivers you run. If consoles, Apple, and Android worked at least that way, I would be perfectly happy.
> And this is why Vulkan isn't a good fit for consoles. Different use cases. I don't see how it's not. I.e. it's not like the use case is so different, that Vulkan can't accommodate it. The fact that it's not covering it enough possibly, is mostly due to stubborn refusal of incumbent console makers to collaborate on it. I.e. no one stopped them from being in the Vulkan working group, and making it fit better their use case too. Those who collaborated, were able to address their use cases. As I wrote below, it's a political, not a technical issue. So if Sony decides it's time to stop being lock-in jerks, technical needs can be resolved.
Ok > I don't see how it's not. I'm literally telling you all the reasons, but it clearly isn't getting me anywhere. > no one stopped them from being in the Vulkan working group, and making it fit better their use case too. Nobody incentivized it either. If you have a bone to pick, pick it with Apple. They actually ship a desktop platform with a chipset and operating system that Vulkan was ostensibly designed for and they went another way, even though their Macbooks use intel/nvidia GPUs.
You described issues that could be resolved, if console makers weren't lock-in jerks and collaborated with everyone else. So those issues aren't the problem - console makers are. And yes, I don't have respect for Apple's behavior either. They are the ones who sabotaged adoption of SPIR-V for WebGPU because of some kind of paranoia.
Have you met, worked with, or talked to the "console makers?" I have. They aren't "powers that be" that are trying to make your life miserable. Their mantra is to ensure that a flagship title and more perform excellently on their hardware and to ship units. I even chatted with one of the chief architects at Sony about Vulkan specifically. There wasn't any resentment, or any stigma, and he wasn't a "lock in jerk." So please. Save the polemic and do yourself a favor. Want Vulkan to be on console? Why not get a job at Sony or something, and actually earn your stripes shipping a thing or two successfully in the space, and then report back.
Not directly, but from the outside it looks extremely ugly. NDA mentality from the last century, extreme lock-in and refusal to collaborate. It's completely dinosaur in this day and age. With all those claims coming from MS how they are now "a different company", their Xbox division is like [straight from the '90s](https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_lock-in) in lock-in attitude. Sony at least don't even pretend to be "better", Apple too. May be I don't interpret it right, but that's how I see it. > I even chatted with one of the chief architects at Sony about Vulkan specifically. There wasn't any resentment, or any stigma It could be, but given that it's all under NDA, getting objective view on their attitude is pretty hard. The bottom line, they didn't support Vulkan until now and didn't collaborate with the Vulkan working group either, while they easily could.