2024-09-17 Render & Cycles Meeting

Attendees

  • Nikita Sirgienko (Intel)
  • Sergey Sharybin (Blender)
  • Sahar A. Kashi (AMD)
  • Thomas Dinges (Blender)
  • Lukas Stockner (Blender)
  • Patrick Mours (NVIDIA)

Notes

  • For 4.3
    • Reminder: beta is in 2 weeks
    • Add ability to control hardware raytacing #125082
      • Now to test HWRT CYCLES_TEST_DEVICES needs to be set to METAL-RT, ONEAPI-RT, HIP-RT.
      • The goal is to enable tests for both configurations on the buildbot
    • Performance regression #127464
      • Sahar will check on Windows, it could be related on the HIP version used
      • It should be safe to update to 6.1 now
    • Linux HIP-RT #121050
      • Build system is landed
      • Waiting for platform maintainers to commit libraries
      • After that the rest of the change will land
    • Lunar Lake GPUs will be enabled for 4.3
      • There might be a value of adding it to 4.2 as well. Depends on the scope of the change
    • Weizhen and Lukas are looking into phase functions patch
      • Seems safe for 4.3
      • We’ll run benchmarks closer to the merge
    • OptiX 7.4 (still) needs deployment to the builder machines
      • Some other way got in a way. Hopefully can happen this week.
  • Other
    • Cycles: various curve rendering issues #124295
      • Previous meeting discussed alignment to GPU
      • Will check with the studio artists to confirm its fine
    • Cycles render test: Failing oneAPI tests 125088
      • Nikita will check if increasing samples properly converges
    • Lukas is working on temporal denoiser
      • he reached out Attila, to align the work
      • Will continue research from our side, and share the current data-set used for training
    • Lukas is looking into OIIO for all formats
      • Added full JPEG netadata support in OIIO (it only supported a single comment block)
      • Looking into implementing OpenEXR multipart file support
      • In the future we might need to use “blender:” prefix for EXR metadata to avoid conflicts
      • Once the OIIO is updated on our side it will bring Jpeg XL support
    • Lukas did preliminary tests with AVX-512 on Xeon 8480 56 cores dual-socket
      • On Blender side there is no benefit (with the corresponding compiler flags, surely)
      • With Embree there is few percent speedup. Could be better with ray streaming, but it needs to be implemented in Cycles.
      • Need to check with CPUs from AMD, which now also come with AVX-512
    • Sahar points out that wmic (used in OpenData) is deprecated
      • Xavier run into similar issue
      • Maybe the solution is to use something completely different, as long-term it doesn’t seem we can rely on this utility

Practical Info

This is a weekly video chat meeting for planning and discussion of Blender rendering development. Any contributor (developer, UI/UX designer, writer, …) working on rendering in Blender is welcome to join and add proposed items to the agenda.

For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.

13 Likes

Minor correction, it’s -RT not _RT

This has been corrected.

At the moment I believe AMD has two different implementations of AVX-512 (one for Zen 4 (Ryzen 7000), and one for Zen 5 (Ryzen 9000)) with different performance characteristics.

I believe AVX-512 is slower on Zen 4, so it will be important testing that generation.

Indeed, thanks. I’ve corrected the post, so people who might not follow all the comment are not getting confused.

1 Like

Oh that is potentially interesting for VSE! For image proxies, today VSE uses JPG format. That lacks alpha channel support, and it lacks HDR support. While doing proxies as EXR files for HDR images is one possible approach, JpegXL, if it was there, is another alternative. Looking forward to when it lands!

3 Likes

The libjxl dependency is kind of a real mess it looks like. Which for a project created in the last 5 years is a real shame. It lacks proper Windows build support and might not support Windows arm64 at all, it’s hard to tell. It will probably take a decent amount of effort to work through even once OIIO 3.x lands (most likely for the library refresh for 4.4 early next year).

Any feedback on the bump modification ?

No currently. When there are updates they are communicated in the corresponding task.

1 Like

There is no problem to build libjxl for Windows.

My build script:

MSYS2 script (often used by Windows’s version of GIMP):

Good to know. One of their build pages for windows still says that “the MSVC compiler is currently not supported” [1] and you’d have to use clang tooling, which is fine, just raises some eyebrows on why that would even be the case nowadays.

[1] libjxl/doc/developing_in_windows_vcpkg.md at main · libjxl/libjxl · GitHub

I did a test build when you mentioned building for MSVC was messy, while perhaps not straight forward (it has quite a few more deps than one would expect from a run of the mill image lib), but saw no red flags and was able to get a workable build with a pure msvc 2022 environment, (2019 may throw a wrench in there)

if we are certain this a direction we want to go in i’ll pick this up after the 4.3 lib update is out the door.

AVIF(AV1 Image File Format) is generally considered to be better than JPEG XL for a number of reasons. lossless compression, High quality, transparency, HDR, wide color gamut, Metadata support

1 Like

Different people have different opinions about which is better, and these opinions can change based on the use case.

Is there a specific reason you think AVIF is a better for image proxies than JPEG XL for the VSE in Blender?

As far as I can tell, JPEG XL supports all of these features.

2 Likes

Both AVIF and JPEG XL (JXL) are excellent formats.
There is no absolute winner.

JXL is very efficient in lossless and near lossless.
AVIF is able to reach very small file sizes and images are still looking acceptable.
There is quality range where JXL and AVIF reach subjectively similar efficiency (it depends on personal opinion)
Some people say that AVIF compress artificial images better than JXL, other say that photos are more efficiently compressed in JXL than in AVIF.

AVIF uses integer precision: 8, 10 or 12 bits/channel.
JXL can go up to 32 bits (floats) per channel.

JXL can do CMYK, AVIF can’t.

Animated AVIF benefits from efficient AV1 video compression.
JXL can be animated too, but it is not as efficient in animations like AVIF.

AVIF is supported almost by all browsers today, JXL works on Apple devices and few minor browsers so far.

I’d like that both JXL and AVIF are supported so that users have freedom to choose which one they prefer.

2 Likes

Thanks for detailing some of the differences between the two formats.

Support in other applications shouldn’t be of much consideration for this use case (Generating lower quality proxies for the video editor) as it’s not intended for the user to look at them outside of Blender.