2021-07-20 Blender Rendering Meeting

Blender Development Meetings
#1

Attendees

  • Brecht Van Lommel (Blender)
  • Kévin Dietrich (Blender)
  • Patrick Mours (NVIDIA)
  • Brian Savery (AMD)
  • Juan Gea Rodriguez)

Notes

Schedule

  • The meeting agreed to move to a biweekly schedule, since there is not enough to discuss every week. Most communication happens on developer.blender.org and blender.chat in between meetings, this meeting is mainly for overall coordination and decision making. So, the next meeting will be in two weeks.

Cycles

  • Cycles X: we are getting closer to feature completeness, which is required for this to go into master. This includes recent improvements the shadow catcher, render passes and various smaller features. The main remaining work is in tiled rendering and volume sampling. Of course we’ll also need some time to stabilize the implementation.
  • AMD is making good progress on their HIP implementation of Cycles-X for Windows and Linux, and they have images rendering. Cycles developers are expected to have access to drivers and a patch for testing in mid to late August. It’s unclear if this can make it into Blender 3.0, if not we aim to have experimental builds available around the time of the 3.0 release.
  • Christophe Hery from Facebook contributed a patch for anisotropy in subsurface scattering. Skin is quite anisotropic and so this can improve the realism there.
  • There is a new performance testing framework in Blender. Currently it’s used for Cycles and can produce the same kinds of graphs as found in the Cycles X announcement blog post. So other developers should now be able to reproduce these. The next step will be to run these on the buildbot.

Eevee & Viewport

  • Kévin worked on improving OpenSubdiv performance, and it’s now in a good place with multiple test files from users showing performance improvements (benchmarks). There is still work to get this feature complete.
  • Jeroen continues working on Vulkan support.

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.

  • Agenda
  • Google Meet
  • Time: Tuesday 5 to 6 PM Amsterdam Time
  • Next Meeting: August 3, 2021
20 Likes
26 July 2021
#2

OpenSubdiv benchmarks look game-changing!
Otherwise skin anisotropy also sounds very useful, great work guys

2 Likes
#3

Was openSubDiv not using GPU before and now it is?

#4

It will use the gpu when open subdivision is the last modifier in the stack.

2 Likes
#5

Sorry for the question, but does “HIP” stand for something? If so, what does it stand for?

#6

Probably the following: HIP — ROCm Documentation 1.0.0 documentation

1 Like
#7

So the requirement for it to go into the master only include restoring features, make sense. But I still want to ask, will Path Guiding be worked on after restoring all features to Cycles X? And does Path Guiding has hope to be in the 3.0 release?

1 Like
#8

It’s so you can fire a Cycles render from the hip, like Bob Munden.

Awesome news on Cycles.

#9

hmmm, interesting. I often put a Weighted Normals Modifier after the subsurf, in my stack, to cleanup some little artifacts in some cases, so then that will cause it to go back to CPU I guess…? :frowning:

I would have to test how much faster it is then, if that’s the case, and add an operator to my custom scripts, to maybe toggle that weighted mod(s) off/on as I work, to keep perf up then…

#10

It would go back to the cpu, but @KevinDietrich would know more.

#11

Indeed, it is only executed on the GPU if the modifier is the last in the stack. Although, we could in the future port a few more modifiers to the GPU. I guess weighted normals could be ported, but if the data is supposed to be made available to other render engines, or export operators (e.g. Alembic), it will have to be executed on the CPU side.

2 Likes
#12

Would it still revert to CPU if I had the Weighted Normals Mod after the subSurf but Disabled in viewport?
Or maybe that falls into that bug/design request to take into account disabled mods…

image

https://developer.blender.org/D11000

#13

AMD is making good progress on their HIP implementation of Cycles-X for Windows and Linux, and they have images rendering. Cycles developers are expected to have access to drivers and a patch for testing in mid to late August. It’s unclear if this can make it into Blender 3.0, if not we aim to have experimental builds available around the time of the 3.0 release.

Oh that makes my day.

I hope this makes it in before 3.0 is released.

Any word on what the performance is like so far? One would hope that it is at the very least equal to Blender 2.93.

1 Like
#14

Presumably the HIP implementation of Cycles-X will have hardware accelerated ray tracing. As such it should be faster than the current implementation of Cycles on hardware that has ray tracing hardware (currently RX 6000 (RDNA2 based) series or higher). But this is all just speculation. If the initial HIP implementation of Cycles-X doesn’t have hardware accelerated ray tracing support, then it’s very likely to get it sooner rather than later.

#15

I am not sure. Maybe we could check if the subdivision modifier is the last enabled, but I don’t know if there are side effects relating to the issue/task you linked. I can look into it though.

1 Like
#16

hip is to convert the cuda code to amd graphics card internal code, efficiency will theoretically dump opencl, and will dump the poorly optimized opencl a lot

#17

Is hip based on rays4.1?

#18

To anyone interested in HIP, its mentioned in AMD’s tutorial material in context of ROCm, which is AMD’s open software platform for GPU accelerated computing.

In the above link, its referred to under “Programming Frameworks”

In this link

AMD says the following about HIP:-

  • The Heterogeneous Interface for Portability (HIP) is AMD’s dedicated GPU programming environment for designing high performance kernels on GPU hardware

  • HIP is a C++ runtime API and programming language that allows developers to create portable applications on AMD and NVIDIA platforms

  • This means developers can write their GPU applications and with very minimal changes be able to run their code in either environment

  • Syntax wise, HIP is similar to CUDA and has virtually no performance overhead on NVIDIA systems

  • HIP includes a rich set of libraries and tools support

3 Likes
#19

According to my understanding rocm currently does not support windows, the above article mentions windows and linux so large it is possible to use the rays4.1 library

#20

Hi all.
I just want to say we appreciate the enthusiasm on AMD support for Cycles-X! We can’t say anything more about timelines other than what’s in the notes above other that “stay tuned”. @JamesCrowther gave a good overview of what HIP is above. HIP will basically allow the C++ kernel code to be executed similarly to CUDA in Cycles-X.

There was a question about the Radeon Rays library, keep in mind the ray tracing intersection side of things is a bit orthogonal to moving to HIP. Radeon Rays currently does not work on HIP.

Anyway like I said, interest is great and stay tuned but that’s about all we can say right now.
Brian

4 Likes