Timothy Miller wrote:
On 7/20/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
Timothy Miller wrote:
> On 7/20/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
>
>> A major consideration is what the GPU is going to do regarding
>> pipelining. A pipelined read is going to have (I think) minimum:
>>
>> 1/2 clock after address generation for row address compare
>>
>> 3 clocks for CAS Latency.
>>
>> 1/2 clock to get the data to the GPU for the first 4 pixels (or 32
>> bytes).
>>
>> The 1/2 clocks may be overly optimistic.
>>
>> Then getting the second 4 pixels or (32 bytes) could overlap
>> address output for the next read.
>>
>> How many pixels will the GPU process at once?
>>
>> Will it be able to generate an address each clock (200 MHz)?
>
> In the Spartan, the GPU is unlikely to run at 200MHz. We'll get the
> speed from the ASIC.
This is important to the selection of memory access methods. If the GPU
can't keep the pipeline full, it might be better to interleave the
screen refresh.
In fact, they will be interleaved.
> But in any case, the basic design of the GPU separates read request
> generation from read data receipt. In between those two units is a
> fifo that absorbs the read latency.
I don't see a FIFO absorbing negative time, so I must be missing
something. Pipelining requires that the address be issued before the
data time. The memory controller needs a FIFO to remember what to do
with the address when it comes up in the memory.
Unit REQ sends a request to the memory controller (an address) (fifo A).
I didn't consider that a FIFO would be needed here.
Unit REQ also puts appropriate metadata into a queue (fifo B).
Yes, I understand that the memory controller needs a FIFO with what you
called "metadate" (r/w, which_bus_master, etc.) to determine what to do
when that address comes up.
Unit RCV waits until metadata arrives in the queue (B) and matching
read data has arrived from the memory controller (fifo C). When that
happens, it dequeues them and goes on.
I was just thinking that the controller would raise a signal telling the
bus master that the data was available/requested. If memory access is
sequential (not out of order) there shouldn't be a need for score-boarding.
With this design, we can get <fifo-length> requests ahead of the
memory controller, absorbing pipeline and CAS latency, along with
somewhat reducing the impact of row misses.
Are you talking about accessing the memory out of order? This isn't
going to be "simple". There is nothing that is going to absorb CAS
latency, and I don't see that getting ahead is necessary. Actually, I
was concerned that there might be a problem getting the address 4 to 6
clocks before the data was needed. I don't see that there is anything
that can be done about row misses without going to out of order memory
access.
It is true that if you have several addresses ahead that you could
predict a row miss, but the logic would be very messy.
> Deep pipelining and fifos will probably have the GPU effectively
> processing a few hundred pixels at once, at least.
I don't appear to have been clear. How *wide* with the GPU be? How
many pixels will it process in parallel? Not how many will be in the
pipeline and cache total. My thought is that if the GPU and the memory
bus are not the same width that you would need a very small cache
between them. Perhaps this would be a good idea in any case.
The intended width is two pixels. For simple solid fills, the GPU
won't be able to saturate the memory bandwidth. If you use a few 3D
features, the total demand will exceed memory bandwidth, and the
arbiter can (by virtue of having lots of different types of pending
requests queued up) process accesses in bulk, minimizing the impact of
row misses and keeping all memory controllers maximally busy all of
the time.
Thanks for the info. I think that I am wasting your time asking
questions. Do we have a block diagram and a technical description of
how the OGC chip(s) are going to function? This would be very helpful.
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
