> On 4/18/06, Nicolas Boulay <nicolas.boulay@etherale.org> wrote:
> > Le mardi 18 Avril 2006 22:45, Timothy Miller a écrit :
> > > On 4/18/06, Nicolas Boulay <nico@seul.org> 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
>
Open-graphics@duskglow.com
>
http://lists.duskglow.com/mailman/listinfo/open-graphics
> List service provided by Duskglow Consulting, LLC (
www.duskglow.com)
>