Previously there was a special extraction process for "vertex colors"
that copied the color data to the GPU with a special format. Instead,
this patch replaces this with use of the generic attribute extraction.
This reduces the number of code paths, allowing easier optimization
in the future.
To make it possible to use the generic extraction system for attributes
but also assign aliases for use by shaders, some changes are necessary.
First, the GPU material attribute can now store whether it actually refers
to the default color attribute, rather than a specific name. This replaces
the hack to use `CD_MCOL` in the color attribute shader node. Second,
the extraction code checks the names against the default and active
names and assigns aliases if the request corresponds to a special active
attribute. Finally, support for byte color attributes was added to the
generic attribute extraction.
Differential Revision: https://developer.blender.org/D15205
When a query begins, the current visibility result buffer needs to be
associated with the currently active Render Pass. The MTLContext and
MTLCommandBuffer are responsible for ensuring new render pass objects are
created if the visibility state changes.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D15356
Currently Blender generates mipmaps that override the existing ones.
This patch disables generating new mipmaps for compressed textures.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D14459
Backend initialization needs to be delayed until after the OpenGL context
is created. This worked fine in foreground mode because the OpenGL context
already exists for the window at the point GPU_backend_init_once was called,
but not for background mode.
Create the backend just in time in GPU_context_create as before, and
automatically free it when the last context id discarded. But check if any
GPU backend is supported before creating the OpenGL context.
Ref D15463, D15465
This causes an assert with libepoxy, but was wrong already regardless.
Refactor logic to work as follows:
* GPU_exit() deletes backend resources
* Destroy UI GPU resources with the context active
* Call GPU_backend_exit() after deleting the context
Ref D15291
Differential Revision: https://developer.blender.org/D15465
When rendering with headless builds, show an error instead of crashing.
Previously GPU_backend_init was called indirectly from
DRW_opengl_context_create, a new function is now called from the window
manager (GPU_backend_init_once), so it's possible to check if the GPU
has a back-end.
This also disables the `bgl` Python module when building WITH_HEADLESS.
Reviewed By: fclem
Ref D15463
Adds a better name that describes when it is used.
The GPU_SHADER_BUILDER is a buildtime tool for developers
to pre-validate GLSL (and in the overseen future pre-compile to
SpirV). We don't see that this needs to become a required
step in the future so WITH_GPU_BUILDTIME_SHADER_BUILDER
is more descriptive name.
This commit adds visualization to the selection in curves sculpt mode.
Previously it was only possible to see the selection when it was
connected to a material.
In order to obstruct the users vision as little as possible, the
selected areas of the curve are left as is, but a dark overlay
is drawn over unselected areas.
To make it work, the overlay requests the selection attribute and then
ensures that the evaluation is complete for curves. Then it retrieves
the evaluated selection GPU texture and passes that to the shader.
This reuses the existing generic attribute extraction system because
there currently wouldn't be any benefits to dealing with selection
separately, and because it avoids duplication of the logic that
extracts attributes from curves and evaluates them if necessary.
Differential Revision: https://developer.blender.org/D15219
The memory manager includes both a GPUContext-local manager which allocates per-context resources such as Circular Scratch Buffers for temporary data such as uniform updates and resource staging, and a GPUContext-global memory manager which features a pooled memory allocator for efficient re-use of resources, to reduce CPU-overhead of frequent memory allocations.
These Memory Managers act as a simple interface for use by other Metal backend modules and to coordinate the lifetime of buffers, to ensure that GPU-resident resources are correctly tracked and freed when no longer in use.
Note: This also contains dependent DIFF changes from D15027, though these will be removed once D15027 lands.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D15277
This modules handles renderpasses allocation and filling. Also handles
blitting to viewport framebuffer and render result reading.
Changes against the old implementation:
- the filling of the renderpasses happens all at once requiring
only 1 geometry pass.
- The filtering is optimized with weights precomputed on CPU and
reuse of neighboor pixels.
- Only one accumulation buffer for renderpasses (no ping-pong).
- Accumulation happens in one pass for every passes using a single
dispatch or fullscreen triangle pass.
TAA and history reprojection is not yet implemented.
AOVs support is present but with a 16 AOV limit for now.
Cryptomatte is not yet implemented.
This happened because of the false assumption that `std::array<char, 32>`
would be treated as a container and not relocate their content if the
`Vector` would grow. Replacing with actual object allocation fixes the
issue.
Candidate for 3.2.1 corrective release.
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
Since the occlusion input is going to be removed in EEVEE-Next, I just
added a temporary workaround. The occlusion is passed as SSS radius
as the Specular BSDF does not use it.
The final result matches 3.1 release
Intel iGPU (HD4000) supports OpenGL 4.4 but doesn't support conservative
depth. (GL_ARB_conservative_depth). This change will only check for the
availability of the extension.
