Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: The New Graphics and Compute API - GDC 2015 Sessions

  1. #1
    Administrator Regular Contributor Khronos_webmaster's Avatar
    Join Date
    Apr 2007
    Location
    Montreal
    Posts
    159

    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
    Webmaster Khronos.org and OpenGL.org

  2. #2
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,485
    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).

  3. #3
    Newbie Newbie
    Join Date
    Feb 2015
    Posts
    1
    Quote Originally Posted by Alfonse Reinheart View Post
    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

    Bye,
    JB.

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,136
    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?
    Last edited by thokra; 03-04-2015 at 05:41 AM.

  5. #5
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,485
    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.

  6. #6
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,136
    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.

  7. #7
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,485
    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.

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,136
    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?

  9. #9
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,485
    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 ).

    Basically, OpDecoration is how SPIR-V spells "layout".

  10. #10
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,294
    Quote Originally Posted by thokra View Post
    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:
    Code :
    // 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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •