2 ms·

I kind of think of OpenGL vs Vulkan like Java vs C. OpenGL tries to help you like Java tries to help you. Vulkan, on the other hand, is like C--get it right o

by bsder 4y ago

I kind of think of OpenGL vs Vulkan like Java vs C. OpenGL tries to help you like Java tries to help you. Vulkan, on the other hand, is like C--get it right or you will blow your foot off. OpenGL holds a lot of implicit state in the driver. This makes writing your code a lot easier as you don't have to track all that state yourself. If you want to learn 3D graphics, I'd either start with OpenGL or some "engine" that makes an abstraction that looks a lot like OpenGL. The problem is that OpenGL state is implicit. Every driver does it differently and there is no way to get at the state via OpenGL. This becomes an issue when you want to optimize--either for maximum performance or for maximum battery life. Vulkan, on the other hand, makes EVERYTHING explicit. This means that every single transition, barrier, matrix change, byte transfer, etc. is all in your hands. You know exactly what is going on because you have to specify it exactly. But don't get it wrong or your pixels will get eaten by a grue. This is precisely what you want when you absolutely need to optimize your graphics, but, man, is it painful to get right. One side benefit of the explicit nature of Vulkan carries over to concurrency. Vulkan can actually do multithreading--OpenGL has no hope because of all its implicit state.

ahartmetz 4y ago
Just to make this clear for people who don't already know OpenGL: The public API state of OpenGL can be queried programmatically and with tooling such as Renderdoc, and it is of course standardized. The hidden state in drivers that you are talking about should only ("only") matter for performance, not correctness. Sometimes it matters for correctness when drivers are buggy, which many are. Driver quality varies widely, with mobile platform OpenGL drivers generally being the worst.
pjmlp 4y ago
Except that OpenGL limitation isn't as bad as it seems, as most of the work not pixel related can be done by background threads anyway, with the GL thread puting the scene graph into pixels. Also if one is feelig adventurous they can make use of switching the OpenGL context on the active thread, although I wouldn't advise that given it isn't portable anyway. https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-wglmakecurrent https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf... Ironically on Windows, the OS that isn't that much keen into OpenGL.

by bsder 4y ago

ahartmetz 4y ago

Just to make this clear for people who don't already know OpenGL: The public API state of OpenGL can be queried programmatically and with tooling such as Renderdoc, and it is of course standardized. The hidden state in drivers that you are talking about should only ("only") matter for performance, not correctness. Sometimes it matters for correctness when drivers are buggy, which many are. Driver quality varies widely, with mobile platform OpenGL drivers generally being the worst.

pjmlp 4y ago

Except that OpenGL limitation isn't as bad as it seems, as most of the work not pixel related can be done by background threads anyway, with the GL thread puting the scene graph into pixels. Also if one is feelig adventurous they can make use of switching the OpenGL context on the active thread, although I wouldn't advise that given it isn't portable anyway. https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-wglmakecurrent https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf... Ironically on Windows, the OS that isn't that much keen into OpenGL.