On 3/16/07, Daniel Rozsnyó <[EMAIL PROTECTED]> wrote:
Timothy Normand Miller wrote:
> It won't be long before we'll have to design a nanocontroller for OGD1
> to manage VGA and DMA. I may be able to just go off and design one
> myself, but I think that many of you would fancy observing and
> participating in the design process, and with more brains on it, we'd
> do a better job.
...
...
Ok, I've read your whole idea.. and I have a question regarding the
memory access:
- is the DMA "hw accelerated", so that this new core will set only
addresses for fragments and the transfer is done automatically, you only
do the calculation of sizes because of interrupted pci tranfers?
This one. I thought about and thought about it, and I decided that
making the CPU baby-sit the DMA would require way too much overhead.
One of my original ideas was to have the PCI master handle individual
transactions, but if the target (the host chipset in this case) were
to terminate the transaction, then our CPU would have to catch it,
recompute the address, and restart. But I decided that a relatively
small enhancement to the state machine for the master would save a
huge amount of trouble in the end.
My plan, at this point, is to decide on some boundary that the CPU is
not allowed to ask the master to cross. Let's say it's 256-byte
boundaries (which is the case for the target at the moment). This
way, we can limit the number of bits in the address counter in the
master, keeping the clock rate up. If something needs to cross the
boundary, then the CPU will just have to issue more requests.
With this approach, the CPU can just toss sets of requests into a
queue and trust that they'll happen (short or something catastrophic).
Then, it can use what limited processing power it has to do useful
things like unpack engine command packets into register writes, etc.
And one more: For what else will it be used? I understand the VGA
emulation (address mapping, maybe pixel resizing),
For 640x480x16, there's weird stuff it has to do, in that reads and
writes are not straightforward. We have to emulate that. Both reads
and writes have to be processed through the CPU.
For 80x25 text mode, what I think we'll want to translate from text to
bitmap characters in the background. (We could do it on the way in,
but if the font changes, we want all corresponding characters to
change immediately.)
DMA (either of
above), but the core seems to be more complex than a nano. Is that the
last/main controller, and the rest of OGD1 will be more like hw (fixed
function units) ?
This CPU won't have the sophistication to do anything like vertex
processing. What I'm proposing is a very simple design. We could do
a simpler 8-bit design, but then we couldn't keep up with the data
flow through PCI.
It would be better to start with a list of things to be controlled by
it,
True. We don't want to get ahead of ourselves.
than designing it first and then attaching other modules. If there
is already such a list, please drop the url here.
We need to collect this list.
Here's a few things it'll do:
- Do translation for VGA text and graphics modes.
- Manage data transfers for copies between host memory and graphics
memory (image up/downloads)
- Unpack GPU command packets into GPU register writes.
For the last one... a lot of GPU operations will typical come with a
number of specific attributes that have to be set, but not always. So
in the header, we have some bit-flags that indicate which attributes
are included in the packet. That makes the packet variable-sized.
More complex than that, we could possibly include "2D" commands. Some
2D ops would be done through the 3D engine, and that requires more
setup than you typically see in a 2D engine. We can hide that setup
by having our CPU do it. This is mostly to get a speed boost by
reducing the required PCI bandwidth.
Bug work-arounds that would require a lot of PCI overhead could be handled here.
Some management of race conditions could be handled here. For
instance, our CPU could wait for the 2D blt engine to finish before
issuing a 3D command, making it appear seamless to the host, reducing
overhead considerably.
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Favorite book: The Design of Everyday Things, Donald A. Norman, ISBN
0-465-06710-7
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
