[Bf-cycles] Tiled Texture Caching for Cycles

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Jun 10 18:47:31 CEST 2017

These are some very promising numbers. Is that with the overhead of the
more expensive OIIO texture filtering included?

For texture cache misses on the GPU, one way to handle that is to record
the missing texture tiles, let the CPU load them into memory, and then
re-execute just the shaders that had missing textures. Maybe there's a
better way with unified virtual memory on newer cards, ideally the CPU
could dynamically load a texture tile from disk when the GPU has a page
fault, but I'm not sure if that's possible.

Regarding branches, I guess there will be no more 2.7x release after 2.79.
But code could still be committed to the 2.7x branch I think, if that's
useful to someone and as long as it's easy to merge into 2.8.

Regarding Embree, that's very interesting as well. Certainly we need a
better motion BVH that does interpolation of the inner node bounding boxes
instead of what we have now. Ideally we can avoid having two BVH backends
because it's harder to maintain and the GPU, and instead just integrate the
optimizations into our own BVH, but I'm not sure how hard it is.

On Sat, Jun 10, 2017 at 3:50 PM, Mohamed Sakr <3dsakr at gmail.com> wrote:

> well, overall this looks promising!
> and please don't rely on AMD in anything :)
> just put into account that GPU-zing the code will be done at some point
> On Sat, Jun 10, 2017 at 12:30 PM, Stefan Werner <stewreo at gmail.com> wrote:
>> > On 10. Jun 2017, at 00:00, Mohamed Sakr <3dsakr at gmail.com> wrote:
>> >
>> > so interesting!, Embree too looks interesting!!, will it work for CUDA?
>> All of this is CPU only at the moment. It should be possible to write GPU
>> traversal code for the BVH trees built by embree or to implement the same
>> method for motion blur into Cycles’ own BVH to speed it up. Texture Caching
>> on the GPU will be more complicated, as there is no way of calling host
>> code (in this case, a texture fetch from disk) from GPU code. Maybe AMD’s
>> promised SSD+GPU will allow something like that. The best odds are probably
>> with the split kernel, there you could insert a (CPU) texture fetch step
>> between (GPU) traversal and shading kernels. It could become tricky with
>> indirect texture fetches or texture coordinates derived from procedurals
>> though.
>> -Stefan
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20170610/b9c3a80e/attachment.htm 

More information about the Bf-cycles mailing list