2023-02-27 Eevee/Viewport Module Meeting

Meetings
,
1

Practical Info

This is a weekly video chat meeting for planning and discussion of Blender Eevee/viewport module development. Any contributor (developer, UI/UX designer, writer, …) working on Eevee/viewport 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: March 6, 2023, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2023-03-06T10:30:00Z → 2023-03-06T11:00:00Z)

Attendees:

  • Clement
  • Jeroen
  • Thomas
  • Michael
  • Miguel

General improvements

  • CPP rotation API (https://projects.blender.org/blender/blender/pulls/104941)
  • Smaller refactorings to GPUTexture.
    • Add header documentation and reorganize sections.
    • Add texture usage flag to all texture creation.
    • Make sure all available texture format are supported.
    • Remove data_format from 3D texture creation function.
    • Remove obsolete GPU_texture_bind_ex argument set_number.

Metal

  • Resolving outstanding issues, PR review iterations
    • Barycentric data: Some tricky solution where global state is required. Metal emulates this using a struct.
    • Issue in memory manager where 1000s buffers where freed. Threading issue,
  • Indirect draw call support, one liner, but requires SSBO support.

Eevee-next

  • Transparent shadows. PR is available

Workbench-next

  • Draw manager handlers without having the overhead of bounding boxes and matrices to make the material slots less resource intensive.
    • Multiple implementations have been done, resulting to a design that we want to achieve.
  • Discussion with Jackque Lucke how to handle volume rendering in Workbench-next.

Vulkan

  • Added initial support for images. Found a challenge where NVIDIA drivers do not support 1D image types.
    • Idea is to have a work-around for 2D images as this can be done inside the Vulkan backend by generating different resource binding and some function overloading. Although this needs some testing. Other vulkan implementations that supports 1D textures can still use their potential optimized sillicon paths for 1D images.
  • Started design for push constants
    • When push constants don’t fit on the device a fallback will be created to use uniform buffer objects. In the case the fallback is needed, all push constants for that particular shader will be inside the uniform buffer objects. Shader developers are responsible to tweak the shaders to minimize the need for the fallback.
    • Minimum size for push constants are 128 bytes. Although modern drivers already support 256 bytes. See Vulkan push constants. - HackMD for an overview of static shaders with more than 128 bytes of push constants.
    • Initial idea is to have a sequential buffer that stores all push constants for a shader that hasn’t been executed yet. When execution has been detected (submit id) the sequential buffer can be reused. Push constants has an API that can benefit from sequential buffers.
  • Vulkan: Query limits of physical device. (#105125 - Vulkan: Get access to physical device limits. - blender - Blender Projects)
  • Vulkan: Add resolving of builtins to shader interface. (#105128 - Vulkan: Resolve Builtin Uniform(Block). - blender - Blender Projects)
  • Vulkan: Initial Uniform buffers support (#105129 - Vulkan: Initial VKUniformBuffer. - blender - Blender Projects)
  • Tracking resources when multiple commands are in flight (Still in developement)
12 Likes