On 2009-10-13, Timothy Normand Miller wrote: > On Mon, Oct 12, 2009 at 7:01 PM, Petter Urkedal <[email protected]> wrote: > > On 2009-10-12, Timothy Normand Miller wrote: > >> There are two ways to handle the stall when waiting on memory data. > >> One is to implicitly issue an instruction that does nothing. The > >> other is to have a "valid" flag that accompanies each instruction. > >> They're essentially identical in principle, and we should do whichever > >> is simpler and smaller (which is probably the former, so I'm going > >> with that until convinced otherwise). > > > > There is another fine detail which I mentioned. When there are several > > pending loads for a certain pipeline, we may allow the pipeline to > > reschedule the first to finish in place of the first hole which is about > > to reenter the pipeline. If we use this minor optimisation, then it's > > most natural to pass down a "noop". > > I don't understand what you're saying.
To put it another way, the memory unit has the ability to reorder threads from a pipeline when the pipeline has more than one pending load. The simplest N-deep pipeline fetch back the same thread in the hole which was created, thus maintaining the relation between the pipeline-local thread ID and the cycle number modulo N. In that case the pipeline-local thread ID is a simple counter in FETCH. If, OTOH, we want to plan ahead to support extra threads, we better pass the pipeline-local thread ID down the pipeline, which allows us to reorder threads within the same pipeline. Then there is no thread associated with a synthetic noop. Anyway, this is too many detail at this stage. > Let's say there are 8 pipeline stages. We'll create 8 or more time > slots (cycles), one slot for each simultaneous task assigned to the > shader. Initially, if a task is stalled waiting on a read, we simply > issue nops during the cycles assigned to that task. Later, we can > consider adding more tasks so that if some task is stalled we can skip > over it and issue another task's instruction in that cycle. Yes. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
