[Bf-committers] Blender 2.8, OpenGL 3.3, and newer versions and extensions
dfelinto at gmail.com
Fri Sep 1 12:53:53 CEST 2017
Some misinformation is being spread  about the OpenGL support in
the upcoming Blender 2.8. So I would like to take the chance to clear
The plan is to support OpenGL 3.3 as a minimum for a fully working
Blender. But also benefit from newer GL version and extensions when
The trick here is to define what is a fully working Blender, and what
we can consider optional advanced behaviour.
[ now for more optional details ]
For an specific example, we want to implement a lazy shader
compilation system. Excerpt from an (yet) unpublished planning
Lazy shader compilation
It doesn’t matter how fast shader compilation gets, or how well the OS
handles shader caching. To open a .blend will be slow and blocking for
real heavy production files. (...).
A solution is to have a fallback shader used for all objects, and
compile new shaders a few at a time, never passing a hardcoded
"waiting time" threshold.
In OpenGL 3.3, there is no way to compile a shader that is not
blocking. So Blender will be frozen while doing so. In OpenGL 4.5 with
the ARB_parallel_shader_compile extension we finally can get past
In this case there is no reason not to support this extension when
available, and we will work towards that.
Another example is OpenSubdiv, which may require CPU fallback if not
entirely supported in old hardware.
In both those cases going from a 3.3 to a 4.5 OpenGL computer will
only affect the overall performance, which is acceptable(-ish).
Now, if any new feature cannot be implemented with OpenGL 3.3, and
there is no look-alike fallback is a different case altogether.
If we still want to support the use of renderfarms, and such, we will
need to stay away from those. Or at least to mark the features as
 - https://blenderartists.org/forum/showthread.php?406129&p=3232354#post3232354
 - https://blenderartists.org/forum/showthread.php?406129&p=3232702#post3232702
More information about the Bf-committers