Multi indirect drawing would bind an offset index buffer, but
indirect drawing parameters also offset the index buffer so
incorrect geometry was drawn.
Fixes drawing of meshes with multiple materials.
Pull Request: https://projects.blender.org/blender/blender/pulls/115190
This PR shows the memory footprint in the statusbar when activated.
Only memory allocated on the VRAM is counted. Memory allocated on host
memory is not counted.
Pull Request: https://projects.blender.org/blender/blender/pulls/115184
Currently we keep track of 3 command buffers. Data transfer, compute and
graphics. The reason is that data transfer and compute commands cannot
be recorded in a command buffer that has an active render pass.
This PR simplifies the implementation by combining data transfer and
compute commands as there is no need to separate those in individual
command buffers.
This is in preparation of improving submission performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/115033
In Blender a context should not be shared between threads. In Vulkan a
command pool must not be shared between threads. In the current
implementation the command pool are stored on device level and could
therefore be shared between multiple context which made the implementation
not matching these rules.
This PR moves the command pool from device to command buffers where it
would not conflict between other contexts. This PR doesn't make the Vulkan
backend fully multithreaded. The access to the queue is still missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/114977
Anisotropy samplers are optional in Vulkan. This change will disable
anisotropy samplers when the feature isn't available on the device.
The support for anisotropy samplers is around 90% so would not expect
any compatibility issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/114833
Until now the Vulkan backend supported a single pre-configured sampler.
This PR realizes creation, caching and freeing of samplers based on what
is required by the state manager.
The implementation is similar to OpenGL or Metal. This fixes many issues
including:
- Textures in workbench and eevee use the correct extend and filtering
- Custom icons render correctly
- Depth sampling issues
- Removes artifacts using EEVEE world shader, lighting and indirect lighting.
Pull Request: https://projects.blender.org/blender/blender/pulls/114827
The initial pipeline state was not set and could lead to undetected
state changes.
This fixes several issues, including:
* Fix incorrect colors in the UI, that would be used everywhere, and
could be fixed by restarting Blender.
* Overlay extra objects where drawn below the grid.
Pull Request: https://projects.blender.org/blender/blender/pulls/114792
Devices that don't support GPU_DEPTH_COMPONENT24 natively will use
GPU_DEPTH_COMPONENT32F in stead. When done the current code path raised
an error as the conversion type wasn't set.
Issue detected on AMD RX5700 device.
Pull Request: https://projects.blender.org/blender/blender/pulls/114786
3 component texture formats are often not supported by vulkan devices.
Sometimes the support is less than 5%. The 4 components variants have
more than 90% support.
This PR builds on top of the existing vulkan data conversion to add
the ability to convert between RGB16F<=>RGBA16F and RGB32F<=>RGBA32F
texture formats.
This allows using color management other then Standard/sRGB. Most places
the 3 component texture formats are phased out, but OCIO, external
render engines and real time compositor uses them.
Pull Request: https://projects.blender.org/blender/blender/pulls/114708
This PR solves an issue when using texture pools with textures that are not
natively supported by the device. In the previous implementation the
internal `Texture::format_` was changed. Any check if the texture could
be reused would fail as its format would be different that the requested one.
This PR fixes this by separating the requested format `Texture::format_` and
how it is stored on the GPU `VKTexture::device_format_`.
This solves the next artifacts:
* Workbench flickering artifacts on AMD/Intel GPUs
* Workbench TAA on AMD/Intel GPUs
* Overlays were not always drawn fully solid
Pull Request: https://projects.blender.org/blender/blender/pulls/114697
OpenGL uses a depth range between -1 and 1, which is then normalized.
Metal & Vulkan uses a depth range between 0 and 1, which is already normalized.
The final plan would be to default to a depth range between 0 and 1, but
for now the depth ranges are retargetted so they won't be clipped away.
This solves the next issues for users:
- Navigate control will be rendered correctly
- Ortographic view clipping artifacts
- EEVEE light evaluation
Retargetting happens at the end of the vertex stage or when a geometry
stage is present at the end of the geometry stage. Derivatives using
depth would have a different value compared to OpenGL, but would match
Metal backend. OpenGL performs clipping and generates derivatives based
on the original depth value.
`gl_FragCoord` and clipping would have some precision differences as clipping
and normalizing are done in a different order but would match Metal.
Geometry shaders should use `gpu_EmitVertex` to ensure that the retargetting
is done per vertex.
Pull Request: https://projects.blender.org/blender/blender/pulls/114669
There were some issues with workbench shadow drawing. This PR
does some tweaks to fix the shadow drawing on vulkan.
* Framebuffer stencil clearing when write stencil is disabled
* Tweaks to stencil operation and tests
* Disable restart for line adjacency
Pull Request: https://projects.blender.org/blender/blender/pulls/114673
Some minor tweaks to the vulkan backend to support grease pencil
drawing. The changes include:
* Add support for GPU_DATA_10_11_11_REV clearing
* Use correct index buffer start and count
Anti aliasing isn't working as they require different samplers being
configured and that require some design work.
Effects haven't been tested.
Pull Request: https://projects.blender.org/blender/blender/pulls/114659
On some platforms `VK_FORMAT_R8G8B8_*` are not supported as vertex buffers. The
obvious workaround for this is to use `VK_FORMAT_R8G8B8A8_*`. Using unsupported
vertex formats would crash Blender as it is not able to compile the graphics
pipelines that use them.
Known platforms are:
- NVIDIA Mobile GPUs (Quadro M1000M)
- AMD Polaris (open source drivers)
This PR adds the initial workings for other unsupported vertex buffer formats we
need to fix in the future.
`VKDevice.workarounds.vertex_formats` contain booleans if the workaround for
a specific format should be turned on (`r8g8b8 = true`). `VertexFormatConverter` can be
used to identify if conversions are needed and perform the conversion.
Pull Request: https://projects.blender.org/blender/blender/pulls/114572
Vulkan API uses Flags and FlagBits for enumerations. The FlagBits
contains the options that can be hold with the Flags data type.
This wasn't well understood at the beginning of the project and
the FlagBits where used where Flags should have been used. This cleanup
fixes this, improving the readability of the code where bit
manipulations where used.
Pull Request: https://projects.blender.org/blender/blender/pulls/114459
When using EEVEE-Next the final render data is readback from texture
views. This wasn't implemented yet.
This PR adds support for reading back texture views. It also makes sure
the correct layer is read when reading back data from framebuffers and
adds internal support to read back a partial texture.
Pull Request: https://projects.blender.org/blender/blender/pulls/114411
This PR replaces submissions with pipeline barriers when generating
mipmaps. This would reduce the amount of submissions and improve
performance during mipmap generation as dependencies will be tracked
between commands.
Pull Request: https://projects.blender.org/blender/blender/pulls/114306
Goal is to reduce the number of command buffer flushes by tracking what is
happening in the different command queues. This is an initial step towards
advanced queue-ing strategies.
The new (intermediate) strategy records commands to different command
buffers based on what they do. There is a command buffer for data transfers,
compute pipelines and graphics pipelines.
When a compute command is recorded it ensures that all graphic commands
are finished. When a graphic command is recorded it ensures all compute
commands are finished. When a graphic or compute command is scheduled
all recorded data transfer commands are scheduled as well.
Some improvements are expected as multiple compute and data transfers
commands can now be scheduled at the same time and don't need to unbind
and rebind render passes. Especially when using EEVEE-Next which is
compute centric the performance change is visible for the user.
Pull Request: https://projects.blender.org/blender/blender/pulls/114104
PR Introduces GPU_storagebuf_sync_to_host as an explicit routine to
flush GPU-resident storage buffer memory back to the host within the
GPU command stream.
The previous implmentation relied on implicit synchronization of
resources using OpenGL barriers which does not match the
paradigm of explicit APIs, where indiviaul resources may need
to be tracked.
This patch ensures GPU_storagebuf_read can be called without
stalling the GPU pipeline while work finishes executing. There are
two possible use cases:
1) If GPU_storagebuf_read is called AFTER an explicit call to
GPU_storagebuf_sync_to_host, the read will be synchronized.
If the dependent work is still executing on the GPU, the host
will stall until GPU work has completed and results are available.
2) If GPU_storagebuf_read is called WITHOUT an explicit call to
GPU_storagebuf_sync_to_host, the read will be asynchronous
and whatever memory is visible to the host at that time will be used.
(This is the same as assuming a sync event has already been signalled.)
This patch also addresses a gap in the Metal implementation where
there was missing read support for GPU-only storage buffers.
This routine now uses a staging buffer to copy results if no
host-visible buffer was available.
Reading from a GPU-only storage buffer will always stall
the host, as it is not possible to pre-flush results, as no
host-resident buffer is available.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/113456
Allow binding of framebuffers without sRGB to linear transform.
`GPU_framebuffer_bind_no_srgb`. This Patch removes color transform
artifacts in node, image and sequence editor.
When the framebuffer is an srgb framebuffer and it is bound without
the transformation, the SRGB textures are bound as UNORM variants.
As framebuffer, render pass and subpass recreation is ensured by
`VKCommandBuffer` we don't need to mark the framebuffer dirty at
this time. Later on we can optimize this by adding a state changed
detection for framebuffers and render passes.
Pull Request: https://projects.blender.org/blender/blender/pulls/113838
With the shift to GPU-driven rendering pipeline,
the SSBO vertex fetch paradigm used to
implement workbench shadows on Metal
instead of utilising the geometry shader
path no longer worked correctly.
This is because the draw submission
required vertex amplification up-front,
based on the expected output geometry
amount for a given input geometry.
This patch aims to resolve this
issue through addition of API to
enable the features within the
GPU driven pipeline.
Co-authored-by: Michael Parkin-White <mparkinwhite@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/113498
When drawing node sockets an immediate mode buffer is created that can
contain all the node sockets of the node. Only visible node sockets will
then be added. Vulkan assumed that all elements in the buffer needed to
be drawn, resulting using uninitialzed memory for drawing node sockets.
This resulted in very colorful and big artifacts rendered in the node
editor. This was detected during drawing of node sockets, but would have
been visible in other places as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/113830
When Vulkan is started with validation layers the console is flooded.
Somewhere in the Vulkan validation layers or mesa driver (or the
combination) there is an issue where maxBufferSize is reported by the
driver to be 4GB, but the validation layers are reporting any buffer
size to be larger than 4GB.
For now we skip this message to be logged.
Pull Request: https://projects.blender.org/blender/blender/pulls/113652
With the shift to GPU-driven rendering pipeline,
the SSBO vertex fetch paradigm used to
implement workbench shadows on Metal
instead of utilising the geometry shader
path no longer worked correctly.
This is because the draw submission
required vertex amplification up-front,
based on the expected output geometry
amount for a given input geometry.
This WIP patch aims to resolve this
issue through addition of API to
enable the features within the
GPU driven pipeline.
Co-authored-by: Michael Parkin-White <mparkinwhite@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/113498
This PR adds workarounds for platforms that don't support `shaderOutputLayer`
or `shaderOutputViewportIndex`. Some NVIDIA laptop GPUs and ARM GPUs don't
have those device features.
The workaround uses the same approach as OpenGL. A geometry shader is injected
to emulate the feature.
For testing the workarounds they have also been connected to the
`--debug-gpu-force-workarounds` command line argument.
Fixes#113475 by implementing #113529
Pull Request: https://projects.blender.org/blender/blender/pulls/113605
Vulkan backend doesn't support subpass transition yet. Currently
shader_builder fails as when compiling shaders that use subpass
transitions.
This PR adds a dummy global variable to the GLSL so the compilation
continues.
Development of subpass would take some time as the current API doesn't
fit Vulkan.
Pull Request: https://projects.blender.org/blender/blender/pulls/113604
When using Immediate mode emulation the data is stored in a ring buffer.
As data isn't overwritten it is safe to call multiple draw commands in
a single command buffer.
This improves drawing performance when immediate mode is being used, it
mostly improves the readability of the GPU traces in renderdoc.
Pull Request: https://projects.blender.org/blender/blender/pulls/113482
Wireframe mode wasn't working and viewport had flickering artifacts.
Reason was that the render pass creation failed for its framebuffer as
the input data was filled with garbage for attachments that were unused.
Vulkan requires every attachment to be filled upto the highest used attachment
slot. This PR fills missing attachments with a dummy texture.
Pull Request: https://projects.blender.org/blender/blender/pulls/113141
This adds basic emulation of the subpass input feature
of vulkan and to a lower extend Raster Order Group on Metal.
This help test paths that might use this feature in the future
(like shadow rendering) on all platform and or simplify higher
level code for supporting older hardware.
This add clear description to the load/store ops and to the
new `GPUAttachementState`.
The OpenGL backend will correctly mask un-writable
attachments and will bind as texture readable attachments.
Even if possible by the vulkan standard, the GPU API prohibit
the read and write to the same attachment inside the same
subpass.
In the GL backend, this is implemented using `glTextureBarrier`
and `texelFetch` as it is described in the ARB_texture_barrier
extension.
https://registry.khronos.org/OpenGL/extensions/ARB/ARB_texture_barrier.txt
Pull Request: https://projects.blender.org/blender/blender/pulls/112051
During Blitting it is not allowed to read/write outside
the texture bounds. This patch ensures that the bounds
(called extents in Vulkan) are inside the expected range.
Pull Request: https://projects.blender.org/blender/blender/pulls/113050
This PR adds support for `GPU_framebuffer_blit` When used with `GPU_DEPTH_BIT`.
The challenge with is that not all GPUs support using a depth texture as a blit destination.
An AMD GPU doesn't support a depth buffer with stencil buffer as blit destination.
> NOTE: AMD GPUs don't support 24 bit unsigned normalized depth textures at all.
In all cases when we use depth blitting we are blitting the whole texture
and in stead we can use a texture copy.
A negative effect is that we need to unbind the framebuffer when copying
depth textures, but a positive effect is that we can use a data transfer function what should
theoretically be faster.
This should be revisited when we are investigating in areas to improve the
performance of the Vulkan backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/112674
When initialy adding textures it wasn't possible to allocate during
initialization as its usage wasn't known. Bot Metal and Vulkan would do
a delayed allocation adding more checks when using textures.
Recently the behavior of setting texture usage was changed and now is
known when initializing textures. This PR makes advantage of this to
give correct feedback to the calling code if the texture can be created
and remove all the delayed allocating of textures.
Pull Request: https://projects.blender.org/blender/blender/pulls/112997
In Vulkan (and Metal) it is not possible to use a global as point
size. It needs to be set for each vertex when drawing points. Blender
has specialized shaders for that, but not all code respect those
shaders.
This PR will add an assert inside the vulkan backend when incorrect
usage of shaders are detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/112906
