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.

glNext: The Future of High Performance Graphics
Date: Thursday, March 5
Time: 10:00am - 11:00am
Location: Room 2006, West Hall

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.

More on the Next Generation of Graphics and Compute API
Date: Thursday, March 5
1st session: 12:00pm – 1:30pm
2nd session: 2:00pm – 3:30pm
Location: SF Green Space

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.

Register for the 1st session
Register for the 2nd session

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).

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

Bye,
JB.

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?

According to the Vulkan (ugh) overview slides, that really is their intention. For OpenGL to still exist and still be updated alongside Vulkan (ugh).

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

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?

I’m quite curious as to how this is going to be resolved.

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.

Let shader objects die already.

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. :slight_smile:

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 :wink: ).

Basically, OpDecoration is how SPIR-V spells “layout”.

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

// vertex shader output
vec3 outposition : POSITION;

// fragment shader input
vec3 inposition : POSITION;

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.

Damn, thank you. That’s a lot of decorations. The example for the fragment shader above the “Decorations” sections actually shows some of them (smooth, noperspective) and even some names, but no location which seems to be crucial to linking.

Admittedly, I don’t fully understand what the “Component” decoration is used for.

My point is that it’s already a solved problem, and has been for many years.

It’s also solved for GLSL. However, if you translate to an IL which (at least it seemed so at first) doesn’t carry the information which current GLSL linkers in part use to do the matching, then one might feel that something is missing. :slight_smile:

Admittedly, I don’t fully understand what the “Component” decoration is used for.

It’s from ARB_enhanced_layouts, one of the cooler 4.4 things. It lets you have two (or more) variables share the same location, but different components within it. Since each vertex shader input and fragment shader output is always (internally) some kind of vec4, it lets you save space on rendering inputs/outputs.

For example, if you have two 2D texture coordinates to pass to a vertex shader, you could give them separate locations. But since inputs are effectively vec4’s, you’re effectively throwing away a location needlessly. You could use a vec4 in your shader, but then you have to treat it semantically like a vec4. That looks ugly in the shading language, since it’s basically a hack.

The component designation allows you to have one vec2 use the first two components of the location, with the second two going to a different vec2 variable in the same location.