Whats Next In Graphics APIs

Thought it was a new YouTube player :P Not the prettiest video player I've seen!

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

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! =)

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.

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

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.

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

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.

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.