The current code is accessing this from outside the gpu "namespace". As
such it should be accessing GPU_ functions, not gpu_ functions.
This is also a place to centralize the XXX message that will be
addressed upon refactor. So we can reuse this call in other places that
need the same temporary workaround.
Groundwork for upcoming fix (D8472)
This reverts commit 58e20b432a.
Was calling discard twice, tsk.
Although for some reason it did quiet the leak.
Reverting because this is causing a crash.
The 10g Intel/Win driver doesn't work well with our emulated
intermediate mode. This patch alters the drawing of the drag widget of
the panels to reduce unneeded drawing.
The previous method would draw 16 boxes per widget. This new way would
cache this drawing in a GPU batch and just move the matrix around.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7345
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
That was caused by a thread safety issue on gpu_batch_presets_unregister()
which was not designed to be used for this kind of situation (managing 3D
meshes batches).
Now use a list of preset batches with a function to add new ones to this
list.
This removes the need of new functions all over the place to reset/exit.
Introduce a UI batch cache. For the moment it's only used by widgetbase so
leaving it interface_widgets.c. If it grows, it can have its own file.
Like all preset batches (batches used by UI context), vaos must be refreshed
each time a new window context is binded.
This still does 3 GWN_batch_draw in the worst cases but at least it does
not use the IMM api.
I will continue and batch the 3 calls together since we are really CPU
bound, so shader complexity does not really matters.
I cannot spot any difference on all the widgets I could test. I did not use
any unit tests so I cannot tell if there is really any defects.
This is not a complete rewrite but it adresses the top bottleneck found
after a profilling session.
This separate context allows two things:
- It allows viewports in multi-windows configuration.
- F12 render can use this context in a separate thread and do a non-blocking render.
The downside is that the context cannot be used while rendering so a request to refresh a viewport will lock the UI. This is something that will be adressed in the future.
Under the hood what does that mean:
- Not adding more mess with VAOs management in gawain.
- Doing depth only draw for operators / selection needs to be done in an offscreen buffer.
- The 3D cursor "autodis" operator is still reading the backbuffer so we need to copy the result to it.
- All FBOs needed by the drawmanager must to be created/destroyed with its context active.
- We cannot use batches created for UI in the DRW context and vice-versa. There is a clear separation of resources that enables the use of safe multi-threading.
