Page MenuHome

Jagannadhan Ravi (easythrees)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 12 2019, 7:47 PM (85 w, 6 d)

Recent Activity

Wed, Apr 28

Pieter Schiettecatte (Schiette) awarded D10609: Modifiers: Performance Simple Deformation a Love token.
Wed, Apr 28, 2:48 AM · Performance, Modifiers

Mon, Apr 26

Yuichiro Fujita (chironamo) awarded rB425e19bc1fca: Modifiers: Performance Simple Deformation a Love token.
Mon, Apr 26, 9:53 PM

Thu, Apr 22

Jagannadhan Ravi (easythrees) added a comment to D10609: Modifiers: Performance Simple Deformation.

Quick update with some numbers:

Thu, Apr 22, 10:30 PM · Performance, Modifiers

Mon, Apr 19

Florian Kamenz (HEYPictures) awarded D10609: Modifiers: Performance Simple Deformation a Love token.
Mon, Apr 19, 9:14 AM · Performance, Modifiers

Wed, Apr 14

Jagannadhan Ravi (easythrees) added a comment to D10609: Modifiers: Performance Simple Deformation.

Patch seems fine. Just a small comment. Do you have updated performance figures between master and this patch?

Wed, Apr 14, 10:54 PM · Performance, Modifiers
Jagannadhan Ravi (easythrees) updated the diff for D10609: Modifiers: Performance Simple Deformation.

moved alignment directive to alternative header file
removed unused variable

Wed, Apr 14, 7:42 PM · Performance, Modifiers

Tue, Apr 13

Jagannadhan Ravi (easythrees) updated the diff for D10609: Modifiers: Performance Simple Deformation.

added alignment directive for struct

Tue, Apr 13, 9:40 PM · Performance, Modifiers
Jagannadhan Ravi (easythrees) updated the diff for D10609: Modifiers: Performance Simple Deformation.

Updated change based on comments.

Tue, Apr 13, 8:16 PM · Performance, Modifiers

Mar 5 2021

Jagannadhan Ravi (easythrees) updated the diff for D10609: Modifiers: Performance Simple Deformation.

Using BLI_task_parallel_range(...) now, and the playback is slightly improved, on my 3990X, it was roughly:

Mar 5 2021, 6:40 AM · Performance, Modifiers

Mar 4 2021

Jagannadhan Ravi (easythrees) added inline comments to D10609: Modifiers: Performance Simple Deformation.
Mar 4 2021, 11:58 PM · Performance, Modifiers
Jagannadhan Ravi (easythrees) updated the diff for D10609: Modifiers: Performance Simple Deformation.

Sorry, I was wrong, the crash is back.

Mar 4 2021, 5:33 AM · Performance, Modifiers
Jagannadhan Ravi (easythrees) updated the diff for D10609: Modifiers: Performance Simple Deformation.

Crash fixed (I think), though this approach is understandably very slow. I wonder if it makes more sense to split the work into chunks and do it that way.

Mar 4 2021, 4:11 AM · Performance, Modifiers
Jagannadhan Ravi (easythrees) added inline comments to D10609: Modifiers: Performance Simple Deformation.
Mar 4 2021, 3:48 AM · Performance, Modifiers

Mar 3 2021

Jagannadhan Ravi (easythrees) requested review of D10609: Modifiers: Performance Simple Deformation.
Mar 3 2021, 9:02 PM · Performance, Modifiers

Jan 3 2021

Maged afra (Maged_afra) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Jan 3 2021, 5:59 PM

Dec 17 2020

Blender Defender (Blender_Defender) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Burninate token.
Dec 17 2020, 2:10 PM

Dec 5 2020

Vilem Duha (pildanovak) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Dec 5 2020, 9:57 AM

Nov 1 2020

B (bnzs) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Nov 1 2020, 4:01 AM

Oct 29 2020

Raimund Klink (Raimund58) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Oct 29 2020, 8:42 PM

Oct 28 2020

Jagannadhan Ravi (easythrees) added a comment to D2057: Materials: Add custom object properties as usable attributes.

Approving the Cycles and shader UI part of this. Have not looked at the Eevee implementation.

When this gets committed, be sure to add a test to the regression test files.

Oct 28 2020, 5:20 PM

Oct 27 2020

Mindinsomnia (mindinsomnia) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Oct 27 2020, 1:23 AM

Oct 26 2020

Jagannadhan Ravi (easythrees) added a comment to D9322: Fix for race condition introduced in recent geom sync multithreading (https://developer.blender.org/D9258).

I'll go ahead and commit this fix, even if this is not ideal for performance. The most important thing right now is to fix the crash quickly.

Once we have a dedicated hair object this will also resolve itself, so it's not that a big deal. Still may be worth re-running the benchmarks and seeing if there is a better solution (like task dependencies).

Oct 26 2020, 4:06 PM · Render & Cycles

Oct 23 2020

Gilberto Rodrigues (gilberto_rodrigues) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a 100 token.
Oct 23 2020, 7:58 PM
Jagannadhan Ravi (easythrees) added a comment to rBbb49aa0d6978: Cycles: multithreaded export of geometry.

Will this affect all kinds of render devices, CPU, GPU, AMD/NVIDIA, etc?

Oct 23 2020, 5:25 PM
Alaska (Alaska) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Oct 23 2020, 4:57 AM
Jagannadhan Ravi (easythrees) added a comment to D9322: Fix for race condition introduced in recent geom sync multithreading (https://developer.blender.org/D9258).

Looks good, does this pass the regression tests?

Oct 23 2020, 12:28 AM · Render & Cycles

Oct 22 2020

Jagannadhan Ravi (easythrees) added a comment to T81976: Crash at Render Startup Time in Object Sync code from "Multithreading Object Sync in Cycles Render (Simpler)" (D9258).

@Olivier Maury (omaury) you're fast! I only just saw the notification. So, what's the protocol here, should I take your fix or will you put it in Blender?

Oct 22 2020, 11:00 PM · Render & Cycles, BF Blender

Oct 21 2020

Marco (nacioss) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Oct 21 2020, 10:28 PM
Everton Schneider (eversimo) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Oct 21 2020, 10:12 PM
Nicolas Lelong (rotoglup) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Oct 21 2020, 9:32 PM
anu manu (anaho) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Hungry Hippo token.
Oct 21 2020, 8:55 PM
Silas Opel (Schamph) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Oct 21 2020, 7:29 PM
Lopo Isaac (lopoIsaac) awarded rBbb49aa0d6978: Cycles: multithreaded export of geometry a Love token.
Oct 21 2020, 7:12 PM
Jagannadhan Ravi (easythrees) added a comment to D9258: Multithreading Object Sync in Cycles Render (Simpler).

I'll commit this with some minor tweaks, thanks for all the work!

Oct 21 2020, 6:58 PM
Jagannadhan Ravi (easythrees) updated the diff for D9258: Multithreading Object Sync in Cycles Render (Simpler).

This passes regression tests and looks like it preserves the speed gains, certainly in the barbershop and BMW scenes. Also synced to latest master. @Brecht Van Lommel (brecht) please let me know if this is good for you.

Oct 21 2020, 1:04 AM

Oct 20 2020

Jagannadhan Ravi (easythrees) added a comment to D9258: Multithreading Object Sync in Cycles Render (Simpler).

The easiest solution for now would be to disable using the task pool for the case where sync_dupli_particle is called. (...)

How do I disable the TaskPool? I don't see a method on the class.

I believe the idea would be to have a test before pushing to the task_pool, preventing to process geometry that will be used later by sync_dupli_particle.

Maybe sync_object could change to be something more like (pseudocode) ?

bool will_need_sync_dupli_particle = (is_instance && b_instance. particle_system());
TaskPool *optional_task_pool = will_need_sync_dupli_particle ? NULL : &task_pool;
sync_geometry(..., optional_task_pool);

The call to sync_geometry with a NULL TaskPool* would instruct to run the sync in the main thread

Oct 20 2020, 9:49 PM
Jagannadhan Ravi (easythrees) added a comment to D9258: Multithreading Object Sync in Cycles Render (Simpler).

We can't update the test, it's randomly giving different results here.

What is happening is that sync_dupli_particle accesses object->geometry, which is not fully initialized since that happens in another thread.

In particular object->geometry->need_attribute(scene, ATTR_STD_PARTICLE) requires used_shaders to be initialized.

The easiest solution for now would be to disable using the task pool for the case where sync_dupli_particle is called. I plan to change how we export such particle data after D2057 lands, and once that happens it should no longer be a problem.

Oct 20 2020, 7:37 PM

Oct 19 2020

Jagannadhan Ravi (easythrees) added a comment to D9258: Multithreading Object Sync in Cycles Render (Simpler).

There is one "fail" in the regression tests (attached).

Well this is new :( Same issue here, with patch applied on current master. The issue goes away when pulling the sync_hair call from the task_pool.

Oct 19 2020, 11:43 PM
Jagannadhan Ravi (easythrees) added a comment to D9258: Multithreading Object Sync in Cycles Render (Simpler).

There is one "fail" in the regression tests (attached).

Well this is new :( Same issue here, with patch applied on current master. The issue goes away when pulling the sync_hair call from the task_pool.

Oct 19 2020, 11:34 PM
Jagannadhan Ravi (easythrees) updated the diff for D9258: Multithreading Object Sync in Cycles Render (Simpler).

removed one last straggler of timing code

Oct 19 2020, 11:19 PM
Jagannadhan Ravi (easythrees) added inline comments to D9258: Multithreading Object Sync in Cycles Render (Simpler).
Oct 19 2020, 11:09 PM
Jagannadhan Ravi (easythrees) updated the diff for D9258: Multithreading Object Sync in Cycles Render (Simpler).

Removed timing code.

Oct 19 2020, 9:32 PM
Jagannadhan Ravi (easythrees) added inline comments to D9258: Multithreading Object Sync in Cycles Render (Simpler).
Oct 19 2020, 9:32 PM
Jagannadhan Ravi (easythrees) updated the diff for D9258: Multithreading Object Sync in Cycles Render (Simpler).

Updated review with comments. Forgot to remove the timing code, so I'll do that in a minute. There is one "fail" in the regression tests (attached).

Oct 19 2020, 9:14 PM
Jagannadhan Ravi (easythrees) added a comment to D9258: Multithreading Object Sync in Cycles Render (Simpler).

Do you think it makes sense to move that test into sync_object(...) instead?

I don't see how that would help, the test depends on the geometry pointer which you only get in sync_geometry.

Oct 19 2020, 4:37 PM
Jagannadhan Ravi (easythrees) added inline comments to D9258: Multithreading Object Sync in Cycles Render (Simpler).
Oct 19 2020, 4:02 PM
Jagannadhan Ravi (easythrees) added a comment to D9258: Multithreading Object Sync in Cycles Render (Simpler).

@Brecht Van Lommel (brecht) regarding your comment in the other review:

Oct 19 2020, 1:32 AM
Jagannadhan Ravi (easythrees) requested review of D9258: Multithreading Object Sync in Cycles Render (Simpler).
Oct 19 2020, 1:21 AM
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Given these timing results, I think we should go with the simpler patch then. Perfomance seems to be a little better, and it avoids increasing memory overhead when there are millions of instances. I suggest to submit a new code review for that.

Unfortunately it means some of the work in this patch will not be used then, but in the end it's about what the best solution is.

In the task pool patch, I think there is still some non-thread safe code in BlenderSync::sync_geometry. It's accessing geom->transform_applied and geom->used_shaders in the main thread while a task pool thread may also be modifying them. Moving the geometry_synced test and insert earlier in the function or duplicating it (haven't checked which is correct) would avoid the issue.

b_permanent_ob is also the same as b_ob_instance as far as I can tell (maybe it needs to be renamed for clarity).

Oct 19 2020, 1:09 AM · Render & Cycles

Oct 16 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

I'd be happy to, and thank you for your work on this. Do you think you could point me to it again please? I'd like to run it in our lab here to get some wider benchmarks.

Great ! You can either grab the patch file attached to D8324#226209, or get it from https://github.com/rotoglup/blender/pull/1/files

Oct 16 2020, 4:58 PM · Render & Cycles

Oct 9 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Given these timing results, I think we should go with the simpler patch then. Perfomance seems to be a little better, and it avoids increasing memory overhead when there are millions of instances. I suggest to submit a new code review for that.

Fine with me, @Jagannadhan Ravi (easythrees) would you be willing to submit that new review ?

Oct 9 2020, 6:52 PM · Render & Cycles

Oct 8 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

I was a little more nuanced than that, i said as long as you can justify the changes, and the images are consistent between renders, you'll be ok, updating the ref images is not that big of a deal, however those two conditions do have to be met.

Oct 8 2020, 10:51 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

So sorting them by name won't help it sounds like, correct?

Yes, it won't help making the test pass.

Sorting will solve the problem. What you need to do is update the test reference image and then verify that multi-threading the test always passes, rather than randomly failing depending on the object order.

Okay, I guess I need to update the reference image, then.

Oct 8 2020, 10:32 PM · Render & Cycles

Oct 7 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Can either if you run the same performance tests with both patches and post the numbers? Then we can decide if the simpler approach is enough or not, and which patch we should be reviewing and helping complete.

I can do that if it's ok with you @Jagannadhan Ravi (easythrees), I think I'll proceed as follows :

  • instrument the code to temporarily add printing of timing values :
    • time spent in serial objects loop
    • time spent in waiting the end of the parallel execution
    • total time spent in sync_objects
  • instrument both patches, as "after" results, and my current master branch, to have a "before" reference
  • gather data from the scene in https://svn.blender.org/svnroot/bf-blender/trunk/lib/benchmarks/cycles/
    • I'm not able to share my "big" scene that I used previously, but I saw that barbershop_interior scene is quite heavy in the synchronizing step
Oct 7 2020, 8:34 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

So sorting them by name won't help it sounds like, correct?

Yes, it won't help making the test pass.

Sorting will solve the problem. What you need to do is update the test reference image and then verify that multi-threading the test always passes, rather than randomly failing depending on the object order.

Oct 7 2020, 8:27 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

And I did something similar for the lights loop as well. Sorting alphabetically doesn't seem to help, am I doing this right?

The emissive objects are not alphabetically ordered in the test file, so it is bound to be still different. Accidentally, they are added in reverse alphabetical order:

Sphere.003
Sphere.002
Sphere.001
Sphere

If you add an Emission shader on the background plane, the objects will be added in this order:

Sphere.003
Sphere.002
Sphere.001
Plane
Sphere

This change should be done in master first I think.

Oct 7 2020, 3:28 AM · Render & Cycles

Oct 6 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi @Brecht Van Lommel (brecht), do you mean sort the vectors of thing like the lights? They're under the scene object.

I'm referring to all lights and meshes that will be put in the distribution in that function.

This would not sort the lights or objects in the scene itself, but rather just create a new vector with pointers to those, and then sort them for creating the light distribution.

Oct 6 2020, 9:44 PM · Render & Cycles

Oct 5 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

I just stick in timing code.

OK, I did it this, too. I attach my results on 2 scenes (benchmark's classroom + my own).

Oct 5 2020, 11:16 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi, I'm have the feeling that this feature/patch could be simplified. On my side, I've given a try to an approach similar to what @Sergey Sharybin (sergey) mentionned in D8230 - which seem to work fine - the general idea is :

  • leave the sync_objects loop as is
  • push the geometry sync tasks in a TaskPool - making sure to use a BL::Object that has the good lifespan
  • wait for the task pool to finish

My code is visible on github for now : https://github.com/rotoglup/blender/pull/1/files

I may be missing something obvious, and this is perhaps not the best place to mention this ? Thanks.

Have you tested this on the benchmark scenes and observed performance improvements?

Oct 5 2020, 7:11 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi, I'm have the feeling that this feature/patch could be simplified. On my side, I've given a try to an approach similar to what @Sergey Sharybin (sergey) mentionned in D8230 - which seem to work fine - the general idea is :

  • leave the sync_objects loop as is
  • push the geometry sync tasks in a TaskPool - making sure to use a BL::Object that has the good lifespan
  • wait for the task pool to finish

My code is visible on github for now : https://github.com/rotoglup/blender/pull/1/files

I may be missing something obvious, and this is perhaps not the best place to mention this ? Thanks.

Oct 5 2020, 6:15 PM · Render & Cycles

Oct 1 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

What I think is happening is that there are two emissive objects in this test, which will be included in the light distribution for importance sampling. If they are added to the distribution in a different order, the resulting noise will be different.

A way to solve this would be to change LightManager::device_update_distribution, to gather all emissive object pointers in a vector and sort them by object name.

Oct 1 2020, 11:14 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

What I think is happening is that there are two emissive objects in this test, which will be included in the light distribution for importance sampling. If they are added to the distribution in a different order, the resulting noise will be different.

A way to solve this would be to change LightManager::device_update_distribution, to gather all emissive object pointers in a vector and sort them by object name.

Oct 1 2020, 2:14 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi @Nicolas Lelong (rotoglup) thank you for reaching out and I'm very flattered you felt that you could learn from my work (I'm also new at this). If you look at my post above yours, the issue seems to be that the order of the noise generation (which is a seeded hash) is the issue. @Sergey Sharybin (sergey)'s contention is exactly right, this isn't a threading conflict, but "just" an issue of ordering. I'm waiting for Sergey to chime in (though he's in the UTC +2 time zone so it may be a while).

Oct 1 2020, 12:04 AM · Render & Cycles

Sep 30 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi @Sergey Sharybin (sergey), with this loop (serial, randomized):

Sep 30 2020, 8:06 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi @Sergey Sharybin (sergey), so I looked at this and noticed a a few things:

Sep 30 2020, 2:50 AM · Render & Cycles

Sep 29 2020

Jagannadhan Ravi (easythrees) updated the diff for D8324: Multithreading Object Sync in Cycles Render.

fixing the diff again

Sep 29 2020, 2:50 AM · Render & Cycles
Jagannadhan Ravi (easythrees) updated the diff for D8324: Multithreading Object Sync in Cycles Render.

fixing the diff

Sep 29 2020, 2:47 AM · Render & Cycles

Sep 28 2020

Jagannadhan Ravi (easythrees) updated the diff for D8324: Multithreading Object Sync in Cycles Render.

Hi @Sergey Sharybin (sergey) this change should work. I noticed with the cycles_shader test that it "failed" on the tex_voronoi example, but the images in the web page look exactly the same. What do you think? Can this go in?

Sep 28 2020, 4:03 AM · Render & Cycles

Sep 24 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi @Sergey Sharybin (sergey), I fixed one regression, but can't find the cause of the others. I'm going to rewrite this change and run the tests as I go along. If anything in the change strikes you as being a culprit, please let me know (this codebase is huge!).

Sep 24 2020, 9:18 PM · Render & Cycles

Sep 17 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi @Sergey Sharybin (sergey), can this go in now?

Sep 17 2020, 7:32 PM · Render & Cycles

Sep 12 2020

Jagannadhan Ravi (easythrees) updated the diff for D8324: Multithreading Object Sync in Cycles Render.

Fixed crash as a result of sync to latest.

Sep 12 2020, 2:23 AM · Render & Cycles

Sep 10 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Hi Sergey, I've updated the review to work with the latest master. I could use your help with something, I'm seeing a crash rendering some scenes (which never happened before), and it's not in my code. I can see it in the BVH code, but I'm not sure how it's related to my code. Do you think you could also take a look and see what I could be missing?

Sep 10 2020, 10:40 PM · Render & Cycles
Jagannadhan Ravi (easythrees) updated the diff for D8324: Multithreading Object Sync in Cycles Render.

Second update to master

Sep 10 2020, 10:38 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Updated against the latest master.

Sep 10 2020, 12:25 AM · Render & Cycles
Jagannadhan Ravi (easythrees) updated the diff for D8324: Multithreading Object Sync in Cycles Render.

updated diff against latest master

Sep 10 2020, 12:24 AM · Render & Cycles

Aug 17 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Here is a more detailed breakdown of improvements. It looks like Koro suffers a little, maybe there's some circumstances where it's better to do a sync serially. Koro has 10 objects and no instances, maybe that's why?

Aug 17 2020, 7:08 PM · Render & Cycles

Aug 15 2020

Kenn Nyström (Frozen_Death_Knight) awarded D8324: Multithreading Object Sync in Cycles Render a Like token.
Aug 15 2020, 12:58 PM · Render & Cycles
Alaska (Alaska) awarded D8324: Multithreading Object Sync in Cycles Render a Love token.
Aug 15 2020, 2:22 AM · Render & Cycles
Jagannadhan Ravi (easythrees) updated the diff for D8324: Multithreading Object Sync in Cycles Render.
Aug 15 2020, 2:19 AM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

I'll clean the code up and put it up here, but in the meantime, here are some render times on my machine (average of 5 runs per scene):

Aug 15 2020, 1:44 AM · Render & Cycles

Aug 12 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Okay, I have moved instance syncing to the serial loop that builds the sync objects. However, in some cases, like the pavilion scene, it reduces the performance. Is there some way to do the sync for instances in parallel?

Aug 12 2020, 2:21 AM · Render & Cycles

Aug 8 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

This is the Pavillon scene that I've stripped down to just the grass and trees. When sync_task(...) is *inside* the loop over b_depsgraph.object_instances, you'll see the trees:

Aug 8 2020, 9:43 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Follow up on this, it looks like if the sync_task(...) method is inside that main loop that goes through the graph (the original for loop in sync_objects(...)), the missing objects get rendered. They go missing again when outside that loop, which makes me wonder if something is getting stale once we leave that loop. Any ideas?

Aug 8 2020, 9:19 PM · Render & Cycles

Aug 4 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Okay, looks like I am missing something here. The Pavilion Barcelona scene doesn't render properly (image attached). Do you know what the trees and lily pad objects are in the scene? Instances?

Aug 4 2020, 9:59 PM · Render & Cycles

Jul 30 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

Heya, so I've added a new method and it seems to work for the barbershop. The sync used to take 12 seconds for the objects and it looks like it takes much less than that now, I'll do more timing tests tomorrow and get them to you. Do you think you could point me to more scenes with lots of objects that I can use for testing?

Jul 30 2020, 7:50 AM · Render & Cycles
Jagannadhan Ravi (easythrees) updated the diff for D8324: Multithreading Object Sync in Cycles Render.

Added a new method sync_geometry_task(...) to serve as the multi-thread friendly version of sync_geometry(...).

Jul 30 2020, 7:48 AM · Render & Cycles

Jul 21 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

So I figured one way to get sync_geometry(...) better suited for multi-threading is to change its data members to their TBB equivalents:

Jul 21 2020, 5:26 AM · Render & Cycles

Jul 20 2020

Jagannadhan Ravi (easythrees) added inline comments to D8324: Multithreading Object Sync in Cycles Render.
Jul 20 2020, 11:10 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added inline comments to D8324: Multithreading Object Sync in Cycles Render.
Jul 20 2020, 9:03 PM · Render & Cycles
Jagannadhan Ravi (easythrees) added inline comments to D8324: Multithreading Object Sync in Cycles Render.
Jul 20 2020, 7:53 PM · Render & Cycles

Jul 17 2020

Jagannadhan Ravi (easythrees) added a comment to D8324: Multithreading Object Sync in Cycles Render.

This renders the benchmark scenes, though with the BMW, there's a wheel missing which I'm assuming is something I'm doing wrong with either a transform or an instance. If you see anything, please let me know.

Jul 17 2020, 4:10 AM · Render & Cycles
Jagannadhan Ravi (easythrees) added a comment to D8230: Multithreading sync portion of Cycles Render.

Hi Sergey, I've created a new review as we discussed. It's located here: https://developer.blender.org/D8324 I'm not sure how to 'delete' an existing review though....

Jul 17 2020, 4:09 AM
Jagannadhan Ravi (easythrees) requested review of D8324: Multithreading Object Sync in Cycles Render.
Jul 17 2020, 4:08 AM · Render & Cycles

Jul 15 2020

Jagannadhan Ravi (easythrees) added a comment to D8230: Multithreading sync portion of Cycles Render.

That is correct.
You'd need to replace b_ob.matrix_world() with the matrix stored in the SyncObject though.

Jul 15 2020, 4:01 PM
Jagannadhan Ravi (easythrees) added a comment to D8230: Multithreading sync portion of Cycles Render.

Hi Sergey, so just to make sure I'm starting things off correctly, I have some specific questions about handling objects in sync_object. Right now, I have this:

Jul 15 2020, 2:34 AM

Jul 14 2020

Jagannadhan Ravi (easythrees) added a comment to D8230: Multithreading sync portion of Cycles Render.

Please don't scatter discussion everywhere where you see comment box.

What does it mean if b_accessible_object.data() return NULL?

If the object is type Empty it's data is null, In all other cases it should never be null. I was testing this P1531 with the classroom scene (which does have instances), and had no b_accessible_object to have data() of null.

Accessing the data() function in my sync function keeps crashing, which makes me think the data underneath's been invalidated. This makes sense given your comment about how b_accessible_object.data() and b_temp_object.data() both point to the same thing, but then how can I make sure it's not being invalidated?

Please have a look into depsgraph_query_iter.cc where temp_dupli_object is constructed, and into DNA_object_types.h where the object's type is defined.

Roughly, b_iterator owns the memory where b_temp_objectlives. b_accessible_object is assigned to b_temp_object and object matrix of b_temp_object is assigned to the world matrix of the instance. The data is a void*. It is owned by the dependency graph. You can assign pointer anywhere, and it will still be valid.

which is how I ended up with all those properties.

I don't see why you went into all the complexity of dealing with modifiers. Material slots, modifiers and so on are all available via b_accessible_object.


I would suggest you starting from scratch in a simpler way:

  • Replace b_instance argument passed to sync_object with Cycles's side structure, which will hold all information of interest needed for Cycles.
  • Split the current for-loop over instances coming from depsgraph into two loops: first loop will initialize the b_instance replacement form above and store it in a vector together with b_accessible_object. Second loop will iterate over this vector and call sync_object(). NO threading at this point. Just make this deferred case to work reliably.
  • Make the loop body run in parallel, using parallel_for. Solve all the possible issues which are discovered.
  • Look into possibly replacing vector+parallel_for with a task-based approach. Not sure it worth it though: you still need to store some per-task context anyway, so to me it seems using Task will just cause more of small allocations, without really reducing the overall memory footprint.

When doing tests, use small scenes first. Default cube, Default cube with sphere. Cornell box.
Only when those work reliably go to a more complex scenes.

Jul 14 2020, 5:35 PM
Jagannadhan Ravi (easythrees) added a comment to P1529 Snippet for D8230.

Hi Sergey, I think something's wrong with the definition of b_accessible_object. Accessing the data() function in my sync function keeps crashing, which makes me think the data underneath's been invalidated. This makes sense given your comment about how b_accessible_object.data() and b_temp_object.data() both point to the same thing, but then how can I make sure it's not being invalidated?

Jul 14 2020, 12:36 AM

Jul 13 2020

Jagannadhan Ravi (easythrees) added a comment to P1529 Snippet for D8230.

What does it mean if b_accessible_object.data() return NULL? I get a crash when there's a check to see if it's a mesh when I'm running this multi-threaded.

Jul 13 2020, 11:21 PM
Jagannadhan Ravi (easythrees) added a comment to D8230: Multithreading sync portion of Cycles Render.

Okay, I'll do up this change again, a third time :).

Jul 13 2020, 7:36 PM
Jagannadhan Ravi (easythrees) added a comment to D8230: Multithreading sync portion of Cycles Render.

This seems to be much more complicated that it should be.

Have a look at P1529.

Basically:

  • Use b_temp_object to access transform and persistent ID and other instance-specific fields.
  • Do not use b_temp_object outside of loop body, cache all the fields of interest in a context of some sort (see the SyncObject from the snipped of code I've sent in blender-chat. Not the best name, but just to show the idea),
  • Pass the SyncObject instead of b_instance to the sync_object().
  • Pass b_accessible_object instead of b_object to the sync_object(),
  • Replace direct call of sync_object() with some threaded pool push.
  • Done.
Jul 13 2020, 6:12 PM