
Gnomes per second in Vulkan and OpenGL ES - alexvoica
http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-and-opengl-es
======
Am-hehu
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.

~~~
kllrnohj
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.

1: [http://blog.imgtec.com/powervr/a-look-at-the-powervr-
graphic...](http://blog.imgtec.com/powervr/a-look-at-the-powervr-graphics-
architecture-tile-based-rendering)

~~~
olaulaja
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

~~~
ashleysmithgpu
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.

------
Drakim
When it says "Vulkan driver for PowerVR Rogue GPUs", does that mean I can only
use Vulkan when the user has a GPU that supports it?

...Because that sounds like it could be a really long wait, if it happens at
all.

I guess it could work for the gaming console market?

~~~
robmaister
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.

~~~
dr_zoidberg
The post specifically targets a mobile GPU. Relevant links:

[1]
[https://en.wikipedia.org/wiki/PowerVR#Series_6_.28Rogue.29](https://en.wikipedia.org/wiki/PowerVR#Series_6_.28Rogue.29)

[2] [http://anandtech.com/show/7335/the-
iphone-5s-review/7](http://anandtech.com/show/7335/the-iphone-5s-review/7)

~~~
simoncion
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. :)

~~~
dr_zoidberg
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.

~~~
simoncion
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.

~~~
alexvoica
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.

~~~
simoncion
Thanks for the info.

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.

~~~
alexvoica
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.

~~~
simoncion
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. :)

~~~
alexvoica
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.

------
raverbashing
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

~~~
Jasper_
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.

~~~
runeks
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.

~~~
bobajeff
I hope this is right.

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.

~~~
simoncion
Sure, but:

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.

~~~
alexvoica
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).

~~~
simoncion
> 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. :)

~~~
alexvoica
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.

~~~
simoncion
> 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?

~~~
alexvoica
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.

------
justabystander
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.

------
10098
Is the Vulkan spec out already? Where can I get it?

~~~
tsomctl
AMD has released a specification for Mantle, which is the predecessor of
Vulkan: [http://www.amd.com/Documents/Mantle-Programming-Guide-and-
AP...](http://www.amd.com/Documents/Mantle-Programming-Guide-and-API-
Reference.pdf)

There is also a demo and sdk for Mantle here:
[https://github.com/Overv/MantleHelloTriangle](https://github.com/Overv/MantleHelloTriangle)

