Film - the bottleneck

[Lord Crc]

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

[SATtva]

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?

[Lord Crc]

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.

[LadeHeria]

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

LadeHeria

[Lord Crc]

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.

[B.Y.O.B.]

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.

[Lord Crc]

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?

[B.Y.O.B.]

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.

[SATtva]

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.

[Lord Crc]

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.