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