|
|
On 10.06.2024 13:51, William F Pokorny wrote:
> On 6/9/24 00:21, William F Pokorny wrote:
>> Ah, and what about facets.
>
> FWIW. The caching mechanism is simpler (older) for facets. As with
> crackle I experimented some with forcing 100% misses. The slow down in
> the heavy AA case is +195% as opposed to the +335% seen with crackle.
> The difference likely comes down to the overhead for the simpler facets
> cache being smaller. The facets cache comes close to what I wanted to
> try with the crackle cache.
>
> Going to let ideas to rattle around in my head for a while as to what to
> do. ( 1. Limit use to one crackle and one facets use in any given scene.
> 2. A cache per crackle/facets use / per thread. 3. ...)
Hi Bill,
the other issue to consider is that while there is no user interface for
it, in theory multiple renders of the same scene can run in parallel.
The actual solution to the whole problem is to keep the data needed not
only thread-local but look carefully at what is actually cached and then
ideally have it block local (also meaning, as with thread-local storage,
that the pattern changes with render block size) or even better pixel
local (no change with block size). To avoid the access to thread-local
storage, the whole rendering actually could be overhauled (which would
be good anyway) to move from a recursive to a stack based approach. That
way the needed local data could be (more easily) passed as argument down
to patterns ... but expect half a year full time to implement something
like this.
Thorsten
Post a reply to this message
|
|