Film - the bottleneck

[jeanphi]

Hi,

Ok, so after all it is required. I agree with the overall idea, however you should push the tiling and locking really low level so the current AddSample doesn't gain tile parameters, but you do the locking when really do splat something on the buffer (ie after the filter computations). Thus you know the span of the filter, you have all the data available and you can properly compute the locking boundaries and keep the locking periods as small as possible.

Jeanphi

[Lord Crc]

Hm, sounds expensive in terms of locking. I'll give it a try and compare with my current scheme.

Sadly I didn't get a 24 core machine for xmas, so it's hard to test the different schemes scale under real pressure.

[B.Y.O.B.]

B.Y.O.B., I agree that having control over sampling density would be nice, it's something else than what this thread is all about though.
This is about how sample contributions are added to the film.

Ok. To me as an un-experienced person in this stuff it seemed that there maybe could have been a relationship

[Lord Crc]

Ok. To me as an un-experienced person in this stuff it seemed that there maybe could have been a relationship

Yes, it's a very deep and nasty part of the core this, not many have crawled this far and survived to tell the tale

[jeanphi]

Hm, sounds expensive in terms of locking. I'll give it a try and compare with my current scheme.

Well, it shouldn't make a difference if you do the locking outside the loops, ie loop over each impacted tile, lock the tile, loop over each impacted pixel of the tile, splat, unlock the tile and move to the next one.

Sadly I didn't get a 24 core machine for xmas, so it's hard to test the different schemes scale under real pressure.

Same here

Jeanphi

[Lord Crc]

Well, it shouldn't make a difference if you do the locking outside the loops, ie loop over each impacted tile, lock the tile, loop over each impacted pixel of the tile, splat, unlock the tile and move to the next one.

But then the contribution pool will need to sort based on tiles, so the film must expose this. As such I don't see why we need to push the tile locking to the film. Seems better to keep it in one place? It's tricky enough as it is.

Anyway your initial post made me think we could perhaps do some lightweight spinlock-like locking per tile for each AddSample. Would be like a hybrid between full-blown tile locking and atomic adds. Could be interesting to try.

[jeanphi]

Anyway your initial post made me think we could perhaps do some lightweight spinlock-like locking per tile for each AddSample. Would be like a hybrid between full-blown tile locking and atomic adds. Could be interesting to try.

That's what I was trying to explain: don't sort contributions at the high level (actually the more random, the better for the locking in my proposed scheme) and lock the tiles as requested during AddSample for a given contribution.

Jeanphi

[Lord Crc]

Yes, I realized that after I had a nap

I'll give it a try.

[Lord Crc]

So, given that I have at least one potential improvement, and quite possibly two after I try out jeanphi's approach, and that I don't have the hardware to really test it...

Could I push these changes into a branch? Given the nature of the changes, one branch per approach would be nice. I could set up my own repo at bitbucket if you don't want to soil the official repo.

[jeanphi]

Hi,

I think that you should be able to experience the bottleneck by running more threads than you have cores. You can make branches in the main repo if you want, or bitbucket, or publish builds with your changes, ...

Jeanphi