I would like to excuse for my incompetent/ignorant comment in advance, but wouldn't it be fairer to compare Vulkan with OpenGL 4.5 where indirect indexed draw calls are available? I also noticed that this demo avoids interactive animations (moving / reacting objects). In my experience with next-gen apis this results often in command dead-locks and inevitable queue-rollbacks.
The GPU in question here, the PowerVR G6430, does not support OpenGL 4.5. It tops out at OpenGL 3.2 since it's a mobile part so everyone is using GLES.
The blog post only somewhat touches on it but I believe a key part of why this is so much faster is that it sounds like Vulkan is actually exposing tiled-based rendering. Note that PowerVR is a tile-based deferred renderer under the hood[1]. So if the app is doing the work of chunking draws into tiles instead of the driver trying to extract that from the OpenGL stream that's going to be significantly more efficient.
Vulkan doesnt really expose tile based rendering. In the demo the scene is split into tiles and since the geometry is static they can prepare commands for gpu execution once for each of these tiles. This cannot be done in OpenGL which effectively has to repeat this work every frame (the driver hides this) There are of course other tricks to speed up crowds like this in OpenGL
Check the blog post after Wednesday, there are some things we cannot say yet.
The demos is slightly unrealistic yes and you could use multi draw indirect. But you would not be able to use multiple cores with that. As for moving objects, you would really just need to handle the objects moving between tiles and pass the animation matricies in the right places. It was thought about, but we didn't have time to implement.
Not necessarily, I believe they're demoing this against OpenGL ES specifically because of google recently announcing that Vulkan will be available on android[1]. Given the 4 cores that seems to line up, since a lot of ARM devices are going to multicore recently.
Vulkan is designed for modern GPUs, not the other way around. You would only have to wait for GPU vendors to write a new driver for their existing cards. NVIDIA, AMD, and a bunch of other large players are part of the Khronos Group designing Vulkan, so I wouldn't be surprised to see desktop/laptop GPU drivers a few weeks after the release of the finalized specification.
The only place you probably won't see a quick uptake is with mobile GPUs, since they essentially never receive updates.
While true, that doesn't invalidate robmaister's point.
If mobile GPUs as a class almost never receive updates, this will slow adoption of a new low-level way of using them, regardless of a few scattered exceptions to the "Mobile GPUs never receive updates" rule. :)
Yes, you don't "upgrade" your mobile phones GPU (or any hardware except the SD card), but many people change their smartphone yearly (and sometimes faster). So there's the "upgrade path" for mobile GPUs. I actually find it amusing that a phone or tablet with a new SoC has a "better" GPU than my 3 year old Core i3.
I said "update" as in "software update", not "upgrade" as in "hardware upgrade".
As I understand it (and I may not understand it well, as I don't do this for a living), SoC vendors are primarily in the business of selling hardware, rather than software. Everything that follows is second-hand information.
Often, folks who want an SDK for that SoC get the hardware, a bunch of blobs to run the hardware, and a particular version of an OS to run the blobs and any ancillary software. Given that the vendor is a hardware manufacturer, you're not infrequently forever stuck with whatever blobs and version of the OS you were handed. (Unless -of course- you can do the dev work on the OS or blobs yourself.) This lack of focus by the vendor on the software side of things implies that -say- interesting new graphics APIs are only available on the newest hardware. Even if the SoC vendor does do the work to port said API to their older hardware, the folks who used that hardware may not want or be able to verify their software with the new stuff from the vendor.
This is how an software update works in mobile: the GPU vendor writes the driver using a spec (e.g. Vulkan), then submits the driver for conformance testing with Khronos. Once the driver achieves conformance, the driver is made available to chip makers and OEMs. They take the driver and build an Android BSP; the new ROM is then pushed to consumers through an OTA. The GPU vendor has little control or influence over the update process beyond the point of providing the driver.
I don't see how it addresses any of my concerns, especially in light of the following things:
* Most Android phones are no longer officially maintained after three years. Many are abandoned much earlier.
* In order to get a GPU manufacturer to design and build a new driver, they must have some incentive to do so. For the not-leading-edge parts that I call out in my comment (and that make up the vast bulk of the SoCs in the field today), how do you create incentive for the GPU vendor to spend the time on these older parts? Money? Contracts?
Perhaps I'm missing something in your analysis, though.
I can't speak for all GPU vendors, but Imagination is actively developing a Vulkan driver for PowerVR Rogue GPUs (this is what the demo is running on). Beyond driver availability, I can't guarantee that OEMs and/or chip makers will license that driver and build new firmware with it.
It seems like your company is doing good work. Kudos! This in no way invalidates my point. Thanks for the info, though. :)
As an unrelated aside, you sort of seem to be indirectly addressing statements that I never made. Maybe I'm wrong here, but it kind of looks like you're speaking to a larger point that goes something like "Vulkan on SoCs will fail because noone will ever update their drivers."
So, here's how I engage in discussion:
I talk to and with people in order to exchange information. I try to be direct, to the point, and say exactly what I mean. Because I am long-winded, I am not always sufficiently terse. Because I am sometimes a mental spaz, I am not always able to put the right words in the right order to convey the right information. However, one thing I avoid like the plague is innuendo or other unspoken implication (except when used for obvious comedic effect). Having to decode hidden meaning in everyday conversation is tiring and tiresome; I've no desire to waste the time and energy of my conversation partners on such things.
When I make an accusation, or outline a scenario, the most literal interpretation of my words is the correct one. I don't have hidden agendas, and I welcome clarifying questions. Anything that I leave unsaid in my prose is a thing that I have forgotten or simply doesn't pertain to the current conversation. :)
Cool, thanks for the clarification. What I was trying to suggest is that we will encourage all of our partners to adopt Vulkan alongside OpenGL ES on Android, Linux or any other operating system that supports Khronos APIs. However, for some manufacturers, updating might not be an option due to factors like costs, development time, etc. So there is no absolute guarantee that every single device having a PowerVR Rogue GPU will have Vulkan. We can only promote it and hope that it happens since it is a really good API.
So, what are the chances of Vulkan drivers from devices makers "follow the tradition" of their OpenGL drivers and only implement half the spec with lots of bugs and lack of functionality
Vulkan is extraordinarily thin. There really isn't the large complex global state machine that OpenGL has -- the potential for complex bugs are a lot less.
Good point. Vulkan's purpose is for GPU hardware companies to stop having to write graphics software (drivers). GPU producers shouldn't be responsible for writing OpenGL compilers any more than AMD and Intel should be responsible for writing C/C++ compilers and Python VMs.
As I understand it, the goal is to move the API closer to the hardware. Hopefully so close that the driver will be very thin. There are plenty of software developers out there who can implement an OpenGL driver in Vulkan as well as the employees of AMD and Nvidia, I would think.
Having to rely on companies to update their drivers or open the source code has been a major pain point for a long time. Especially on mobile where there are many custom chips from different companies.
If Vulkan is too low level, perf will could be absolutely terrible. If chip makers expect a third party to -effectively- write an optimizing compiler for their graphics chips, they're probably[0] gonna have to tell people a lot more about those chips than they do already.
Worst case, maybe we're looking at another Itanium failure where noone decides that it's worth it to write such software.
(Note: I know next-to-nothing about Vulkan and only slightly more about modern graphics programming[1]. It's entirely possible that this worry is wholly unfounded. Also, given that the open-source AMD/ATI driver exists and has decent performance, it's highly unlikely that this will be a repeat of the Itanium failure.)
[0] Really, "they" is largely code for "Nvidia". :p
[1] I did a fair bit of fixed-function OpenGL software in a former life, tho! Remarkable how poor and ever-changing the support for that was from one NVidia driver revision to the next.
Developers have been asking for Vulkan for years. Essentially Vulkan and OpenGL ES provide two fundamental choices: going low level for highly tuned, architecture-specific optimizations (i.e. game engines) or high level, respectively, for quick and easy code writing that can run across multiple platforms (i.e. a simple UI or a 2D game).
> Developers have been asking for Vulkan for years.
I would wager that a very large slice of the folks doing graphics programming are largely incapable of writing a new high-performance graphics card driver.
Is there demand? Sure. Does anyone want to exert the effort required to meet that demand? I don't know.
Once upon a time, the CPU manufacturers were demanding a CPU that was easier for them to design, but just as performant. This lead to the Itanium, which had a simple hardware design but required very complex compilers for optimal performance. Thing is, noone wanted to expend the effort required to make a sufficiently clever compiler in order to get the best perf possible out of the CPU.
Anyway, if you can deliver more than platitudes, I'm all ears. I'm pretty ignorant on the topic and would love more information. :)
When I say developers, I mean graphics people like Unity, Epic, Gameloft, Steam etc. who want to have more control over performance optimization. When OpenGL was first designed, GPUs were fixed-function hardware that performed only a fraction of the tasks they handle now. Vulkan has been designed to be aware of tile-based renderers so that these developers can use them more efficiently. Driver and compiler development is a different topic although it is true that some parts of the driver will be more easier to write and manage.
> When I say developers, I mean graphics people like Unity...
Oh. You mean modern game 3D engine development houses. Okay. :) I would expect that these companies would be far more likely to employ very smart people than some random software house that also does OGL/D3D-driven graphics. However -as you allude to in your comment- skill in engine design and construction does not guarantee skill in graphics driver design and construction.
> When OpenGL was first designed, GPUs were fixed-function hardware...
Oh, I know. In my first message in this thread, I mention the fixed-function work that I did in a former life. I've read about OpenGL back when it was just SGI's GL. I've even made use of OpenGL's network transparency! :)
I think you've lost sight of why I started this thread.
runeks wrote:
> Vulkan's purpose is for GPU hardware companies to stop having to write graphics software (drivers)... Hopefully [Vulkan's API will be] so close [to the metal] that the driver will be very thin.
bobajeff replied:
> Having to rely on companies to update their drivers or open the source code has been a major pain point for a long time.
bobajeff seems to be thinking that Vulkan development will be handled primarily by third parties.
runeks's comment reminded of Itanium, a CPU whose programming API -as one could call it- was very, very thin; requiring compiler authors to do a huge amount of work -such as instruction scheduling- traditionally done by logic in the hardware.
A big reason Itanium failed in the wider market was because it asked far too much of what -i guess- could be called CPU driver writers. It hid far too little of what was required to get good performance out of modern CPUs, instead demanding that that work be offloaded on to compiler authors.
Do you see why I might be concerned about the same sort of problems with Vulkan? Can you provide some technical -rather than social- details about Vulkan plans to assuage this concern?
Ah, I see what you mean. I was thinking more in terms of market-driven motives for adoption rather than technical facts. Unfortunately, Vulkan is currently still under development and under strict NDA so I can't disclose any of the inner workings at this moment in time (beyond what we have posted on the blog). However, when the spec is final and public, we will talk a lot about the technical implications in more detail, offering code snippets and tutorials so developers can understand how to use Vulkan.
When it comes to Vulkan development, it is a pretty much a joint effort. We (the GPU providers) design the graphics processors and write the drivers/compilers to support Khronos. Then the application developers (the middleware guys) adopt their engines and libraries for Vulkan too in cooperation with us and other members of Khronos. Finally, the high-level application developers (e.g. games developers) port their software too. In addition, third parties might also create Vulkan open source drivers and compilers for the GPUs so it's a combination of in-house and third-party work.
Not quite although I get your point. Vulkan is designed for developers that want to get close to the metal (e.g. game engine guys). OpenGL ES will still live for high-level rendering.
I suspect the most intractable OpenGL ES issues on mobile have nothing to do with that state machine though. For example, some drivers have oddball hardware limitations on the complexity of shader they'll execute and silently miscompile or drop shaders if they exceed the limits. That's not going to go away with Vulkan.
The most intractable OpenGL ES issues on mobile have to do with the large amount of state kept, requiring long pipeline flushes, complex application-level batching, driver batching, and other things.
Normally, drivers try to batch up a lot of work, but being really subtle about things (calling glGet, for instance), you can accidentally cause a blocking flush of your entire state.
Making applications fast involves trying to defer and hack around this state machine as much as possible, while maintaining correct behavior. As such, you end up with tons of subtle, hard-to-find interaction bugs. I've debugged and fixed some of these in a certain mobile OpenGL driver we're deploying on our platform we licensed from the vendor.
This is independent from other tricky bits of OpenGL ES, like the shader compiler front-end choking on perfectly valid GLSL, because there's no compliance tests for any of it.
Hard to say yet, but since one of the design goals of Vulkan is to address this very issue, it seems inept to assume they can't/won't improve things w.r.t drivers before there is evidence.
Google will be porting their Android OpenGL ES conformance test suite to Vulkan and will donate the source to the Khronos group [1].
----
For Vulkan, we’ll not only develop similar tests for use in the Android CTS, but we’ll also contribute them to Khronos for use in Vulkan’s own open source Conformance Test Suite.
----
> So, what are the chances of Vulkan drivers from devices makers "follow the tradition" of their OpenGL drivers and only implement half the spec with lots of bugs and lack of functionality
High if Khronos doesn't provide a comprehensive certification suite. Dunno what's the status for Vulkan, but OGL/OGLES versus D3D (any feature level) is a joke. :S
Any progress on getting OSS drivers for the PowerVR prodcut family? Security demands I keep an updated system, but that's not really practical with closed-source drivers.
