Check out our Monthly Survey Page to see what our users are running.

Whats Next In Graphics APIs

By - | Views: 16,111
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 GamingOnLinux.com.
0 Likes
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.
13 comments
Page: 1/2»
  Go to:

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 http://robertsspaceindustries.com/, especially the ship models in the "Holo Viewer" on certain ships that have their models released - click a ship's detail page from https://robertsspaceindustries.com/ship-specs

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.

gl.next 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 gl.next 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
mirv 29 Dec, 2014
View PC info
  • Supporter Plus
GL 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.
vulture 30 Dec, 2014
Quoting: mirvGL 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

mirv 30 Dec, 2014
View PC info
  • Supporter Plus
IR 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.
vulture 30 Dec, 2014
Quoting: mirvIR 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.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

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.