Vulkan support #68990

New Issue

GHOST

We should add support for vulkan for all windowing system.

Linux X11
Windows
MacOS with MoltenVk
SDL

Preliminary Work

Work to be done before starting to work on the vulkan implementation.

Isolate OpenGL functions and constants to the GPU module.
Port most GPU C files containing OpenGL calls to C++.
#101905 (Blender: Add command line argument to switch gpu backends)
#93031 (GHOST Vulkan Backend API.)
#89364 (Vulkan: Add GLSL SpirV compiler.)

GPU module OpenGL backend

This needs to be complete before doing the vulkan backend. It is just a matter of isolating the GL specific code behind abstract classes.
Edit: Doing this refactor, it came up that doing clean abstraction is more time consuming. This step is not as straight forwards as it seems. However, doing it properly will ease the transition.

GL_batch
GL_context
GL_debug
GL_drawlist
GL_element
GL_capabilities
GL_framebuffer
GL_immediate
GL_platform
GL_select_pick
GL_select_sample_query
GL_shader
GL_shader_interface
GL_state
GL_texture
GL_uniformbuffer
GL_vertex_buffer

GPU module Vulkan backend

The Vulkan backend can be implemented as smaller tasks. In order to increase the validation and testability it was chosen to start with compute shader. Compute shaders are already being tested using GTEST. #104518 adds initial support for compute shaders and the first hand full of test cases.

After #104518 landed the development can scatter to improve the resource handling of vulkan.

VKStorageBuffer
VKTexture #105762
VKPixelBuffer
VKUniformBuffer
Support for push constants. #104880
Resource submission trackin. #105183
Renderdoc integration (used to validate internal workings)

The plan is to have the major part of this done in 2023Q1. In Q2 we can than focus on the minimum requirements to get Blender running using the Vulkan backend. This will be a highly instable version with a lot of render glitches, it might even be that immediate mode support isn't supported at all.

VKFrameBuffer
VKIndexBuffer
VKVertexBuffer
VKBatch
Graphics pipeline
Offscreen rendering
Basic Command Encoding

See #106224 for the progress of the graphical pipeline and the attached video to demonstrate the current state.

In Q3 we can focus on implementing all the missing features. Note that at this point we are not optimizing and utilizing Vulkan specific features, but use a least of development effort to get something running.

Immediate mode
Fallback for SRGB encoded textures.
Fallback for platforms not supporting 1D textures. #104812
AMD doesn't support VK_FORMAT_X8_D24_UNORM_PACK32. Idea is to be able to use a different texture format on the CPU/API level as actually being used on the GPU. This requires some refactoring of VKTexture.
Indirect drawing: It is implemented in a branch needs to add test cases. #111334
Add support for texture views. Is available in a branch, but requires some more test cases. and should be aligned with the refactoring of VKTexture. #110887
Texture filtering: Current implementation uses a single sampler for all textures.
Depth ranges/clipping: OpenGL and Vulkan uses different depth ranges which renders some UI elements (including the orientation widget) incorrect. Not sure what the best solution for this would be. Try experimenting with VK_EXT_depth_clip_control and check availability.
Resources of textures and buffers should be deallocated after the next flush/swap.
Add support to use a different GPU for rendering than the one attached to the display. According to the Vulkan specification this should be working out of the box. I expect some semaphore issues/resource issues in GHOST
Add support for barycentric coordinates for devices that don't support it. The extensions became available in vulkan 1.3 but before that time vendors could have implemented their own extension. Unclear what would be the best approach.
- Only work around and wait until we bump to vulkan 1.3. Workaround isn't supported when using geometry shaders, so we need to check where it is actually required.
- Allocate 1.3 context and check for official extension
Add support for pixel buffers
Add wayland support. Currently when building with wayland you cannot start blender with vulkan.
VKFramebuffer::blit_to should also support stencil and depth aspects.

In Q4 we can slowly stabilize, and add Vulkan specific optimizations to the code-base. Those optimizations are most likely be focussed on synchronizations, reducing overhead of data transfers/conversions. Here is a list of topics we already found as potential candidates to pick up in this quarter.

Implement GPUQueryPool. Current prototype shows it has to happen inside a single command submission. #112717
Use descriptor set per resource frequency
Use descriptor buffers (single ringbuffer)
Store static Vertex buffers/Index buffers on GPU memory
Auto include pipeline and resource barriers based on the commands inside the command buffer and the description of the ShaderCreateInfos. Might require changes to extract more detailed resource usage. MTL does this automatically, but VK this needs to be done manually. Doing it manually requires another buffer between the command buffer and the commands what leads to more overhead.
Use Vulkan 1.2 allocations. Currently the implementation is based on Vulkan 1.0 memory allocations without any extensions.
Use vulkan for cycles viewport drawing.

Compatibility issues

AMD RX 480:
Note I have only detected this to fail on Mesa drivers.

Validation Error: [ VUID-VkVertexInputAttributeDescription-format-00623 ] Object 0: handle = 0x7f7158652340, name = LogicalDevice_0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xa8c1a564 | vkCreateGraphicsPipelines: pCreateInfo[0].pVertexInputState->vertexAttributeDescriptions[1].format (VK_FORMAT_R8G8B8_UNORM) is not a supported vertex buffer format. (supported bufferFeatures: VkFormatFeatureFlags2(0)) The Vulkan spec states: The format features of format must contain VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT (https://vulkan.lunarg.com/doc/view/1.3.250.1/linux/1.3-extensions/vkspec.html#VUID-VkVertexInputAttributeDescription-format-00623) 
- ObjectType[VK_OBJECT_TYPE_DEVICE],Handle[0x7f7158652340],Name[LogicalDevice_0]```

## GHOST We should add support for vulkan for all windowing system. - [x] Linux X11 - [x] Windows - [x] MacOS with MoltenVk - [ ] SDL ## Preliminary Work Work to be done before starting to work on the vulkan implementation. - [x] Isolate OpenGL functions and constants to the GPU module. - [x] Port most GPU C files containing OpenGL calls to C++. - [x] #101905 (Blender: Add command line argument to switch gpu backends) - [x] #93031 (GHOST Vulkan Backend API.) - [x] #89364 (Vulkan: Add GLSL SpirV compiler.) ## GPU module OpenGL backend This needs to be complete before doing the vulkan backend. It is just a matter of isolating the GL specific code behind abstract classes. Edit: Doing this refactor, it came up that doing clean abstraction is more time consuming. This step is not as straight forwards as it seems. However, doing it properly will ease the transition. - [x] GL_batch - [x] GL_context - [x] GL_debug - [x] GL_drawlist - [x] GL_element - [x] GL_capabilities - [x] GL_framebuffer - [x] GL_immediate - [x] GL_platform - [x] GL_select_pick - [x] GL_select_sample_query - [x] GL_shader - [x] GL_shader_interface - [x] GL_state - [x] GL_texture - [x] GL_uniformbuffer - [x] GL_vertex_buffer ## GPU module Vulkan backend The Vulkan backend can be implemented as smaller tasks. In order to increase the validation and testability it was chosen to start with compute shader. Compute shaders are already being tested using GTEST. #104518 adds initial support for compute shaders and the first hand full of test cases. After #104518 landed the development can scatter to improve the resource handling of vulkan. - [x] VKStorageBuffer - [x] VKTexture #105762 - [x] VKPixelBuffer - [x] VKUniformBuffer - [x] Support for push constants. #104880 - [x] Resource submission trackin. #105183 - [x] Renderdoc integration (used to validate internal workings) The plan is to have the major part of this done in 2023Q1. In Q2 we can than focus on the minimum requirements to get Blender running using the Vulkan backend. This will be a highly instable version with a lot of render glitches, it might even be that immediate mode support isn't supported at all. - [x] VKFrameBuffer - [x] VKIndexBuffer - [x] VKVertexBuffer - [x] VKBatch - [x] Graphics pipeline - [x] Offscreen rendering - [x] Basic Command Encoding See #106224 for the progress of the graphical pipeline and the attached video to demonstrate the current state. In Q3 we can focus on implementing all the missing features. Note that at this point we are not optimizing and utilizing Vulkan specific features, but use a least of development effort to get something running. - [x] Immediate mode - [ ] Fallback for SRGB encoded textures. - [x] Fallback for platforms not supporting 1D textures. #104812 - [ ] AMD doesn't support `VK_FORMAT_X8_D24_UNORM_PACK32`. Idea is to be able to use a different texture format on the CPU/API level as actually being used on the GPU. This requires some refactoring of VKTexture. - [x] Indirect drawing: It is implemented in a branch needs to add test cases. #111334 - [ ] Add support for texture views. Is available in a branch, but requires some more test cases. and should be aligned with the refactoring of VKTexture. #110887 - [ ] Texture filtering: Current implementation uses a single sampler for all textures. - [ ] Depth ranges/clipping: OpenGL and Vulkan uses different depth ranges which renders some UI elements (including the orientation widget) incorrect. Not sure what the best solution for this would be. Try experimenting with `VK_EXT_depth_clip_control` and check availability. - [x] Resources of textures and buffers should be deallocated after the next flush/swap. - [ ] Add support to use a different GPU for rendering than the one attached to the display. According to the Vulkan specification this should be working out of the box. I expect some semaphore issues/resource issues in GHOST - [ ] Add support for barycentric coordinates for devices that don't support it. The extensions became available in vulkan 1.3 but before that time vendors could have implemented their own extension. Unclear what would be the best approach. - Only work around and wait until we bump to vulkan 1.3. Workaround isn't supported when using geometry shaders, so we need to check where it is actually required. - Allocate 1.3 context and check for official extension - [x] Add support for pixel buffers - [ ] Add wayland support. Currently when building with wayland you cannot start blender with vulkan. - [ ] VKFramebuffer::blit_to should also support stencil and depth aspects. In Q4 we can slowly stabilize, and add Vulkan specific optimizations to the code-base. Those optimizations are most likely be focussed on synchronizations, reducing overhead of data transfers/conversions. Here is a list of topics we already found as potential candidates to pick up in this quarter. - [ ] Implement GPUQueryPool. Current prototype shows it has to happen inside a single command submission. #112717 - [ ] Use descriptor set per resource frequency - [ ] Use descriptor buffers (single ringbuffer) - [ ] Store static Vertex buffers/Index buffers on GPU memory - [ ] Auto include pipeline and resource barriers based on the commands inside the command buffer and the description of the ShaderCreateInfos. Might require changes to extract more detailed resource usage. MTL does this automatically, but VK this needs to be done manually. Doing it manually requires another buffer between the command buffer and the commands what leads to more overhead. - [x] Use Vulkan 1.2 allocations. Currently the implementation is based on Vulkan 1.0 memory allocations without any extensions. - [ ] Use vulkan for cycles viewport drawing. **Compatibility issues** *AMD RX 480*: Note I have only detected this to fail on Mesa drivers. ```ERROR (gpu.debug.vulkan): : {0xa8c1a564}VUID-VkVertexInputAttributeDescription-format-00623 Validation Error: [ VUID-VkVertexInputAttributeDescription-format-00623 ] Object 0: handle = 0x7f7158652340, name = LogicalDevice_0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xa8c1a564 | vkCreateGraphicsPipelines: pCreateInfo[0].pVertexInputState->vertexAttributeDescriptions[1].format (VK_FORMAT_R8G8B8_UNORM) is not a supported vertex buffer format. (supported bufferFeatures: VkFormatFeatureFlags2(0)) The Vulkan spec states: The format features of format must contain VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT (https://vulkan.lunarg.com/doc/view/1.3.250.1/linux/1.3-extensions/vkspec.html#VUID-VkVertexInputAttributeDescription-format-00623) - ObjectType[VK_OBJECT_TYPE_DEVICE],Handle[0x7f7158652340],Name[LogicalDevice_0]```

does it blend.webm

14 MiB

Added subscriber: @dfelinto

Added subscriber: @Blendork

Added subscriber: @dabuxian

Added subscriber: @newin

Added subscriber: @blenderrocket

Added subscriber: @lemenicier_julien

Added subscriber: @1ace

Added subscriber: @MaciejJutrzenka

Added subscriber: @dhruvin

Added subscriber: @2046411367

Added subscriber: @BartekMoniewski

Added subscriber: @fclem

Added subscriber: @KenzieMac130

Added subscriber: @KuiyueRO

Added subscriber: @girafic

Added subscriber: @Tommy_Newman

Added subscriber: @AlexeyPerminov

Added subscriber: @filibis

Added subscriber: @MeshVoid

Added subscriber: @Stat_Headcrabed

Added subscriber: @ckohl_art

Added subscriber: @TheRedWaxPolice

Added subscriber: @Fux

Added subscriber: @sharaths21312

Added subscriber: @chr.schmitz

Added subscriber: @bblanimation

Added subscriber: @Wesley-Rossi

Added subscriber: @Alaska

Hello, I have worked with Vulkan before and I have a couple questions/concerns about pitfalls (many through hard lessons learned):

Is the handling of render synchronization going to be handled using a dependency graph like structure, manually or via a JIT system GL style? I can imagine it not being such a difficult task manually for the UI and possibly the viewport but Eevee might get out of hand.
One of the big issues in Vulkan is overlap between render-passes, framebuffers, vertex formats, descriptor layouts and pipelines. Things won't cleanly map to isolated concepts. I think GPU batches are an excellent step forward, don't underestimate how much tedious stuff Vulkan needs up front though.
Pipeline permutations. This can also get rather out of control especially if immediate mode style control of blending and depth testing settings come into play. Might be ideal to JIT compile permutations, garbage collect old ones and cache pipelines on disk for faster file loading with complex materials.
Persistently mapped memory/general memory nonsense. I am not the most familiar with how blender uploads data to the GPU in GL but in Vulkan it is possible and even recommended to keep data memory mapped between frames to flush. Mapping and unmapping memory is more expensive than other APIs. Beyond this, there is generally a lot more memory management things to worry about, keeping track of allocations, fragmenting, etc. Might be worth looking into a library like VMA for more robust memory management.
Multi-threading. Sooner rather than later. Vulkan ports often initially perform worse than GL. Would be a good idea to offset some inefficiencies by multi-threading scene draw calls. The way I have handled it in the past is a task would request a new secondary command buffer from a central manager each frame, it would pass that mini context to abstracted VkCmd functions and finalize geometry buckets with the manager, which is kicked off in a subpass. An important thing to note is that secondary command buffers are very limited in what they can do. Don't rely too heavily on them outside of parallelizing render passes.
Do not fall into the trap of command buffer re-use. Generally a lot of stuff in Vulkan can be re-used and slightly altered (pipeline dynamics) but re-using command buffers isn't worth it for scene rendering. As stated before secondary command buffers are limited and while one might be tempted to cache it with the rendered object: it does not inherit viewport settings... This kills re-use for multi-viewport/dynamic res apps. Instead of trying to create mechanisms to re-use command buffers for multiple frames, parallelize and lower the cost of recording them.
Will the shader interface generate descriptor layouts? If so what approach is going to be used? (combining manual definition, SPIR-V/GLSL reflection, etc)
Make sure you can debug your graphics code with tools like RenderDoc. Literal lifesaver. Might want to expose a way of creating markers in the GPU module for debugging.

I assume most of these have been addressed in this plan, just want to try and help contribute and avoid some disasters. I am excited to see Blender finally getting Vulkan support.

Thank you for your Amazing work!

Hello, I have worked with Vulkan before and I have a couple questions/concerns about pitfalls (many through hard lessons learned): 1. Is the handling of render synchronization going to be handled using a dependency graph like structure, manually or via a JIT system GL style? I can imagine it not being such a difficult task manually for the UI and possibly the viewport but Eevee might get out of hand. 2. One of the big issues in Vulkan is overlap between render-passes, framebuffers, vertex formats, descriptor layouts and pipelines. Things won't cleanly map to isolated concepts. I think GPU batches are an excellent step forward, don't underestimate how much tedious stuff Vulkan needs up front though. 3. Pipeline permutations. This can also get rather out of control especially if immediate mode style control of blending and depth testing settings come into play. Might be ideal to JIT compile permutations, garbage collect old ones and cache pipelines on disk for faster file loading with complex materials. 4. Persistently mapped memory/general memory nonsense. I am not the most familiar with how blender uploads data to the GPU in GL but in Vulkan it is possible and even recommended to keep data memory mapped between frames to flush. Mapping and unmapping memory is more expensive than other APIs. Beyond this, there is generally a lot more memory management things to worry about, keeping track of allocations, fragmenting, etc. Might be worth looking into a library like VMA for more robust memory management. 5. Multi-threading. Sooner rather than later. Vulkan ports often initially perform worse than GL. Would be a good idea to offset some inefficiencies by multi-threading scene draw calls. The way I have handled it in the past is a task would request a new secondary command buffer from a central manager each frame, it would pass that mini context to abstracted VkCmd functions and finalize geometry buckets with the manager, which is kicked off in a subpass. An important thing to note is that secondary command buffers are very limited in what they can do. Don't rely too heavily on them outside of parallelizing render passes. 6. Do not fall into the trap of command buffer re-use. Generally a lot of stuff in Vulkan can be re-used and slightly altered (pipeline dynamics) but re-using command buffers isn't worth it for scene rendering. As stated before secondary command buffers are limited and while one might be tempted to cache it with the rendered object: it does not inherit viewport settings... This kills re-use for multi-viewport/dynamic res apps. Instead of trying to create mechanisms to re-use command buffers for multiple frames, parallelize and lower the cost of recording them. 7. Will the shader interface generate descriptor layouts? If so what approach is going to be used? (combining manual definition, SPIR-V/GLSL reflection, etc) 8. Make sure you can debug your graphics code with tools like RenderDoc. Literal lifesaver. Might want to expose a way of creating markers in the GPU module for debugging. I assume most of these have been addressed in this plan, just want to try and help contribute and avoid some disasters. I am excited to see Blender finally getting Vulkan support. Thank you for your Amazing work!

Added subscriber: @AmpereNV

Added subscriber: @marioamb

@astrand130

Is the handling of render synchronization going to be handled using a dependency graph like structure, manually or via a JIT system GL style? I can imagine it not being such a difficult task manually for the UI and possibly the viewport but Eevee might get out of hand.

Render sync is something I'm not super familiar with. I do believe that the UI (using our immediate mode) will be first to be implemented.

One of the big issues in Vulkan is overlap between render-passes, framebuffers, vertex formats, descriptor layouts and pipelines. Things won't cleanly map to isolated concepts. I think GPU batches are an excellent step forward, don't underestimate how much tedious stuff Vulkan needs up front though.

We have already taken some time to plan this. Our GPU objects should be able to abstract most of this. For pipelines we plan to use a hashmap.

Pipeline permutations. This can also get rather out of control especially if immediate mode style control of blending and depth testing settings come into play. Might be ideal to JIT compile permutations, garbage collect old ones and cache pipelines on disk for faster file loading with complex materials.

For the UI we could cache these permutations but I wouldn't do that for the materials (too many variations).

Persistently mapped memory/general memory nonsense. I am not the most familiar with how blender uploads data to the GPU in GL but in Vulkan it is possible and even recommended to keep data memory mapped between frames to flush. Mapping and unmapping memory is more expensive than other APIs. Beyond this, there is generally a lot more memory management things to worry about, keeping track of allocations, fragmenting, etc. Might be worth looking into a library like VMA for more robust memory management.

This could be abstracted inside our GPU object and just double or tripple buffer everything. Thanks for the VMA suggestion, I'll likely add this to our dependencies.

Multi-threading. Sooner rather than later. Vulkan ports often initially perform worse than GL. Would be a good idea to offset some inefficiencies by multi-threading scene draw calls. The way I have handled it in the past is a task would request a new secondary command buffer from a central manager each frame, it would pass that mini context to abstracted VkCmd functions and finalize geometry buckets with the manager, which is kicked off in a subpass. An important thing to note is that secondary command buffers are very limited in what they can do. Don't rely too heavily on them outside of parallelizing render passes.

Initial implementation is likely not going to have any mutli-threading.
Our viewport rendering is using some RenderPass abstraction that would have to be compatible with multithreading first. But we could also look at just multithreading the submission process first which would be way more trivial.

Do not fall into the trap of command buffer re-use. Generally a lot of stuff in Vulkan can be re-used and slightly altered (pipeline dynamics) but re-using command buffers isn't worth it for scene rendering. As stated before secondary command buffers are limited and while one might be tempted to cache it with the rendered object: it does not inherit viewport settings... This kills re-use for multi-viewport/dynamic res apps. Instead of trying to create mechanisms to re-use command buffers for multiple frames, parallelize and lower the cost of recording them.

I already fell into this trap before trying to cache our render tree between redraw. But this was not easily acheivable. So caching using another on top of another API does not sounds plausible for now.

Will the shader interface generate descriptor layouts? If so what approach is going to be used? (combining manual definition, SPIR-V/GLSL reflection, etc)

This is something I'm still thinking about. I would like to

Make sure you can debug your graphics code with tools like RenderDoc. Literal lifesaver. Might want to expose a way of creating markers in the GPU module for debugging.

We already use renderdoc for debugging. We have markers inside the DRW manager to monitor renderpass time. I did not try to use the GL debug names yet. Something to keep in mind for future code quality cleanups!

Thank again for sharing your thoughts!

@astrand130 >Is the handling of render synchronization going to be handled using a dependency graph like structure, manually or via a JIT system GL style? I can imagine it not being such a difficult task manually for the UI and possibly the viewport but Eevee might get out of hand. Render sync is something I'm not super familiar with. I do believe that the UI (using our immediate mode) will be first to be implemented. >One of the big issues in Vulkan is overlap between render-passes, framebuffers, vertex formats, descriptor layouts and pipelines. Things won't cleanly map to isolated concepts. I think GPU batches are an excellent step forward, don't underestimate how much tedious stuff Vulkan needs up front though. We have already taken some time to plan this. Our GPU objects should be able to abstract most of this. For pipelines we plan to use a hashmap. >Pipeline permutations. This can also get rather out of control especially if immediate mode style control of blending and depth testing settings come into play. Might be ideal to JIT compile permutations, garbage collect old ones and cache pipelines on disk for faster file loading with complex materials. For the UI we could cache these permutations but I wouldn't do that for the materials (too many variations). >Persistently mapped memory/general memory nonsense. I am not the most familiar with how blender uploads data to the GPU in GL but in Vulkan it is possible and even recommended to keep data memory mapped between frames to flush. Mapping and unmapping memory is more expensive than other APIs. Beyond this, there is generally a lot more memory management things to worry about, keeping track of allocations, fragmenting, etc. Might be worth looking into a library like VMA for more robust memory management. This could be abstracted inside our GPU object and just double or tripple buffer everything. Thanks for the VMA suggestion, I'll likely add this to our dependencies. >Multi-threading. Sooner rather than later. Vulkan ports often initially perform worse than GL. Would be a good idea to offset some inefficiencies by multi-threading scene draw calls. The way I have handled it in the past is a task would request a new secondary command buffer from a central manager each frame, it would pass that mini context to abstracted VkCmd functions and finalize geometry buckets with the manager, which is kicked off in a subpass. An important thing to note is that secondary command buffers are very limited in what they can do. Don't rely too heavily on them outside of parallelizing render passes. Initial implementation is likely not going to have any mutli-threading. Our viewport rendering is using some RenderPass abstraction that would have to be compatible with multithreading first. But we could also look at just multithreading the submission process first which would be way more trivial. >Do not fall into the trap of command buffer re-use. Generally a lot of stuff in Vulkan can be re-used and slightly altered (pipeline dynamics) but re-using command buffers isn't worth it for scene rendering. As stated before secondary command buffers are limited and while one might be tempted to cache it with the rendered object: it does not inherit viewport settings... This kills re-use for multi-viewport/dynamic res apps. Instead of trying to create mechanisms to re-use command buffers for multiple frames, parallelize and lower the cost of recording them. I already fell into this trap before trying to cache our render tree between redraw. But this was not easily acheivable. So caching using another on top of another API does not sounds plausible for now. >Will the shader interface generate descriptor layouts? If so what approach is going to be used? (combining manual definition, SPIR-V/GLSL reflection, etc) This is something I'm still thinking about. I would like to >Make sure you can debug your graphics code with tools like RenderDoc. Literal lifesaver. Might want to expose a way of creating markers in the GPU module for debugging. We already use renderdoc for debugging. We have markers inside the DRW manager to monitor renderpass time. I did not try to use the GL debug names yet. Something to keep in mind for future code quality cleanups! Thank again for sharing your thoughts!

@fclem Awesome! Glad you found some of it useful!
I have spent a bit of time digging through the different gpu modules and have made some notes on them and how I would personally address them. I will post the notes, hopefully they are also useful.

GPU_batch:
- desc: contains vertex buffer, index buffer, and a reference to "GPUShaderInterface"
- depends: GPUShaderInterface, VertexBuffer, Element
- vulkan requires: N/A
- notes: pretty standard geo bucket, if GPUShaderInterface maps to a pipeline layout we are pretty much good.
GPU_context:
- desc: "default_vao" (is this also default VBO?), "default framebuffer" (get to why this is a problem later), GPU_batches, xform matrix, "VAO" GC and thread safety for GL
- depends: GPU_batch, GPU_framebuffer
- vulkan requires: N/A
- notes: per-thread render context, seems to allow multiple threads to be merged? In VK the matrix stack can be immediately uploaded through push constants, however this would knock off 64 bytes per-active-matrix from an already strained push constant limmit: https://vulkan.gpuinfo.org/displaydevicelimit.php?name=maxPushConstantsSize, VAO's ditto, VK-era thread-global immediate contexts seem not great.
GPU_debug:
- desc: debug logging and markers
- depends: N/A
- vulkan requires: N/A
- notes: straight shot to validation layers
GPU_drawlist:
- desc: contains a batch of geometry, "base index" (instance index?), a list of draw call data buckets "GPUDrawCommand/GPUDrawCommandIndexed", or an optional indirect draw buffer. (Feels like an extension of GPU_batch)
- depends: GPUBatch
- vulkan requires: N/A
- notes: pretty straight-forward port, replace a GLuint and you are pretty much done.
GPU_element:
- desc: module maintains information about the vertex buffer: int type, base idx, a IBO, bunch of seemingly irrelevant to VK CPU side stuff, uploading to the index buffer.
- depends: N/A
- vulkan requires: N/A
- notes: convert "gl_index_type" GL enum to VkIndexType, encapsulate glBufferData with Vulkan paperwork and you are done (again... buffer/persistent memory and all that jazz).
GPU_extensions:
- desc: handles GL extensions, capabilities, workarounds, etc.
- depends: N/A
- vulkan requires: N/A
- notes: Lots of stuff that was an extension in GL is now standard but with things like "GPU_crappy_amd_driver" (lol) being public scope probably it would be good if a lot of these were subcatogorized as "legacy GL related stuff". asside from hardware info Vulkan would be a fresh start. "Get API" enum, add "supports_raytracing()" just to get people excited :)
GPU_framebuffer:
- desc: contains a list of attachments, width, height, "dirty_flag" (rebuilding FBO?)
- depends: GPUTexture
- vulkan requires: VkRenderPass (compatible)
- notes: This is where I get concerned... We hit on a fundamental difference between Vulkan and GL... Renderpasses! https:*www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#renderpass-compatibility PERMUTATION ISSUE!: Create one using compatible dummy renderpasses you somehow figured out ahead of time (very not practical) or use "GPUFrameBuffer" to simply help create child framebuffers on the fly and figure out caching. You will likely need to solve/plan for the renderpass overlap crisis first! https:*youtu.be/x2SGVjlVGhE (11:30 references frambuffer)
GPU_immediate:
- desc: old-fashioned GL style rendering
- depends: GPUShader, GPUVertFormat
- vulkan requires: Shader reflection data
- notes: (In an ideal world this could be parallelized by passing imm contexts to functions but I will skip past that, too much refactor.) immInit/immActivate/immDeactivate/immDestroy buffer setup would need porting. immBindShader should convert well assuming it maps to pipelines. VAOs need to go bybye. PERMUTATION ISSUE!: Uniforms are unsupported in Vulkan and will need to be handled by manually constructing and caching a UBO for each draw call (very not ideal, but push constants will not cut it). Strings are no-longer sufficient and should look into a (GLSL-level) shader reflection structure. PERMUTATION ISSUE!: Descriptor sets: Given the fact that you can arbitrarilly bind textures and vary uniforms per-draw either a massive refactor would be needed or a JIT creation of descriptor sets. Might be worth looking into bindless textures via descriptor arrays (not confused w/ array textures, these have no size/format/sampler/continuous memory restrictions) for different types and dynamic uniform buffers to solve/aleviate these. https:*github.com/SaschaWillems/Vulkan/tree/master/examples/dynamicuniformbuffer http:*roar11.com/2019/06/vulkan-textures-unbound/ under this approach the dynamic uniform buffer becomes basically a per-frame linear allocator of constant values and textures (since textures are now just integers). Whenever a new shader is bound with a different constant layout or values are set after a draw the allocator progresses.
GLSL:
- desc: shader snippets
- depends: N/A
- vulkan requires: Better defined inputs
- notes: GLSL will need to be ported to convert uniforms to UBO data if Vulkan is specified (this can be done with clever use of macros). In addition GLSL level shader reflection data will be required to get the offset into the UBO data. Extra care will be needed as vanilla Vulkan 1.1x has its own alignment issues: https:*www.khronos.org/registry/vulkan/specs/1.1-extensions/html/chap15.html#interfaces-resources-layout this can be bypassed with a (commonly supported by up-to-date drivers) extension (or Vulkan 1.2 core) https:*www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_uniform_buffer_standard_layout.html). Texture sampling should be abstracted to macros as well to add support for bindless indexing with minimal API change.
GPU_platform:
- desc: retrieves information about current device
- depends: N/A
- vulkan requires: N/A
- notes: not much to say
GPU_select_pick:
- desc: handles object picking from the depth buffer by reading back depth buffer data.
- depends: ?
- vulkan requires: N/A
- notes: If your hardware supports Vulkan chances are you could do something like this in a compute shader instead of CPU depth buffer readback.
GPU_select_sample_query:
- desc: manages hardware occlusion query for selection
- depends: N/A
- vulkan requires: N/A
- notes: should be straight forward? haven't worked much with occlusion queries
GPU_shader:
- desc: group of shader types for rasterization, contains "interface", functionality for shader compiling pipeline
- depends: GPUShaderInterface
- vulkan requires: N/A
- notes: hook this up to shaderc to compile SPIR-V, unless addressed somehow... uniforms need to go, refactor the explicit inputs for different shader types (vertex/frag/geo) to support more categories and other domains than rasterization.
GPU_shader_interface:
- desc: contains shader reflection data
- depends: N/A
- vulkan requires: N/A
- notes: this would be a perfect time to collect the data that is not availible in SPIR-V from GLSL and create a pipeline layout
GPU_state:
- desc: Manages immediate mode state (glEnable()/glDisable())
- depends: N/A (kind of the problem... :))
- vulkan requires: PERMUTATION ISSUE!: VkRenderPass (compatible), Subpass, VkDescriptorSetLayout, Vertex Layout, Depth State, Blend State, MSAA, Topology, (VP/Scissors are ommitted through dynamics), otherwise the kitchen sink...
- notes: As pointed out: JIT creation of pipelines and hash maps seems to be the best way to go. Long term optimization: Recent disk cache particularly heavy, long-to compile base pipelines to improve ux when loading files (complex shader graphs), small shaders shouldn't be a problem in my experience (though I have only ever loaded SPIR-V from disk so skipping shader compile by caching might be worth it). https:*www.khronos.org/registry/vulkan/specs/1.2/html/chap10.html#pipelines-cache Use pipeline derivatives to quickly create variations for state changes. https:*www.khronos.org/registry/vulkan/specs/1.2/html/chap10.html#pipelines-pipeline-derivatives you can also use various dynamic state extensions.
GPU_texture:
- desc: gpu raster containers
- depends: N/A
- vulkan requires: N/A
- notes: The definition (restriction) of what a texture is in Vulkan is very loose, especially with the ability to control, reuse, page and alias memory and types as you please. Most of them are exotic game optimizations that Blender probably doesn't need. But the one thing I would reccomend is setting aside a place and leave open the door for sparse memory (possibly for implementing well after GL is no-more). VMA already makes this easier. Blender is now responsible for rendering detailed volumetrics on the GPU, these 3D textures can take up a lot of memory fast. A future where eevee can render sparse voxels for detailed sims would be rather welcome. https://www.asawicki.info/news_1698_vulkan_sparse_binding_-_a_quick_overview This would be a long term goal... The initial implimentation should be just replicating GL/DX style textures by combining Images and Image Views. Should store bindless index as applicable (if that approach is taken)
GPU_uniformbuffer:
- desc: Pretty straight-forward implimentation of a UBO
- depends: N/A
- vulkan requires: N/A
- notes: PERMUTATION ISSUE! Vulkan groups shader inputs into descriptor sets so: GPU_uniformbuffer_bind() would need an aux JIT descriptor set, you could also impliment dynamic uniform buffer capabilities here if you wanted to avoid issues with immediate mode uniform variables. Other than that just refactors for persistent mapping.
GPU_vertex_buffer:
- desc: Pretty straight-forward implimentation of a VBO
- depends: N/A
- vulkan requires: N/A
- notes: Persistent mapping, (possibly in the future investigate sparse memory binding for improved edit performance for vertex/element resizing?)
GPU_vertex_format:
- desc: Handles CPU side vertex attribute packing, encoding and swizzling
- depends: N/A
- vulkan requires: N/A
- notes: Enumerator refactor

These are my own observations based on a pretty limited interaction with blender's GPU code. I am sure there is a lot I am not aware of that might be an issue.
A lot of it is probably stuff to tackle later down the line, I just threw some of it in there because certain possibilities opened up with Vulkan are exciting.
Also it deviates under the hood a bit from the GL implementation. In my opinion the GL/VK backends should not be treated like a 1-1 thing technique wise, especially since it is a new API with a very different way of doing things. While understanding the legacy and design of GL rendering in Blender, Modernizing how it uses the graphics API where possible or things like introducing the concept of bindless textures seems like a necessary step to reducing complexity of the VK backend.

Thank you!

@fclem Awesome! Glad you found some of it useful! I have spent a bit of time digging through the different gpu modules and have made some notes on them and how I would personally address them. I will post the notes, hopefully they are also useful. GPU_batch: - desc: contains vertex buffer, index buffer, and a reference to "GPUShaderInterface" - depends: GPUShaderInterface, VertexBuffer, Element - vulkan requires: N/A - notes: pretty standard geo bucket, if GPUShaderInterface maps to a pipeline layout we are pretty much good. GPU_context: - desc: "default_vao" (is this also default VBO?), "default framebuffer" (get to why this is a problem later), GPU_batches, xform matrix, "VAO" GC and thread safety for GL - depends: GPU_batch, GPU_framebuffer - vulkan requires: N/A - notes: per-thread render context, seems to allow multiple threads to be merged? In VK the matrix stack can be immediately uploaded through push constants, however this would knock off 64 bytes per-active-matrix from an already strained push constant limmit: https://vulkan.gpuinfo.org/displaydevicelimit.php?name=maxPushConstantsSize, VAO's ditto, VK-era thread-global immediate contexts seem not great. GPU_debug: - desc: debug logging and markers - depends: N/A - vulkan requires: N/A - notes: straight shot to validation layers GPU_drawlist: - desc: contains a batch of geometry, "base index" (instance index?), a list of draw call data buckets "GPUDrawCommand/GPUDrawCommandIndexed", or an optional indirect draw buffer. (Feels like an extension of GPU_batch) - depends: GPUBatch - vulkan requires: N/A - notes: pretty straight-forward port, replace a GLuint and you are pretty much done. GPU_element: - desc: module maintains information about the vertex buffer: int type, base idx, a IBO, bunch of seemingly irrelevant to VK CPU side stuff, uploading to the index buffer. - depends: N/A - vulkan requires: N/A - notes: convert "gl_index_type" GL enum to VkIndexType, encapsulate glBufferData with Vulkan paperwork and you are done (again... buffer/persistent memory and all that jazz). GPU_extensions: - desc: handles GL extensions, capabilities, workarounds, etc. - depends: N/A - vulkan requires: N/A - notes: Lots of stuff that was an extension in GL is now standard but with things like "GPU_crappy_amd_driver" (lol) being public scope probably it would be good if a lot of these were subcatogorized as "legacy GL related stuff". asside from hardware info Vulkan would be a fresh start. "Get API" enum, add "supports_raytracing()" just to get people excited :) GPU_framebuffer: - desc: contains a list of attachments, width, height, "dirty_flag" (rebuilding FBO?) - depends: GPUTexture - vulkan requires: VkRenderPass (compatible) - notes: This is where I get concerned... We hit on a fundamental difference between Vulkan and GL... Renderpasses! https:*www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#renderpass-compatibility **PERMUTATION ISSUE!**: Create one using compatible dummy renderpasses you somehow figured out ahead of time (very not practical) or use "GPUFrameBuffer" to simply help create child framebuffers on the fly and figure out caching. You will likely need to solve/plan for the renderpass overlap crisis first! https:*youtu.be/x2SGVjlVGhE (11:30 references frambuffer) GPU_immediate: - desc: old-fashioned GL style rendering - depends: GPUShader, GPUVertFormat - vulkan requires: Shader reflection data - notes: (In an ideal world this could be parallelized by passing imm contexts to functions but I will skip past that, too much refactor.) immInit/immActivate/immDeactivate/immDestroy buffer setup would need porting. immBindShader should convert well assuming it maps to pipelines. VAOs need to go bybye. **PERMUTATION ISSUE!**: **Uniforms are unsupported in Vulkan** and will need to be handled by manually constructing and caching a UBO for each draw call (very not ideal, but push constants will not cut it). Strings are no-longer sufficient and should look into a (GLSL-level) shader reflection structure. **PERMUTATION ISSUE!**: Descriptor sets: Given the fact that you can arbitrarilly bind textures and vary uniforms per-draw either a massive refactor would be needed or a JIT creation of descriptor sets. Might be worth looking into bindless textures via descriptor arrays (not confused w/ array textures, these have no size/format/sampler/continuous memory restrictions) for different types and dynamic uniform buffers to solve/aleviate these. https:*github.com/SaschaWillems/Vulkan/tree/master/examples/dynamicuniformbuffer http:*roar11.com/2019/06/vulkan-textures-unbound/ under this approach the dynamic uniform buffer becomes basically a per-frame linear allocator of constant values and textures (since textures are now just integers). Whenever a new shader is bound with a different constant layout or values are set after a draw the allocator progresses. GLSL: - desc: shader snippets - depends: N/A - vulkan requires: Better defined inputs - notes: GLSL will need to be ported to convert uniforms to UBO data if Vulkan is specified (this can be done with clever use of macros). In addition GLSL level shader reflection data will be required to get the offset into the UBO data. Extra care will be needed as vanilla Vulkan 1.1x has its own alignment issues: https:*www.khronos.org/registry/vulkan/specs/1.1-extensions/html/chap15.html#interfaces-resources-layout this can be bypassed with a (commonly supported by up-to-date drivers) extension (or Vulkan 1.2 core) https:*www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_uniform_buffer_standard_layout.html). Texture sampling should be abstracted to macros as well to add support for bindless indexing with minimal API change. GPU_platform: - desc: retrieves information about current device - depends: N/A - vulkan requires: N/A - notes: not much to say GPU_select_pick: - desc: handles object picking from the depth buffer by reading back depth buffer data. - depends: ? - vulkan requires: N/A - notes: If your hardware supports Vulkan chances are you could do something like this in a compute shader instead of CPU depth buffer readback. GPU_select_sample_query: - desc: manages hardware occlusion query for selection - depends: N/A - vulkan requires: N/A - notes: should be straight forward? haven't worked much with occlusion queries GPU_shader: - desc: group of shader types for rasterization, contains "interface", functionality for shader compiling pipeline - depends: GPUShaderInterface - vulkan requires: N/A - notes: hook this up to shaderc to compile SPIR-V, unless addressed somehow... uniforms need to go, refactor the explicit inputs for different shader types (vertex/frag/geo) to support more categories and other domains than rasterization. GPU_shader_interface: - desc: contains shader reflection data - depends: N/A - vulkan requires: N/A - notes: this would be a perfect time to collect the data that is not availible in SPIR-V from GLSL and create a pipeline layout GPU_state: - desc: Manages immediate mode state (glEnable()/glDisable()) - depends: N/A (kind of the problem... :)) - vulkan requires: **PERMUTATION ISSUE!**: VkRenderPass (compatible), Subpass, VkDescriptorSetLayout, Vertex Layout, Depth State, Blend State, MSAA, Topology, (VP/Scissors are ommitted through dynamics), otherwise the kitchen sink... - notes: As pointed out: JIT creation of pipelines and hash maps seems to be the best way to go. Long term optimization: Recent disk cache particularly heavy, long-to compile base pipelines to improve ux when loading files (complex shader graphs), small shaders shouldn't be a problem in my experience (though I have only ever loaded SPIR-V from disk so skipping shader compile by caching might be worth it). https:*www.khronos.org/registry/vulkan/specs/1.2/html/chap10.html#pipelines-cache Use pipeline derivatives to quickly create variations for state changes. https:*www.khronos.org/registry/vulkan/specs/1.2/html/chap10.html#pipelines-pipeline-derivatives you can also use various dynamic state extensions. GPU_texture: - desc: gpu raster containers - depends: N/A - vulkan requires: N/A - notes: The definition (restriction) of what a texture is in Vulkan is very loose, especially with the ability to control, reuse, page and alias memory and types as you please. Most of them are exotic game optimizations that Blender probably doesn't need. But the one thing I would reccomend is setting aside a place and leave open the door for sparse memory (possibly for implementing well after GL is no-more). VMA already makes this easier. Blender is now responsible for rendering detailed volumetrics on the GPU, these 3D textures can take up a lot of memory fast. A future where eevee can render sparse voxels for detailed sims would be rather welcome. https://www.asawicki.info/news_1698_vulkan_sparse_binding_-_a_quick_overview This would be a long term goal... The initial implimentation should be just replicating GL/DX style textures by combining Images and Image Views. Should store bindless index as applicable (if that approach is taken) GPU_uniformbuffer: - desc: Pretty straight-forward implimentation of a UBO - depends: N/A - vulkan requires: N/A - notes: **PERMUTATION ISSUE!** Vulkan groups shader inputs into descriptor sets so: GPU_uniformbuffer_bind() would need an aux JIT descriptor set, you could also impliment dynamic uniform buffer capabilities here if you wanted to avoid issues with immediate mode uniform variables. Other than that just refactors for persistent mapping. GPU_vertex_buffer: - desc: Pretty straight-forward implimentation of a VBO - depends: N/A - vulkan requires: N/A - notes: Persistent mapping, (possibly in the future investigate sparse memory binding for improved edit performance for vertex/element resizing?) GPU_vertex_format: - desc: Handles CPU side vertex attribute packing, encoding and swizzling - depends: N/A - vulkan requires: N/A - notes: Enumerator refactor These are my own observations based on a pretty limited interaction with blender's GPU code. I am sure there is a lot I am not aware of that might be an issue. A lot of it is probably stuff to tackle later down the line, I just threw some of it in there because certain possibilities opened up with Vulkan are exciting. Also it deviates under the hood a bit from the GL implementation. In my opinion the GL/VK backends should not be treated like a 1-1 thing technique wise, especially since it is a new API with a very different way of doing things. While understanding the legacy and design of GL rendering in Blender, Modernizing how it uses the graphics API where possible or things like introducing the concept of bindless textures seems like a necessary step to reducing complexity of the VK backend. Thank you!

Added subscriber: @JacobMerrill-1

Big thanks to @astrand130 for providing P1590.

Big thanks to @astrand130 for providing [P1590](https://archive.blender.org/developer/P1590.txt).

Added subscriber: @slumber

Added subscriber: @Beryesa

Added subscriber: @Eary

Added subscriber: @hadesx01

Added subscriber: @higgsas

Added subscriber: @piiichan

Added subscriber: @ucupumar

Added subscriber: @M_Rodionov

Added subscriber: @MikhailShablin

Added subscriber: @DirSurya

any updates?

Added subscriber: @damd

Added subscriber: @esciron

Added subscriber: @Jous

Added subscriber: @Sigra

Added subscriber: @garwell

Added subscriber: @Noto

Hey is there any estimate how much developer time or how much $ have to be spend to finish this whole thing so Blender can run. MacOS with MoltenVk? or ARM_M1 ? I might have company that could sponsor that.

Hi @MaciejJutrzenka, the project is a low priority for the current team, and it is part of more a long term target. The best way to accelerate it it is for interested parties to contribute with development time. Any developer can take the lead on finishing this initiative. For anything related to donations you better reach out to foundation@blender.org.

Hi @MaciejJutrzenka, the project is a low priority for the current team, and it is part of more a long term target. The best way to accelerate it it is for interested parties to contribute with development time. Any developer can take the lead on finishing this initiative. For anything related to donations you better reach out to `foundation@blender.org`.

Added subscriber: @HammadAsif

Added subscriber: @Harvester

Good day. Do you plan to use the following technologies in a wider perspective to speed up the rendering of multi-polygonal meshes?
https://developer.nvidia.com/blog/introduction-turing-mesh-shaders/

Good day. Do you plan to use the following technologies in a wider perspective to speed up the rendering of multi-polygonal meshes? https://developer.nvidia.com/blog/introduction-turing-mesh-shaders/

Added subscriber: @Voldie

Added subscriber: @Two-Tone

Added subscriber: @Maged_Afra

any forward movement on this?

Added subscriber: @LazyDodo

@JacobMerrill-1 If there was any movement it would have been reflected in this ticket, please do not use the bug tracker for these kinds of questions

Added subscriber: @aBSy

@Clément Foucault please man,, make it fast, we cant wait for that.

Added subscriber: @MysticalUnicat

Added subscriber: @kevinzhow

Added subscriber: @AntonioJavierTorralbaMoreno

Added subscriber: @(Deleted)

Added subscriber: @AditiaA.Pratama

Added subscriber: @Emi_Martinez

Added subscriber: @ysano

Added subscriber: @tsvi

Added subscriber: @PhlixFer

Added subscriber: @ww123td

Added subscriber: @piledog

Added subscriber: @m-kim

Added subscriber: @sadern

Added subscriber: @kadam

Added subscriber: @Vyach

Added subscriber: @cagram

Added subscriber: @VDC

Added subscriber: @CreatorSiSo

Added subscriber: @marci

Added subscriber: @fanny

Added subscriber: @Defka

Added subscriber: @jta

Added subscriber: @Kazvko

Added subscriber: @Raimund58

Added subscriber: @markhaxx

Added subscriber: @thanhph111

Added subscriber: @AndyCuccaro

Added subscriber: @Jarrett-Johnson

Added subscriber: @dodo-2

Added subscriber: @imustblend

Added subscriber: @Zelig

Added subscriber: @Sait-Kiat

Added subscriber: @Will-7

Added subscriber: @hatchli

Added subscriber: @lucacustom

Any news about this, he should be release for 3.1 ?? or later ?

(i seen in github he is updated here : https://github.com/blender/blender/tree/tmp-vulkan)

i suppose the team work now on vulkan :) this is a great news for all next features of this project !

Any news about this, he should be release for 3.1 ?? or later ? (i seen in github he is updated here : https://github.com/blender/blender/tree/tmp-vulkan) i suppose the team work now on vulkan :) this is a great news for all next features of this project !

Added subscriber: @Jeroen-Bakker

@dodo-2 it will not be 3.1 there are still design issues that need to be answered, before we can start development.

Added subscriber: @Gabi_love

In #68990#1251702, @Jeroen-Bakker wrote:
@dodo-2 it will not be 3.1 there are still design issues that need to be answered, before we can start development.

Can you elaborate, or at least refer us to a blog post so we can read more about the design problems?

> In #68990#1251702, @Jeroen-Bakker wrote: > @dodo-2 it will not be 3.1 there are still design issues that need to be answered, before we can start development. Can you elaborate, or at least refer us to a blog post so we can read more about the design problems?

@Gabi_love We don't have a post out on it. The design issue is that we want to support OpenGL, Vulkan and other GLs next to each other. We currently have a rough idea how to do it, but still need to prototype if it is feasible and what limitations there are. What holds us back is time.

Current approach that is being researched is that shaders will have meta data to abstract away how uniforms/buffers etc are handled by the different GPU backend.

@Gabi_love We don't have a post out on it. The design issue is that we want to support OpenGL, Vulkan and other GLs next to each other. We currently have a rough idea how to do it, but still need to prototype if it is feasible and what limitations there are. What holds us back is time. Current approach that is being researched is that shaders will have meta data to abstract away how uniforms/buffers etc are handled by the different GPU backend.

I don't understand why you continue use some features of OpenGL, Vulkan can't only run all with this own libraries like OpenGL/SL ??

Because at the start OpenGL is lefting for Vulkan ? No ?

The better solution is integrated only Vulkan full api in blender and to withdraw openGL cuz Vulkan is a real multi support on all devices with this modern LIBS... No ?

I don't understand why you continue use some features of OpenGL, Vulkan can't only run all with this own libraries like OpenGL/SL ?? Because at the start OpenGL is lefting for Vulkan ? No ? The better solution is integrated only Vulkan full api in blender and to withdraw openGL cuz Vulkan is a real multi support on all devices with this modern LIBS... No ?

Added subscriber: @geocentric_wage

Added subscriber: @GeorgiaPacific

Added subscriber: @Lain-Iwakura

Added subscriber: @fire

Added subscriber: @Dangry

Added subscriber: @Yuro

Added subscriber: @leomid

Added subscriber: @JD-Morani

Removed subscriber: @cagram

Added subscriber: @ShyDugong

Added subscriber: @Sj

Added subscriber: @nlate

Added subscriber: @Mounir

Added subscriber: @Diogo_Valadares

Added subscriber: @Supine

Added subscriber: @vr_sebas

Added subscriber: @Peter-Sampson

Added subscriber: @Michael-Parkin-White-Apple

Added subscriber: @RafaelRistovski

Added subscriber: @hzuika

Added subscriber: @osayami

Added subscriber: @Spundun-Bhatt

Removed subscriber: @thanhph111

Removed subscriber: @Gabi_love

Added subscriber: @Steve-Hanff

Added subscriber: @Stanimir-Azmanov

Added subscriber: @tiagoffcruz

Added subscriber: @jljusten

Added subscriber: @Cigitia

Added subscriber: @Jonathan-61

Added subscriber: @intrah

Added subscriber: @vnapdv

Changed status from 'Confirmed' to: 'Needs Developer To Reproduce'

Hi everyone.
I would like to proceed with the development of the cycles version of vulkan raytracing. .
Or maybe I can contribute something.
Data on the blender side is referenced from push constant using EXT_buffer_reference.
I wrote it with VK_NV_ray_tracing about 2 years ago, so it doesn't support KHR_ray_tracing.
https://github.com/AgAmemnno/VulkanRaytracingCycles/tree/develop/data/shaders/rt/bl3
Can it be developed into a prototype?

Hi everyone. I would like to proceed with the development of the cycles version of vulkan raytracing. . Or maybe I can contribute something. Data on the blender side is referenced from push constant using EXT_buffer_reference. I wrote it with VK_NV_ray_tracing about 2 years ago, so it doesn't support KHR_ray_tracing. https://github.com/AgAmemnno/VulkanRaytracingCycles/tree/develop/data/shaders/rt/bl3 Can it be developed into a prototype?

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Hi @vnapdv

Best to check this with the cycles module as it depends on many other factors as well. This task specific is to add support of vulkan to the viewport.

Hi @vnapdv Best to check this with the cycles module as it depends on many other factors as well. This task specific is to add support of vulkan to the viewport.

Absolutely.
The checks in the Cycles Module go all the way up to the principal shader. However, viewport requires a completely different rasterization pipeline. In order to proceed with work, which blender source should be used for building and testing?

Absolutely. The checks in the Cycles Module go all the way up to the principal shader. However, viewport requires a completely different rasterization pipeline. In order to proceed with work, which blender source should be used for building and testing?

Removed subscriber: @piiichan

Added subscriber: @AlfredENeuman

Removed subscriber: @esciron

Removed subscriber: @HammadAsif

Added subscriber: @Dogway

Added subscriber: @Nabarun

Added subscriber: @FynnGr

Added subscriber: @Taumich

Removed subscriber: @imustblend

Removed subscribers: @Taumich, @FynnGr, @Nabarun, @Dogway, @AlfredENeuman, @vnapdv, @intrah, @Jonathan-61, @Cigitia, @jljusten, @tiagoffcruz, @Stanimir-Azmanov, @Steve-Hanff, @Spundun-Bhatt, @osayami, @hzuika, @RafaelRistovski, @Michael-Parkin-White-Apple, @Peter-Sampson, @vr_sebas, @Supine, @Diogo_Valadares, @Mounir, @nlate, @Sj, @ShyDugong, @JD-Morani, @leomid, @Yuro, @Dangry, @fire, @Lain-Iwakura, @GeorgiaPacific, @geocentric_wage, @Jeroen-Bakker, @lucacustom, @hatchli, @Will-7, @Sait-Kiat, @Zelig, @dodo-2, @Jarrett-Johnson, @AndyCuccaro, @markhaxx, @Raimund58, @Kazvko, @jta, @Defka, @fanny, @marci, @CreatorSiSo, @VDC, @Vyach, @kadam, @sadern, @m-kim, @piledog, @ww123td, @PhlixFer, @tsvi, @ysano, @Emi_Martinez, @AditiaA.Pratama, @AntonioJavierTorralbaMoreno, @kevinzhow, @MysticalUnicat, @aBSy, @LazyDodo, @Maged_Afra, @Two-Tone, @Voldie, @Harvester, @Noto, @garwell, @Sigra, @Jous, @damd, @DirSurya, @MikhailShablin, @M_Rodionov, @ucupumar, @higgsas, @hadesx01, @Eary, @Beryesa, @slumber, @JacobMerrill-1, @marioamb, @AmpereNV, @Alaska, @Wesley-Rossi, @bblanimation, @chr.schmitz, @sharaths21312, @Fux, @TheRedWaxPolice, @ckohl_art, @Stat_Headcrabed, @MeshVoid, @filibis, @AlexeyPerminov, @Tommy_Newman, @girafic, @KuiyueRO, @KenzieMac130, @fclem, @BartekMoniewski, @2046411367, @dhruvin, @MaciejJutrzenka, @1ace, @lemenicier_julien, @blenderrocket, @newin, @dabuxian, @Blendork, @dfelinto

Added subscribers: @Taumich, @FynnGr, @Nabarun, @Dogway, @AlfredENeuman, @vnapdv, @intrah, @Jonathan-61, @Cigitia, @jljusten, @tiagoffcruz, @Stanimir-Azmanov, @Steve-Hanff, @Spundun-Bhatt, @osayami, @hzuika, @RafaelRistovski, @Michael-Parkin-White-Apple, @Peter-Sampson, @vr_sebas, @Supine, @Diogo_Valadares, @Mounir, @nlate, @Sj, @ShyDugong, @JD-Morani, @leomid, @Yuro, @Dangry, @fire, @Lain-Iwakura, @GeorgiaPacific, @geocentric_wage, @Jeroen-Bakker, @lu_zero, @hatchli, @Hsingai-Altaica, @Sait-Kiat, @Zelig, @dodo-2, @Jarrett-Johnson, @AndyCuccaro, @markhaxx, @diogo0880, @Kazvko, @jta

Added subscribers: @Defka, @fanny, @marci, @CreatorSiSo, @VDC, @Vyach, @kadam, @sadern, @m-kim, @piledog, @ww123td, @PhlixFer, @tsvi, @ysano, @Emi_Martinez, @AditiaA.Pratama, @AntonioJavierTorralbaMoreno, @kevinzhow, @MysticalUnicat, @aBSy, @LazyDodo, @Maged_Afra, @Two-Tone, @Voldie, @Harvester, @Noto, @garwell, @Sigra, @Jous, @damd, @DirSurya, @MikhailShablin, @M_Rodionov, @ucupumar, @higgsas, @hadesx01, @Eary, @Beryesa, @slumber, @JacobMerrill-1, @marioamb, @AmpereNV, @Alaska, @Wesley-Rossi, @bblanimation

Added subscribers: @chr.schmitz, @sharaths21312, @Fux, @TheRedWaxPolice, @ckohl_art, @Stat_Headcrabed, @MeshVoid, @filibis, @AlexeyPerminov, @Tommy_Newman, @girafic, @KuiyueRO, @KenzieMac130, @fclem, @BartekMoniewski, @2046411367, @dhruvin, @MaciejJutrzenka, @1ace, @lemenicier_julien, @blenderrocket, @newin, @dabuxian, @Blendork, @dfelinto

I am really sorry but it seemed that I pressed edit task, but expected that I was pressing Create sub task.
I don't see the option to rollback to the previous version and had to add you all back manually.

If I mistakenly forgot someone, please subscribe you to the task again.

I am really sorry but it seemed that I pressed edit task, but expected that I was pressing Create sub task. I don't see the option to rollback to the previous version and had to add you all back manually. If I mistakenly forgot someone, please subscribe you to the task again.

Removed subscriber: @kevinzhow

Added subscriber: @JanErik

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Vulkan support #68990

GHOST

Preliminary Work

GPU module OpenGL backend

GPU module Vulkan backend