Confused on Steam Play and Proton? Be sure to check out our guide.

Whats Next In Graphics APIs

By - | Views: 16,959
Neil Trevett from Nvidia shared a presentation about what's going on in the world of graphics APIs.

I don't really have many thoughts on it, other than just that I am waiting to see what happens with Mantle from AMD, and OpenGL Next.

I really hope that the next generation OpenGL is well adopted, and that Linux has good drivers for it.

See the full slides and source here.

Tell us your thoughts. Sorry I am a few weeks late on posting this too, oops. Article taken from
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.

StianTheDark 27 Dec, 2014
Thought it was a new YouTube player :P Not the prettiest video player I've seen!
jordicoma 27 Dec, 2014
And what is the status? It's something done? Hope they achieve all they say about opengl (future).
Quoting: jordicomaAnd what is the status? It's something done? Hope they achieve all they say about opengl (future).
Status is slide 15
pd12 28 Dec, 2014
Quoting: page 6OpenGL 4.4 is a superset of DX11
- well I never knew that.

The benefits on p.12 might mean that AMD/ATI will have more competitive drivers for OpenGL Next. =)

You can see some cool WebGL stuff at, especially the ship models in the "Holo Viewer" on certain ships that have their models released - click a ship's detail page from

Yay for unprecedented level of participation from game engine ISVs! =)
Ooo OpenCL for Embedded and Safety-Critical applications on Roadmap (p.17)
And apparently a lot of my goto software use OpenCL: VLC, X264, FFMPEG, Handbrake, GIMP, ImageMagick, IrfanView

Lol, that "Matrix" representation of Data on p.26
Interesting slide on p.31,33 - OpenCV and OpenVX complementary.

p.36 - interesting slide showing how Khronos' APIs work together in an Augmented Reality environment! =)
jordicoma 28 Dec, 2014
Quoting: Madeanaccounttocomment
Quoting: jordicomaAnd what is the status? It's something done? Hope they achieve all they say about opengl (future).
Status is slide 15
By status I mean what is done so far. How it will look like. And when we will be able to try it/learn it. It will be ready for the next siggraph? It has reach 50%? It will be more c++ friendly? etc... Hope if it's smaller and simple api we will see the drivers compatible soon. We haven't even get a stable nvidia opengl 4.5 driver yet.
vulture 29 Dec, 2014
Quoting: pd12
Quoting: page 6OpenGL 4.4 is a superset of DX11
- well I never knew that.

well, this is a known fact. same as two other sadly. and more is not always better if more is done in a wrong way

shaders not being reliably equally implemented, since shader compiler is in each driver. one driver might suffer from compile time issue, while other might suffer from conformity and so on

humongous methods acting out in 1000 and 1 way, where implementation of each vendor cannot even test all the posibillities. this led to drivers being incomplete or drivers being crappy or drivers being good. solves both problems.

shader compiler is not something left to driver, there is only one shader compiler (just like in directx) and that one is provided by khronos. all that driver needs to implement is CIL execution, which is trivial compared to compiler.

methods are small and testable.

if everything is done as on paper, i can really imagine we will see gl4.5 on implementation where it will work reliably against all vendors, not to mention that this would also solve all the previous problems. kind of like mesa or galium nine is now
vulture 30 Dec, 2014
Quoting: GuestGL next will not have one compiler, just one IR. There is more to compilers than that. The main idea is really to allow distribution of shaders without source access - it won't improve compiling times noticably, or have any other effect.
It might, however, help improve the conformity situation eventually.

which means exactly what i said. i didn't say compiler times will improve, i said they won't be better/worse between vendor. they can be equal if used common crossplatform compiler front end. also, since vendors can ship precompiled into IR which is simpler than raw source, those start up times will be faster

there is a big difference in complexity between making compliant compiler and compliant IR execution. right now, compliance varies between drivers

vulture 30 Dec, 2014
Quoting: GuestIR does not cover optimisation and linker passes of compilation. Those are the most time consuming phases of shader compilation - an initial IR pass is trivial by comparison, so startup times won't really be any faster.
I just hope that multiple shaders can be compiled simultaneously with the new GL. That would be worth something.

just currious why would you stop at initial phase. if i remember correctly you create initial IR and then start branching for optimizations. i don't really see how most optimizations could differ between drivers. especially when you ave defined the IR it executes.

right now, you can write source that won't work on some vendor. IR won't allow that. as far as they were saying it won't even allow one platform to behave differently than other which is done by common compiler front end. it also means a lot less porting work

but, then again only IR i work with is mono. startup time with mono is already negligible, but you can always enable AOT.
vulture 30 Dec, 2014
Quoting: Guest(excuse short reply and lack of links - forced to use a tablet for a few more days)
It comes down to GPU architecture differences. GL doesn't use any sort of interpreter, and I doubt they'll introduce one because it'd kill performance. So while basic optimisations might be done, any generic IR can only make very limited assumptions about supported instructions, available registers and width, etc.
This was covered fairly well in one of the steam dev day talks I think.....
As for timing issues, that was from nvidia showing what could and couldn't be done to reduce runtime impact of generating shaders on the fly.

makes sense, thanks. not all optimization passes can be done

now... this is just my opinion. any driver could provide AOT if they wanted to counter that. optimize on first run when running on specific card/machine, then use already precompiled shaders.

but, still main thing here is single shader working everywhere, no matter of platform or vendor. speed up is the least of what games on linux need. conformity beats that by miles. and making conformant IR driver is far easier than providing conformant compiler in driver. IR simplifies driver a lot. small and testable methos do the same

selling niche of is not "will be faster than others", it is "it's down to metal as possible with some compromises that might slow it down a bit, but same thing should work on any platform/vendor". if it has decent speed, but at the same time it allows developer to write once for all platforms... win. more sales, less work is exactly what is needed to boost linux gaming. that is something where gl blows. it does work everywhere, yes... but, not all vendors have all extensions and not all vendors guarantee same shader will work since they might not support some extension. this not only makes writing optimized newer gl harder, it also makes a lot more QA cost
godlike 31 Dec, 2014
The motivation for GLnext's IR:
- Bugs (or spec misinterpretations) in driver compilers. This is a huge pain for developers.
- Nobody targets GLSL. Big engine developers write their shaders in HLSL and then compile the source to IR's for DX and consoles (and some of them to GLSL, Unity)
- Obfuscate the shader source (Nobody admits it but many want it)

What GLnext's IR is not:
- Compile times won't be significantly faster
- It will not perform any heavy-weight optimizations. This is up to the driver's compiler because the driver compiler knows better
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.