Vulkan backend #68990

Open
opened 2019-08-21 16:11:49 +02:00 by Dalai Felinto · 160 comments

Currently this project is on hold due to resource issues. After the EEVEE-Next project has landed this project will continue.

TODO:

  • Vulkan Render Graph: Allows multi treaded command recording, command reordering.
  • Vulkan Clear on framebuffer bind. Required for EEVEE
  • Vulkan Specialization Constants
  • Vulkan Subpasses: WIll be a work around. Subpasses are only useful on Tiled based GPUs which are used in low powered devices like phones/tablets.
  • Editors: Replace vertex buffer attributes that are not compatible with Metal/Vulkan so slow paths are not used.
  • Platform Support
    • NVIDIA GTX 760 currently fails to start
  • 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 HDPI monitors. Currently WM, GHOST are not aligned and the GPU API expects this alignment to be fixed.

Future Tasks

  • OpenXR support
  • Use vulkan in cycles viewport.
  • #117992 check should be enabled again when eevee-next replaced eevee

GHOST

  • Linux X11
  • Linux Wayland
  • Windows
  • MacOS with MoltenVk
  • SDL

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 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.

Currently this project is on hold due to resource issues. After the EEVEE-Next project has landed this project will continue. **TODO**: - [ ] Vulkan Render Graph: Allows multi treaded command recording, command reordering. - [ ] Vulkan Clear on framebuffer bind. Required for EEVEE - [ ] Vulkan Specialization Constants - [ ] Vulkan Subpasses: WIll be a work around. Subpasses are only useful on Tiled based GPUs which are used in low powered devices like phones/tablets. - [ ] Editors: Replace vertex buffer attributes that are not compatible with Metal/Vulkan so slow paths are not used. - [ ] Platform Support - NVIDIA GTX 760 currently fails to start - [ ] 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 HDPI monitors. Currently WM, GHOST are not aligned and the GPU API expects this alignment to be fixed. **Future Tasks** - OpenXR support - Use vulkan in cycles viewport. - [ ] #117992 check should be enabled again when eevee-next replaced eevee ## GHOST - [x] Linux X11 - [x] Linux Wayland - [x] Windows - [ ] MacOS with MoltenVk - [ ] SDL 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 - [x] Fallback for SRGB encoded textures. - [x] Fallback for platforms not supporting 1D textures. #104812 - [x] 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 - [x] 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 - [x] Texture filtering: Current implementation uses a single sampler for all textures. - [x] 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. - [x] 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 - [x] Add support for pixel buffers - [x] Add wayland support. Currently when building with wayland you cannot start blender with vulkan. - [x] VKFramebuffer::blit_to should also support stencil and depth aspects.
Clément Foucault was assigned by Dalai Felinto 2019-08-21 16:11:49 +02:00
Author
Owner

Added subscriber: @dfelinto

Added subscriber: @dfelinto

Added subscriber: @Blendork

Added subscriber: @Blendork

Added subscriber: @dabuxian

Added subscriber: @dabuxian

Added subscriber: @newin

Added subscriber: @newin

Added subscriber: @blenderrocket

Added subscriber: @blenderrocket

Added subscriber: @lemenicier_julien

Added subscriber: @lemenicier_julien

Added subscriber: @1ace

Added subscriber: @1ace

Added subscriber: @MaciejJutrzenka

Added subscriber: @MaciejJutrzenka

Added subscriber: @dhruvin

Added subscriber: @dhruvin

Added subscriber: @2046411367

Added subscriber: @2046411367

Added subscriber: @BartekMoniewski

Added subscriber: @BartekMoniewski
Clément Foucault removed their assignment 2020-02-05 15:01:44 +01:00

Added subscriber: @fclem

Added subscriber: @fclem
Contributor

Added subscriber: @KenzieMac130

Added subscriber: @KenzieMac130

Added subscriber: @KuiyueRO

Added subscriber: @KuiyueRO

Added subscriber: @girafic

Added subscriber: @girafic

Added subscriber: @Tommy_Newman

Added subscriber: @Tommy_Newman

Added subscriber: @AlexeyPerminov

Added subscriber: @AlexeyPerminov

Added subscriber: @filibis

Added subscriber: @filibis

Added subscriber: @MeshVoid

Added subscriber: @MeshVoid

Added subscriber: @Stat_Headcrabed

Added subscriber: @Stat_Headcrabed

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art

Added subscriber: @TheRedWaxPolice

Added subscriber: @TheRedWaxPolice

Added subscriber: @Fux

Added subscriber: @Fux

Added subscriber: @sharaths21312

Added subscriber: @sharaths21312

Added subscriber: @chr.schmitz

Added subscriber: @chr.schmitz

Added subscriber: @bblanimation

Added subscriber: @bblanimation

Added subscriber: @Wesley-Rossi

Added subscriber: @Wesley-Rossi
Member

Added subscriber: @Alaska

Added subscriber: @Alaska
Contributor

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!

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: @AmpereNV

Added subscriber: @marioamb

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!
Contributor

@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

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: @slumber

Added subscriber: @Beryesa

Added subscriber: @Beryesa
Clément Foucault self-assigned this 2020-08-31 15:43:58 +02:00
Contributor

Added subscriber: @Eary

Added subscriber: @Eary

Added subscriber: @hadesx01

Added subscriber: @hadesx01

Added subscriber: @higgsas

Added subscriber: @higgsas

Added subscriber: @piiichan

Added subscriber: @piiichan

Added subscriber: @ucupumar

Added subscriber: @ucupumar

Added subscriber: @M_Rodionov

Added subscriber: @M_Rodionov

Added subscriber: @MikhailShablin

Added subscriber: @MikhailShablin

Added subscriber: @DirSurya

Added subscriber: @DirSurya

any updates?

any updates?

Added subscriber: @damd

Added subscriber: @damd

Added subscriber: @esciron

Added subscriber: @esciron

Added subscriber: @Jous

Added subscriber: @Jous

Added subscriber: @Sigra

Added subscriber: @Sigra

Added subscriber: @garwell

Added subscriber: @garwell

Added subscriber: @Noto

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.

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.
Author
Owner

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: @HammadAsif

Added subscriber: @Harvester

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: @Voldie

Added subscriber: @Two-Tone

Added subscriber: @Two-Tone

Added subscriber: @Maged_Afra

Added subscriber: @Maged_Afra

any forward movement on this?

any forward movement on this?
Member

Added subscriber: @LazyDodo

Added subscriber: @LazyDodo
Member

@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

@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

Added subscriber: @aBSy

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

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

Added subscriber: @MysticalUnicat

Added subscriber: @MysticalUnicat

Added subscriber: @kevinzhow

Added subscriber: @kevinzhow

Added subscriber: @AntonioJavierTorralbaMoreno

Added subscriber: @AntonioJavierTorralbaMoreno
(Deleted) commented 2021-02-06 21:25:28 +01:00 (Migrated from localhost:3001)

Added subscriber: @(Deleted)

Added subscriber: @(Deleted)

Added subscriber: @AditiaA.Pratama

Added subscriber: @AditiaA.Pratama

Added subscriber: @Emi_Martinez

Added subscriber: @Emi_Martinez

Added subscriber: @ysano

Added subscriber: @ysano

Added subscriber: @tsvi

Added subscriber: @tsvi

Added subscriber: @PhlixFer

Added subscriber: @PhlixFer

Added subscriber: @ww123td

Added subscriber: @ww123td

Added subscriber: @piledog

Added subscriber: @piledog

Added subscriber: @m-kim

Added subscriber: @m-kim

Added subscriber: @sadern

Added subscriber: @sadern

Added subscriber: @kadam

Added subscriber: @kadam

Added subscriber: @Vyach

Added subscriber: @Vyach

Added subscriber: @cagram

Added subscriber: @cagram

Added subscriber: @VDC

Added subscriber: @VDC

Added subscriber: @CreatorSiSo

Added subscriber: @CreatorSiSo

Added subscriber: @marci

Added subscriber: @marci

Added subscriber: @fanny

Added subscriber: @fanny

Added subscriber: @Defka

Added subscriber: @Defka
Member

Added subscriber: @jta

Added subscriber: @jta

Added subscriber: @Kazvko

Added subscriber: @Kazvko
Contributor

Added subscriber: @Raimund58

Added subscriber: @Raimund58

Added subscriber: @markhaxx

Added subscriber: @markhaxx

Added subscriber: @thanhph111

Added subscriber: @thanhph111

Added subscriber: @AndyCuccaro

Added subscriber: @AndyCuccaro

Added subscriber: @Jarrett-Johnson

Added subscriber: @Jarrett-Johnson

Added subscriber: @dodo-2

Added subscriber: @dodo-2

Added subscriber: @imustblend

Added subscriber: @imustblend

Added subscriber: @Zelig

Added subscriber: @Zelig

Added subscriber: @Sait-Kiat

Added subscriber: @Sait-Kiat

Added subscriber: @Will-7

Added subscriber: @Will-7

Added subscriber: @hatchli

Added subscriber: @hatchli

Added subscriber: @lucacustom

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 !
Member

Added subscriber: @Jeroen-Bakker

Added subscriber: @Jeroen-Bakker
Member

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

@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

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?
Member

@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: @geocentric_wage

Added subscriber: @GeorgiaPacific

Added subscriber: @GeorgiaPacific

Added subscriber: @Lain-Iwakura

Added subscriber: @Lain-Iwakura

Added subscriber: @fire

Added subscriber: @fire

Added subscriber: @Dangry

Added subscriber: @Dangry

Added subscriber: @Yuro

Added subscriber: @Yuro

Added subscriber: @leomid

Added subscriber: @leomid

Added subscriber: @JD-Morani

Added subscriber: @JD-Morani

Removed subscriber: @cagram

Removed subscriber: @cagram

Added subscriber: @ShyDugong

Added subscriber: @ShyDugong

Added subscriber: @Sj

Added subscriber: @Sj

Added subscriber: @nlate

Added subscriber: @nlate

Added subscriber: @Mounir

Added subscriber: @Mounir

Added subscriber: @Diogo_Valadares

Added subscriber: @Diogo_Valadares

Added subscriber: @Supine

Added subscriber: @Supine

Added subscriber: @vr_sebas

Added subscriber: @vr_sebas

Added subscriber: @Peter-Sampson

Added subscriber: @Peter-Sampson

Added subscriber: @Michael-Parkin-White-Apple

Added subscriber: @Michael-Parkin-White-Apple

Added subscriber: @RafaelRistovski

Added subscriber: @RafaelRistovski

Added subscriber: @hzuika

Added subscriber: @hzuika

Added subscriber: @osayami

Added subscriber: @osayami

Added subscriber: @Spundun-Bhatt

Added subscriber: @Spundun-Bhatt

Removed subscriber: @thanhph111

Removed subscriber: @thanhph111

Removed subscriber: @Gabi_love

Removed subscriber: @Gabi_love

Added subscriber: @Steve-Hanff

Added subscriber: @Steve-Hanff

Added subscriber: @Stanimir-Azmanov

Added subscriber: @Stanimir-Azmanov

Added subscriber: @tiagoffcruz

Added subscriber: @tiagoffcruz

Added subscriber: @jljusten

Added subscriber: @jljusten

Added subscriber: @Cigitia

Added subscriber: @Cigitia

Added subscriber: @Jonathan-61

Added subscriber: @Jonathan-61

Added subscriber: @intrah

Added subscriber: @intrah
Contributor

Added subscriber: @vnapdv

Added subscriber: @vnapdv
Clément Foucault was unassigned by Kazashi Yoshioka 2022-10-18 07:12:29 +02:00
Jeroen Bakker was assigned by Kazashi Yoshioka 2022-10-18 07:12:29 +02:00
Contributor

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

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

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?
Member

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

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

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.
Contributor

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

Removed subscriber: @piiichan

Added subscriber: @AlfredENeuman

Added subscriber: @AlfredENeuman

Removed subscriber: @esciron

Removed subscriber: @esciron

Removed subscriber: @HammadAsif

Removed subscriber: @HammadAsif

Added subscriber: @Dogway

Added subscriber: @Dogway

Added subscriber: @Nabarun

Added subscriber: @Nabarun
Contributor

Added subscriber: @FynnGr

Added subscriber: @FynnGr

Added subscriber: @Taumich

Added subscriber: @Taumich

Removed subscriber: @imustblend

Removed subscriber: @imustblend
Jeroen Bakker changed title from Vulkan support to Vulkan: Report memory statistics using `vmaGetHeapBudgets` 2023-01-31 11:32:33 +01:00
Member

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

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
Jeroen Bakker changed title from Vulkan: Report memory statistics using `vmaGetHeapBudgets` to Vulkan support 2023-01-31 11:34:42 +01:00
Member

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: @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
Member
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
Member
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
Member

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

Removed subscriber: @kevinzhow

Added subscriber: @JanErik

Added subscriber: @JanErik
Clément Foucault added this to the EEVEE & Viewport project 2023-02-09 01:05:52 +01:00
Clément Foucault removed the
Interest
EEVEE & Viewport
label 2023-02-09 01:06:22 +01:00
Jeroen Bakker added a new dependency 2023-02-18 17:51:43 +01:00
Jeroen Bakker removed a dependency 2023-02-18 17:51:56 +01:00
Jeroen Bakker changed title from Vulkan support to Vulkan backend 2024-02-22 08:51:12 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
127 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#68990
No description provided.