This changes the state of occlusion queries quite a bit. Now scissors is
explicitely disabled and we enabled color write.
I still don't understand why we now need this. This patch is just trial and
error on an affected setup. Note that on the same computer, renderdoc
was not able to capture the regression (the regression did not manifest
during capture).
Regression likely introduced by rB5f414234ddea
This is in preparation of vulkan backend. We move all opengl
functionnalities behind an abstract class.
This also cleansup the "dynamic" ubo create and rename it to
`GPU_uniformbuf_from_list()`
Contains, no functional change.
Part of T68990 Vulkan support.
This follows the GPU module naming of other buffers.
We pass name to distinguish each GPUUniformBuf in debug mode.
Also remove DRW_uniform_buffer interface.
This make use of the GLStateStack functions for:
- `GPU_blend()`
- `GPU_blend_set_func()`
- `GPU_blend_set_func_separate()`
The goal is to unify them using an explicit state setting.
This will remove the need to use obscure blend functions
Now error printing only display the line related to the error.
We also put char marker if present.
Example:
```
-- Shader Compilation Errors : MAMaterial --
10414 | node_fresnel(, facingnormal, viewposition, tmp34);
| ^
| error: syntax error, unexpected ',', expecting ')'
----------------------------------
```
Issue introduced on fe045b2b77.
Since the stereoscopy compositing (anaglyph, ...) is only done for
viewports the VSE preview and compositor need to use viewports.
Reviewed by: dfelinto
Differential Revision: https://developer.blender.org/D8472
This changes the drawing paradigm a bit. The VAO configuration is done
JIT-style and depends on context active shader.
This is to allow more flexibility for implementations to do optimization
at lower level.
The vao cache is now its own class to isolate the concept. It is this
class that is reference by the GLContext for ownership of the containing
VAO ids.
We instead use a handle reference counter on the GPUVertBufs used by
the instancing batches. This make sure that if an update happens on the
GPUVertBuf used to contruct the batch, they will never have the same
memory address than the previously allocated ones (since they are still
pending deletion thanks to the refcounter).
This avoid the linear search to update the GPUBatch in the case a
batch is deleted (which was even a bad option since they could be only
cleared)
A handle refcount is here to avoid freeing of the GPUVertBuf datablock
if it is still referenced somewhere else.
This does not prevent deleting the actual data. This is to avoid too
much zombie data usage.
This is in order to avoid most hacks inside `draw_instance_data.c`.
