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

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

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.

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 gl.next 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

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