[Bf-committers] "Official" CUDA Benchmark/Implementation Thread

joe joeedh at gmail.com
Sat Dec 20 11:29:50 CET 2008


It'd be interesting to modify my bucketing system to store actual
faces/strands per tiles, and not just references to them, and see if
zbuffering goes faster.
BTW, what about reading one stream, and using it to write another?  That's
basically what DSM does in a lot of its code.  This is really interesting; I
may need to do this sort of optimization (I'm nearing, or at, the limits of
what algorithmic improvements can give me).  If you can find that google
tech talk that'd be really great.

Joe

On Fri, Dec 19, 2008 at 1:09 PM, Timothy Baldridge <tbaldridge at gmail.com>wrote:

> > I'm not sure how you'd avoid cache misses though. . .we simply have to
> deal
> > with too much data.  About the only thing I can think of is sorting
> > faces/strands (I actually do this in my DSM branch) per tile and using a
> > more optimal render order then simply going over the scanlines.  The ray
> > tracing traversal could be made more efficient, but optimizing what the
> > renderer does between could be more difficult.
> > You know I think the CodeAnalyst profiling tool from AMD can measure
> cache
> > misses, I'll have to try and figure out how it works.
>
> You cannot avoid all cache misses, but it is possible to avoid many
> cache misses. Modern CPUs load cache lines in 64byte segements. This
> means that if you read one byte from memory the CPU really loads
> 64bytes. Thus, if you can arrange data in such a way that it can be
> read and processed as sequential data, the performance will be greatly
> enhanced.
>
> I wish I could find it, but there is an excellent video on youtube
> from a Google Tech Talk. In the talk the speaker explains these
> caches, and goes to show that reading items from a linked list or
> vector can be (IIRC) up to a order of magnitude slower than reading
> items from an array. That is if the entire set does not lie in memory.
> This is due to the fact that linked lists require allot of jumping
> around in memory, which causes the cache to be come less useful.
>
> Timothy
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20081220/f3ba352b/attachment-0001.htm 


More information about the Bf-committers mailing list