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.

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?

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.

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.

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.

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.

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.

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.

I added support for rendering USD files from the Cycles standalone executable in rC1a5f4932b481: Add USD as a file format for Cycles standalone rendering and rC5d03a41653e3: Build: preparation for supporting USD in standalone.

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 rC949e461053ab: Build: install Houdini render delegate in houdini/dso/usd_plugins.

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

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

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!!

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.

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.

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

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.

In T96731#1431393, @Brecht Van Lommel (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 T96731#1431393, @Brecht Van Lommel (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.

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.

Thx @Brecht Van Lommel (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.