This was caused by a missing state apply.
We force the GPUState to be set after the callbacks to avoid
desync between our state tracker and the real gl state.
This fixes some issues but a better general fix for all BGL would
be better.
This fix T80297 2.91 texture alpha is not transparent
This project moves the current UV/Image editor drawing to the draw manager.
Why would we do this:
**Performance**:
Current implementation would draw each texel per time. Multiple texels could be
drawn per pixel what would overwrite the previous result. You can notice this
when working with large textures. Repeat image drawing made this visible by
drawing for a small period of time and stop drawing the rest. Now the rendering
is fast and all repeated images are drawn.
**Alpha drawing**:
Current implementation would draw directly in display space. Giving incorrect
results when displaying alpha transparent images.
This addresses {T52680}, {T74709}, {T79518}
The image editor now can show emission only colors. See {D8234} for
examples.
**Current Limitations**
Using images that are larger than supported by your GPU are resized (eg larger
than 16000x16000 are resized to 8k). This leaves some blurring artifacts. It is
a low priority to add support back of displaying individual pixels of huge
images. There is a design task {T80113} with more detail.
**Implementation overview**
Introduced an Image Engine in the draw module. this engine is responsible for
drawing the texture in the main area of the UV/Image editor. The overlay engine
has a edit_uv overlay which is responsible to draw the UV's, shadows and
overlays specifically for the UV Image editor. The background + checker pattern
is drawn by the overlay_background.
The patch will allow us to share overlays between the 3d viewport and UV/Image
editor more easily. In most cases we just need to switch the `pos` with the `u`
attribute in the vertex shader.
The project can be activated in the user preferences as experimental features.
In a later commit this will be reversed.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8234
This is part of the Vulkan task T68990.
This commits changes a few things:
- Rename extensions to capabilities (but left the file name untouched).
- Cubemap mip render workaround detection is rewritten using gl
commands to avoid using the GPU API before initialization.
- Put all the capabilities that are only relevant for the GL backend
inside GLContext as static variables.
- Cleanup the names of the limit variables.
- Separate all GL related workaround search inside the GL module.
This is to modernize the API:
- Add meaningful name to all textures (except DRW textures).
- Remove unused err_out argument: only used for offscreen python.
- Add mipmap count to creation functions for future changes.
- Clarify the data usage in creation functions.
This is a cleanup commit, there is no functional change.
# Conflicts:
# source/blender/gpu/GPU_texture.h
Some underlying functionality was not ready for greasepencil:
- BKE_modifiers_get_virtual_modifierlist (now introduce dedicated BKE_gpencil_modifiers_get_virtual_modifierlist)
- BKE_modifiers_is_deformed_by_armature
- checks in drawing code
- checks in (pose) selection code
A couple of changes to make this work:
- `eGpencilModifierType_Armature` has to be respected (not only `eModifierType_Armature`)
- `OB_MODE_WEIGHT_GPENCIL` has to be respected (not only `OB_MODE_WEIGHT_PAINT`) -- (now use new `OB_MODE_ALL_WEIGHT_PAINT`)
- `gpencil_weightmode_toggle_exec` now shares functionality from `wpaint_mode_toggle_exec` -- moved to new `ED_object_posemode_set_for_weight_paint`
This patch will also set the context member "weight_paint_object" for greasepencil (otherwise some appropriate pose operators wont work when in weightpaint mode)
Reviewed By: campbellbarton
Maniphest Tasks: T63125
Differential Revision: https://developer.blender.org/D8483
This is related to the Vulkan port T68990.
This is a full cleanup of the Framebuffer module and a separation
of OpenGL related functions.
There is some changes with how the default framebuffers are handled.
Now the default framebuffers are individually wrapped inside special
GLFrameBuffers. This make it easier to keep track of the currently bound
framebuffer state and have some specificity for operations on these
framebuffers.
Another change is dropping the optimisation of only configuring the
changed attachements during framebuffers update. This does not give
any benefits and add some complexity to the code. This might be brought
back if it has a performance impact on some systems.
This also adds support for naming framebuffers but it is currently not
used.
A test case that compiles all the GLSL shaders for workbench, gpencil, overlay and some
of eevee. Compilation is still platform dependent, but when run on a test-farm
with different hardware we will be able to detect GLSL compilation
errors early on.
The test will be compiled when `WITH_GTEST` and `WITH_OPENGL_DRAW_TESTS`
are On.
For eevee only the shaders inside eevee_shaders.c are included. EEVEE has some shaders
located inside the submodule. They aren't accessible to the outside and aren't added
to the test case. We should see how we want to add them. For the test cases it is better
to move them to eevee_shaders.c, but for eevee perspective it is better to keep them in
the submodule. Keeping them in the submodule could lead to situations that is harder to test.
as the shader could already have been initialized.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8667
This replace `GPU_clear()` by `GPU_clear_color()` and `GPU_clear_depth()`.
Since we always set the clear value before clearing, it is unecessary
to track the clear color state.
Moreover, it makes it clearer what we clear the framebuffer to.
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.
Split the depsgraph allocation into a separate function
`BKE_scene_ensure_depsgraph()`. Parameters are only passed to those
functions that actually need them. This removes the the "if that boolean
is `false` this pointer is allowed to be `NULL`" logic and more cleanly
decouples code.
No functional changes.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/draw` module. Not all warnings are addressed
in this commit.
No functional changes.
In Blender 2.90 EEVEE materials were refactored that introduced crashes on Intel
GPUs on Windows. The crash happened in the `local_context_workaround` that temporary
stored compiled materials in a binary form to reload it in the main GL context.
It has been tested that the workaround isn't needed anymore for HD6xx GPUs, but it
is still needed for HD4000.
After several unsuccesfull fixes we came to the conclusion that we could not support
the local context workaround and needed to come with a different workaround. The idea
of this patch is that in these cases there is only a single context that is used for
rendering. Threads that uses these contextes are guarded by a mutex and will block.
Impact on User Level:
* Due to main mutex lock the UI freezes when rendering or baking or feel less snappy
Reviewed By: Clément Foucault, Brecht van Lommel
Differential Revision: https://developer.blender.org/D8410
When bl_use_gpu_context is set, an OpenGL context will be available for
OpenGL based render engines.
Differential Revision: https://developer.blender.org/D8305
This was caused by the override viewport size not being maintained after
DRW_cache_restart().
Also this fixes issue with the inv_size not being updated correctly.
This revisit the render pipeline to support time slicing for better motion
blur.
We support accumulation with or without the Post-process motion blur.
If using the post-process, we reuse last step next motion data to avoid
another scene reevaluation.
This also adds support for hair motion blur which is handled in a similar
way as mesh motion blur.
The total number of samples is distributed evenly accross all timesteps to
avoid sampling weighting issues. For this reason, the sample count is
(internally) rounded up to the next multiple of the step count.
Only FX Motion BLur: {F8632258}
FX Motion Blur + 4 time steps: {F8632260}
FX Motion Blur + 32 time steps: {F8632261}
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D8079
This adds object motion blur vectors for EEVEE as well as better noise
reduction for it.
For TAA reprojection we just compute the motion vector on the fly based on
camera motion and depth buffer. This makes possible to store another motion
vector only for the blurring which is not useful for TAA history fetching.
Motion Data is saved per object & per geometry if using deformation blur.
We support deformation motion blur by saving previous VBO and modifying the
actual GPUBatch for the geometry to include theses VBOs.
We store Previous and Next frame motion in the same motion vector buffer
(RG for prev and BA for next). This makes non linear motion blur (like
rotating objects) less prone to outward/inward blur.
We also improve the motion blur post process to expand outside the objects
border. We use a tile base approach and the max size of the blur is set via
a new render setting.
We use a background reconstruction method that needs another setting
(Background Separation).
Sampling is done using a fixed 8 dithered samples per direction. The final
render samples will clear the noise like other stochastic effects.
One caveat is that hair particles are not yet supported. Support will
come in another patch.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7297
The memory leak is noticeable when using custom bone shapes. When using custom
bone shapes objects could be extracted twice. Where the second extraction can
overwrite data created by the first extraction what causes the memory leak.
Options that have been checked:
1. Use two task graphs phases. One for normal extraction (DST.task_graph) and
the other one will handle extractions that require blocking threads.
2. Keep a list of all objects that needs extraction and only start extraction
when all objects have been populated.
The second would slow performance as the extraction only happens when all
objects have been populated. In the future we might want to go for the second
option when we have the capability to render multiple viewports with a single
populate. As this design isn't clear this patch will implement the first
option.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7969
This cleanup use the recent changes in shader interface to allow querying
the binding location a texture should use.
This should aleviate all issue we have with texture state change recompiling
the shaders at drawtime.
All binds are now treated like persistent binds and will stick until a new
shading group bind a different shader. The only difference is that you can
still change it with a new subgroup or same shader shgroup.
Since unbinding can be heavy we only do it when using `--debug-gpu`.
This patch uses a graph flow scheduler for creating all mesh batches.
On a Ryzen 1700 the framerate of Spring/020_02A.anim.blend went from 10 fps to 11.5 fps.
For each mesh where batches needs to be updated a sub-graph will be added to the task_graph.
This sub-graph starts with an extract_render_data_node. This fills/converts the required data
from Mesh.
Small extractions and extractions that can't be multi-threaded are grouped in a single
`extract_single_threaded_task_node`.
Other extractions will create a node for each loop exceeding 4096 items. these nodes are
linked to the `user_data_init_task_node`. the `user_data_init_task_node` prepares the userdata
needed for the extraction based on the data extracted from the mesh.
Note: If the `lines` and `lines_loose` are requested, the `lines_loose` sub-buffer is created
as part of the lines extraction. When the lines_loose is only requested the sub-buffer is
created from the existing `lines` buffer. It is assumed that the lines buffer is always
requested before or together with the lines_loose what is always the case (see
`DRW_batch_requested(cache->batch.loose_edges, GPU_PRIM_LINES)` in `draw_cache_impl_mesh.c`).
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7618
