OpenGL 4.5 Is Not The End Of The Road For OpenGL

[Luke_Wolf]

Some day, some one will reimplement OpenGL and Direct3D as SPIR-V drivers. Then it would be clear that OpenGL/Direct3D are to SPIR-V what Qt/GTK+/Motif are to X11.

fixed that for you.

[elect]

You need to deal with them either way. Want to use std::thread? Go ahead. No one is forcing you to use pthreads with Vulkan. You can even use Vulkan from languages like Rust. Memory management is OK if you use RAII. If you can't deal with threads - better learn how to do it if you plan to make games.

Of course, but since I am a small (nub) dev I prefer doing it through higher abstraction and let the driver do the rest. I am fine with multi-thread on cpu side and single on rendering, but I see multi-threading rendering very error prone for me..

[shmerl]

Of course, but since I am a small (nub) dev I prefer doing it through higher abstraction and let the driver do the rest. I am fine with multi-thread on cpu side and single on rendering, but I see multi-threading rendering very error prone for me..

Anything can be error prone if not thought through and not designed well. Even higher level abstractions won't preventing from shooting in one's foot if developers don't know what they are doing (they can reduce the risk only). Languages like Rust help if you stay in their domain, but once you go into unsafe (outside the language) - it's the same issue.

[bridgman]

fixed that for you.

Don't understand your fix. Graphics APIs have two parts - shader language and runtime calls. SPIR-V covers the shader language part, but you still need runtime calls as well.

AFAIK implementing OpenGL over Vulkan (which implies SPIR-V) is more "correct" than implementing over SPIR-V alone.

[mr_tawan]

I'm not sure what relevance this question has. SDL uses OpenGL in two places:

1. The Render API, which is a GPU-accelerated 2D API intended for porting old DirectDraw-based games to modern systems.
2. The API calls to create an OpenGL window, which you then draw to using the standard OpenGL APIs, since OpenGL doesn't standardize creating drawing contexts.

For #1, there isn't really much need for Vulkan since OpenGL already greatly exceeds the Render API's needs.
For #2, it's a no-brainer that they'll add some API calls to create a Vulkan window and call it a day.

Well if they are going to support Vulkan, they would have to do both anyway. If only the #2 is implemented that then the custom Vulkan code would conflict with the renderer creates in other API (unless Vulkan works peacefully with OpenGL/GLES's context). In OpenGL's case there are functions that bridge between Render API and OpenGL, like `SDL_GL_BindTexture()` and `SDL_GL_UnbindTexture()`, and I expects the same thing with Vulkan.

From what I see in their mailing list there isn't much going on about Vulkan, probably because the API itself is not published yet so not many people have enough information to discuss. I think Vulkan-specific code is being implemented though, as the Steam Runtime (if I'm not mistaken) uses SDL under the hood (in Linux), and Sam is working for Valve now.

[elect]

Anything can be error prone if not thought through and not designed well. Even higher level abstractions won't preventing from shooting in one's foot if developers don't know what they are doing (they can reduce the risk only). Languages like Rust help if you stay in their domain, but once you go into unsafe (outside the language) - it's the same issue.

That's obvious, but it is way more easier at lower level

[Luke_Wolf]

Don't understand your fix. Graphics APIs have two parts - shader language and runtime calls. SPIR-V covers the shader language part, but you still need runtime calls as well.

AFAIK implementing OpenGL over Vulkan (which implies SPIR-V) is more "correct" than implementing over SPIR-V alone.

Everything I've read about it made it sound like SPIR-V is roughly equivalent to but a bit lower level than gallium, which you can then write arbitrary APIs (or even IL transformers, like LLVM -> SPIR-V or CIL -> SPIR-V) ontop of, of which Vulkan is only one way to do it. Is this understanding wrong bridgman?

[Philip]

Everything I've read about it made it sound like SPIR-V is roughly equivalent to but a bit lower level than gallium, which you can then write arbitrary APIs (or even IL transformers, like LLVM -> SPIR-V or CIL -> SPIR-V) ontop of, of which Vulkan is only one way to do it. Is this understanding wrong bridgman?

Gallium contains TGSI, which is a vendor-independent intermediate representation of shader programs. SPIR-V is roughly equivalent to TGSI, not to the whole of Gallium. (In the same way, it's roughly equivalent in functionality to GLSL (though binary rather than text-based), not to the whole of OpenGL.)

GPUs require a lot more functionality than just their shader cores: there's fixed-function hardware for rasterisation, depth testing, blending, as well as all the memory management and synchronisation, etc. GLSL/TGSI/SPIR-V don't cover any of that stuff - that's all handled by the rest of the OpenGL/Gallium/Vulkan APIs.

If you want to use SPIR-V as a component of a different API like, say, OpenCL, then the OpenCL specification still has to define all the work item dispatching and memory management and synchronisation etc itself, and OpenCL drivers have to implement all that themselves. The only thing SPIR-V provides is the intermediate representation for code that runs on the shader cores, which is an important part of the API but a long way from being the whole API.

I think there's nothing very novel about SPIR-V's functionality - it's taking concepts that are already widely used in graphics drivers and OpenCL drivers in a dozen different variants, and standardising them into one well-designed multi-language multi-API multi-vendor design (which is exactly what a good standard should be doing!)

[bridgman]

Everything I've read about it made it sound like SPIR-V is roughly equivalent to but a bit lower level than gallium, which you can then write arbitrary APIs (or even IL transformers, like LLVM -> SPIR-V or CIL -> SPIR-V) ontop of, of which Vulkan is only one way to do it. Is this understanding wrong bridgman?

Your interpretation is correct, however:

1. The "which you can then write arbitrary APIs ... ontop of" part is incorrect - you can write IL transformers but you can't write APIs.

2. The counterpart to SPIR-V (the shader representation used by Vulkan) is TGSI, the shader representation used by Gallium3D, not Gallium3D itself. What matters most is the Vulkan API to Gallium3D API comparison, not the SPIR-V to TGSI comparison. I say that because the shader language inputs are compiled down to hardware instructions anyways, so whether SPIR-V is a bit higher or lower than TGSI doesn't really matter.

3. If you ignore SPIR-V and focus on the Vulkan API vs the Gallium3D API, my impression is that they are at relatively similar levels, although on average I would say Vulkan is a bit higher level than Gallium3D.

BTW if you want to get an idea of what the Gallium3D API is like, the pipe driver context header is probably the best place to start :

http://cgit.freedesktop.org/mesa/mes...pe/p_context.h