Re: EXR texture memory overhead

But it's not optimal for a use pattern like TextureSystem where the typical
> request is ONE tile, and the next tile it wants may not even be adjacent.
>

Whoops. What I pointed at look like its only the case if you read through
Imf::InputFile.  If you use Imf::TiledInputFile (like in exrinput.cpp), I
don't think you hit that buffering.



Wait, I'm not quite sure how threads play into this. Is this allocated
> framebuffer part of the ImageInptut itself? Do threads lock to use it? Or
> is this per thread, per file?
>

I think the per-thread part is around ImfTiledInputFile.cpp::267
<https://github.com/openexr/openexr/blob/develop/OpenEXR/IlmImf/ImfTiledInputFile.cpp#L267>.
Each TileBuffer has an uncompressedData ptr which is what the compressor
fills during decode.

This *should* just be a tile per thread, but it does look like it's held
over the lifetime of the ImfTiledInputFile.

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel