5 ms·
OpenGL has received continuous development. Also, I find it easier to work with than Vulkan. Sometimes you do want higher abstraction.
by spookie 3y ago
OpenGL has received continuous development. Also, I find it easier to work with than Vulkan.
Sometimes you do want higher abstraction.
- DonHopkins 3y agoGuess what? GPUs have received continuous development too, since the days of SGI. And OpenGL hasn't kept up. Its "higher" abstraction is the wrong abstraction.
- josefx 3y agoSo we are no longer running arbitrary code against arbitrary buffers of random access data?
- flohofwoe 3y agoOpenGL isn't really a 'high abstraction level' API though, that would be a lot more 'declarative'. Instead it's originally modelled after some mid-80s(?) fixed-function 3D rendering hardware from SGI, which then got incrementally extended in the following decades to support new GPU hardware features, but without any thought put into the overall API design.
- junon 3y agoI don't think "higher level" intrinsically means "declarative" though. I'd think most people would agree OpenGL is higher level than Vulkan for a variety of reasons.
- flohofwoe 3y agoI guess what I wanted to say is that GL transitioned from a non-abstractive API in it's very early days into the wrong abstraction in the present day.
- pjmlp 3y agoWell, there is AZDO, and in platforms like Android, until Google bothers to provide Java/Kotlin bindings, it is the API most app developers will reach out. Most will never deal with Vulkan and the NDK directly, unless there is no other way. Likewise on the Web, for developers that what to write 3D code that is actually usable everywhere.
- junon 3y agoCan you explain why you think it's "wrong"?
- flohofwoe 3y agoThe GL programming model defines a highly granular and highly dynamic state machine of dozens (hundreds?) of small knobs and sliders that needs to be mapped to an underlying hardware which looks very different by now. This results in small state changes potentially causing large and unpredictable 'recompiles' of the internal 'driver state' at random points (e.g. calling one of the blend state functions - which should be a very cheap operation - might trigger expensive shader recompiles in some random GL call down the line, but if and when this exactly happens depends on the specific GL implementation). That's one important reason why modern 3D APIs prefer to group state into immutable state-group objects (even if those modern 3D-APIs also don't perfectly map the underlying hardware).