Vulkan: Texture Data Conversions #105762

Jeroen Bakker · 2023-03-14T13:59:35+01:00

Jeroen Bakker commented

2023-03-14 13:59:35 +01:00

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.

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 more memory than the other options.

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
and requires a workaround. This will be 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
your platform. For example on
OpenGL/NVidia I get the next failure, because the texture type isn't
supported. But it is in 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

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. 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 more memory than the other options. **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 and requires a workaround. This will be 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 your platform. For example on OpenGL/NVidia I get the next failure, because the texture type isn't supported. But it is in 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 ```

Jeroen Bakker added this to the 3.6 LTS milestone 2023-03-14 13:59:35 +01:00

Jeroen Bakker added the

 @ -0,0 +51,4 @@
   UNSUPPORTED,
 };
 static ConversionType type_of_conversion_float(eGPUTextureFormat device_format)

 @ -214,3 +214,3 @@
 {
   int mip = 0;
   int extent[3], offset[3] = {0, 0, 0};
   int extent[3] = {1, 1, 1};

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Vulkan: Texture Data Conversions #105762