2022-10-10 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: October 17, 2022, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2022-10-17T09:30:00Z → 2022-10-17T10:00:00Z)

Attendees:

  • Miguel Pozo
  • Michael Parkin-White
  • Omar Emara
  • Clément Foucault
  • Jeroen Bakker

Workbench

  • Development of migration to new draw manager follows a similar approach as Eevee-next.
    • Initial development will be done in a branch.
    • When in a usable state it will be committed to master for adding features.
  • This refactor would also rely on the Metal backend.
  • For the overlay a similar project should be done. Currently having two draw managers requires new features to be developed twice (fe. scene attributes)
  • Currently we measured a 2 times speedup when drawing heavy scenes with a lot of instancing.
  • Viewport matrix split has landed in master. [DRW: Split ViewProjectionMatrix in order to increase precision · 6306d747b7 - blender - Blender Projects]

Eevee-next

  • Shadow rendering development is still work in progress.
  • Current work is in supporting multi view rendering.
  • Issue is instance rendering. We currently use an uint32_t to index to the matrix of an instance. For shadow rendering we want to reserve several bits to select the multi view. This would reduce the number of ‘visible’ unique instances on screen. For mitigation we have two plans
    • A: Specify the number of views per shader. This won’t work for shadows shaders as they still require 64 views.
    • B: Introduce a second uint32_t. This impacts performance as it needs a double lookup and increases the memory footprint.

Viewport Compositor

  • Implemented parallel reductions.
  • Continued development of glare node. See [Real-time Compositor: Feedback and discussion - #183 by OmarEmaraDev] for more details on the topic.
    • Simple star/Glow mode are implemented using sequential algorithms and are hard to implement in a more parallel way.
    • Ghost mode can use direct convolution, but might have different results than the current implementation.
    • Some changes would need approval of the VFX/Compositor module. Better to discuss these changes when it is clear what direction is expected to be taken.

Metal Viewport

  • Currently to enable the Metal viewport some changes needs to be done by the tester in the code. Eventually this should be done by a command line option / automatic detection.
    Ideally this would happen in one go based on some launch parameter or global setting. But for the time being, both GHOST and the GPU Backend need to be aware of the API.
    • in gpu_context.cc, change backend from static const eGPUBackendType g_backend_type = GPU_BACKEND_OPENGL; to GPU_BACKEND_METAL
    • in GHOST_ContextCGL.h change bool m_useMetalForRendering = false; to true
  • Development was primarily on porting the outstanding EEVEE shaders to use GPUShaderCreateInfo. Have ported most of them, including the generated material graphs, and have also applied a few fixes to the Metal backend to handle non-contiguous bind locations for other resource types (some previous assumptions were made in the past, and not all resource types supported explicit locations).
  • Patch for the CreateInfo changes will be send for review this week. Still have around 7 shaders left to port, and then some testing to do for point cloud material types, but these should be fairly quick. With this second patch in place, and a separate one for the Metal compatibility changes, rendering with the current EEVEE pipeline should work in Metal.
    • There are a few paths which may need some more rigorous testing, especially on drivers with shader workarounds. Such as the differing modes for passing in draw matrices, and drw_resourceID.
    • There was one performance consideration, regarding library includes. Given CreateInfos include each other recursively, some libraries have dependencies which would result in multiple includes. This was not an issue for the actual source injection, but for individual shader resources which were using append vs append_no_duplicates. For the time being, I’ve changed this to avoid including duplicates, but I think the additional_info include could perhaps be changed slightly to avoid inefficiencies here, though happy to see what the feedback on the DIFF is first.
21 Likes