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. > > (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. 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)
