On Mon, Sep 28, 2009 at 6:08 AM, Kenneth Ostby <[email protected]> wrote: > Timothy Normand Miller: >>On Mon, Sep 21, 2009 at 9:41 PM, Hugh Fisher <[email protected]> wrote: >>> Loads and stores are mostly of matrices (eg skinning), or materials >>> and colors which are one or more 3/4-way RGB/RGBA vectors. >> >>Good argument for vector load instructions. I can totally buy that. > > I see the point in vector load instructions, however, as a computer > architect, I'm wondering if there is other ways to solve this. Mainly, > cause I want to expose a simple ISA to the software developers ( > Software developers here being the compilers and OpenGL driver > developers ). > > What strikes me, and this isn't well though through yet, is that we > might be able to "emulate", in lack of a better term, the performance > gain of a vector load instruction by instead, increasing the cache line > size from the naive 32 bit, to Y*(number of ALUs). This will have the > effect that every time we make a request for address X, we will fetch > the entire line. Although, it might not be the entire vector for a > single thread, we can, by storing our data in interleaved fashion, make > sure that it's the data for the threads that are to be scheduled on the > cores in round.
In my conception of this, we don't have data caches for the shaders. But what we might do here is make what amounts to a single-line 4x 32-bit fully associative dcache. That is, if you fetch any word, you fetch it and its three aligned neighbors. The result is that the first of four is expensive, but the neighboring three cost only a cycle (for the instruction). We have to see just how often we'll fetch only a scalar and waste time/space/energy. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
