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