Cycles geometry preparation and upload refactor #105372

New Issue

William Leeson · 2023-03-02T12:41:47+01:00

William Leeson commented

2023-03-02 12:41:47 +01:00

Why

Cycle's geometry upload and preparation can be refactored to be easier to understand and also to improve its efficiency. By creating a single parallel_for for each device instead of one thread per copy operation the overhead of handling threading can be reduced thereby improving performance. Also, by splitting the host side work from the device side work it is easier to distribute the workload. Some calculations are performed twice or unnecessarily as they only needed for specific task but are performed regardless as this is hard to work out with the current code.

What

Break the geometry update into host and device update.
Re-order the update so that it is easier to understand
Create a parallel loop over each device and from there upload the data.
- Create a DeviceScene per device instead of using the MultiDevice
- Create a BVH per device instead of using the MultiDevice
Only perform calculations that are required
This results in the program flow looking like the following
This method works as follows:

Calculate vertex normals and gather undisplaced vertices
Tessellate mesh if needed
Compute object bounds
fill attribute buffers
fill geometry buffers
----DEVICE SPECIFIC BEGIN----
copy attribute buffers to device
copy geometry buffers to device
--- only run on the first device ---
displace meshes and calculate shadow transparency if needed
----DEVICE SPECIFIC END----
if displacement or shadow transparency then refill buffers and re-upload
----START OF MIXED DEVICE AND HOST CODE----
build geometry BVHs
build scene BVH
----HOST SPECIFIC BELOW THIS POINT
Remove modified or update tags

The original flow and the new flow are shown in the files below. To achieve this a DeviceScene is created for each device. However, as this is just updating the geometry device update (and not all uses of the DeviceScene) the old DeviceScene needs to remain so other that buffers can be handled by the multi-device. The host side pointers are shared by all the DeviceScenes so they only need to be packed once. This is done using a method to update the host pointer of one DeviceScene from an existing DeviceScene.

## Why Cycle's geometry upload and preparation can be refactored to be easier to understand and also to improve its efficiency. By creating a single parallel_for for each device instead of one thread per copy operation the overhead of handling threading can be reduced thereby improving performance. Also, by splitting the host side work from the device side work it is easier to distribute the workload. Some calculations are performed twice or unnecessarily as they only needed for specific task but are performed regardless as this is hard to work out with the current code. ## What * Break the geometry update into host and device update. * Re-order the update so that it is easier to understand * Create a parallel loop over each device and from there upload the data. * Create a DeviceScene per device instead of using the MultiDevice * Create a BVH per device instead of using the MultiDevice * Only perform calculations that are required This results in the program flow looking like the following This method works as follows: 1. Calculate vertex normals and gather undisplaced vertices 2. Tessellate mesh if needed 3. Compute object bounds 4. fill attribute buffers 5. fill geometry buffers ----DEVICE SPECIFIC BEGIN---- 6. copy attribute buffers to device 7. copy geometry buffers to device --- only run on the first device --- 8. displace meshes and calculate shadow transparency if needed ----DEVICE SPECIFIC END---- 9. if displacement or shadow transparency then refill buffers and re-upload ----START OF MIXED DEVICE AND HOST CODE---- 10. build geometry BVHs 11. build scene BVH ----HOST SPECIFIC BELOW THIS POINT 12. Remove modified or update tags The original flow and the new flow are shown in the files below. To achieve this a DeviceScene is created for each device. However, as this is just updating the geometry device update (and not all uses of the DeviceScene) the old DeviceScene needs to remain so other that buffers can be handled by the multi-device. The host side pointers are shared by all the DeviceScenes so they only need to be packed once. This is done using a method to update the host pointer of one DeviceScene from an existing DeviceScene.

new_device_update.png

104 KiB

original_device_update.png

130 KiB

nsys_visualization_of_new_geom_update.png

210 KiB

👍 3 ❤️ 3 🎉 3

William Leeson added the

Type

Design

label 2023-03-02 12:41:48 +01:00

Iliya Katushenock commented

2023-03-02 14:31:01 +01:00

It would be nice to ever be able to calculate render attributes using buitin groups of geometry nodes. They are already trying to provide acceptable speed and unification for things like vertex normals, edge separation or island indices.

William Leeson added reference main

2023-03-02 15:31:26 +01:00

William Leeson added this to the Render & Cycles project 2023-03-02 15:31:37 +01:00

William Leeson commented

2023-03-02 15:43:44 +01:00

It would be nice to ever be able to calculate render attributes using buitin groups of geometry nodes. They are already trying to provide acceptable speed and unification for things like vertex normals, edge separation or island indices.

Yes that would be possible. However, Cycles currently uses it's own routines to calculate normals from the faces and vertices. I believe the attributes are filled from the existing data passed in from Blender some of which could come from the geometry nodes.

> It would be nice to ever be able to calculate render attributes using buitin groups of geometry nodes. They are already trying to provide acceptable speed and unification for things like vertex normals, edge separation or island indices. Yes that would be possible. However, Cycles currently uses it's own routines to calculate normals from the faces and vertices. I believe the attributes are filled from the existing data passed in from Blender some of which could come from the geometry nodes.

William Leeson added the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles geometry preparation and upload refactor #105372

Why

What