4 ms·

I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, especially when OpenGL does its

by fizixer 12y ago

I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, especially when OpenGL does its job (as a graphics library) in a very crappy manner by trying to be part-framework, part-library, and not doing either properly, and making the life of a graphics programmer a living hell, who has to code 80% of the graphics pipeline by hand or using third party matrix libraries anyway. I realized this very strongly when I considered doing graphics using OpenGL but with a photorealistic renderer like a path tracer. Currently the only reason for OpenGL over GPU being inevitable is that GPU vendors don't provide access to "non-GPGPU" parts (like TMU, ROP) directly to OpenCL (or CUDA), which is clearly a matter of design rather then technicality. Unsurprisingly, people were offended or upset (you either don't use OpenGL, or you end up defending it against criticism, subconsciously, because you have invested so much time learning it). I hope something good comes out of this initiative.

jamesfmilne 12y ago
I've spent 15 years working on OpenGL, but I'd kick it to the kerb in a heartbeat. AMD and NVIDIA are free to implement Vulkan on Windows and Linux, but the problem is that we will probably be stuck with OpenGL 4.0 on Mac OS X for the foreseeable future.
- saschispatzi 12y ago
  I don't know too much about the topic (I wish I did), but how what makes you think so? I see that it says "Will work on any platform that supports OpenGL ES 3.1 and up" and Apple platforms seem not to support that (as of now). However Apple is part of the working group, doesn't that make it very likely they are working on an implementation, too?
  - readstoomuch 12y ago
    Apple are traditionally tardy when it comes to OpenGL. Yosemite is still on 4.1 (2010 release), lacking support for things like compute shaders.
    - saschispatzi 12y ago
      Oh, I see, didn't realize that. That is a pity because I would very much like for cross platform gaming to become much more of a thing and Vulkan does seem likely to be a big milestone in that, esp. considering Valve's involvement.
      - pjmlp 12y ago
        Cross platform gaming equals to game engines abstracting graphics APIs. Despite urban legends propagating the myth, games consoles don't feature OpenGL APIs as such, rather using more low level ones, even if inspired by OpenGL.
    - tormeh 12y ago
      This explains why CryEngine supports Linux but not Mac. CryEngine requires OpenGL 4.3 as that's what was the easiest translation target for CryTek from DirectX 11.
    - ixtli 12y ago
      It seems like it's unfair to say "Apple are late with OpenGL features." The third parties could put the same effort into making drivers for OS X that they do into making them (and their crapware frontends) for Windows, but they don't. I may be wrong, but it appears to me that it's Apple doing most of the work.
      - deleted 12y ago
        [deleted]
      - jsheard 12y ago
        There's not much hard information on how Apple deals with graphics drivers, but from what I gather they use a unified in-house OpenGL frontend for the hardware-independent layer, then defer to a modified version of the vendors driver for the low-level stuff. Their frontend only implements up to GL 4.1, so even if the vendors were to release drivers independently there would be no way for an app to access the newer functionality through the OS X frameworks.
      - deleted 12y ago
  - jamesfmilne 12y ago
    I'm a cynic, but don't get me wrong, I'd be delighted if Vulkan or OpenCL 2.1 show up in OS X 10.11. Khronos is a funny beast, a bit like the United Nations. Just because these companies are all part of it doesn't mean they actually like each other and want to cooperate! Apple has famously lagged far behind with their implementation of OpenGL. They only support OpenGL 4.1, the spec for which was released in 2010 [1]. Their developer tools are also pretty lacking on the desktop, and because they keep their drivers closed, external vendors can't do much to help. (Apple write their own drivers for Intel, NVIDIA and AMD GPUs, and even the engineers at those companies have little insight to what goes on behind Apple's closed doors.) Perhaps this new, streamlined Vulkan API will be easier and more attractive for Apple to implement. We live in hope... [1] http://en.wikipedia.org/wiki/OpenGL#OpenGL_4.1 http://en.wikipedia.org/wiki/OpenGL#OpenGL_4.1
    - mbel 12y ago
      > Khronos is a funny beast, a bit like the United Nations. Just because these companies are all part of it doesn't mean they actually like each other and want to cooperate! It seems to me that this is an accurate description for any technology focused consortium or work group.
- jitl 12y ago
  From the website: > Will work on any platform that supports OpenGL ES 3.1 and up Furthermore, Apple is on the working group.
  - jamesfmilne 12y ago
    It doesn't just magically work, someone still has to write the drivers & user space libraries. Apple would also then have to support three graphics APIs, vintage OpenGL, Metal (on iOS) and Vulkan (on iOS and OS X?), across four hardware platforms (AMD, NVIDIA, Intel, Imagination on ARM).
  - jsheard 12y ago
    It's a single data-point, but Apple was on the working group for KHR_debug and still hasn't implemented it three years later.
pjmlp 12y ago
Google tried this when they introduced RenderScript, but they dropped support for graphics calculations on the second release and steered it into a way to use C99 with GPU capabilities, without having to drop into the NDK.
datenwolf 12y ago
> I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, > (...) > I realized this very strongly when I considered doing graphics using OpenGL but with a photorealistic renderer like a path tracer. Well, then you're going be disappointed by Vulkan as well. OpenGL (and modern GPUs) are built around screen space rasterization of points, lines and triangles. Being aimed primarily at the graphics part of GPUs, Vulkan uses the same primitives. The major difference to OpenGL is, that you no longer do stuff like glGenTextures(...) glBindTexture(…, texID) glTexStorage…(...) glTexImage…(...) glActiveTexture(... + i) glBindTexture(…, texID) glUniform1i(sampler_index, i) operating on a global, TLS driver state, which the driver has to queue and reorder into a command stream to the GPU. Instead you allocate some memory (using the Vulkan API) map it, write to it directly and set elements of a resource descriptor to what the layout of the data in that memory actually is. vkCmdBindDescriptorSet(cmdBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, textureDescriptorSet[0], 0); vkQueueSubmit(graphicsQueue, 1, &cmdBuffer, 0, 0, fence); vkMapMemory(staticUniformBufferMemory, 0, (void **)&data); // ... vkUnmapMemory(staticUniformBufferMemory); It's much more low level. And there's no strong type safety remaining. You can use a block of memory to be written by rendering operations, and then, just using another descriptor, use that same memory as a texture in post processing. However due to the asynchronous nature of GPU processing this puts a lot of burden on the application using it to get all the synchronization right.
- tormeh 12y ago
  >It's much more low level. And there's no strong type safety remaining. It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level.
  - datenwolf 12y ago
    > It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level. Actually no, because Vulkan itself is just a API. But what you can do it create high-level bindings, similar to, say, the Haskell X bindings that immediately leverage the asynchronous execution, lazy evaluation and built-in concurrent parallelism. Also typesafety regarding the buffer contents can be mapped into a Hindley-Miller system as well, by looking at the tuple `(memory handle, descriptor)`; in Haskell (e.g.) that'd nicely map into a type constructor.
higherpurpose 12y ago
Speaking of path tracing, I hope Khronos keeps an eye to the future for Vulkan in regards to supporting path tracing. I don't think we're too many years away from seeing gaming engines or graphics card makers support path tracing in a big way (mainly because I think it's the future of gaming, especially for VR gaming - which is also the future of gaming itself). Vulkan should be optimized for that from the beginning and not tacked-on later.

by fizixer 12y ago

jamesfmilne 12y ago

I've spent 15 years working on OpenGL, but I'd kick it to the kerb in a heartbeat. AMD and NVIDIA are free to implement Vulkan on Windows and Linux, but the problem is that we will probably be stuck with OpenGL 4.0 on Mac OS X for the foreseeable future.

saschispatzi 12y ago
I don't know too much about the topic (I wish I did), but how what makes you think so? I see that it says "Will work on any platform that supports OpenGL ES 3.1 and up" and Apple platforms seem not to support that (as of now). However Apple is part of the working group, doesn't that make it very likely they are working on an implementation, too?
- readstoomuch 12y ago
  Apple are traditionally tardy when it comes to OpenGL. Yosemite is still on 4.1 (2010 release), lacking support for things like compute shaders.
  - saschispatzi 12y ago
    Oh, I see, didn't realize that. That is a pity because I would very much like for cross platform gaming to become much more of a thing and Vulkan does seem likely to be a big milestone in that, esp. considering Valve's involvement.
    - pjmlp 12y ago
      Cross platform gaming equals to game engines abstracting graphics APIs. Despite urban legends propagating the myth, games consoles don't feature OpenGL APIs as such, rather using more low level ones, even if inspired by OpenGL.
  - tormeh 12y ago
    This explains why CryEngine supports Linux but not Mac. CryEngine requires OpenGL 4.3 as that's what was the easiest translation target for CryTek from DirectX 11.
  - ixtli 12y ago
    It seems like it's unfair to say "Apple are late with OpenGL features." The third parties could put the same effort into making drivers for OS X that they do into making them (and their crapware frontends) for Windows, but they don't. I may be wrong, but it appears to me that it's Apple doing most of the work.
    - deleted 12y ago
      [deleted]
    - jsheard 12y ago
      There's not much hard information on how Apple deals with graphics drivers, but from what I gather they use a unified in-house OpenGL frontend for the hardware-independent layer, then defer to a modified version of the vendors driver for the low-level stuff. Their frontend only implements up to GL 4.1, so even if the vendors were to release drivers independently there would be no way for an app to access the newer functionality through the OS X frameworks.
    - deleted 12y ago
- jamesfmilne 12y ago
  I'm a cynic, but don't get me wrong, I'd be delighted if Vulkan or OpenCL 2.1 show up in OS X 10.11. Khronos is a funny beast, a bit like the United Nations. Just because these companies are all part of it doesn't mean they actually like each other and want to cooperate! Apple has famously lagged far behind with their implementation of OpenGL. They only support OpenGL 4.1, the spec for which was released in 2010 [1]. Their developer tools are also pretty lacking on the desktop, and because they keep their drivers closed, external vendors can't do much to help. (Apple write their own drivers for Intel, NVIDIA and AMD GPUs, and even the engineers at those companies have little insight to what goes on behind Apple's closed doors.) Perhaps this new, streamlined Vulkan API will be easier and more attractive for Apple to implement. We live in hope... [1] http://en.wikipedia.org/wiki/OpenGL#OpenGL_4.1 http://en.wikipedia.org/wiki/OpenGL#OpenGL_4.1
  - mbel 12y ago
    > Khronos is a funny beast, a bit like the United Nations. Just because these companies are all part of it doesn't mean they actually like each other and want to cooperate! It seems to me that this is an accurate description for any technology focused consortium or work group.
jitl 12y ago
From the website: > Will work on any platform that supports OpenGL ES 3.1 and up Furthermore, Apple is on the working group.
- jamesfmilne 12y ago
  It doesn't just magically work, someone still has to write the drivers & user space libraries. Apple would also then have to support three graphics APIs, vintage OpenGL, Metal (on iOS) and Vulkan (on iOS and OS X?), across four hardware platforms (AMD, NVIDIA, Intel, Imagination on ARM).
- jsheard 12y ago
  It's a single data-point, but Apple was on the working group for KHR_debug and still hasn't implemented it three years later.

pjmlp 12y ago

Google tried this when they introduced RenderScript, but they dropped support for graphics calculations on the second release and steered it into a way to use C99 with GPU capabilities, without having to drop into the NDK.

datenwolf 12y ago

> I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, > (...) > I realized this very strongly when I considered doing graphics using OpenGL but with a photorealistic renderer like a path tracer. Well, then you're going be disappointed by Vulkan as well. OpenGL (and modern GPUs) are built around screen space rasterization of points, lines and triangles. Being aimed primarily at the graphics part of GPUs, Vulkan uses the same primitives. The major difference to OpenGL is, that you no longer do stuff like glGenTextures(...) glBindTexture(…, texID) glTexStorage…(...) glTexImage…(...) glActiveTexture(... + i) glBindTexture(…, texID) glUniform1i(sampler_index, i) operating on a global, TLS driver state, which the driver has to queue and reorder into a command stream to the GPU. Instead you allocate some memory (using the Vulkan API) map it, write to it directly and set elements of a resource descriptor to what the layout of the data in that memory actually is. vkCmdBindDescriptorSet(cmdBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, textureDescriptorSet[0], 0); vkQueueSubmit(graphicsQueue, 1, &cmdBuffer, 0, 0, fence); vkMapMemory(staticUniformBufferMemory, 0, (void **)&data); // ... vkUnmapMemory(staticUniformBufferMemory); It's much more low level. And there's no strong type safety remaining. You can use a block of memory to be written by rendering operations, and then, just using another descriptor, use that same memory as a texture in post processing. However due to the asynchronous nature of GPU processing this puts a lot of burden on the application using it to get all the synchronization right.

tormeh 12y ago
>It's much more low level. And there's no strong type safety remaining. It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level.
- datenwolf 12y ago
  > It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level. Actually no, because Vulkan itself is just a API. But what you can do it create high-level bindings, similar to, say, the Haskell X bindings that immediately leverage the asynchronous execution, lazy evaluation and built-in concurrent parallelism. Also typesafety regarding the buffer contents can be mapped into a Hindley-Miller system as well, by looking at the tuple `(memory handle, descriptor)`; in Haskell (e.g.) that'd nicely map into a type constructor.

higherpurpose 12y ago

Speaking of path tracing, I hope Khronos keeps an eye to the future for Vulkan in regards to supporting path tracing. I don't think we're too many years away from seeing gaming engines or graphics card makers support path tracing in a big way (mainly because I think it's the future of gaming, especially for VR gaming - which is also the future of gaming itself). Vulkan should be optimized for that from the beginning and not tacked-on later.