> On 4/18/06, Nicolas Boulay <[EMAIL PROTECTED]> wrote: >> Le mardi 18 Avril 2006 22:45, Timothy Miller a écrit : >> > On 4/18/06, Nicolas Boulay <[EMAIL PROTECTED]> wrote: >> > > Even worst : how do you manage the variable latency of a memory read >> ? >> > >> > Two ways: >> > >> > (1) Stall on attempt to read from empty read response queue. >> >> It's never empty. It contain the previous read. > > Why would you implement it this way? If you have an outstanding read, > you'll get out of sequence and cause all sorts of havoc. >
You can not see the output register of the load and store unit as a read register. But as a stack that is empty for each read. That's different for a compiler. >> > (2) Branch on status flag >> >> To make an active wait ? > > Yes. > > You probably wouldn't want to write an algorithm that did something > different depending on whether or not data was available, so you'd end > up just spinning on the branch instruction. When data is streaming, > that's a wasted instruction for every read (because you always have to > check). It's better to just schedule the read as far after the > request as you can and just stall when it's not available yet. It look so much easier to just write the result when it's available in a destination register with a scoreboard that block any read of this precise register... So could easly hide the latency without any software modification and quite little hardware change. > > Also if we're not careful, we'll think too single-threaded here. > Every fragment shader needs to be split into two pipelined threads. > One thread's output is the input to the other one, and there's a fifo > in between them. Either thread can do anything, but generally, when > there are memory reads to be done (texture stuff, etc.), one thread's > job is to make requests, while the other is the consumer of that > requested data. All other work should just get split intelligently. > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
