Cycles Hydra Render Delegate #96731

New Issue

Brecht Van Lommel · 2022-03-23T14:57:24+01:00

Brecht Van Lommel commented

2022-03-23 14:57:24 +01:00

Status

There is experimental support for building Cycles as a Hydra render delegate. This enables Cycles to be used as a renderer in applications with Hydra support, for example Usdview, Omniverse and Houdini.

No official support is provided at this point due to the experimental state.

Features

CPU/CUDA/OptiX/HIP/Metal support
Camera Settings
Render Settings (automatically queried from Cycles via node type system)
AOVs
- Basic AOVs (color, depth, normal, primId, instanceId)
- Other AOVs
- Custom AOVs
Lights (Disk, Distant, Dome, Rect, Sphere)
Meshes
Geom Subsets
Subdivision Surfaces (using native Cycles support)
Custom Primvars (converted to Cycles attributes)
Cycles Materials (can be exported to USD using the universal-scene-description branch of Blender)
USD Preview Surface Materials
Curves
Point Clouds
OpenVDB Volumes
Motion Blur
Display driver
- Windows OpenGL interop
- macOS interop
- Linux interop
Device selection

.. list to be completed ...

Bugs

Default white environment inconsistent with other renderers
Fix Blender USD exporter not setting normalize attribute, causing too bright lights
Fix viewport with OpenGL interop not working in Houdini on Windows (D15090)
Distant light without normalization is too bright
Area light missing focus mapping to spread
Wrong environment map rotation
Fix excessive camera depth of field with scenes exported from Blender

Building

https://wiki.blender.org/wiki/Building_Blender/CyclesHydra

## Status There is experimental support for building Cycles as a Hydra render delegate. This enables Cycles to be used as a renderer in applications with Hydra support, for example Usdview, Omniverse and Houdini. No official support is provided at this point due to the experimental state. ## Features - [x] CPU/CUDA/OptiX/HIP/Metal support - [x] Camera Settings - [x] Render Settings (automatically queried from Cycles via node type system) - [ ] AOVs - [x] Basic AOVs (color, depth, normal, primId, instanceId) - [ ] Other AOVs - [ ] Custom AOVs - [x] Lights (Disk, Distant, Dome, Rect, Sphere) - [x] Meshes - [x] Geom Subsets - [x] Subdivision Surfaces (using native Cycles support) - [x] Custom Primvars (converted to Cycles attributes) - [x] Cycles Materials (can be exported to USD using the universal-scene-description branch of Blender) - [x] USD Preview Surface Materials - [x] Curves - [x] Point Clouds - [x] OpenVDB Volumes - [ ] Motion Blur - [ ] Display driver - [x] Windows OpenGL interop - [ ] macOS interop - [ ] Linux interop - [ ] Device selection .. list to be completed ... ## Bugs - [x] Default white environment inconsistent with other renderers - [x] Fix Blender USD exporter not setting normalize attribute, causing too bright lights - [x] Fix viewport with OpenGL interop not working in Houdini on Windows ([D15090](https://archive.blender.org/developer/D15090)) - [x] Distant light without normalization is too bright - [ ] Area light missing focus mapping to spread - [ ] Wrong environment map rotation - [ ] Fix excessive camera depth of field with scenes exported from Blender ## Building https://wiki.blender.org/wiki/Building_Blender/CyclesHydra

Brecht Van Lommel commented

2022-03-23 14:57:24 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Brecht Van Lommel commented

2022-03-23 14:57:24 +01:00

Added subscribers: @brecht, @pmoursnv

Steffen Dünner commented

2022-03-23 16:44:02 +01:00

Added subscriber: @SteffenD

Alaska commented

2022-03-24 00:41:41 +01:00

Added subscriber: @Alaska

Sebastian Herholz commented

2022-03-24 10:52:38 +01:00

Added subscriber: @sherholz

Richard Frangenberg commented

2022-03-24 13:01:08 +01:00

Added subscriber: @RicoF

Richard Frangenberg commented

2022-03-24 13:01:08 +01:00

Thanks for the great work on this.
Are there any details, which build configurations have been tested?
I'm getting some build errors on windows vs2019 when Python is enabled, so I had to disable it in the USD (21.08) and the hdCycles builds.
Also the OpenVDB versions are causing some problems. The USD default is v6.1 and the Cycles defaulft is 8.0.1 and changing any of them to match them is generating new errors.

Thanks for the great work on this. Are there any details, which build configurations have been tested? I'm getting some build errors on windows vs2019 when Python is enabled, so I had to disable it in the USD (21.08) and the hdCycles builds. Also the OpenVDB versions are causing some problems. The USD default is v6.1 and the Cycles defaulft is 8.0.1 and changing any of them to match them is generating new errors.

Stefan Werner commented

2022-03-24 13:55:04 +01:00

Added subscriber: @Stefan_Werner

Sebastian Herholz commented

2022-03-24 15:32:14 +01:00

I am havening similar issues when trying to build it under Linux.
One of the main problems seems to be that the build prefers using the
USD, Boost, and Python versions of the Blender dependencies and not the ones used to build the external USD.

Is there any reason why hdCycles uses its own FindUSD.cmake to set up the USD dependencies instead of the cmake config which is automatically build
by USD?

I am havening similar issues when trying to build it under Linux. One of the main problems seems to be that the build prefers using the USD, Boost, and Python versions of the Blender dependencies and not the ones used to build the external USD. Is there any reason why hdCycles uses its own FindUSD.cmake to set up the USD dependencies instead of the cmake config which is automatically build by USD?

Ray molenkamp commented

2022-03-24 15:38:02 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2022-03-24 15:38:02 +01:00

Is there any reason why hdCycles uses its own FindUSD.cmake to set up the USD dependencies instead of the cmake config which is automatically build

Try setting the CMAKE_FIND_PACKAGE_PREFER_CONFIG option to sidestep that behavior.

> Is there any reason why hdCycles uses its own FindUSD.cmake to set up the USD dependencies instead of the cmake config which is automatically build Try setting the [CMAKE_FIND_PACKAGE_PREFER_CONFIG](https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_PACKAGE_PREFER_CONFIG.html#variable:CMAKE_FIND_PACKAGE_PREFER_CONFIG) option to sidestep that behavior.

Brecht Van Lommel commented

2022-03-24 15:55:51 +01:00

It's probably not possible to use Blender's precompiled libraries at all, unless you build USD against Blender's precompiled libraries. So right now, it may be easiest to build without a precompiled library directory present, and setting TBB_ROOT_DIR, OPENVDB_ROOT_DIR, PYTHON_ROOT_DIR, etc. manually if needed.

We should be able to make this process smoother though, or at least document it.

It's probably not possible to use Blender's precompiled libraries at all, unless you build USD against Blender's precompiled libraries. So right now, it may be easiest to build without a precompiled library directory present, and setting `TBB_ROOT_DIR`, `OPENVDB_ROOT_DIR`, `PYTHON_ROOT_DIR`, etc. manually if needed. We should be able to make this process smoother though, or at least document it.

Patrick Mours commented

2022-03-24 16:22:25 +01:00

Right, the build process could use some improvement. Setting USD_ROOT, TBB_ROOT(_DIR), OPENVDB_ROOT(_DIR) etc. works for the moment though (most importantly USD_ROOT and OPENVDB_ROOT, the others are used in mostly ABI compatible ways, so doesn't matter as much if linking against the different version in the precompiled libraries). Can also just disable OpenVDB support to not worry about it at all with WITH_OPENVDB=0. To get a USD build working that was built with Python, currently have to set a USD_PYTHON_LIBRARIES CMake variable with the additional libs to link (e.g. USD_PYTHON_LIBRARIES=boost_python37-vc141-mt-x64-1_68;python37 on Windows for Python 3.7).

Relying on find_package(pxr) and pxrConfig.cmake could be an option to solve this, just need to find a way to integrate this into the Blender build system without disrupting it when not building the Hydra render delegate.

Right, the build process could use some improvement. Setting `USD_ROOT`, `TBB_ROOT(_DIR)`, `OPENVDB_ROOT(_DIR)` etc. works for the moment though (most importantly `USD_ROOT` and `OPENVDB_ROOT`, the others are used in mostly ABI compatible ways, so doesn't matter as much if linking against the different version in the precompiled libraries). Can also just disable OpenVDB support to not worry about it at all with `WITH_OPENVDB=0`. To get a USD build working that was built with Python, currently have to set a `USD_PYTHON_LIBRARIES` CMake variable with the additional libs to link (e.g. `USD_PYTHON_LIBRARIES=boost_python37-vc141-mt-x64-1_68;python37` on Windows for Python 3.7). Relying on `find_package(pxr)` and `pxrConfig.cmake` could be an option to solve this, just need to find a way to integrate this into the Blender build system without disrupting it when not building the Hydra render delegate.

blender-admin commented

2022-03-31 19:27:32 +02:00

This issue was referenced by f60cffad38

This issue was referenced by f60cffad38d12bdfefe503924e93c33a7c89f671

Trung Phạm commented

2022-03-31 20:21:38 +02:00

Added subscriber: @zNight

blender-admin commented

2022-04-06 22:25:40 +02:00

This issue was referenced by 0de0950ad5

This issue was referenced by 0de0950ad5d1de5172cbd2b6b0e67fe319a420c1

Esteban Covo commented

2022-04-07 05:44:15 +02:00

Added subscriber: @EstebanCovo

Brecht Van Lommel commented

2022-04-07 20:11:51 +02:00

I committed various fixes for Linux, and updated the standalone repository to include the Hydra render delegate. Hopefully I didn't break Windows in the process.

Brecht Van Lommel commented

2022-04-08 00:18:04 +02:00

I did some work towards getting this building against Houdini in D14594: Cycles Hydra: support for building against Houdini.

It's not actually working yet, any help debugging this is welcome.

I did some work towards getting this building against Houdini in [D14594: Cycles Hydra: support for building against Houdini](https://archive.blender.org/developer/D14594). It's not actually working yet, any help debugging this is welcome.

Patrick Mours commented

2022-04-08 18:30:08 +02:00

Awesome! There is a bit more necessary to get it running with Houdini on Windows it seems. I posted some suggestions to D14594 that made it work for me.

Awesome! There is a bit more necessary to get it running with Houdini on Windows it seems. I posted some suggestions to [D14594](https://archive.blender.org/developer/D14594) that made it work for me.

blender-admin commented

2022-04-17 07:01:13 +02:00

This issue was referenced by 9b92ce9dc0

This issue was referenced by 9b92ce9dc00971cd9f7f0d0ba6109a9cba2090bd

Brecht Van Lommel commented

2022-04-18 02:32:32 +02:00

I added support for rendering USD files from the Cycles standalone executable in blender/cycles@1a5f493 and blender/cycles@5d03a41.

This also includes changes to make the Hydra render delegate build using the upcoming 3.2 precompiled libraries update. The resulting plugin will not be particularly useful as Blender can't load it, but being able to build the standalone executable without any additional libraries is nice.

Still rough around the edges in many ways, here's a render with a USD file exported from Blender:

I also made some changes to Houdini building to fix issues with packages in blender/cycles@949e461.

I added support for rendering USD files from the Cycles standalone executable in blender/cycles@1a5f493 and blender/cycles@5d03a41. This also includes changes to make the Hydra render delegate build using the upcoming 3.2 precompiled libraries update. The resulting plugin will not be particularly useful as Blender can't load it, but being able to build the standalone executable without any additional libraries is nice. Still rough around the edges in many ways, here's a render with a USD file exported from Blender: ![cycles_junkshop.png](https://archive.blender.org/developer/F13006919/cycles_junkshop.png) I also made some changes to Houdini building to fix issues with packages in blender/cycles@949e461.

Brecht Van Lommel commented

2022-04-20 19:44:43 +02:00

Topic for feedback created here:
https://devtalk.blender.org/t/cycles-hydra-render-delegate-and-usd-feedback/24075

Topic for feedback created here: https://devtalk.blender.org/t/cycles-hydra-render-delegate-and-usd-feedback/24075

Robert Rioux commented

2022-04-24 01:13:21 +02:00

Added subscriber: @Funnybob

Christian Brinkmann commented

2022-04-30 14:38:35 +02:00

Added subscriber: @p2or

Dylan Neill commented

2022-06-10 01:34:17 +02:00

Added subscriber: @semimetallic

Ahmed Hindy commented

2022-07-03 11:39:40 +02:00

Added subscriber: @ahmed.hindy96

platerytter blandebord commented

2022-08-21 18:48:06 +02:00

Added subscriber: @platerytter

Ahmed Hindy commented

2022-08-24 12:40:56 +02:00

any updates for Solaris integration and feature parity?
There doesnt seem to be any updates since last April

any updates for Solaris integration and feature parity? There doesnt seem to be any updates since last April

Esteban Covo commented

2022-08-24 16:30:27 +02:00

No updates yet, it's actually been a while, I guess the team has been super busy, It was picking up steam for a while but it went silent pretty quickly, we have been impleenting a Hybrid pipeline at the studio for a while now and having a Hydra delegate of cycles would be huge for us, since the majority of our artists prefer blender for asset development and most feel more comftrable with cycles than Redshift.
We are still super excited to see Cycles rendering properly in Solaris, I hope the dev team has some time later this year, we can't wait to try it out!!

No updates yet, it's actually been a while, I guess the team has been super busy, It was picking up steam for a while but it went silent pretty quickly, we have been impleenting a Hybrid pipeline at the studio for a while now and having a Hydra delegate of cycles would be huge for us, since the majority of our artists prefer blender for asset development and most feel more comftrable with cycles than Redshift. We are still super excited to see Cycles rendering properly in Solaris, I hope the dev team has some time later this year, we can't wait to try it out!!

Brecht Van Lommel commented

2022-08-24 18:36:13 +02:00

This is currently up to community to pick up, I personally don't have much time to invest in this in the near future. There was some interest from Intel to improve the implementation but nothing concrete so far.

Esteban Covo commented

2022-08-30 19:40:04 +02:00

That's a shame, now that there seems to be interest in developing Hydra viewport support natively having a cycles delegate seems like a logical step.

Alexander Osborne commented

2022-09-14 15:03:15 +02:00

Added subscriber: @ao.cmi

Thomas Lindemeier commented

2022-10-11 20:42:24 +02:00

Added subscriber: @tlinde

Thomas Lindemeier commented

2022-10-11 21:05:40 +02:00

Hey there,
thx to all contributors for the work on the hydra delegate. It all sounds very promising and it will enable lots of projects, increasing the usage of cycles.

I am trying to compile cycles standalone together with USD on Linux. Sadly, I get a segmentation fault as soon as I try to "usdview" a simple scene (tried several scenes) with hdCycles. I started a GDB session and this is where it segfaults:

0x00007ffeedb09656 in HdCycles::(anonymous namespace)::writePixels<float, int, HdCycles::(anonymous namespace)::IdConversion> (
    srcPtr=0x7ffee00d9c00, srcSize=..., srcChannelCount=1, dstPtr=0x0, dstSize=..., dstChannelCount=1, convertor=...)
    at /home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/cycles/cycles/src/hydra/render_buffer.cpp:178
178	        dstPtr[x * dstChannelCount + c] = convertor.convert(srcPtr[x * srcChannelCount + c]);

dstPtr=0x0, looks like the issue? Is it due to OpenGL interop not fully implemented on Linux?

Tried USD Version: 22.03 and 21.11
cycles: tag v3.3.0, master
OS: Ubuntu 20.04
GPU NVIDIA RTX 3060 Ti (driver 515.65.01)

USD compile command (conda env):

python build_scripts/build_usd.py  --usdview --use-cxx11-abi 0 ${INSTALL_FOLDER}

I also built the hdCycles with the USD library included in the cycles SVN. If i tr to run this with my usdview I get this error:

Traceback (most recent call last):
  File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/stageView.py", line 1677, in paintGL
    renderer = self._getRenderer()
  File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/stageView.py", line 950, in _getRenderer
    self._renderer = UsdImagingGL.Engine()
pxr.Tf.ErrorException: 
	Error in 'pxrInternal_v0_22__pxrReserved__::Hf_PluginEntry::IncRefCount' at line 98 in file /home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/USD/pxr/imaging/hf/pluginEntry.cpp : 'Plugin HdCyclesPlugin is missing TfType registration'
Unable to load numpy_formathandler accelerator from OpenGL_accelerate
Traceback (most recent call last):
  File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/appController.py", line 1411, in <lambda>
    self._rendererPluginChanged(pluginType))
  File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/appController.py", line 1371, in _rendererPluginChanged
    if not self._stageView.SetRendererPlugin(plugin):
  File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/stageView.py", line 997, in SetRendererPlugin
    if self._renderer.SetRendererPlugin(plugId):
pxr.Tf.ErrorException: 
	Error in 'pxrInternal_v0_22__pxrReserved__::HdRendererPluginRegistry::CreateRenderDelegate' at line 100 in file /home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/USD/pxr/imaging/hd/rendererPluginRegistry.cpp : 'Couldn't find plugin for id HdCyclesPlugin'

What USD version are you using in the SVN?

Any ideas what the problem is in both cases? I could contribute here if that would be desired, would need some pointers though.

Thx in advance

Hey there, thx to all contributors for the work on the hydra delegate. It all sounds very promising and it will enable lots of projects, increasing the usage of cycles. I am trying to compile cycles standalone together with USD on Linux. Sadly, I get a segmentation fault as soon as I try to "usdview" a simple scene (tried several scenes) with hdCycles. I started a GDB session and this is where it segfaults: ``` 0x00007ffeedb09656 in HdCycles::(anonymous namespace)::writePixels<float, int, HdCycles::(anonymous namespace)::IdConversion> ( srcPtr=0x7ffee00d9c00, srcSize=..., srcChannelCount=1, dstPtr=0x0, dstSize=..., dstChannelCount=1, convertor=...) at /home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/cycles/cycles/src/hydra/render_buffer.cpp:178 178 dstPtr[x * dstChannelCount + c] = convertor.convert(srcPtr[x * srcChannelCount + c]); ``` `dstPtr=0x0,` looks like the issue? Is it due to OpenGL interop not fully implemented on Linux? Tried USD Version: 22.03 and 21.11 cycles: tag v3.3.0, master OS: Ubuntu 20.04 GPU NVIDIA RTX 3060 Ti (driver 515.65.01) USD compile command (conda env): ``` python build_scripts/build_usd.py --usdview --use-cxx11-abi 0 ${INSTALL_FOLDER} ``` I also built the hdCycles with the USD library included in the cycles SVN. If i tr to run this with my usdview I get this error: ``` Traceback (most recent call last): File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/stageView.py", line 1677, in paintGL renderer = self._getRenderer() File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/stageView.py", line 950, in _getRenderer self._renderer = UsdImagingGL.Engine() pxr.Tf.ErrorException: Error in 'pxrInternal_v0_22__pxrReserved__::Hf_PluginEntry::IncRefCount' at line 98 in file /home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/USD/pxr/imaging/hf/pluginEntry.cpp : 'Plugin HdCyclesPlugin is missing TfType registration' Unable to load numpy_formathandler accelerator from OpenGL_accelerate Traceback (most recent call last): File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/appController.py", line 1411, in <lambda> self._rendererPluginChanged(pluginType)) File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/appController.py", line 1371, in _rendererPluginChanged if not self._stageView.SetRendererPlugin(plugin): File "/home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/usd_v22.03_hdCycles-v3.3.0-install/lib/python/pxr/Usdviewq/stageView.py", line 997, in SetRendererPlugin if self._renderer.SetRendererPlugin(plugId): pxr.Tf.ErrorException: Error in 'pxrInternal_v0_22__pxrReserved__::HdRendererPluginRegistry::CreateRenderDelegate' at line 100 in file /home/zotlinde/dev/crt.revip/crt.revip.usd_hydra/third_party/USD/pxr/imaging/hd/rendererPluginRegistry.cpp : 'Couldn't find plugin for id HdCyclesPlugin' ``` What USD version are you using in the SVN? Any ideas what the problem is in both cases? I could contribute here if that would be desired, would need some pointers though. Thx in advance

Brecht Van Lommel commented

2022-10-12 18:05:44 +02:00

The USD version can be found in the headers, it's 22.03 for Blender currently.

OpenGL interop is not implemented on Linux, but it should be falling back to slower pixel copying without interop, which I think is where the crash is happening for you.

The code seems to expect that first HdCyclesRenderBuffer::Allocate gets called specify the size in _dataSize, and then HdCyclesRenderBuffer::Map gets called to allocate that in _data, after which there should be a non-null buffer to write to in HdCyclesRenderBuffer::WritePixels. You could investigate why that's not happening as expected.

The USD version can be found in the headers, it's 22.03 for Blender currently. OpenGL interop is not implemented on Linux, but it should be falling back to slower pixel copying without interop, which I think is where the crash is happening for you. The code seems to expect that first `HdCyclesRenderBuffer::Allocate` gets called specify the size in `_dataSize`, and then `HdCyclesRenderBuffer::Map` gets called to allocate that in `_data`, after which there should be a non-null buffer to write to in `HdCyclesRenderBuffer::WritePixels`. You could investigate why that's not happening as expected.

Thomas Lindemeier commented

2022-10-12 22:30:58 +02:00

In #96731#1431393, @brecht wrote:
The USD version can be found in the headers, it's 22.03 for Blender currently.

OpenGL interop is not implemented on Linux, but it should be falling back to slower pixel copying without interop, which I think is where the crash is happening for you.

The code seems to expect that first HdCyclesRenderBuffer::Allocate gets called specify the size in _dataSize, and then HdCyclesRenderBuffer::Map gets called to allocate that in _data, after which there should be a non-null buffer to write to in HdCyclesRenderBuffer::WritePixels. You could investigate why that's not happening as expected.

Thank you for the suggestion. I'll investigate as soon as I have as bit more time again to look into that.

> In #96731#1431393, @brecht wrote: > The USD version can be found in the headers, it's 22.03 for Blender currently. > > OpenGL interop is not implemented on Linux, but it should be falling back to slower pixel copying without interop, which I think is where the crash is happening for you. > > The code seems to expect that first `HdCyclesRenderBuffer::Allocate` gets called specify the size in `_dataSize`, and then `HdCyclesRenderBuffer::Map` gets called to allocate that in `_data`, after which there should be a non-null buffer to write to in `HdCyclesRenderBuffer::WritePixels`. You could investigate why that's not happening as expected. Thank you for the suggestion. I'll investigate as soon as I have as bit more time again to look into that.

Thomas Lindemeier commented

2022-10-17 15:37:19 +02:00

In #96731#1431393, @brecht wrote:
The USD version can be found in the headers, it's 22.03 for Blender currently.

OpenGL interop is not implemented on Linux, but it should be falling back to slower pixel copying without interop, which I think is where the crash is happening for you.

The code seems to expect that first HdCyclesRenderBuffer::Allocate gets called specify the size in _dataSize, and then HdCyclesRenderBuffer::Map gets called to allocate that in _data, after which there should be a non-null buffer to write to in HdCyclesRenderBuffer::WritePixels. You could investigate why that's not happening as expected.

I had some time to look into the problem now:
HdCyclesRenderBuffer::Allocate defines the size of the memory to allocate, but an actual allocation of HdCyclesRenderBuffer::_data happens only in HdCyclesRenderBuffer::Map.
There are two options:

call _data.resize(_dataSize); or HdCyclesRenderBuffer::Map directly in HdCyclesRenderBuffer::Allocate
call HdCyclesRenderBuffer::Map in HdCyclesRenderBuffer::WritePixels if not already mapped. A HdCyclesRenderBuffer::unmap at the end of the scope of ``HdCyclesRenderBuffer::WritePixels` would make sense?

Both options work and the example scenes are rendered in usdview, but the question is which option is the correct one. IMHO option 1 would be the sound choice, but i don't know the hydra details about when HdRenderBuffer::Map is being called.

> In #96731#1431393, @brecht wrote: > The USD version can be found in the headers, it's 22.03 for Blender currently. > > OpenGL interop is not implemented on Linux, but it should be falling back to slower pixel copying without interop, which I think is where the crash is happening for you. > > The code seems to expect that first `HdCyclesRenderBuffer::Allocate` gets called specify the size in `_dataSize`, and then `HdCyclesRenderBuffer::Map` gets called to allocate that in `_data`, after which there should be a non-null buffer to write to in `HdCyclesRenderBuffer::WritePixels`. You could investigate why that's not happening as expected. I had some time to look into the problem now: `HdCyclesRenderBuffer::Allocate` defines the size of the memory to allocate, but an actual allocation of `HdCyclesRenderBuffer::_data` happens only in `HdCyclesRenderBuffer::Map`. There are two options: 1. call `_data.resize(_dataSize);` or `HdCyclesRenderBuffer::Map` directly in `HdCyclesRenderBuffer::Allocate` 2. call `HdCyclesRenderBuffer::Map` in `HdCyclesRenderBuffer::WritePixels` if not already mapped. A `HdCyclesRenderBuffer::unmap` at the end of the scope of ``HdCyclesRenderBuffer::WritePixels` would make sense? Both options work and the example scenes are rendered in `usdview`, but the question is which option is the correct one. IMHO option 1 would be the sound choice, but i don't know the hydra details about when `HdRenderBuffer::Map` is being called.

Brecht Van Lommel commented

2022-10-17 19:21:06 +02:00

I'd go with option 2, calling Map/Unmap inside WritePixels. We don't need to check if already mapped, I don't think that's possible.

In HdCyclesOutputDriver::update_render_tile there are two cases, and in one we are already using Map/Unmap, and the other is WritePixels where we could do the same.

I'd go with option 2, calling Map/Unmap inside `WritePixels`. We don't need to check if already mapped, I don't think that's possible. In `HdCyclesOutputDriver::update_render_tile` there are two cases, and in one we are already using Map/Unmap, and the other is `WritePixels` where we could do the same.

Thomas Lindemeier commented

2022-10-17 20:49:56 +02:00

Thx @brecht for your comments and pointers in the right direction. I've tested your suggestion to go with option 2 and I've just submitted a patch (https://developer.blender.org/D16272). Let me know if something is missing and if more information is needed.