BGL deprecation #80730

New Issue

Situation:
For 2.91 we refactored the whole GPU module to be ready for vulkan. In this process we added a state tracking mechanism which removes unneeded state changes by only pushing the state before drawing commands.

The issue is that BGL does not make use of this and directly use the GL API which can lead to unsafe states.

The current workaround is to push the state to the GL before the callbacks loop starts and just force reset all states after the loop (see blender/blender@fe5efccd8f).

This is quite ugly since it does not prevent misusage of the BGL API with the pyGPU API (which is using our GPU module states).

So we have things to do here:

Polish the pyGPU API and force its usage everywhere: Impractical for 2.91 because there would be no transition period. But we do need to get started already since the API did change a little (see GPUOffscreen). A refactor is in the process here D8826. This is the long term plan. blender/blender@4430e8a008
Make wrappers inside the BGL module to make the GPUState undefined if calling a function that modifies it: This would trigger a special path inside gl_state.cc where the state would be ignored. This should fix some of the API mixing issues. blender/blender@f12b0373f3
~~But we also need to push the state for commands that need it (like glClear, glDrawArray, glReadPixels, ...). ~~ blender/blender@f12b0373f3
~~The last remaining issue is our resource binding check that needs to be disable because incompatible with the glUniform + glBindTexture idiom (we now use internal fixed binding points).~~ blender/blender@f12b0373f3

We still have to figure how to mitigate:

~~Current framebuffer state: calling glBindFramebuffer(GL_FRAMEBUFFER, id) will break the state tracking.~~ (Resolved with python's with statement forcing a context specific block. See blender/blender@4430e8a008)
Current bound program state: calling glUseProgam(program) will break the state tracking.
... (any other?)

Other issues with pyGPU:

There are still functions to get the raw GL handle for some object (Shader/Texture). Deprecate them.
GPUOffscreen / GPUFramebuffer now always store/resets their own Viewport/Scissor bounds. Document the API change.

Addons and scripts using the bgl module:

addons
- archimesh (547adaa4ed)
- curve_assign_shapekey.py (f7c2fc6395)
- curve_tools (c383b02744)
- cycles
- greasepencil_tools (294e899bf7)
- io_mesh_uv_layout (5578ae83b3)
- magic_uv (6feb9c532d)
- measureit (a1424dc87f)
- mesh_snap_utilities_line
- node_wrangler.py (d37c2abc6f)
- object_carver (708255a88f)
- object_collection_manager (be6cbe0222)
- object_scatter (c8109966ce)
- power_sequencer (ce8c5f8d1b)
- precision_drawing_tools (c1cdc33579)
- space_view3d_math_vis (f3e1e980b6)
- sun_position (af94627460)
- viewport_vr_preview.py (ec558f2a91)
addons_contrib
- animation_motion_trail.py
- exact_edit
- mesh_show_vgroup_weights.py
- np_station
- space_clip_editor_autotracker.py
modules
- bl_ui_utils/bug_report_url.py
- bpy_types.py
- gpu_extras/presets.py
- sys_info.py
templates
- operador_modal_draw.py

Related links:
https://devtalk.blender.org/t/suggestions-feedback-on-the-extensions-for-the-gpu-module/17706/38

**Situation:** For 2.91 we refactored the whole GPU module to be ready for vulkan. In this process we added a state tracking mechanism which removes unneeded state changes by only pushing the state before drawing commands. The issue is that BGL does not make use of this and directly use the GL API which can lead to unsafe states. The current workaround is to push the state to the GL before the callbacks loop starts and just force reset all states after the loop (see blender/blender@fe5efccd8f). This is quite ugly since it does not prevent misusage of the BGL API with the pyGPU API (which is using our GPU module states). **So we have things to do here:** - ~~Polish the pyGPU API and force its usage everywhere: Impractical for 2.91 because there would be no transition period. But we do need to get started already since the API did change a little (see GPUOffscreen). A refactor is in the process here [D8826](https://archive.blender.org/developer/D8826). This is the long term plan.~~ blender/blender@4430e8a008 - ~~Make wrappers inside the BGL module to make the `GPUState` undefined if calling a function that modifies it: This would trigger a special path inside `gl_state.cc` where the state would be ignored. This should fix some of the API mixing issues.~~ blender/blender@f12b0373f3 - ~~But we also need to push the state for commands that need it (like `glClear`, `glDrawArray`, `glReadPixels`, ...). ~~ blender/blender@f12b0373f3 - ~~The last remaining issue is our resource binding check that needs to be disable because incompatible with the `glUniform + glBindTexture` idiom (we now use internal fixed binding points).~~ blender/blender@f12b0373f3 **We still have to figure how to mitigate:** - ~~Current framebuffer state: calling `glBindFramebuffer(GL_FRAMEBUFFER, id)` will break the state tracking.~~ (Resolved with python's `with` statement forcing a context specific block. See blender/blender@4430e8a008) - Current bound program state: calling `glUseProgam(program)` will break the state tracking. - ... (any other?) **Other issues with pyGPU:** - There are still functions to get the raw GL handle for some object (Shader/Texture). Deprecate them. - GPUOffscreen / GPUFramebuffer now always store/resets their own Viewport/Scissor bounds. Document the API change. **Addons and scripts using the bgl module:** - [x] addons - [x] archimesh (547adaa4ed) - [x] curve_assign_shapekey.py (f7c2fc6395) - [x] curve_tools (c383b02744) - [x] cycles - [x] greasepencil_tools (294e899bf7) - [x] io_mesh_uv_layout (5578ae83b3) - [x] magic_uv (6feb9c532d) - [x] measureit (a1424dc87f) - [x] mesh_snap_utilities_line - [x] node_wrangler.py (d37c2abc6f) - [x] object_carver (708255a88f) - [x] object_collection_manager (be6cbe0222) - [x] object_scatter (c8109966ce) - [x] power_sequencer (ce8c5f8d1b) - [x] precision_drawing_tools (c1cdc33579) - [x] space_view3d_math_vis (f3e1e980b6) - [x] sun_position (af94627460) - [x] viewport_vr_preview.py (ec558f2a91) - [ ] addons_contrib - [ ] animation_motion_trail.py - [ ] exact_edit - [ ] mesh_show_vgroup_weights.py - [ ] np_station - [ ] space_clip_editor_autotracker.py - [ ] modules - [x] bl_ui_utils/bug_report_url.py - [x] bpy_types.py - [ ] gpu_extras/presets.py - [x] sys_info.py - [x] templates - [x] operador_modal_draw.py **Related links:** https://devtalk.blender.org/t/suggestions-feedback-on-the-extensions-for-the-gpu-module/17706/38

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscribers: @fclem, @ideasman42, @brecht, @mano-wii

Added subscriber: @rjg

Added subscriber: @EAW

Added subscriber: @lichtwerk

Added subscriber: @slumber

Added subscriber: @Jeroen-Bakker

Added subscriber: @JacobMerrill-1

So all the same abilities - (grab texture ID - replace with new Texture using py - will be abstracted now like the draw calls in order to be restored?)

Added subscriber: @KenzieMac130

Added subscriber: @MACHIN3

Added subscriber: @erik85

Added subscriber: @2046411367

Added subscriber: @ckohl_art

Added subscriber: @PhilippeCrassous

Once D8826: Python: gpu module: add new submodules and types is committed, this task should be updated to reflect the current status.

Besides taking care of any remaining known API issues and documenting the new APIs, I think we should also involve the community. Once we are ready for it, I suggest to:

Create a task with the list of add-ons that needs to be updated, and get the community to help with this
Create a devtalk thread to gather feedback

Once [D8826: Python: gpu module: add new submodules and types](https://archive.blender.org/developer/D8826) is committed, this task should be updated to reflect the current status. Besides taking care of any remaining known API issues and documenting the new APIs, I think we should also involve the community. Once we are ready for it, I suggest to: * Create a task with the list of add-ons that needs to be updated, and get the community to help with this * Create a devtalk thread to gather feedback

This issue was referenced by blender/blender@4430e8a008

This issue was referenced by blender/blender@4430e8a00810ca8df2fa20029c4cb8078e8cdbe6

This issue was referenced by f01d08b7c5

This issue was referenced by f01d08b7c5f7873e0ce8a77b84788e2f6b1ad716

Added subscriber: @jta

Added subscriber: @lvxejay

Added subscriber: @JasonvanGumster

Added subscriber: @cwolf3d

Added subscriber: @warcanin

Added subscriber: @alisealy

Added subscriber: @blendersamsonov

Added subscriber: @regcs

Added subscriber: @Raimund58

Added subscriber: @Imaginer

Added subscriber: @timodriaan

Added subscriber: @hlorus

Added subscriber: @gfxcoder

Added subscriber: @JakubUhlik

This issue was referenced by blender/blender@1a627d528c

This issue was referenced by blender/blender@1a627d528cf91a58893e31ce89a6114eec2a6630

So, which release is BGL actually going to be removed for? And why was object_collection_manager removed from the list?

In #80730#1420991, @Imaginer wrote:
So, which release is BGL actually going to be removed for?

Probably in 3.4 (along with the Metal stand support)

And why was object_collection_manager removed from the list?

It doesn't look like this addon has ever used bgl, it seems like it was a mistake to add it to the list.

> In #80730#1420991, @Imaginer wrote: > So, which release is BGL actually going to be removed for? Probably in 3.4 (along with the Metal stand support) > And why was object_collection_manager removed from the list? It doesn't look like this addon has ever used `bgl`, it seems like it was a mistake to add it to the list.

It doesn't look like this addon has ever used bgl, it seems like it was a mistake to add it to the list.

No, it uses bgl fairly extensively in qcd_move_widget.py (I should know, I'm the author 😛 )

I've been waiting to update it to use the pyGPU API for a number of reasons, but if it's official that bgl is being removed for 3.4 then I'll update it.

> It doesn't look like this addon has ever used bgl, it seems like it was a mistake to add it to the list. No, it uses `bgl` fairly extensively in `qcd_move_widget.py` (I should know, I'm the author 😛 ) I've been waiting to update it to use the pyGPU API for a number of reasons, but if it's official that `bgl` is being removed for 3.4 then I'll update it.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

BGL deprecation #80730