Age | Commit message (Collapse) | Author |
|
`GPU_SHADER_3D_IMAGE_MODULATE_ALPHA` can be seamlessly replaced by
`GPU_SHADER_3D_IMAGE_COLOR` with no real harm done.
|
|
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
|
|
Use an off-screen buffer for the screen-shot operator.
Reading from the front-buffer immediately after calling swap-buffers
failed for GHOST/Wayland in some cases.
While EGL can request to preserve the front-buffer while drawing,
this isn't always supported. So workaround the problem by avoiding
use of the front-buffer entirely.
|
|
|
|
Remove mask suffix from:
- GHOST_TButtonMask
- GHOST_TModifierKeyMask
.. neither are used as bit-masks.
Remove 'Grab' from:
- GHOST_kGrabAxisNone
- GHOST_kGrabAxisY
.. matching the existing GHOST_TAxisFlag & GHOST_kAxisX.
|
|
pass coordination.
MTLFrameBuffer has been implemented to support creation of RenderCommandEncoders, along with supporting functionality in the Metal Context.
Optimisation stubs for GPU_framebuffer_bind_ext has been added, which enables specific assignment of attachment load-store ops at the bind level, rather than on a framebuffer object as a whole.
Begin and end frame markers are used to encapsulate frame boundaries for explicit workload submission. This is required for explicit APIs where implicit flushing of work does not occur.
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D15027
|
|
Add a method to access the custom cursor from GHOST which is used
for drawing a software cursor. This means the knife tools cursor now
work as expected.
Although non-custom cursors are still not supported.
|
|
The current gnome-shell (v42.2) has a bug where grabbing the cursor
doesn't scale the region when confining it to the window.
For Hi-DPI displays this means the cursor may be confined to a quarter
of the window, making grab unusable.
Even though this has been fixed up-stream the issue remains in the
latest release - so workaround the problem by implementing window
confined grab using a software cursor.
This is only used gnome-shell for displays that use Hi-DPI scaling.
|
|
When grab was disabled, the software cursor would remain displayed
in the image view. Ensure an additional redraw is done to clear the
cursor.
|
|
The software cursor was being enabled with absolute events,
causing a problem with absolute tablet events.
This caused both cursors to be visible at once when using a tablet
(with D15152 applied).
|
|
As Wayland doesn't support moving the cursor, draw a cross-hair cursor
at the location used by Blender.
Without this, the cursor was locked at the location where grab started,
making some actions unusable since the cursor location was invisible.
Resolves T77311.
|
|
The acquire locking of the draw manager introduced other issues.
The current implementation was a hacky solution as we know that the
final solution is something totally different {T98016}.
Related issues:
* {T97988}
* {T97600}
|
|
Viewports weren't drawn as they couldn't get a lock. Resulted in compositing
uninitialized viewports. Fixed by checking that both views were drawn.
|
|
This patch adds the drag and drop strip previews in the VSE.
It also adds two new functions to the drag and drop API.
1. "draw_in_view" for callbacks that wants to draw elements in local viewport coordinates
2. "on_drag_start" that can be used for prefetching data only once at the start of the drag.
Reviewed By: Julian, Campbell
Differential Revision: http://developer.blender.org/D14560
|
|
This is a partial fix to the fact that rendering with EEVEE or other GL
render engines is currently blocking the whole UI when asking to redraw
a viewport.
This patch just bypasses the viewport bind (containing the Draw Context
lock) and the following drawing. There is an update tagging to not
loose a viewport update if there was one asked.
Other queries other than view redraw (such as selection depth drawing or
offscreen drawing) will still block the whole UI as they need immediate
data feedback.
Ping @Severin for the change in `WM_draw_region_viewport_bind()`.
I'm assuming this is not an issue because it's highly unlikely to
bring up this operator during rendering. But in this case, it would just
lock as usual.
The bypassing in `DRW_notify_view_update` might be a bit overparanoid.
|
|
Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths.
Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly.
Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14293
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
|
|
Also add groups in some files.
|
|
The global theme state didn't get updated or unset properly when drawing
overlays. Now paint cursors use the theme settings of the space they are
in, while global overlays use the global fallback, which is the main 3D
View region.
|
|
No functional changes.
This commit adds 3 callbacks for `wmDropBox` which allow custom drawing
without affecting the internal dropbox API.
Differential Revision: https://developer.blender.org/D12948
|
|
Use arrays for wmEvent coordinates, this quiets warnings with GCC11.
- `x, y` -> `xy`.
- `prevx, prevy` -> `prev_xy`.
- `prevclickx, prevclicky` -> `prev_click_xy`.
There is still some cleanup such as using `copy_v2_v2_int()`,
this can be done separately.
Reviewed By: campbellbarton, Severin
Ref D12901
|
|
|
|
This addresses reduced visibility of scenes (as displayed in the VR
headset) that can result from the 8-bit color depth format currently
used for XR swapchain images.
By switching to a swapchain format with higher color depth (RGB10_A2,
RGBA16, RGBA16F) for supported runtimes, visibility in VR should be
noticeably improved.
However, current limitations are lack of support for these higher
color depth formats by some XR runtimes, especially for OpenGL.
Also important to note that GPU_offscreen_create() now explicitly
takes in the texture format (eGPUTextureFormat) instead of a
"high_bitdepth" boolean.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D9842
|
|
limit
The crash happens because `GPU_offscreen_create` is called with `err_out` `NULL`.
This patch proposes a solution within the `GPU_offscreen_create` itself
and raises an error report in the interface if a menu is called with
dimensions beyond what is supported.
Ref T89782
Maniphest Tasks: T89782
Differential Revision: https://developer.blender.org/D11927
|
|
Now `ED_view3d_backbuf_depth_validate`, `ED_view3d_draw_depth` and
`ED_view3d_draw_depth_gpencil` are unified in `ED_view3d_depth_override`.
This new function replaces `ED_view3d_autodist_init`.
Also, since `ED_view3d_depth_update` depends on the render context, and
changing the context is a slow operation, that function also was removed,
and the depth buffer cached is now updated inside the new unified drawing
function when the "bool update_cache" parameter is true.
Finally `V3D_INVALID_BACKBUF` flag has been renamed and moved to
`runtime.flag`.
Differential revision: https://developer.blender.org/D10678
|
|
crash
The handle of a drawing callback can be removed within the drawing function itself.
This causes `var = (type)(((Link *)(var))->next` to read an invalid memory value in C.
|
|
Match naming of other wm_cursor_position_* functions.
|
|
Approximately 91 spelling corrections, almost all in comments.
Differential Revision: https://developer.blender.org/D10288
Reviewed by Harley Acheson
|
|
|
|
- Reduce variable scope.
- Use LISTBASE_FOREACH macros.
- Return early in some cases to reduce to reduce indentation.
|
|
This makes sure no BGL call before window drawing locks the GPUState.
|
|
This makes the debugging easier
|
|
|
|
The drawing of popus should be done with the window's default viewport
and scissor. Previous functions may change these, so they should be
explicitly reset.
|
|
Caused by rB2e908156d0c7
This was caused by the sequencer timeline area not using a GPUViewport
but still using `sequencer_draw_preview`.
|
|
This is in order to remove GPU_draw_primitive to streamline the drawing
abstraction.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
We now use GPU_blend for enabling / disabling blending and explicitly
set the blend equation.
|
|
|
|
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
|
|
Issue introduced on fe045b2b77dc6d7f0b552619fe824b496d34db6c.
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 addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenlib` 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
|
|
|