Vulkan support #68990
Open
opened 2019-08-21 16:11:49 +02:00 by Dalai Felinto
·
160 comments
No Branch/Tag Specified
main
blender-v4.0-release
temp-sculpt-brush-channel
temp-sculpt-dyntopo
blender-v3.6-release
universal-scene-description
blender-v3.3-release
asset-browser-frontend-split
brush-assets-project
asset-shelf
anim/armature-drawing-refactor-3
temp-sculpt-dyntopo-hive-alloc
tmp-usd-python-mtl
tmp-usd-3.6
blender-v3.5-release
blender-projects-basics
blender-v2.93-release
temp-sculpt-attr-api
realtime-clock
sculpt-dev
gpencil-next
bevelv2
microfacet_hair
xr-dev
principled-v2
v3.6.4
v3.6.3
v3.3.11
v3.6.2
v3.3.10
v3.6.1
v3.3.9
v3.6.0
v3.3.8
v3.3.7
v2.93.18
v3.5.1
v3.3.6
v2.93.17
v3.5.0
v2.93.16
v3.3.5
v3.3.4
v2.93.15
v2.93.14
v3.3.3
v2.93.13
v2.93.12
v3.4.1
v3.3.2
v3.4.0
v3.3.1
v2.93.11
v3.3.0
v3.2.2
v2.93.10
v3.2.1
v3.2.0
v2.83.20
v2.93.9
v3.1.2
v3.1.1
v3.1.0
v2.83.19
v2.93.8
v3.0.1
v2.93.7
v3.0.0
v2.93.6
v2.93.5
v2.83.18
v2.93.4
v2.93.3
v2.83.17
v2.93.2
v2.93.1
v2.83.16
v2.93.0
v2.83.15
v2.83.14
v2.83.13
v2.92.0
v2.83.12
v2.91.2
v2.83.10
v2.91.0
v2.83.9
v2.83.8
v2.83.7
v2.90.1
v2.83.6.1
v2.83.6
v2.90.0
v2.83.5
v2.83.4
v2.83.3
v2.83.2
v2.83.1
v2.83
v2.82a
v2.82
v2.81a
v2.81
v2.80
v2.80-rc3
v2.80-rc2
v2.80-rc1
v2.79b
v2.79a
v2.79
v2.79-rc2
v2.79-rc1
v2.78c
v2.78b
v2.78a
v2.78
v2.78-rc2
v2.78-rc1
v2.77a
v2.77
v2.77-rc2
v2.77-rc1
v2.76b
v2.76a
v2.76
v2.76-rc3
v2.76-rc2
v2.76-rc1
v2.75a
v2.75
v2.75-rc2
v2.75-rc1
v2.74
v2.74-rc4
v2.74-rc3
v2.74-rc2
v2.74-rc1
v2.73a
v2.73
v2.73-rc1
v2.72b
2.72b
v2.72a
v2.72
v2.72-rc1
v2.71
v2.71-rc2
v2.71-rc1
v2.70a
v2.70
v2.70-rc2
v2.70-rc
v2.69
v2.68a
v2.68
v2.67b
v2.67a
v2.67
v2.66a
v2.66
v2.65a
v2.65
v2.64a
v2.64
v2.63a
v2.63
v2.61
v2.60a
v2.60
v2.59
v2.58a
v2.58
v2.57b
v2.57a
v2.57
v2.56a
v2.56
v2.55
v2.54
v2.53
v2.52
v2.51
v2.50
v2.49b
v2.49a
v2.49
v2.48a
v2.48
v2.47
v2.46
v2.45
v2.44
v2.43
v2.42a
v2.42
v2.41
v2.40
v2.37a
v2.37
v2.36
v2.35a
v2.35
v2.34
v2.33a
v2.33
v2.32
v2.31a
v2.31
v2.30
v2.28c
v2.28a
v2.28
v2.27
v2.26
v2.25
Labels
Clear labels
This issue affects/is about backward or forward compatibility
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports
Apply labels
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
This issue affects/is about backward or forward compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
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
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
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
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports
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 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 & 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
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
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
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Set Project
Clear projects
No project
Assignees
Assign users
Clear assignees
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
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
GHOST
We should add support for vulkan for all windowing system.
Preliminary Work
Work to be done before starting to work on the vulkan implementation.
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.
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.
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.
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.
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.VK_EXT_depth_clip_control
and check availability.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.
Compatibility issues
AMD RX 480:
Note I have only detected this to fail on Mesa drivers.
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!
Added subscriber: @AmpereNV
Added subscriber: @marioamb
@astrand130
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.
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.
For the UI we could cache these permutations but I wouldn't do that for the materials (too many variations).
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.
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.
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.
This is something I'm still thinking about. I would like to
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!
Added subscriber: @JacobMerrill-1
Big thanks to @astrand130 for providing P1590.
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
.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/
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 !
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
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.
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?
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.
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
Vulkan supportto Vulkan: Report memory statistics using `vmaGetHeapBudgets`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
Vulkan: Report memory statistics using `vmaGetHeapBudgets`to Vulkan supportAdded 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.
Removed subscriber: @kevinzhow
Added subscriber: @JanErik