Vulkan Tutorial
vulkan-tutorial.com
vulkan-tutorial.com
I 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.
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.
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.
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.