Page MenuHome

[ON HOLD] Line Art feature update: Multi thread intersection stage
AbandonedPublic

Authored by YimingWu (NicksBest) on Jul 30 2021, 1:44 AM.

Details

Summary

Update: Me and @Sebastian Parborg (zeddb) is experimenting with an alternate algorithm using embree. This specific revision can be put on hold.


This patch contains change for doing intersection in multiple threads in line art.

At the moment, it's split into 8 (for example) threads like this in the image frame:

(x,y range -1 to 1)
-1              0                1
+-----------+-----------+  1
| thread 1  | thread 2  |
+-----------+-----------+
| thread 3  | thread 4  |
+-----------+-----------+  0
| thread 5  | thread 6  |
+-----------+-----------+
| thread 7  | thread 8  |
+-----------+-----------+  -1

This naturally handles intersection only when they are visible in the frame, so if you zoom in on a portion of the model, only intersections in that part is getting calculated. However the problem with this method is that if your model largely stays inside one of the tiles, only one thread is effectively producing anything.

We may need better tile splitting method for threading. Now on an average model, this tiled method uses about 50% less time in calculating the intersections, but with 8 threads we should do better, however with the spatial locking in place I'm not sure how much speed up we could eventually gain.

Diff Detail

Repository
rB Blender

Event Timeline

YimingWu (NicksBest) requested review of this revision.Jul 30 2021, 1:44 AM
YimingWu (NicksBest) created this revision.

@Sebastian Parborg (zeddb) Could you take a look at this patch? I never user threading, so cannot review the patch. Maybe @Falk David (filedescriptor) has used it and can help here.

@Antonio Vazquez (antoniov) Yiming and I are currently brainstorming on how to improve the thread scaling performance with alternative algorithms.
So I think this specific patch is put on hold until we finish that.

Thanks @Sebastian Parborg (zeddb), you and Yming know how to manage this, so what you decide is perfect for me.

Use grid+sort/merge method to avoid all locks in add_triangles stage, indeed much more improvement there.

727 test file time ~0.74s (without intersection, not implemented in this structure just yet), with original method ~1.02s with intersection off.

Updated to include tile subdiv depth limit (to the same current limit value in master)

Tested using the file from T90695, with intersection off, master is about 12-13s, while this patch shows 10s, but the value is not as stable on my surface pro, as the cpu temperature may affect the speed a lot. I consider the patch is behaving correctly.

Triangle based pair record, way too slow, and may need to get rid of some pairs by bound box, but that used to be handled in thread.

YimingWu (NicksBest) updated this revision to Diff 41322.EditedSep 1 2021, 12:16 PM

Now build triangle pairs in threads.

Uses 3.86s for 727 file (1.97s in triangle_add and pair_build), in comparison, line art branch uses 3.59s in total with intersection, with only 1.4s for triangle_add.

The extensive search could be a problem, especially pronounced in this T90695 file.

Uses about 40s for the file form T90695, doesn't sound very good, and this is only for triangle pair building.

Note this patch now applies on master, there's a intermediate branch on my other machine so I can't diff only the thread commits here, but to show the idea of how this works.

YimingWu (NicksBest) retitled this revision from Line Art feature update: Multi thread intersection stage to [ON HOLD] Line Art feature update: Multi thread intersection stage.Jan 17 2022, 1:28 AM
YimingWu (NicksBest) edited the summary of this revision. (Show Details)
YimingWu (NicksBest) added a project: Line Art.

This is a legacy algorithm and will be replaced with D14953. So it should not be needed now.