Hi Andreas,
On Wed, Mar 05, 2003 at 01:25:02AM +0100, Andreas Karrenbauer wrote:
> Hello,
>
> I've attached some patches for the Savage ddx and the drm. The drm
> supports two basic ioctls right now. The output in the XFree86.0.log
> gives me now
>
> [...]
>
> But that doesn't mean that we have direct rendering yet. There are lots
> of thing to do. So, I hope that I get any feedback from some experienced
> developers what to do next. Actually, I am a bit stuck with this BCI
> thing. The SavagePtr structure has had a field called
> unsigned char* BciMem;
> which is also used in the 2D driver. Is this the correct address for
> mapping the bci region?
> I am also confused about the naming: bci/cob/ring. I think I messed this
> since I have simply copied and pasted from the radeon driver.
Ok, let's start with some background info (I don't know this for a fact,
please correct me if I'm wrong): 2D cards started by having a small FIFO
buffer for the 2D commands so that the CPU could send a resonable number
of commands without having permanetyly pooling the card for idle. With
the comming of 3D the ammount of command data sent to the cards
increased substantially so another level (bigger) of buffering was
required. The BCI(Burst Command Interface)+COB(Command Overflow Buffer)
in Savage, or the CP (Command Processor (?)) in Radeon, or the Circular
Buffer in Mach64, the Primary DMA buffer in MGA are, loosely speaking,
all such higher level buffers. As you can notice by their name, some
imply data is stored in a circular manner so are usually revered as
"ring buffers".
FIFO (First In First Out), ring buffers, circular buffers, strictly
speaking, refer to the same data structure learned in Computer Science -
the queue buffer. So the difference is artificial.
Now, back to the Savage reality: you can consider the COB as a ring
buffer - it's buffer where the commands are stored in a circular manner.
But the difference with several other cards (specifically the Radeon)
is that it's not the CPU the one who writes to that ring buffer - it's
the card. The CPU writes commands the to the BCI memory region, and if
the chip's
In reality Savage has several internal FIFOS plus this external ring
buffer:
(commands)
CPU------------>BCI region
(not real memory)
|
| (if BCI FIFO is full)
+---------------------+
| |
| v
| COB (it's in framebuffer memory)
| |
BCI FIFO ----------------+
(32 slot)
|
|
(PIO) v
CPU--------------->+-----------------+--->2D FIFO
^ |
| +--->3D FIFO
MMIO Region |
(not real memory) +--->...
^
(also commands) |
CPU----------------+
>From the picture above you notice that the CPU doesn't access the COB
directly, but only the BCI region and MMIO regions (PIO is irrelevant
for our purposes), and those are the only regions we need to map into
the DRM. Unfortunately we can't map those regions into the clients
because they're too powerfull, but that power (to read/write system
memory) is handy for other things later on.
> Any feedback is appreciated. Especially about what to do next.
First thing is to remove references to the ring* variables in DRM and
DDX!
After that we need to define the macros for MMIO in DRM and write some
utility functions for stuff like "wait for card is idle". Both these
things can be based on what is done on the existing DDX driver.
After this we need to tackle the SAREA: what stuff should be there (the
3D state registers most likely) and write a simple IOCTL in the DRM to
dispatch a vertex data buffer (via MMIO now). At this point we should be
able to write a simple test program which opens the DRM and draws some
triangles on the screen. That would be another great milestone! ;-)
José Fonseca
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
