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
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
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
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
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
It is recommended to map buffers once and not each time the
mapped memory is needed. This patch will map the buffer when
created and unmap the buffer when the buffer is freed.
This patch will reduce the overhead where the Vulkan driver or
the virtual memory manager needs to be accessed.
Pull Request: https://projects.blender.org/blender/blender/pulls/105588
Due to an error in GPU module we fixed the memory size in the
Vulkan backend. Last week the error has been fixed in the GPU module
so we can remove the temp fixes in the Vulkan backend.
Pull Request #105244
Descriptor set locations are now determined in the
VKShaderInterface. Issues with the previous solution:
- Due to legacy code in GPU module the locations/bindings
must be the same. Using one for something else might
result in undesired lookups, incorrect resource
bindings.
- Images/Textures reuses the same namespace, that didn't
work as expected when looking up the resources via
its binding.
This refactoring is required for adding support for
push constants.
Pull Request #105073
This patch adds initial support for compute shaders to
the vulkan backend. As the development is oriented to the test-
cases we have the implementation is limited to what is used there.
It has been validated that with this patch that the following test
cases are running as expected
- `GPUVulkanTest.gpu_shader_compute_vbo`
- `GPUVulkanTest.gpu_shader_compute_ibo`
- `GPUVulkanTest.gpu_shader_compute_ssbo`
- `GPUVulkanTest.gpu_storage_buffer_create_update_read`
- `GPUVulkanTest.gpu_shader_compute_2d`
This patch includes:
- Allocating VkBuffer on device.
- Uploading data from CPU to VkBuffer.
- Binding VkBuffer as SSBO to a compute shader.
- Execute compute shader and altering VkBuffer.
- Download the VkBuffer to CPU ram.
- Validate that it worked.
- Use device only vertex buffer as SSBO
- Use device only index buffer as SSBO
- Use device only image buffers
GHOST API has been changed as the original design was created before
we even had support for compute shaders in blender. The function
`GHOST_getVulkanBackbuffer` has been separated to retrieve the command
buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order
to do correct command buffer processing we needed access to the queue
owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles`
function.
Open topics (not considered part of this patch)
- Memory barriers & command buffer encoding
- Indirect compute dispatching
- Rest of the test cases
- Data conversions when requested data format is different than on device.
- GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices.
NVIDIA doesn't seem to support 1d textures.
Pull-request: #104518
This patch adds a placeholder for the vulkan backend.
When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`)
it might open a blender screen, but nothing should be visible as
none of the functions are implemented or otherwise crash on a nullptr.
This is expected as this is just a placeholder. The goal is to add shader compilation
+validation to this backend as one of the next steps so we can validate
changes to existing shaders on OpenGL, Metal and Vulkan at the same time.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D16338
