VKVertexAttributeObject was both defined as a class and a struct.
Settled on being a class.
Also removed an assert that is currently failing as workbench has
more attributes defined than actually used.
Pull Request: https://projects.blender.org/blender/blender/pulls/107874
After uploading the vertex buffer the state got corrupted.
Reason of this corruption is an assign-compare operation that should
just be an compare operation.
Pull Request: https://projects.blender.org/blender/blender/pulls/107875
Add support for index buffers as subrange. When an index buffer
is a subrange it should bind the source buffer and use the index start
as an offset in the buffer.
Pull Request: https://projects.blender.org/blender/blender/pulls/107871
Initial graphic pipeline targeting. The goal of this PR is to have an initial
graphics pipeline with missing features. It should help identifying
areas that requires engineering.
Current state is that developers of the GPU module can help with the many
smaller pieces that needs to be engineered in order to get it working. It is not
intended for users or developers from other modules, but your welcome to learn
and give feedback on the code and engineering part.
We do expect that large parts of the code still needs to be re-engineered into
a more future-proof implementation.
**Some highlights**:
- In Vulkan the state is kept in the pipeline. Therefore the state is tracked
per pipeline. In the near future this could be used as a cache. More research
is needed against the default pipeline cache that vulkan already provides.
- This PR is based on the work that Kazashi Yoshioka already did. And include
work from him in the next areas
- Vertex attributes
- Vertex data conversions
- Pipeline state
- Immediate support working.
- This PR modifies the VKCommandBuffer to keep track of the framebuffer and its
binding state(render pass). Some Vulkan commands require no render pass to be
active, other require a render pass. As the order of our commands on API level
can not be separated this PR introduces a state engine to keep track of the
current state and desired state. This is a temporary solution, the final
solution will be proposed when we have a pixel on the screen. At that time
I expect that we can design a command encoder that supports all the cases
we need.
**Notices**:
- This branch works on NVIDIA GPUs and has been validated on a Linux system. AMD
is known not to work (stalls) and Intel GPUs have not been tested at all. Windows might work
but hasn't been validated yet.
- The graphics pipeline is implemented with pixels in mind, not with performance. Currently
when a draw call is scheduled it is flushed and waited until it is finished drawing, before
other draw calls can be scheduled. We expected the performance to be worse that it actually
is, but we expect huge performance gains in the future.
- Any advanced drawing (that is used by the image editor, compositor or 3d viewport) isn't
implemented and might crash when used.
- Using multiple windows or resizing of window isn't supported and will stall the system.
Pull Request: https://projects.blender.org/blender/blender/pulls/106224
Vulkan doesn't have a conversion from uint32_t/int32_t to float. It does
have conversions from 16/8 bits. Main reason is that Vulkan expects that
there is no benefit when converting 32 bits from one type to the other
and should be solved by passing the right data type.
In Blender however this isn't the case as there are benefits on other
GPU backends (OpenGL for example).
This PR adds helper function to check if conversion is needed and
perform any conversions in place. It also implements the function to
upload vertex buffers to the GPU.
NOTE: Test cases have been added to validate this, but they are not
able to run on the Vulkan backend just yet, because they require the
graphics pipeline to be available.
Pull Request: https://projects.blender.org/blender/blender/pulls/107733
ShaderInput lookup used to be explicit as in we know for sure that the
shader input exists. This was guarded by a assert. During development
of the graphics pipeline we came to the conclusion that this isn't
always the case due to its late bindings of resources.
This PR Makes the shader input lookup return an optional result.
This result can then be checked depending on the area where it is used
to validate the existence.
Pull Request: https://projects.blender.org/blender/blender/pulls/107735
In Vulkan it is not allowed to allocate a buffer of zero bytes. This
would generate an error. In Blender it is possible that a buffer is zero
bytes. For example when the draw manager is drawing instances and there
are no instanced in the scene.
This PR ensures that at least a single byte is allocated in order to not
fail later on.
Co-authored-by: Jeroen Bakker <j.bakker@atmind.nl>
Pull Request: https://projects.blender.org/blender/blender/pulls/107731
Vulkan coordinate system is flipped compared to OpenGL. This PR
flips the drawing when drawn to the on-screen frame buffer.
Offscreen frame buffers are still drawn upside down.
The flipping is done by making the viewport of the framebuffer negative.
Pull Request: https://projects.blender.org/blender/blender/pulls/107743
Previous GHOST_ContextVK would create a logical device for each
context. Blender uses multiple contexts at the same time and wasn't able
to share resources between them as the logical device where different.
This patch will create a single logical device and share them between
multiple contexts. This allows sharing memory/shaders between contexts
and make sure that all memory allocations are freed from the device it
was allocated from.
Some allocations in Blender are freed when there isn't a context, this
was failing in the previous implementation. We didn't noticed it before
as we didn't test multiple contexts.
This patch also moves device specific data structures from VKContext to
VKDevice like the descriptor pools, debug layers etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/107606
Vulkan spec only wants to have a single aspect bit when a texture
contains both a stencil and a depth part. As for Blender depth
is more used than stencil we standardize to depth aspect.
Pull Request: https://projects.blender.org/blender/blender/pulls/107542
When creating a texture view, Metal may require that the original
GPUTexture state is modified in some way. This may be a result
of deferred creation, or, to cache the texture view against the
source.
As a result, GPUTexture passed into GPU_texture_create_view
cannot be const.
Small fixes have also been made in the Metal texture
implementation to ensure correct function of texture views.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/107167
This PR adds support for `GPU_unpack_row_length_set` to the vulkan
backend.
Texture unpacking is used when uploading a part of a texture from
host memory to device memory.
Pull Request: https://projects.blender.org/blender/blender/pulls/107360
Changes to the internal workings of the VKCommandBuffer:
- Use state engine to track correct usage.
- Switch between render pass/no render pass automatically.
Eventually the command buffer should be rewritten to use custom command
encoding to improve performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/107337
Apparently we always constructed a Vulkan 1.0 Context, although we
are targetting Vulkan 1.2. This also lead to incorrect expectations
when using the Vulkan Memory allocator.
Pull Request: https://projects.blender.org/blender/blender/pulls/107300
This PR uses the VK_EXT_debug_utils extension, but it's only for labeling, so it doesn't rely on the VK_LAYER_KHRONOS_validation functionality.
The functions that do these things are loaded into the runtime as vulkan extensions.
Declare the function pointers in a struct and make them members of vk_context.
Pull Request: https://projects.blender.org/blender/blender/pulls/106098
This PR adds debug information inside the spir-v assembly to enable
step-by-step debugging of Shaders using renderdoc. The debugging
information can be fairly large so are only generated when used
with the `--debug-gpu-renderdoc` feature.
During debugging shader optimizations are turned off.
Pull Request: https://projects.blender.org/blender/blender/pulls/106546
This patch refactors the texture samples code by mainly splitting the
eGPUSamplerState enum into multiple smaller enums and packing them
inside a GPUSamplerState struct. This was done because many members of
the enum were mutually exclusive, which was worked around during setting
up the samplers in the various backends, and additionally made the API
confusing, like the GPU_texture_wrap_mode function, which had two
mutually exclusive parameters.
The new structure also improved and clarified the backend sampler cache,
reducing the cache size from 514 samplers to just 130 samplers, which
also slightly improved the initialization time. Further, the
GPU_SAMPLER_MAX signal value was naturally incorporated into the
structure using the GPU_SAMPLER_STATE_TYPE_INTERNAL type.
The only expected functional change is in the realtime compositor, which
now supports per-axis repetition control, utilizing new API functions
for that purpose.
This patch is loosely based on an older patch D14366 by Ethan Hall.
Pull Request: https://projects.blender.org/blender/blender/pulls/105642
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
This PR adds support for clearing framebuffers and scissor testing.
Tweaks had to be made to VKTexture to keep track of its layout
on the device. Based on the actual call the layout can switch
to a more optimum layout.
For example during upload of a texture the texture will be converted
to a transfer destination optimized layout. When reading from the
texture it will be converted to a transfer source optimized layout.
The order of the attachments in the framebuffer follows the next rules
- When only color attachments are there the color attachments will
be placed in the slot they are defined. This way it will match
the ShaderCreateInfo binding location.
- When a stencil/depth attachment is added it will be placed
right after the color attachments. When there isn't a color
attachment it will be the first attachment.
Pull Request: https://projects.blender.org/blender/blender/pulls/106044
This PR adds basic support for texture update, read back and clearing
for Vulkan. In Vulkan we need to convert each data type ourselves as
vulkan buffers are untyped. Therefore this change mostly is about data
conversions.
Considerations:
- Use a compute shader to do the conversions:
- Leads to performance regression as compute pipeline can stall
graphics pipeline
- Lead to additional memory usage as two staging buffers are needed
one to hold the CPU data, and one to hold the converted data.
- Do inline conversion when sending the data to Vulkan using `eGPUDataFormat`
- Additional CPU cycles required and not easy to optimize as it the
implementation requires many branches.
- Do inline conversion when sending the data to Vulkan (optimized for CPU)
For this solution it was chosen to implement the 3rd option as it is fast
and doesn't require additional memory what the other options do.
**Use Imath/half.h**
This patch uses `Imath/half.h` (dependency of OpenEXR) similar to
alembic. But this makes vulkan dependent of the availability of
OpenEXR. For now this isn't checked, but when we are closer to
a working Vulkan backend we have to make a decision how to cope with
this dependency.
**Missing Features**
*Framebuffer textures*
This doesn't include all possible data transformations. Some of those
transformation can only be tested after the VKFramebuffer has been
implemented. Some texture types are only available when created for a
framebuffer. These include the depth and stencil variations.
*Component format*
Is more relevant when implementing VKVertexBuffer.
*SRGB textures*
SRGB encoded textures aren't natively supported on all platforms, in
all usages and might require workarounds. This should be done in a
separate PR in a later stage when we are required to use SRGB textures.
**Test cases**
The added test cases gives an overview of the missing bits and pieces of
the patch. When the implementation/direction is accepted more test cases
can be enabled/implemented.
Some of these test cases will skip depending on the actual support of
platform the tests are running on. For example OpenGL/NVidia will skip
the next test as it doesn't support the texture format on OpenGL, although
it does support it on Vulkan.
```
[ RUN ] GPUOpenGLTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI
[ SKIPPED ] GPUOpenGLTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI [ RUN ] GPUVulkanTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI
[ OK ] GPUVulkanTest.texture_roundtrip__GPU_DATA_2_10_10_10_REV__GPU_RGB10_A2UI
```
Pull Request: https://projects.blender.org/blender/blender/pulls/105762
In Vulkan multiple commands can be in flight simultaneously.
These commands can share resources like descriptor sets or push
constants. When between commands these resources are updated
a new version of the resources should be created.
When a resource is updated it should check the submission id of the
command buffer. If this is different than last known by the resources,
the previous resources should be freed.
If the submission id is the same than previously it has to create a
new version of the resource to not intervene with other commands that
uses the resource before the update.
When the resource wasn't updated between multiple usages in the same
submission id it could reuse the previous resource.
This PR introduces a `ResourceTracker` and a `SubmissionTracker`.
A submission tracker can check if the command buffer is submitted.
In this case all resources of the resource tracker should be freed.
Unmodified resources in the same submission can be shared.
A resource tracker will keep track of all resources that are in
flight. After the resources are used (submission + execution) have
finished the resources can be cleared.
Pull Request: https://projects.blender.org/blender/blender/pulls/105183
This PR uses renderdoc for frame capturing when enabled.
It enabled an easier workflow for frame capturing.
- Capture GPU API calls from test cases
- Capture GPU API calls from background threads
- Capture GPU API calls from background rendering.
Renderdoc is an important GPU debugger used by the Eevee/
Viewport module. Previously we needed to change code in
order to record background rendering, that could on its own
lead to other side-effects.
The integration with renderdoc can be enabled using
`WITH_RENDERDOC=On` compiler option. `GPU_debug_capture_begin`
and `GPU_debug_capture_end` can be added to the section
of the code you want to debug. When running Blender inside
renderdoc this part will automatically be captured.
All GPU test cases are now guarded by these calls. In order
to capture the test cases you need to start the test cases
from renderdoc and the captured GPU API calls will appear
where each capture is a single test case.
Pull Request: https://projects.blender.org/blender/blender/pulls/105921
Adds two modes of GPU frame capture support for
enhanced debugging. GPU frame capture begin/end
allow instantaneous frame capture of all GPU commands
within the capture boundary.
GPU frame capture scopes allow several user-defined capture
regions which can wrap key parts of code. These scopes are
exposed to connected GPU tools allowing the user to manually
trigger a capture of a known scope at the desired time.
This is currently integrated with the Metal backend for
support with Xcode.
Related to #105591
Pull Request: https://projects.blender.org/blender/blender/pulls/105717
