Film - the bottleneck

Discussion related to the implementation of new features & algorithms to the Core Engine.

Moderators: Dade, jromang, tomb, zcott, coordinators

Film - the bottleneck

Postby Lord Crc » Fri Dec 23, 2011 1:33 pm

Hi,

as I guess you know, adding contributions to the Film ("splatting") is a pretty bad bottleneck, especially with GPU rendering. Contributions that are splatted are either really close by or separated by a fair amount. As such I think we should exploit this by tiling the buffers. This way each tile could be splatted to separately.

Essentially we divide the film into "tiles", and when calling AddSample we pass the tile index, making sure that the AddSample code only writes to the specific tile. The splatting buffer pool is indexed by tile, with a splatting lock per tile. So far I've used horizontal strips as tiles, which seem to work well. The main sample count is updated via an atomic add.

The primary difficulty is handling contributions which cross tile boundaries. My current idea is to assign these to a "special tile", which represents the whole film. Due to the double-buffering system in the contribution pool, locking the entire film every now and then shouldn't be a huge issue I think. The alternative is to add such contributions to both tiles. The code makes sure a tile is larger than 2x filter width, so a contribution can't span more than two tiles.

As you can see in the image below, it does indeed solve the CPU contention. You'll also observe that I have a small bug near tile borders :)
Attachments
contribtiling_ref.jpg
Hybrid bidir - reference
contribtiling1.jpg
Hybrid bidir - 8 tiles
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

Re: Film - the bottleneck

Postby SATtva » Fri Dec 23, 2011 2:33 pm

Nice one! I've encountered this bottleneck recently with one of my projects. Is it possible to adapt this trick to outliers rejection as well -- separate the accelerator structure to the same tiles and contribute to each individually?
Linux builds packager
聞くのは一時の恥、聞かぬのは一生の恥
User avatar
SATtva
Developer
 
Posts: 7163
Joined: Tue Apr 07, 2009 12:19 pm
Location: from Siberia with love

Re: Film - the bottleneck

Postby Lord Crc » Fri Dec 23, 2011 2:53 pm

SATtva wrote:Is it possible to adapt this trick to outliers rejection as well


Yes, this should work with outlier rejection with little modification. I haven't added it yet, but shouldn't be any big issues.
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

Re: Film - the bottleneck

Postby LadeHeria » Fri Dec 23, 2011 6:37 pm

It looks very cool !
Coule it also works with renderfarming rendering ? So 1 tile for eatch machine !

LadeHeria
LadeHeria
 
Posts: 163
Joined: Fri Aug 27, 2010 8:59 am

Re: Film - the bottleneck

Postby Lord Crc » Sat Dec 24, 2011 10:02 am

LadeHeria wrote:Coule it also works with renderfarming rendering ? So 1 tile for eatch machine !


In most cases this will not be a good idea. As such I'm not focusing on this aspect. However if we decide to do something like that the code I'm writing could be used as a basis.
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

Re: Film - the bottleneck

Postby B.Y.O.B. » Sat Dec 24, 2011 11:05 am

If there was also vertical tiling, could you then add a function that you tell Lux to only render one of these tiles (and maybe create sub-tiles then)?
I'm thinking of something like built-in border-rendering.
User avatar
B.Y.O.B.
Developer
 
Posts: 5154
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

Re: Film - the bottleneck

Postby Lord Crc » Sat Dec 24, 2011 11:14 am

B.Y.O.B. wrote:If there was also vertical tiling, could you then add a function that you tell Lux to only render one of these tiles (and maybe create sub-tiles then)?
I'm thinking of something like built-in border-rendering.


I don't do square tiles because handling tile borders is somewhat expensive, so less borders the better. Also I don't understand what this would gain that regular border rendering doesn't do already?
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

Re: Film - the bottleneck

Postby B.Y.O.B. » Sun Dec 25, 2011 3:52 am

I think it would be more comfortable. Also it could maybe be done while rendering and the single tile rendering could maybe switched on and off, so you could put more renderpower in parts of the image that need it.
I had a case were this had been very useful several weeks ago with this image - the lower right part of the image, the curtain, needs much more samples. I couldn't use border rendering because it would not have any benefits in speed in this case - the area is too big and the image aldready had ca. 5kS/p, so even the border-rendering had taken ca. 15h I guess.
A method were the samples in the "border" would be added to the samples that are already computed would be great.

I don't know if it's possible, I just wanted to ask.
User avatar
B.Y.O.B.
Developer
 
Posts: 5154
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

Re: Film - the bottleneck

Postby SATtva » Sun Dec 25, 2011 5:22 am

It's not that easy -- one must account for sample weights after switching such "refine area rendering" on and off, or the resulting image will be completely corrupted. But i agree with the overall sentiment: if it's possible to work out the math, it would be an awesome feature.

This steers out off topic, but anyway... We've had several discussions on the "refine area rendering" in the past, and i cannot recall now whether this approach was mentioned explicitly. But what if the "refine area" could define not a region where a sampler spends more time during rendering, but where it spends all the time. This could be organized as follows:

1. User selects a region for refined rendering.
2. Another frame buffer is created from the main one and is cropped down to the selected region.
3. Rendering is continued inside that region only.
4. User stops refined rendering.
5. The cropped frame buffer is merged with main frame buffer.
6. Rendering is continued on the whole image.

I think #3 and #5 are the most tricky parts. Guess we need jeanphi to comment on the feasibility of this task.
Linux builds packager
聞くのは一時の恥、聞かぬのは一生の恥
User avatar
SATtva
Developer
 
Posts: 7163
Joined: Tue Apr 07, 2009 12:19 pm
Location: from Siberia with love

Re: Film - the bottleneck

Postby Lord Crc » Mon Dec 26, 2011 12:27 am

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.
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

Next

Return to Architecture & Design

Who is online

Users browsing this forum: No registered users and 1 guest