- User Since
- Sep 12 2019, 7:47 PM (85 w, 6 d)
Wed, Apr 28
Mon, Apr 26
Thu, Apr 22
Quick update with some numbers:
Mon, Apr 19
Wed, Apr 14
moved alignment directive to alternative header file
removed unused variable
Tue, Apr 13
added alignment directive for struct
Updated change based on comments.
Mar 5 2021
Using BLI_task_parallel_range(...) now, and the playback is slightly improved, on my 3990X, it was roughly:
Mar 4 2021
Sorry, I was wrong, the crash is back.
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 3 2021
Jan 3 2021
Dec 17 2020
Dec 5 2020
Nov 1 2020
Oct 29 2020
Oct 28 2020
Oct 27 2020
Oct 26 2020
Oct 23 2020
Looks good, does this pass the regression tests?
Oct 22 2020
@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 21 2020
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 20 2020
Oct 19 2020
removed one last straggler of timing code
Removed timing code.
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).
@Brecht Van Lommel (brecht) regarding your comment in the other review:
Oct 16 2020
Oct 9 2020
Oct 8 2020
Oct 7 2020
Oct 6 2020
Oct 5 2020
Oct 1 2020
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).
Sep 30 2020
Hi @Sergey Sharybin (sergey), with this loop (serial, randomized):
Hi @Sergey Sharybin (sergey), so I looked at this and noticed a a few things:
Sep 29 2020
fixing the diff again
fixing the diff
Sep 28 2020
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 24 2020
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 17 2020
Hi @Sergey Sharybin (sergey), can this go in now?
Sep 12 2020
Fixed crash as a result of sync to latest.
Sep 10 2020
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?
Second update to master
Updated against the latest master.
updated diff against latest master
Aug 17 2020
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 15 2020
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 12 2020
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 8 2020
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:
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 4 2020
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?
Jul 30 2020
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?
Added a new method sync_geometry_task(...) to serve as the multi-thread friendly version of sync_geometry(...).
Jul 21 2020
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 20 2020
Jul 17 2020
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.
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 15 2020
That is correct.
You'd need to replace b_ob.matrix_world() with the matrix stored in the SyncObject though.
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 14 2020
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 13 2020
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.
Okay, I'll do up this change again, a third time :).