blender/cycles
8
16
Fork 11
Code Issues 3 Pull Requests 5 Releases Activity

Cycles shared library #1

Open
Alex Fuller wants to merge 1 commits from boberfly/cycles:cycles_shared_lib into main
pull from: boberfly/cycles:cycles_shared_lib
merge into: blender:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 4 Commits 1 Files Changed 24 +371 -60
Alex Fuller commented 2023-04-01 05:38:11 +02:00
Contributor
Copy Link

From the archives: https://archive.blender.org/developer/D16736

Hello,

This is an experiment with making a cleaner way of packaging Cycles into one shared library, as well as bringing along a single header + config which brings along all the build pre-processor defines so that other code linking to Cycles doesn't get conflicting or out-of-sync defines, which we've been finding when linking against Gaffer/GafferCycles.

I've added WITH_CYCLES_SHARED_LIBRARY but set as off as default. The idea is that when this is enabled, it'll generate a shared library of Cycles instead, and the Hydra delegate and standalone cycles in App will link to this instead of statically-linking.

I'm anticipating some tweaks to this to get things just right, but I've already tested the single header with Gaffer. What I haven't fully tested is all the dependencies like OpenImageIO as static instead of dynamic.

Some open questions, should all headers join the source/ sub-directory that's designed for runtime compiling of shaders (this is what the patch currently does) or should they live in a dedicated include/ directory? With packaging in Gaffer we were preferring the latter, as well as putting the dynamic library into lib/ and executable into bin/.

My hand-created cycles.h includes all the necessary headers that both the Hydra delegate and Gaffer module need to compile with, but should this just contain all headers instead of my hand-picked ones, that's generated by CMake also.

Cheers

Updated with the changes Brecht commented

  • Changed namespace from ccl to cycles
  • Any occurance to ccl:: is now replaced with the pre-processor define CCL_NS:: (to match the Hydra delegate)
  • Moved headers to include/
  • Defaulted WITH_CYCLES_SHARED_LIBRARY to ON

Open questions/TODOs

  • Should kernel/ also live in include/ or just use source/ (kernel/types.h is needed)
  • How do we make it easy for the user to ensure libcycles is pathed for the hydra delegate?
  • Migrate Hydra and cycles_standalone to cycles.h ?
  • Should the shared lib and binary just live at the root of the directory or go into bin/ and lib/ respectively?
From the archives: https://archive.blender.org/developer/D16736 Hello, This is an experiment with making a cleaner way of packaging Cycles into one shared library, as well as bringing along a single header + config which brings along all the build pre-processor defines so that other code linking to Cycles doesn't get conflicting or out-of-sync defines, which we've been finding when linking against Gaffer/GafferCycles. I've added WITH_CYCLES_SHARED_LIBRARY but set as off as default. The idea is that when this is enabled, it'll generate a shared library of Cycles instead, and the Hydra delegate and standalone cycles in App will link to this instead of statically-linking. I'm anticipating some tweaks to this to get things just right, but I've already tested the single header with Gaffer. What I haven't fully tested is all the dependencies like OpenImageIO as static instead of dynamic. Some open questions, should all headers join the source/ sub-directory that's designed for runtime compiling of shaders (this is what the patch currently does) or should they live in a dedicated include/ directory? With packaging in Gaffer we were preferring the latter, as well as putting the dynamic library into lib/ and executable into bin/. My hand-created cycles.h includes all the necessary headers that both the Hydra delegate and Gaffer module need to compile with, but should this just contain _all_ headers instead of my hand-picked ones, that's generated by CMake also. Cheers **Updated with the changes Brecht commented** - Changed namespace from ccl to cycles - Any occurance to ccl:: is now replaced with the pre-processor define CCL_NS:: (to match the Hydra delegate) - Moved headers to include/ - Defaulted WITH_CYCLES_SHARED_LIBRARY to ON **Open questions/TODOs** - Should kernel/ also live in include/ or just use source/ (kernel/types.h is needed) - How do we make it easy for the user to ensure libcycles is pathed for the hydra delegate? - Migrate Hydra and cycles_standalone to cycles.h ? - Should the shared lib and binary just live at the root of the directory or go into bin/ and lib/ respectively?
Alex Fuller added 1 commit 2023-04-01 05:38:13 +02:00 
Differential Revision: https://developer.blender.org/D16736
Alex Fuller requested review from Brecht Van Lommel 2023-04-01 05:39:04 +02:00
Alex Fuller requested review from Patrick Mours 2023-04-01 05:39:14 +02:00
Esteban Covo commented 2023-04-05 22:34:45 +02:00
First-time contributor
Copy Link

This would be great to have

This would be great to have
Alex Fuller force-pushed cycles_shared_lib from f8a9628758 to be5f561005 2023-04-20 02:17:33 +02:00 Compare
Alex Fuller commented 2023-06-04 11:28:34 +02:00
Author
Contributor
Copy Link

Hey @brecht

https://projects.blender.org/boberfly/blender/src/branch/cycles_shared_lib

I've moved this one to Blender itself (I feel kind of silly that I didn't know of make cycles until now) so I think this is probably best to move this one forward so I don't break the Blender build while tweaking this one.

Hey @brecht https://projects.blender.org/boberfly/blender/src/branch/cycles_shared_lib I've moved this one to Blender itself (I feel kind of silly that I didn't know of `make cycles` until now) so I think this is probably best to move this one forward so I don't break the Blender build while tweaking this one.
Suryavarman commented 2024-10-04 10:26:37 +02:00
Contributor
Copy Link

Hello,
Having Cycles as a normal dependency would be really interesting for me. To integrate Cycles into my project I have to build it every time I rebuild my project. This weighs heavily on build time.
Anyway, just to ask you why Cycles hasn't yet been designed as a shared library?

Hello, Having Cycles as a normal dependency would be really interesting for me. To integrate Cycles into my project I have to build it every time I rebuild my project. This weighs heavily on build time. Anyway, just to ask you why Cycles hasn't yet been designed as a shared library?
Alex Fuller commented 2024-10-04 10:36:41 +02:00
Author
Contributor
Copy Link

I'm currently looking to deploying Cycles in a production environment using rez which this is needed to reduce compiling and library bloat as well. Cycles has traditionally been compiled into Blender so it hasn't been a huge need, and hdCycles is deployed as a USD library already, same as GafferCycles but it's a bit heavy to support agreed.

I'm currently looking to deploying Cycles in a production environment using rez which this is needed to reduce compiling and library bloat as well. Cycles has traditionally been compiled into Blender so it hasn't been a huge need, and hdCycles is deployed as a USD library already, same as GafferCycles but it's a bit heavy to support agreed.
This pull request has changes conflicting with the target branch.
  • src/device/oneapi/device_impl.cpp
  • src/scene/alembic.h
  • src/scene/scene.cpp
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u cycles_shared_lib:boberfly-cycles_shared_lib
git checkout boberfly-cycles_shared_lib
Sign in to join this conversation.
Reviewers
No reviewers
Brecht Van Lommel
Patrick Mours
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: blender/cycles#1
No description provided.
Delete Branch "boberfly/cycles:cycles_shared_lib"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?