On Thu, 17 Mar 2005 19:51:42 -0500
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Thursday 17 March 2005 16:37, Attila Kinali wrote:
> > > > * There is no advantage to being able to reuse consumed pages
> > > > in random order versus a fixed order
> >
> > It doesn't matter. A driver will always have to determine whether
> > it can reuse a certain page or not. Thus it doesn't matter
> > whether it goes trough a linear list or a linked list.
>
> Do you grok the concept of a ring buffer?
Looks like i do not.
Are there any good docu/webpages/books to read about this stuff ?
My knowledge i have currently is based on what i know from
VGA programming way back in DOS days and a little bit from
mga_vid coding.
> > > > * Another way to grow/shrink the ring buffer is to have a
> > > > predefined list of pages as I described earlier
> >
> > Which will fail if you cannot reserve the buffer at startup -> bad
> > thing[tm]
>
> Wrong, the "list of pages" is exactly what prevents this.
Then i didnt understand that either. Sorry.
> > > > * This is more complicated for the driver than a simple,
> > > > virtually contiguous buffer
> >
> > Actually, all solutions i've seen so far are too complicated.
>
> Then I simply didn't explain clearly. The ring buffer scheme (even with
> definable physical page vector) is pretty much as simple as it gets.
> It needs the following PIO registers:
>
> - Head register: The ring buffer offset from which the card will
> next read an indirect DMA command.
>
> - Tail register: The ring buffer offset where the kernel driver
> will next write an indirect DMA command.
>
> - Threshold register: The threshold below which the card will
> generate a buffer low interrupt.
>
> As opposed to having a single physical base register for the command
> ring buffer (the classic arrangement) there is a table of physical
> pages, which I suggested can be just one page for the initial rev
> (sufficient for a PCI card).
Do i understand it correctly, that the head register is
the "source" and the tail register the "destination" ?
Or do i completely missunderstand your concept ?
BTW: how about replacing the threshold register by a
DMA command that triggers an interrup ? Then it would
be possible to insert interrupts at any arbitrary point
("drawing operation X has been completed") or leave it
completely away if no interrupt is needed (when the driver
is sure that the operation will finish before it will send
the next commands).
> That's it: three PIO registers, two command/status bits and a four-bit
> command/status field. We press the cursor upload mechanism into double
> duty, a nicety I'm rather fond of.
Juup, looks good.
> > I'd like to have a bus system that "just knows" my virtual
> > adresses so that i just can tell you where my data stats,
> > how much it has to read and where to store it.
>
> This sounds like a whole bunch of hardware and a potential breeding
> place for bugs.
Actualy, it need's to be supported by the bus system itself.
AFAIK only sbus and some bus systems of mainframe type machines
support this. In no way did i mean that we should implement something
like this. It was just a definition of my "heaven". "Just give
a source, a destination and a length and let the hardware handle
the rest".
> I should reiterate what we are avoiding with the proposed ring buffer
> interface: a fullblown and wooly scatter/gather DMA interface.
How does a scatter/gather DMA interface work ? I thought
it was just a list of "get the blocks from there in this
order and place them over there", or am i wrong ?
Maybe i should wait for the DMA draft to be finished.
Might clear up a few things.
Attila Kinali
--
éãåããéãåã
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
