NVIDIA driver before 550 doesn't work as expected on Linux. The issue is
known on the internet, but no real solutions are provided.
This change will limit the block list of older driver to the Linux
platform only. It has been reported that Windows these driver are
working and would enable older GPUs to work on Windows.
Ref #129160
Pull Request: https://projects.blender.org/blender/blender/pulls/131674
Vulkan version 1.2 supports Workgroup execution model. Vulkan 1.3
introduced the LocalSizeId execution model and has been backported in
the VK_KHR_maintenance4 extension. In future SPIR-V versions the
Workgroup execution model will be deprecated.
This PR checks the availability of VK_KHR_maintenance4 extension and
when enabled compile the shaders towards Vulkan 1.3. This would
automatically use the LocalSizeId execution model.
See https://registry.khronos.org/vulkan/specs/latest/man/html/WorkgroupSize.html
Pull Request: https://projects.blender.org/blender/blender/pulls/131663
When using a texture as attachment it must be created witht the
GPU_TEXTURE_USAGE_ATTACHMENT flag. If this is not the case it would lead
to incorrect usage in Vulkan. This change adds asserts to detect
incorrect usage.
Pull Request: https://projects.blender.org/blender/blender/pulls/131656
GPU_texture_clear was only used for clearing color textures, but that
changed recently. This PR adds supports for clearing depth/stencil
textures using GPU_texture_clear.
Pull Request: https://projects.blender.org/blender/blender/pulls/131653
Depth 24 stencil 8 texture could not be cleared directly. Recently
GPUViewports clear their attachments when created. This resulted into
non consistent behavior between backends.
This change adds support to clear depth 24 stencil 8 textures using
`GPU_texture_clear`. The implementation currently assumes that the input
value is a float.
Pull Request: https://projects.blender.org/blender/blender/pulls/131650
GPUViewport is creating a bunch of framebuffer textures for itself, but
some space types never initialize/use them. E.g. Sequencer, Nodes etc.
only ever use the "overlay" texture. Eventually when viewport is
"drawn", it combines this uninitialized texture data and then only by
luck it happens that most of the time it is black. But not always!
The textures were only cleared (right now) on Metal backend, under
GPU_clear_viewport_workaround as if it was some driver workaround. Stop
doing that, and just clear them always.
However, there was seemingly a performance issue on OpenGL, when this
clear was being done. At least on my machine (Win10, Geforce RTX
3080Ti), the overhead of doing the clears is measurable, and is caused
by usage of GL4.4 glClearTexImage instead of a framebuffer clear. As if
glClearTexImage makes "pixel data to exist" on the CPU side and then
later on binding this framebuffer sends off that data to the GPU, or
somesuch.
More details in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/131518
The string `msl_patch_default` can have been read
partially uninitialized or initialized multiple
time and read uncomplete during multithreaded
compilation.
This should fix the GPU tests randomly failing on mac.
While this would never fail when blender runs from the UI (since
UI shaders are init in single threaded manner and always compile
before EEVEE shaders), this race condition could happen when running
EEVEE through background rendering or running tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/131580
Reduces the number of times a graphic context needs to be paused/resumed.
The scheduler reorders the nodes to put these initial data transfer nodes
to the start of the nodes that are about to be submitted.
Pull Request: https://projects.blender.org/blender/blender/pulls/131502
Move the Gamma Correction pass of blur nodes into its own algorithm to
avoid code duplication and optimize pixel access, since gamma is now
applied for each pixel in the filter window. Gives a 15% improvement.
Pull Request: https://projects.blender.org/blender/blender/pulls/131480
Devices reported by failing drivers were still part of the device
selection list. When selected they would never be picked.
This change hides these devices from the UI
Pull Request: https://projects.blender.org/blender/blender/pulls/131431
In OpenGL the last vertex is the provoking vertex. In Vulkan the first
vertex is the provoking vertex. This PR uses `VK_EXT_provoking_vertex`
to use the last vertex as the provoking vertex.
Pull Request: https://projects.blender.org/blender/blender/pulls/131412
Continuation of #131332.
Including built-in headers in VS2019 ends up including `corecrt_math.h`
as a side effect, which has many functions that overlap in name with
our stubs.
This puts the conflicting functions inside its own namespace (`glsl`)
and declares macros for them.
(Note this has the side effect of not allowing us to use those as
variable names)
This also removes the `<cassert>` and `<cstdio>` includes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131386
There seems to be an issue inside Intel OpenGL driver of legacy
platforms that fails to link `gpu_shader_sequencer_strips`.
Uniform locations are used to fix an specialization constants issue.
This PR only adds the uniform location when the shader can be
specialized. It is unclear what is actually failing inside the driver
but there are other issues with the driver.
Pull Request: https://projects.blender.org/blender/blender/pulls/131293
When copying from/to depth stencil images the aspect of the image was
set incorrectly. It pointed to only one aspect of the full image when
building resource links, which could lead to incorrect decisions in the
driver.
Found when researching #131269
Pull Request: https://projects.blender.org/blender/blender/pulls/131298
The new buffer size could have been non aligned when using the
fractional growing heuristic. This non aligned allocation
would then trigger an assert at the SSBO constructor.
Aligning the alocation size fixes the issue.
GPU and GHOST require to have identical checks to remove faulty drivers.
When not done GHOST can still select a device that isn't supported and
lead to freezing interfaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/131241
This was caused by querying on the selection state
before it is setup. It is only setup just before
the draw function.
To fix this, we sync the `info_buf` just before
drawing the overlays.
Also add some safety to avoid uninitialized memory.
Its not standard how `Present Engines` return images for presentation, and
currently is expected that they cycle between swap-chain images with each
`vkAcquireNextImageKHR` call.
However present engines could return any available image, that can mean
to reuse the last presented one if available. (This seem to be the behavior
using `Layered on DXGI Swapchain` the default `Present Method` used
with latest NVIDIA drivers on Windows).
Since resource pools expects to images to cycle in a sequential order, if any
present engine always return the same image for presentation only a single
resource pool would be used for each rendered frame, and since resources
are only released by cycling between resource pools, this resource pool would
overflow since it never releases any resource.
This changes makes resource pools to cycle each time a image is presented.
Pull Request: https://projects.blender.org/blender/blender/pulls/131129
This avoid stack overflow on GCC because types were getting too
large (70 bytes for a float4) and created a lot of static
memory for UBOs declarations.
