|
One of the main advantages I hear of Vulkan is how low-level it is, and how you can use it to directly communicate with the GPU, and other things like reducing overall CPU overhead. Is there anything you can do in Vulkan that you particularly can't do in OpenGL, or is that Vulkan makes it more convenient to tinker with low-level poo poo? If so, how would one go about a low-level approach with OpenGL?
|
#
?
Jan 2, 2016 10:24
|
|
|
|
| # ? Apr 29, 2024 06:39 |
|
|
Depends on what you consider a feature. When I'm building an engine, in OpenGL, I have to think about how sampler state could silently recompile shaders behind my back to not prevent stalls. I have to think about batching and expensive state flushes, invisible in the OpenGL API. I think the conceptual cleanliness and general ease of mind in Vulkan is a major feature. I don't have to care about batching -- as much -- because state flushes are less expensive than they are in OpenGL. In terms of the pixels on the screen, I don't think there's anything you can do in Vulkan that you can't do in OpenGL. There's probably things you could theoretically do in OpenGL, but practically can't, because of the expense of it, that Vulkan cleans up, but anything major like that would have a vendor extension to fix.
|
|
#
?
Jan 2, 2016 20:32
|
|
