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.
That will change when pressure will grow. Same as ActiveX was driven out by standard Web technologies. Lock-in freaks will try to resist, but they can only delay it.
> 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.
I see you still are a fan of lock-in. Calling it "fine" and saying that's how it's supposed to be is not helpful. "Industry" which thinks backwards doesn't need to be shown as an example. It's not the "industry", it's monopolistic participants who use lock-in to control the market. Progress is driven by competition, not by monopolistic lock-in stagnation.
> most companies have and will just port it to different platforms, using the api that gives them the most performance
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.
Of course they do, but under NDA, just ask. OpenGL on top of whatever GAPI is on target platform is usually <100 KLOC, so completely possible to write your own if you REALLY need to (really is when your 1kk+$ budget game will fail just because there is an engineering problem).
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.
> OpenGL on top of whatever GAPI is on target platform is usually <100 KLOC, so completely possible to write your own
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.
So first you develop your game for Windows on DirectX, and than you make a port to OSX/iOS/Android using OpenGL, and than if you're lucky you make a port to XBox and PS4, maybe WiiU. Graphics pipeline rendering code is really small and simple part of any game, usually in big games you do have different render code for different GPU series or/and platforms, but it's much smaller in comparison with everything else.
What's big and bulky - shaders themselves, but there are solutions to translate them between different available languages.
I might be harsh to say it, but current vulkan/spir-v tooling is more like a toy than production ready. If one need to convert HLSL to GLSL then one probably will use something like https://github.com/James-Jones/HLSLCrossCompiler
and IIRC one place just used advanced macros magic to make HLSL and GLSL from the same source code :)
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.
As I suspected, all of the features that I can see described here are in Vulkan. In particular, the first couple of slides pretty much identically resemble Vulkan's "elevator pitch".
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.
Descriptor layouts are the equivalent of SRT in Vulkan. It is unclear to me what exactly DispatchDraw is for, because back-face and offscreen culling are standard features of any graphics pipeline.
>Descriptor layouts are the equivalent of SRT in Vulkan.
I am not sure how. I do not use Vulkan, I use GNM. I asked this because implementing SRT does not seem possible in a platform independent API. So I checked the docs again and the descriptor layout is the same thing I remember - a set of bindings you manage through a bunch of API calls. On the other hand SRT is a plain c-structure. You pass a pointer to structure to a shader as a parameter. Exactly as same as you pass a structure to a function in C/C++. You don't need APIs to create sturctures, you can store them in a file, you can write them from another shader etc. etc.
> It is unclear to me what exactly DispatchDraw is for, because back-face and offscreen culling are standard features of any graphics pipeline.
It's pretty clear what is it for if you actually wrote real-time graphics. JFYI - it's "index shader" essentially. Having control over indices you can implement much faster culling.
> 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.
Indirect draw is a draw, which instead of direct arguments (number of indices, number of instances, offsets) takes an address of a structure with these parameters. It does not create indices. You could use it for culling but only on the level of a whole draw. DispatchDraw generates indices in a shader and can do a triangle level culling among other things.
Sure, it's possible, but it would be much slower(just for going off chip, not taking synchronization into account) than just letting all triangles through so it has no practical application. Again, even if this had been practical, it does not make DD same as ID. You can draw anything with OpenGl 1.0 but it does not make it the same API as Vulcan, does it?
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?
> So why would Sony throw all this away, just to make some Reddit and HN users happy, that wouldn't anyway make games for the PS4?
They won't have to discard their API - they can support Vulkan and their current API and make everyone happy. In this case 'everyone' includes people who would like to port their Vulkan games to PSNext as well as Vulkan-based graphics/game engines.
> 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.
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.
Vulcan, DirectX 12, and Metal are basically like C. They're made to be as low level as possible while maintaining hardware portability.
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.
It's not better, it's lower level than even Vulkan, and Vulkan itself is already very low level. Sure you can go as low as hardware specific machine code in theory. The question is whether it's something needed, or it's an overkill for most intents and purposes.
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.
There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions.
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.
> 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).
> There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions.
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.
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.
We don't really have enough experience to compare GPU assembly vs. SPIR-V. For pjmlp's claim that the PS4 API is "much better" than Vulkan to hold up, as far as I can tell you'd have to show that the codegen (i.e. passes after IR-level optimizations) of the driver's SPIR-V compiler can't match what game developers regularly do. I'm doubtful (instruction scheduling, for example, is too much to keep in your head to regularly beat a compiler), and especially so without data.
I'm also doubtful that developers can regularly beat optimizing compiler by a big margin. It's theoretically possible, but I'd expect it to be far from trivial, and as result require substantial effort every time it's needed.
I disagree. I regularly stomp all over the optimizing compiler, and it's not a massive amount of effort. It doesn't come for free though, and requires some upfront planning. The best way to think of it, IMHO is rather than thinking of "beating the compiler", think about working _with_ the compiler to help it do it's job.
I don't always agree with what he says, but Mike Acton has some good words and examples of this. https://www.youtube.com/watch?v=GPpD4BBtA1Y - a youtube talk where he talks about working with the compiler. The slides are at http://www.slideshare.net/cellperformance/gdc15-code-clinic In particular take a look at slide 69 and the few following it for an example of things the compiler can't figure out (for various reasons) that we can help it along with.
As I said, it should be possible in theory. It boils down to details. I.e. how good the compiler is and how hard is to do better than automatic optimization for given hardware. It's not a uniform yes / no situation.
That presentation is talking about IR-level optimizations, not codegen-level optimizations. Remember that SPIR-V is an IR, so you are free to manually do IR-level optimizations to your heart's content just as you can on the PS4.
Where IR-level optimizations are concerned, I agree that you can often do in areas like aliasing (where you, the programmer, have more knowledge than a compiler can easily prove). I'm much less convinced that you can beat a compiler at codegen-level optimizations: instruction scheduling, isel, register allocation, etc.
> As I replied on another comment, besides the lower level control of pushing pixels around
I haven't seen any "lower level control" here, except assembly vs. SPIR-V.
> Vulkan like OpenGL is leaving to the developers the effort to bring their own math library, OS integration and graphical debuggers.
A math library is trivial (and it seems odd that you would claim that not having a math library is a significant downside when your entire premise is "low level, minimalist APIs are better"). "OS integration" and "graphical debuggers" are not part of the API.
> For the rest most of it is hidden behind NDA walls, so you need to sign one to see the codegen examples.
Given that none of the presentation you linked was relevant (it was comparing against pre-DX12, not Vulkan), I doubt that signing an NDA would show me anything more.
What I've been repeatedly asking for is the specific technical advantage that the PS4 API has over Vulkan—in other words, what did Sony do right that Khronos did wrong? I'm interested from the perspective of a compiler writer and a graphics programmer. I haven't heard anything, and at this point I'm inclined to believe that no such thing exists.
Sony doesn't support OpenGL on PS4. Vulkan is a different story. It will depend on their mood. Their desire to deal a blow to MS might outweigh their lock-in habits.
It can be fully cross platform, as long as developers can access the system and its GPU. It doesn't include sick systems which are walled gardens and on purpose prevent cross platform technologies.
My question will probably sound naïve because of my lack of knowledge of the Macintosh, but Macintosh hardware nowadays seems to be the same than PCs. So what prevent Intel, AMD or nVidia to propose a driver for this platform in the same way they do it for Linux and Windows? Is there a legal reason? A technical reason?
My limited guess as a OpenGL developer on Os X is that it has something to do with Apple prodividing a software OpenGL -implementation also, so maybe they don't want to pour in the work in that to support the more recent advances in OpenGL ?
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.
> 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 understand that Vulkan is very, very niche but as someone who doesn't know much more than the basics of maybe setting up an OpenGL window to draw anything, the "drawing a triangle part" just seems insane!
I knew this is some hardcore, hardware-level stuff usually only ever touched by rendering engine programmers but I figured, if I had some super special niche case that could be sped up by Vulkan, I could maybe "give it a try". But this? 800 lines of code to draw a triangle! I never knew the difference to OpenGl was this extreme!
Well obviously there's a lot more boiler plate than OpenGL, but Vulkan's goal isn't to replace OpenGL in cases like yours.
And honestly, 800 lines of configuration is probably a godsend for people who want it, considering there's not much of a leap in terms of number of lines between drawing a triangle and drawing... well, anything else.
It's the difference between the C standard runtime library (OpenGL), where you can call `read` and calling the kernel directly via custom system calls to implement the functionality of read (Vulkan).
And like many modern applications, this power is necessary (like OCamal uni-kernels that re-implement system calls for high performance servers). Virtual reality can barely work on cutting edge graphics cards, even then the quality has to be low; to say nothing of augmented reality (which also uses the cards for image processing).
> It's the difference between the C standard runtime library (OpenGL), where you can call `read` and calling the kernel directly via custom system calls to implement the functionality of read (Vulkan).
In fact, that's just one line:
syscall(SYS_read, fd, buf, size);
I guess it's like writing your own SATA commands for the disk drive. Or like a car analogy of some kind.
The goal is that libraries will pop up to wrap around vulkan and give bare metal access to those who want to use it. It is necessary in order approach zero driver overhead. OpenGL is also not geared for multi threaded applications.
I figured that. I guess the days where an indie-ish indie developer would ever touch the bottom-level graphics API are over. Somehow that just seems a little sad.
> I guess the days where an indie-ish indie developer would ever touch the bottom-level graphics API are over.
They weren't touching it before, either. Great complexity is hidden in GPU drivers. Vulkan and DirectX 12 just makes it so you have to write a great deal of that complexity yourself, in hopes that you'll be able to optimize for your specific use case.
> I understand that Vulkan is very, very niche but as someone who doesn't know much more than the basics of maybe setting up an OpenGL window to draw anything, the "drawing a triangle part" just seems insane!
Every time a Vulkan/DX12 post is shared, this sort of comment is written. Modern GPUs are complex. They have a lot of knobs to turn. OpenGL has a lot of these same knobs, except they are implicitly turned for you in the most basic cases. But your average rendering code is nothing like the most basic OpenGL case, and involves much more knob turning.
You'll be fine. If you want to learn about how your modern GPU works, this will suit you. If not, no worries, you still have game engines.
Maybe that's old-fashioned but I'm just not a big fan of the "just use Unity" argument. Game engines tend to be horribly bloated, it's in their nature. Plus you're now dependent on a costly, proprietary black-box for the lifetime of the game, good luck if a screw is loose between the layers.
I guess the answer is that there is now a greater purpose than ever for in-between graphics libraries if all you want to do is draw a few triangles with a texture. They say they continue to support OpenGL in parallel, but considering that Vulkan was originally called "GLNext", I have my doubts about how long they want to continue to do that.
It's just that I haven't come across such a wall of code in a "beginner's guide" tutorial in quite a while. Feels a bit like they are moving to target big-budget engines exclusively, now. I see that this is in the nature of modern graphics hardware, but still.
Well, what are you trying to do (from a beginner's perspective)?
Are you trying to quickly understand how to draw a triangle to a screen with a texture? I would say...write a quick software rasterizer.
Are you trying to understand how modern GPUs work, and how to use them? Use Vulkan/DX12/Metal.
Are you just trying to draw a ball on the screen and kick it around? Use a game engine.
At this point, OpenGL doesn't really fit any of those boxes. What it does kinda do is...conceptually show you how 3D rendering works, but does it faster than your first software rasterizer would, and abstracts a bit of the math away if you use the API in just the right way.
The most important aspect of OpenGL is that it has a huge legacy catalog of software, including courses that teach 3D graphics programming with OpenGL.
> They say they continue to support OpenGL in parallel, but considering that Vulkan was originally called "GLNext", I have my doubts about how long they want to continue to do that.
Meh, they've been using "GLNext" in internal presentations forever. "Vulkan" as you know is basically AMD's Mantle more than an evolution to OpenGL. And don't you fret about OpenGL: lots of workstation apps still use it with no intent of changing, so...it'll stick around.
I suspect that you'll be able continue to use the tried-and-true methods, far, far into the future. OpenGL and DirectX11 aren't going anywhere anytime soon, and there are still games coming out with DX9 minimum specs. Last time I checked you can even use mid-90s OpenGL immediate mode calls.
At the very least, there will continue to be support for all of the thousands and thousands of legacy games, one way or another.
I look at Unity as a Camera. 100 years ago you needed to build your own camera if you wanted to shoot a movie. Now, almost no directors build their own cameras except for special needs (filming underwater for example).
So, do you want to make cameras or do you want to make movies? Translating to games. Do you want to make game engines or do you want to make games? Like the camera example, if you have some special needs maybe you want to make the game engine but for most games, like most movies, just using an off the shelf game engine will be good enough.
I agree with you GL is dead. There might be one more version of GL but after that there will be zero pressure to update it because all the top graphics people will be vulkan/metal/dx12 only
Developers that deal with high performance graphics want as much control as possible with their rendering pipeline. Vulkan gives them this control. Developers complained about the overhead that OpenGL and DirectX (before 12) imposed on their rendering pipeline and these bottlenecks would always be in the API of these graphics libraries. When you need to render a frame in 16ms or 30ms you can't afford precious milliseconds being wasted by bloated and inefficient API calls. Vulkan was created to address the years of complaints AMD received from game developers. So, while you may think that's a lot of code, a game developer would think otherwise.
This sentence stuck out to me, from the 'Overview' page:
"Because Vulkan is so explicit about every operation and the validation layers are so extensive, it can actually be a lot easier to find out why your screen is black compared to OpenGL and Direct3D!"
So Vulkan is verbose? Meh - do it once, put it in a function/class/etc abstraction of your choice. On the other hand, while I now know OpenGL well enough that I rarely have the black screen problem anymore, I've had the kind of lingering, conditioned fear of it hammered into me. I haven't spent enough time with Vulkan to witness it for myself yet but I find the above sentence encouraging.
90 comments
[ 3.2 ms ] story [ 98.0 ms ] threadI would scratch the fully, it's not on iOS or macOS
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.
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.
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.
If it's available, it'll certainly be a tempting target for those who have lower budget and those who need to port it faster.
http://develop.scee.net/wp-content/uploads/2014/11/ParisGC20...
Starts on slide 32 for the graphics part.
The presentation is from 2014, so when they claim "better than DirectX", they're referring to pre-DX12. It certainly doesn't back up your claim that it's "much better" than Vulkan.
I am not sure how. I do not use Vulkan, I use GNM. I asked this because implementing SRT does not seem possible in a platform independent API. So I checked the docs again and the descriptor layout is the same thing I remember - a set of bindings you manage through a bunch of API calls. On the other hand SRT is a plain c-structure. You pass a pointer to structure to a shader as a parameter. Exactly as same as you pass a structure to a function in C/C++. You don't need APIs to create sturctures, you can store them in a file, you can write them from another shader etc. etc.
> It is unclear to me what exactly DispatchDraw is for, because back-face and offscreen culling are standard features of any graphics pipeline.
It's pretty clear what is it for if you actually wrote real-time graphics. JFYI - it's "index shader" essentially. Having control over indices you can implement much faster culling.
This sounds like indirect draw, which has been standard for years and is supported by Vulkan.
You combine it with a Compute Shader to create the indices. Indirect draw is how you make those indices available to the drawing functionality.
Like another user has commented, the PS4 low level API is like Assembly in terms of hardware control, whereas the higher level, is is similar to Vulkan in API surface, is a bit more like C in terms of control.
Another area where the PS4 APIs are better is infrastructure, meaning graphical debuggers, libraries and OS integration.
Also the amount of production code experience that both Sony and licensed developers have with the whole stack.
So why would Sony throw all this away, just to make some Reddit and HN users happy, that wouldn't anyway make games for the PS4?
They won't have to discard their API - they can support Vulkan and their current API and make everyone happy. In this case 'everyone' includes people who would like to port their Vulkan games to PSNext as well as Vulkan-based graphics/game engines.
And as I've argued here, that isn't a plus. I don't believe that game developers are producing better GPU assembly than an optimizing backend can.
> Another area where the PS4 APIs are better is infrastructure, meaning graphical debuggers, libraries and OS integration.
That isn't part of the API. That's part of the tooling.
> Also the amount of production code experience that both Sony and licensed developers have with the whole stack.
That isn't part of the API either.
> So why would Sony throw all this away, just to make some Reddit and HN users happy, that wouldn't anyway make games for the PS4?
Er, nobody is talking about "throwing all of this away". I'm simply questioning your claim that Vulkan is worse than what Sony created for the PS4.
With the PS4 hardware is locked so their API is more like assembly (or maybe inline assembly in a C program) where you're doing specific hardware operations.
They also provide a second graphics API that wraps that one, working basically at the same level as Direct3D 11 or OpenGL.
This article might be of interest: http://www.eurogamer.net/articles/digitalfoundry-inside-play...
Consoles had a distinct need for assembly like level APIs - their hardware had very long update cycle (7+ years), so it used to quickly become outdated, and developers had to go to insane lengths to squeeze performance out of it. It's not only very costly to do it, it can't be reused (it's all platform specific). Currently consoles are moving away from these long cycles (under competitive pressure), so need for that will be less as well.
The same concept applies to Vulkan / DX12. The hardware manufacturers will know better than any developers about per-device shortcuts to put into their drivers, and if they do not need to maintain millions of LOCs of OpenGL state machine and validation layers they might find time to optimize the shader compiler to be in the same class of "the compiler is smarter than you" reasons not to use a hard ASM language.
In the case of consoles, all of them are using AMD based graphics, and when the next generation comes out they will all be on a similar cadence of GCN. I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM.
Good point. Today not to provide Vulkan on consoles is a political diversion (to make cross platform development more costly by taxing developers with doing the same thing multiple times).
I agree. In fact, the fact that it's not even a good idea in most situations to write in assembly on x86 CPUs proves the point even more. GPUs are less willing to spend die space on things like sophisticated branch prediction, complex superscalar architectures, register renaming, and so forth. This effectively means that GPUs punish naive codegen (which is the kind of codegen that humans without in-depth knowledge of the architecture tend to produce with their brains) significantly worse than x86 CPUs do. For an extreme example, look at the vector part of the low-power VideoCore IV architecture [1]: compared to a compiler, I don't trust myself for a second to program this optimally.
[1]: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
It's like saying that assembly is better than higher level languages. So propose writing everything in assembly as the next step? Everything has its trade-offs.
Hacker folklore: http://www.catb.org/jargon/html/story-of-mel.html
I don't always agree with what he says, but Mike Acton has some good words and examples of this. https://www.youtube.com/watch?v=GPpD4BBtA1Y - a youtube talk where he talks about working with the compiler. The slides are at http://www.slideshare.net/cellperformance/gdc15-code-clinic In particular take a look at slide 69 and the few following it for an example of things the compiler can't figure out (for various reasons) that we can help it along with.
Where IR-level optimizations are concerned, I agree that you can often do in areas like aliasing (where you, the programmer, have more knowledge than a compiler can easily prove). I'm much less convinced that you can beat a compiler at codegen-level optimizations: instruction scheduling, isel, register allocation, etc.
Vulkan like OpenGL is leaving to the developers the effort to bring their own math library, OS integration and graphical debuggers.
For the rest most of it is hidden behind NDA walls, so you need to sign one to see the codegen examples.
Graphical debuggers on the other hand are useful indeed. LunarG stopped working on Glave: https://github.com/LunarG/VulkanTools/commit/87220f80a643860...
Not sure what happened there. Valve were sponsoring Glave development.
Renderdoc is active (not Linux UI yet however): https://github.com/baldurk/renderdoc
I haven't seen any "lower level control" here, except assembly vs. SPIR-V.
> Vulkan like OpenGL is leaving to the developers the effort to bring their own math library, OS integration and graphical debuggers.
A math library is trivial (and it seems odd that you would claim that not having a math library is a significant downside when your entire premise is "low level, minimalist APIs are better"). "OS integration" and "graphical debuggers" are not part of the API.
> For the rest most of it is hidden behind NDA walls, so you need to sign one to see the codegen examples.
Given that none of the presentation you linked was relevant (it was comparing against pre-DX12, not Vulkan), I doubt that signing an NDA would show me anything more.
What I've been repeatedly asking for is the specific technical advantage that the PS4 API has over Vulkan—in other words, what did Sony do right that Khronos did wrong? I'm interested from the perspective of a compiler writer and a graphics programmer. I haven't heard anything, and at this point I'm inclined to believe that no such thing exists.
That is kind of the point of Vulcan.
[0] https://oneplus.net/3
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.
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 understand that Vulkan is very, very niche but as someone who doesn't know much more than the basics of maybe setting up an OpenGL window to draw anything, the "drawing a triangle part" just seems insane!
I knew this is some hardcore, hardware-level stuff usually only ever touched by rendering engine programmers but I figured, if I had some super special niche case that could be sped up by Vulkan, I could maybe "give it a try". But this? 800 lines of code to draw a triangle! I never knew the difference to OpenGl was this extreme!
And like many modern applications, this power is necessary (like OCamal uni-kernels that re-implement system calls for high performance servers). Virtual reality can barely work on cutting edge graphics cards, even then the quality has to be low; to say nothing of augmented reality (which also uses the cards for image processing).
In fact, that's just one line: syscall(SYS_read, fd, buf, size);
I guess it's like writing your own SATA commands for the disk drive. Or like a car analogy of some kind.
Isn't it about that to open a window that you can draw on in windows from first principles too?
Not that this is an acceptable situation, it just is.
http://pastebin.com/drrRJ6Kd
They weren't touching it before, either. Great complexity is hidden in GPU drivers. Vulkan and DirectX 12 just makes it so you have to write a great deal of that complexity yourself, in hopes that you'll be able to optimize for your specific use case.
Every time a Vulkan/DX12 post is shared, this sort of comment is written. Modern GPUs are complex. They have a lot of knobs to turn. OpenGL has a lot of these same knobs, except they are implicitly turned for you in the most basic cases. But your average rendering code is nothing like the most basic OpenGL case, and involves much more knob turning.
You'll be fine. If you want to learn about how your modern GPU works, this will suit you. If not, no worries, you still have game engines.
I guess the answer is that there is now a greater purpose than ever for in-between graphics libraries if all you want to do is draw a few triangles with a texture. They say they continue to support OpenGL in parallel, but considering that Vulkan was originally called "GLNext", I have my doubts about how long they want to continue to do that.
It's just that I haven't come across such a wall of code in a "beginner's guide" tutorial in quite a while. Feels a bit like they are moving to target big-budget engines exclusively, now. I see that this is in the nature of modern graphics hardware, but still.
Are you trying to quickly understand how to draw a triangle to a screen with a texture? I would say...write a quick software rasterizer.
Are you trying to understand how modern GPUs work, and how to use them? Use Vulkan/DX12/Metal.
Are you just trying to draw a ball on the screen and kick it around? Use a game engine.
At this point, OpenGL doesn't really fit any of those boxes. What it does kinda do is...conceptually show you how 3D rendering works, but does it faster than your first software rasterizer would, and abstracts a bit of the math away if you use the API in just the right way.
The most important aspect of OpenGL is that it has a huge legacy catalog of software, including courses that teach 3D graphics programming with OpenGL.
> They say they continue to support OpenGL in parallel, but considering that Vulkan was originally called "GLNext", I have my doubts about how long they want to continue to do that.
Meh, they've been using "GLNext" in internal presentations forever. "Vulkan" as you know is basically AMD's Mantle more than an evolution to OpenGL. And don't you fret about OpenGL: lots of workstation apps still use it with no intent of changing, so...it'll stick around.
At the very least, there will continue to be support for all of the thousands and thousands of legacy games, one way or another.
So, do you want to make cameras or do you want to make movies? Translating to games. Do you want to make game engines or do you want to make games? Like the camera example, if you have some special needs maybe you want to make the game engine but for most games, like most movies, just using an off the shelf game engine will be good enough.
I agree with you GL is dead. There might be one more version of GL but after that there will be zero pressure to update it because all the top graphics people will be vulkan/metal/dx12 only
Developers that deal with high performance graphics want as much control as possible with their rendering pipeline. Vulkan gives them this control. Developers complained about the overhead that OpenGL and DirectX (before 12) imposed on their rendering pipeline and these bottlenecks would always be in the API of these graphics libraries. When you need to render a frame in 16ms or 30ms you can't afford precious milliseconds being wasted by bloated and inefficient API calls. Vulkan was created to address the years of complaints AMD received from game developers. So, while you may think that's a lot of code, a game developer would think otherwise.
"Because Vulkan is so explicit about every operation and the validation layers are so extensive, it can actually be a lot easier to find out why your screen is black compared to OpenGL and Direct3D!"
So Vulkan is verbose? Meh - do it once, put it in a function/class/etc abstraction of your choice. On the other hand, while I now know OpenGL well enough that I rarely have the black screen problem anymore, I've had the kind of lingering, conditioned fear of it hammered into me. I haven't spent enough time with Vulkan to witness it for myself yet but I find the above sentence encouraging.