The New Graphics and Compute API - GDC 2015 Sessions

There will be 3 sessions at GDC this year covering "glNext" all on March 5th. Included here is an overview of the sessions. For complete details, and seat reservation information, please visit the event page.

Join us for the unveiling of Khronos' glNext initiative, the upcoming cross-platform graphics API designed for modern programming techniques and processors. glNext will be the singular choice for developers who demand peak performance in their applications. We will present a technical overview of the API, advanced techniques and live demos of real-world applications running on glNext drivers and hardware.

Take a break from the Moscone crowds and join us at SF Green Space (see map and directions below) for more about this exciting new API, whether you missed the 10:00am session at Moscone or just want to learn more. We’ll have many of the speakers and demos that were presented at the 10:00am session, and we will have plenty of time for Q&A. While you’re here, pick up a reference guide, and more.You DO NOT need a GDC conference or exhibitor pass to attend, however seating is limited. If the first session is full, come to the encore session at 2:00. Please register for your session below.

I don't suppose that there's even the slightest chance that there will be videos of these available.

I also find it a bit disconcerting that this is being called a "graphics and compute API". The API being singular. While I'm sure that there would be benefits to various compatibility in having the compute and graphics APIs being the same, these are two different domains.

I'm sure compute-only people don't want to have to put up with the 80% of the API that deals in graphics, and us graphics-only people don't want to have to handle the cruft that the compute API will enforce (such as slower shaders. GLSL and OpenCL have different requirements for shader precision and such). Not to mention the whole CPU-side element of OpenCL, which is virtually useless in graphics work (or at least, we'd just write a real thread for it).

I don't suppose that there's even the slightest chance that there will be videos of these available.

One of the presenter (John McDonald) said on reddit that the main session will be recorded.
But if I understood this correctly I don't know if they will be available immediatly though, as you need to subscribe to GDC to get the last videos (previous years videos are freely available in the GDC vault).
I doubt that the extended talks (at SF Green Space) will be recorded as they are Q&As.

Sorry, new account, can't post a link, see reddit .com/r/linux_gaming/comments/2ujojs/glnext_opengl_successor_to_be_unveiled_at_gdc/co9ilpe

I found the following statement and especially one word in there very surprising:

Vulkan expands the family of Khronos 3D APIs, and complements OpenGL and OpenGL ES that between them, provide access to billions of GPUs today, and will continue to be evolved and maintained to meet industry needs.

I might be misunderstanding the sentence as a whole, but I was under the impression that the next gen API was supposed to replace OpenGL, not live alongside it. Is OpenGL to elvolve on a separate path? When will OpenGL reach its end of life?

So there would be two graphics APIs: one low-level, and one not-so-low-level.

Aside from not being too enthusiastic about that, I suspect the low-level part would then still maintain the cruft that motivated Vulkan (ugh, why?) in the first place. Unless, the evolution of OpenGL actually means making a clean cut and essentially giving us the low-level equivalent of the graphics related subset (and the minimal compute subset) of Vulkan (ugh, srsly?). Also, would OpenGL implementations then provide a GLSL compiler able to translate to SPIR-V and would OpenGL be extended to be able to compile shader objects from SPIR-V? Will there be other kinds of interop? Will OpenGL and Vulkan maintain feature parity?

Aside from not being too enthusiastic about that, I suspect the low-level part would then still maintain the cruft that motivated Vulkan (ugh, why?) in the first place.

When I said two graphics APIs, I meant Vulkan and OpenGL. Vulkan being the low-level, and OpenGL being not-so-low-level (ie: where it is now).

And yes, I'd guess that the idea is that they will maintain feature parity. That's what the slide suggested, at any rate. They're probably not going to do anything radical with OpenGL, like another round of deprecation/removal or something.

Also, would OpenGL implementations then provide a GLSL compiler able to translate to SPIR-V

Khronos said that the GLSL-to-SPIR-V compiler will be open sourced. So if you need one... just use that. No need to force implementations to stick that code into their drivers.

and would OpenGL be extended to be able to compile shader objects from SPIR-V?

God, I hope not. I'd much rather they just standardize SPIR-V as a separable Program Binary format that all implementations can use. Though it would make program introspection... interesting, to say the least, since SPIR-V interfaces don't have to be named.

When I said two graphics APIs, I meant Vulkan and OpenGL. Vulkan being the low-level, and OpenGL being not-so-low-level (ie: where it is now).

My bad, I twisted the two and worded it badly as well.

Though it would make program introspection... interesting, to say the least, since SPIR-V interfaces don't have to be named.

How does one do interface matching between program stages, if interfaces cannot be identified by name? Unique IDs generated during GLSL->SPIR-V translation? Am I missing something? Or can they be named to be able to process such cases?

How does one do interface matching between program stages, if interfaces cannot be identified by name? Unique IDs generated during GLSL->SPIR-V translation? Am I missing something? Or can they be named to be able to process such cases?

That's actually covered (though don't feel bad for not seeing it. It took me a while to find it too; you have to look in the actual spec, since the introduction was written for OpenCL programmers). Variables, and declarations, can have these decorations associated with them. These are used to specify things like built-in variables (for gl_Position, gl_FragCoord, and the like), but they also specify "location", "binding", even "component" (which I rather thought was odd, considering SPIR-V's low-level focus, but I'll take it ).

How does one do interface matching between program stages, if interfaces cannot be identified by name? Unique IDs generated during GLSL->SPIR-V translation? Am I missing something? Or can they be named to be able to process such cases?

D3D resolves this by attaching semantics to the input/output and instead of matching by name it matches by semantic:

If it's in the output but not in the input it's silently discarded (and a runtime warning or error may be generated). If it's not in the output but is in the input it can get the default of {0, 0, 0, 1} (with likewise an error or warning generated). This can all be well-defined and part of a hypothetical conformance test.

This may or may not be the approach that Vulkan adopts; that's not my point. My point is that it's already a solved problem, and has been for many years.