Practical Info
This is a weekly video chat meeting for planning and discussion of Blender Viewport & EEVEE module development. Any contributor (developer, UI/UX designer, writer, …) working on Viewport & EEVEE in Blender is welcome to join.
For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.
- Google Meet
- Next Meeting: 26 May 2025, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2025-05-26T09:30:00Z → 2025-05-26T10:00:00Z)
Attendees
- Clement
- Christoph
- James
- Jeroen
- Miguel
Shader
[Shading Language - Blender Developer Documentation] Updated the GPU shader documentation.
Instance performance
Looking in improving the performance of instancing using blender::VectorList. This already improved the performance noticeable. It only places the locality where the data is kept when processing.
GPU
INT_FETCH_AS_FLOAT isn’t supported anymore due to recent changes. We took time to discuss the consequences. The feature isn’t used that much, but if it is used it will crash. We could still support it, have a deprecation warning and drawn incorrect when used. We will look into possibilities and try to find a balanced fix.
A new GPU context is added for icon rendering. This will solve specialization constant compiling hang.
EEVEE
[#138898 - WIP: EEVEE: Reverse-Z implementation - blender - Blender Projects] Reversed-Z improves Z-fighting. There is one regression but expect to land upcoming week. Overlays will be fine as EEVEE has a small offset to account for sample differences. Workbench and Overlays will not use Reverse-Z for now.
Metal backend
There was a memory leak found in the Metal backend. Might be related to an issue we had several weeks ago where upgrading the buildbot to a newer version didn’t test the texture atomics workaround. There a GPU_flush solved the issue back then. Further research will be done to find the root cause.
Vulkan backend
[Issues - blender - Blender Projects] Mainly fixing bugs. Please keep reporting. Currently looking in OpenXR performance regressions. When using Blender + OpenXR + Vulkan the current design can be slow. Performance can be improved but require a different internal API/Process with potential bugs. Decision should be made if we want to solve this for 4.5 ot 5.0.
Windows timing
[#138867 - WIP: WM: Use increased timer resolution on Windows - blender - Blender Projects] When there are no OS events to process, Blender will ask the OS to sleep for 5 ms. Windows internally will round it up to 15ms. Playback of animations can be improved by changing the sleep. to use a high precision timer or other solution. It is not clear what the real reasons are for Blender to sleep. It could be legacy as that was done many years ago. Some discussion will be held to find out what we expect from performance and power usage.