This seems like an out of memory issue where the storage
buffer could not be allocated but still used as a destination
for a copy. After an out of memory issue memory can be fragmented
and any allocation can still fail.
On `AMD Radeon(TM) 890M Graphics Advanced Micro Devices AMD`
`24.30.58` I got to multires subdivision level 2+6 using the steps
described in the report. 2+7 is failing for me. 2+6 already requires 16GB
of memory using large chunks.
OpenGL and Vulkan work with other limits and memory models and can
have different behavior. This PR only improves the mentioned issue, but
can still fail in other areas.
Pull Request: https://projects.blender.org/blender/blender/pulls/147713
On certain platforms Blender can crash on startup after the update of
VMA. This was because we want to select the correct memory area based on
requirements/preferences, but the overall flag was set to auto.
These options are mutual exclusive. This PR changes the flags to use the
requirements/preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/147781
Qualcomm driver team found an issue how Blender uses dynamic rendering.
The issue is that between suspend/resume of rendering only a limited
commands are possible. However we add commands that shouldn't be added
there. It is a violation of the Vulkan spec
VUID-VkSubmitInfo-pCommandBuffers-06015
It went unnoticed as it is mere a single line in the 5000+pages spec
and wasn't covered by the validation layers. This has been reported
upstream.
To fix this issue we remove the usage of suspending/resuming render
passes and fix any issue that used this together with clearops. Most
likely the fix will require a second dynamic rendering pass when
clearops are used.
Pull Request: https://projects.blender.org/blender/blender/pulls/147425
b2eaf812b1 made sure that the min offset alignment for text rendering
was used to calculate the correct offset. However the change didn't
update the region to be uploaded to the GPU. The artifacts are caused by
reading from allocated, but uninitialized memory.
This PR fixes this by calculating the correct region to copy to the GPU.
The artifact didn't appear on AMD/NVIDIA GPUs as their alignment are
4 bytes. Intel GPU is 64 bytes.
Pull Request: https://projects.blender.org/blender/blender/pulls/147265
Subimage tracking is done per layer, but workbench depth of field
required to track per mipmap level. This PR refactors sub image tracking
and implements tracking the state per mipmap level to ensure that
the correct pipeline barriers can be generated.
Most platforms wouldn't show any artifacts as the pixel layouts are the
same, but there it is a violation of the spec.
Pull Request: https://projects.blender.org/blender/blender/pulls/147207
!146956 introduced buffer streaming and is used to improve the
performance of text rendering. However the solution didn't check the
minimum allowed offset for storage buffers.
This PR will use the correct offset. This was only visible on Qualcomm
devices as other systems don't limit this offset.
Detected when looking into: #147023
Pull Request: https://projects.blender.org/blender/blender/pulls/147192
OpenGL has the concept of streaming buffers these buffers are marked to be
rewritten and used a small number of times. Vulkan (being low-level API)
doesn't have this concept. When performing font rendering Blender uses
streaming buffers and can slow down Vulkan as GPU barriers are added
between uploading and using the buffer.
Using a different approach could reduce the GPU barriers. The overall
idea is:
Altering render graph nodes
During font rendering the streaming buffer is rewritten from start with
the data to render the next part. This could only cover a part of the fully
allocated buffer. And would introduce a barrier before and after rewritting
the next part.
The allocated buffer on the GPU can fit more data but that data needs to be
passed along the first update to reduce the barriers. Allowing access to an
existing node in the render graph would allow to change the initial upload to
upload more data, without additional barriers.
VKStreamingBuffer
A new buffer type is introduced that will keep track of the streaming buffer
on the current render graph. A streaming buffer can be shared between multiple
threads and requires state manager to be done per context.
Pull Request: https://projects.blender.org/blender/blender/pulls/146956
7becc38a3c introduced new text rendering.
In the refactoring the vertex buffer was replaced by a more shallow
storage buffer. However the refactoring removed one optimization that
the vulkan backend uses, namely the actual amount of bytes that is being
used by the draw call. This resulted in overly large data transfers.
For example in the text editor the texts are rendered one glyph at a
time. But the storage buffer would always upload the data for 1024
glyphs.
This PR allows the usage size of a storage buffer to be set to ensure
that the data transfers are limited.
The implementation wasn't added to OpenGL as it draws incorrectly.
Issue detected during the research of !146956 That PR will implement
better data streaming inside the Vulkan backend and also requires
to know the actual usage size of the buffer to detect what data can
be grouped together.
Pull Request: https://projects.blender.org/blender/blender/pulls/146958
In Render properties > Color Management > Display.
* Off: Directly output image as produced by OpenColorIO. This is not correct
in general, but may be used when the system configuration and actual display
device is known to match the chosen display.
* Automatic: Display images consistent with most other applications, to preview
images and video for export. A best effort is made to emulate the chosen
display on the actual display device.
The option is grayed out when the current OpenColorIO config and display/view
does not support emulation.
Ref #145022, #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/146808
This PR moves the ownership of vulkan memory allocator from gpu/device
to GHOST/context/device. This will allow in the future a cleaner control
flow between OpenXR and Vulkan. Currently as the ownership is in the gpu
module many objects would need to pass from GHOST to the GPU module to be
shared between the 2 allocators. Moving both (OpenXR/Context) allocator
to GHOST would reduce the complexity.
Pull Request: https://projects.blender.org/blender/blender/pulls/146819
For wide line rendering it is preferred to use polyline shaders. However
creating a custom shader is complicated and a stone to far for many
scriptors.
This PR allows using line_width_set when wide line rendering is
supported by the platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/146762
This is the first step of moving the create infos
back inside shader sources.
All info files are now treated as source files.
However, they are not considered in the include tree
yet. This will come in another following PR.
Each shader source file now generate a `.info` file
containing only the create info declarations.
This renames all info files so that they do not
conflict with their previous versions that were
copied (non-generated).
Pull Request: https://projects.blender.org/blender/blender/pulls/146676
Due to an incorrect assumption float buffers were converted to sRGB
values when uploading to an sRGBA8 texture. This is done when rendering
flames in workbench and resulted in to bright renders.
This PR removes sRGB encoding when uploading float values to sRGBA8 textures.
Fixes:
- render/openvdb/fire
- render/openvdb/principled_blackbody
- render/openvdb/smoke_fire
Pull Request: https://projects.blender.org/blender/blender/pulls/146636
Before the render graph was introduced we relied on a submission
resource tracker that allowed to resuse resources in the next frame.
With the introduction of the render graph we slowly migrated the
resource tracking to the render graph and eventually also moved the
whole discard pools to the submission runner.
There was still one part that 'used' the legacy resource tracker, but
actually didn't as it never reused resources. This PR removes the
resource tracker and migrate the push constants to use the render graph
to update a single buffer per shader.
Pull Request: https://projects.blender.org/blender/blender/pulls/146627
Fixes several validation errors when using VMA.
- Always enable buffer device address in VMA as it is already a Blender
requirement.
- Add host access hints when host access is needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/146312
The referenced commit introduced the use of gamma 2.2 or piecewise sRGB
for the backbuffer blit depending on the operating system. This commit
switches from a push constant for this to a preprocessor define.
Ref 5d72498154
Pull Request: https://projects.blender.org/blender/blender/pulls/146170
Pixel buffers will be imported by Cycles in Cuda/OneAPI/HIP
when supported. However the priority and export field is not filled correctly,
resulting in that the priority is always 1 and the buffer is never exported.
Should be backported to 4.5 as Cycles GPU interop isn't working
when using Vulkan.
Regression introduced by: !144422
Pull Request: https://projects.blender.org/blender/blender/pulls/146090
Although this doesn't lead to any different behaviour or fixes any issue
it was an oversight as this would not wait for empty render graphs to be
finished in the order of submission
Pull Request: https://projects.blender.org/blender/blender/pulls/146066
`GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In
that case an approach where swap chain images are acquired and released
would map better. This PR introduces `GHOST_SwapWindowBufferAcquire`
and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap
chains.
Previous implementation would first record all GPU commands based on
the last used swap chain. In case a swapchain needed to be recreated
(window resize, move to other monitor) the recorded commands would
not match the swap chain and could lead to artifacts.
OpenGL only implements the release functions as they don't
have a mechanism to acquire a swap chain image. (Need to validate with
the Metal API how this is working and adapt is needed).
Currently when starting blender on a HDR capable display the first frame
would be based on an sRGB surface and presented on an extended RGB
(or other) surface. As these don't match the first frame could be incorrect and
also lead to UBs as another surface is expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/145728
Functions for convert between the color types and ostream support are
now outside the classes.
Many files were changed to fix cases where direct includes for headers
were missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/145756
Even when a device is capable to allocate a buffer with a certain size
it can still fail the allocation due to driver internals. This could be that
the memory area doesn't support the required flags or fragmentation.
This PR changes downloading GPU textures to CPU to use at max buffer
sizes of 2GB. Larger textures will be split over multiple buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/145568
Maintenance4 contains the maxBufferSize property that contains the
maximum allowed buffer allocation.
This PR uses this property to precheck if allocations will fail. It
was an attempt to improve the reliability of failing allocations but
currently they fail at the driver side.
Pull Request: https://projects.blender.org/blender/blender/pulls/145555
Multiple previous changes made resource pools obsolete. Resource
pools were used to keep track of resources when the frame is rendered.
Multiple frames can be rendered at the same time and resources could
overlap.
This has been replaced (not this commit) to be part of the render graph
and when an submission has completed the resources are recycled.
Continuation of: https://projects.blender.org/blender/blender/pulls/145408
Pull Request: https://projects.blender.org/blender/blender/pulls/145511
Multiple previous changes made resource pools obsolete. Resource
pools were used to keep track of resources when the frame is rendered.
Multiple frames can be rendered at the same time and resources could
overlap.
This has been replaced (not this commit) to be part of the render graph
and when an submission has completed the resources are recycled.
Pull Request: https://projects.blender.org/blender/blender/pulls/145408
Moves the descriptor pools from resource pools to thread data.
The descriptor pools uses a recycling approach and don't need
to be guarded anymore inside a resource pool. Now only the
descriptor set tracker is inside the resource pool.
Pull Request: https://projects.blender.org/blender/blender/pulls/145393
See the code comments for detailed explanation. But overall we use particular
combinations of sRGB and gamma 2.2 encode/decode to match SDR applications
while still ensuring HDR values are passed on linearly.
This means the user interface and SDR content will display different in
Windows HDR mode off and on, but that is consistent with other applications.
Split use_hdr variable into use_hdr_buffer about the graphics buffer,
and use_hdr_display about the chosen display in Blender.
Ref #145022
Pull Request: https://projects.blender.org/blender/blender/pulls/145025
The OpenGL specs require that the storage image qualifier in shaders
(e.g., "rgba32f") needs to be compatible with the format of a bound image
(see https://registry.khronos.org/OpenGL/specs/gl/glspec46.core.pdf#page=318).
We know that Blender currently does not handle this correctly in
multiple places. AMD and NVIDIA seem to silently ignore a mismatch and
just seem to use the format of the bound image. However, for the
Intel Windows drivers, this seems to lead to visual corruptions
(#141436, #141173). While a more graceful handling of a mismatch may
be nice, this is in line with the OpenGL specs.
This PR adds code for validating image formats for bindings.
Pull Request: https://projects.blender.org/blender/blender/pulls/143791
