On Tue, Oct 13, 2009 at 1:27 PM, Petter Urkedal <[email protected]> wrote: > 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.
Ah. I see what you're saying. I'm in favor of the tagging method. > > 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) > -- 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)
