10 ms·
> I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, > (...) > I realized this ver
by 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.
- pjmlp 12y agoI think he/she meant targeting SPIR-V with your language of choice.
- datenwolf 12y agoSPIR-V is on a completely different level. The Vulcan API is called by the binary running on the CPU. The binary generated from SPIR-V is executed on the compute device, which in 99% or all cases that Vulkan is concerned with will be the GPU. In the same way you don't use GLSL to program OpenGL, you don't use SPIR-V to program Vulkan. GLSL/SPIR are to OpenGL/Vulkan what browser-side JavaScript is to a webserver.
- pjmlp 12y agoSure, but like PTX/CUDA it will mean you can write shaders in other languages with a better hardware mapping, instead of compiling them to GLSL/OpenCL C source, which is currently one advantage of CUDA.
- datenwolf 12y agoOh yes, I've been waiting to do that with OpenGL for a looong time. As a matter of fact I preferred working with the ARB_vertex_program and ARB_fragment_program extensions; I even designed (but never fully implemented) a custom, Lisp inspired language that compiles into the ARB_???_program assembly.