With more and more talk about mac dropping opengl and the desire to support vulkan at one point in the future. I got intrugued on what needs to be done to allow different rending backends.
Current issues preventing that:
Opengl has nestled it self deeply into the codebase (even makesrna depends on glew.h) and even though the recent Gawain cleanup did a good job in wrapping the old opengl api, there’s still of it plenty left. I took a quick survey and in a lite build there’s bf_windowmanager, bf_draw, bf_python (bgl is the main offender there) and a very large chunk of the editors in source/blender/editors and naturally bf_gpu and intern_gawain all calling functions or using opengl types (gluint etc)
most of the offending calls are various state changes with glEnable/glDisable but it’s not stricly limited to those there’s other problematic calls such as blend modes and calls like glLineWidth which may or may not exist in other rendering backends.
Gawain uses opengl types in it’s structures and even worse exposes the full structure to client code, so they now also depend on glew.h. Also there’s calls like GWN_batch_program_set which counts on the shader program being an integer, this will definitely not be the case for many of the ‘alternative’ backends.
a second problem is the extensive use of gsgl, this will naturally be an issue, however I don’t see it as the main issue, I’m perfectly happy making a platform dev initially hand write the shaders needed for their platform, Unity has a library for conversion of dx bytecode to gsgl/hlsl/metal/vulkan, but there’s other options available like gslang. So yes shaders will be an issue but it’s only a secondary issue. this one doesn’t have to be solved right away. there’s plenty of time to bicker about this one while we solve the other problem.
Now how to proceed?
I’d like the backend specific stuff to be in as few libraries as possible so source/blender/editors will definitely will have to be cleaned up. but with what?
one could replace all gl* calls left in those libraries with a GPU* or GWN* calls that wrap the opengl call. Sounds good, but in the end any new backend is just gonna substitute the opengl call with whatever is native to it, and emulate what isn’t. at which point the argument can be made you might as well cut out the middle man and just try to supply a glew drop in replacement for metal/vulkan/whatever. saves the effort of doing a massive code cleanup.
Another option is not to do any of these things, and see if we can get googles angle library to work again (there is some support in our cmake files, but I’m pretty sure no-one has tried in years) but i’m not familiar enough with eeve to know if it can be wrangled down to opengl es from full desktop and what the performance implications would be.
Yes, i know this project will be a massive time sink, and I’m ok with that, what I’m not ok with however is sinking months into this only to hear “yeahhh that’s not the way we want it/would have done it. patch->rejected!”
What are the main devs thoughts on this subject?