2023-01-23 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: January 30, 2023, 11:30 AM to 12:00 PM Amsterdam Time (Your local time: 2023-01-30T10:30:00Z → 2023-01-30T11:00:00Z)

Attendees:

  • Clement
  • Jeroen
  • Michael
  • Miguel
  • Thomas

Metal backend

  • Stabilizing the metal backend when using Python add-ons and scripts. BGL directly wraps OpenGL API what will not work when Metal backend is active. As OpenGL library isn’t loaded it would crash blender. There were some ideas how to solve this. One was to activate both the OpenGL backend and the Metal backend, so the crashes didn’t occur, but users won’t see the effect. Other option was to block any calls to the OpenGL API when no OpenGL backend is active. We decided to go for the last option. We also made sure that the template scripts and scripts in the manual work when using the Metal backend. Those scripts use the gpu module in stead of the bgl module.
    • Block bgl calls when when metal backend is active. (Blender Archive - developer.blender.org) The user is presented with a pop-up telling that one of the Python scripts/add-ons is using OpenGL and should be migrated to use the gpu module.
    • Read from unallocated memory msl_patch_default.
    • Attribute list in shader interface isn’t updated when using Metal D17042
  • Fix T103433: Ensure Metal memory allocator is safe for multi-threaded allocation. Resolves crash when baking indirect lighting. D17018
  • During review, many patches are dependent, but sometimes not obvious what the order are.
    • Compositor patch first, before the other patches.
    • Michael will describe the dependency-chain of the patches.
  • More focus to AMD issues will also commence.
  • A patch is in the making that improves the startup times. The patch makes changes to CMake configuration that requires more people to look at about what is wise to do. The patch will be uploaded as draft that can be discussed with people taht have more experience with CMake. Note that Blender does deviate from CMake standard by having many wrappers, and there is no documentation how to structure CMake files. Mostly is just being done by looking at other files.

Workbench-next

Eevee-next

  • Backporting changes to master that were local to the eevee-shadow branch.
  • Fixing remaining issues on shadows, most of them are now fixed. Transparent objects is costly as it requires a second pass, other option was bounding boxes, but wasn’t robust enough especially near the near-clip plain. Currently a limitation, and we need to find a solution for it down the road.
    • Other limitation: Shadows are on par with old implementation, but some are lacking due to missing contact shadows and soft shadows. Might give the impression that new are worse than the old one.
    • Bug on AMD pro driver on linux (at least), that prevents OpenGL error when binding multiple texture views of the same texture where each texture view covers one layer of the texture. In this case the driver doesn’t want to bind the texture.
      • Depth of field
      • Shadow of field (might can get a work-a-round)
      • Need to check if this is supported by Metal
16 Likes
2

Would it be helpful if I took a look? I could check out a branch and do the same porting work I have done for the last half year while updating the branch?

Anyway, if there are specific problems/questions let me know…

3

Hi @Baardaap!
The links got swapped (I’ve updated them in the original post), the actual fix is this one:
https://developer.blender.org/rB1b5a594a0529bf696caa419f26ac34712b5caeb0

The fix is quite straightforward and it’s just a copy of the change done in the current Workbench engine, so I think everything should be fine already?

1 Like
4

looks fine, yes.

Glad it wasn’t too much hassle.

2 Likes
5

I played around with the experimental version of Workbench Next a bit. Is rendering of points/pointcloud supposed not working at the moment? I see neither the task nor the commit message mentions it.

6

Point Clouds, Hair, and Volumes are not implemented yet.
I forgot to include Point Clouds in the maniphest task, I just added them:
https://developer.blender.org/T101619

1 Like
7

It seems that with each update to Eevee, it becomes slower and/or in multiple instances, worse. Are devs planning to address that?

8

@Nick_Vincent Have you reported it? Performance is important to us, many changes that we have done for Eevee-next/Workbench-next/Metal backend are improving performance. Sometimes this might not be clear to end-users as some of those projects are still experimental.

There are some known regressions in Blender 3.2 concerning bump nodes. Those regressions were needed in order to develop Eevee-next next to Eevee. Other regressions we want to know about as this might be a specific setup you’re using or might be related to other changes inside or outside Blender. We want to know so we can pin-point to the root cause.

Would love to see some artists to step forward and get involved in the module to test and give feedback on topics like this. Sometimes regressions get to our knowledge when the next version of Blender is released. They could also deliver some scenes with performance regressions, so we can add it to our benchmark so we can see those regressions during development.

7 Likes
9

Ever since rB80859a6cb272: GPU: Make nodetree GLSL Codegen render engine agnostic
Eevee performance has dropped significantly, in some instances, while rendering scenes it can take up to 2x to 3x longer. There hasn’t been an instance where (since 3.0) eevee has gotten faster.

Also, that change introduced regression “ShaderToRGB node will remove any SSR and SSS form a shader” which changes final look for some of my scenes scenes specifically using that node in combination, NPR rendering.

But that’s an issue that only a very few people experience.

All in all, it makes no sense to use Eevee for rendering in any versions of blender after 3.0. If I require shorter rendertimes, I will be required to downgrade. Makes no sense for an end-user.

10

Create a proper bug report please, this will make it easier to track the issue.

3 Likes
11

I’ve been experiencing slower render times in recent versions as well, just noticed it over the past two weeks because I’ve been working on a project that needs Eevee exclusively and I was updating files from 3.1 to 3.4, but I don’t know how to report it, because is not exactly a bug…? Is just slower overall, how can we report it?

Also, in my case (don’t know about other users), it’s not something replicable 100% of the times, sometimes a small change on a shader or a light will make it MUCH slower, and other times the same scene will render faster without changing anything, just re-loading Blender; so is hard to find what it is that needs to be reported.

2 Likes
12

@Nick_Vincent @JulianPerez

The best way to report performance regressions is to isolate the issue and open a bug report.

For example, if it’s related to a specific material create a scene with just a plane covering the whole viewport and that material applied.
Then, if possible, try to simplify that material by removing nodes that don’t affect performance so only the problematic ones remain.

That way we have something specific to test against.

There have been some performance regressions related to bump nodes.
One was already fixed in 3.4 and backported to 3.3:
https://developer.blender.org/T98989
We have another high-priority report open right now that hopefully should be fixed on master soon.
https://developer.blender.org/T103903

5 Likes
13

Yes, I understand that, but again my question remains, if the issue is not easy to reproduce constantly and/or doesn’t happen all the time, then how to report it?

1 Like
14

Well best to start in steps, make the first bug report, explain everything including that its not always reproduceable, try to render said scene on a different PC if possible or ask someone from this forum to help you with rechecking your findings ie. also render the same scene as you, as there could be something wrong with hardware as well, try to isolate objects/shaders as much as possible.

I know that reporting can get quite tedious, but the more information you collect the easier it is to pinpoint the issue.

2 Likes