Index: [thread] [date] [subject] [author]
  From: Brian S. Julin <bri@tull.umassp.edu>
  To  : James Simmons <jsimmons@edgeglobal.com>
  Date: Wed, 4 Aug 1999 23:30:27 -0400 (EDT)

Re: Accels and /dev/gfx.

On Wed, 4 Aug 1999, James Simmons wrote:

>    As for the flushing of the accel commands before the ping pong buffers
> are full. I saw alot of people discussing a a ioctl for this. Why? Did you
> forget about msync?
Yep.. didn't know about that... but Steffen pointed out a better way even
than this -- to flush you access the mapped out page at the page base +
the offset in the mapped page, and this way you tell the kernel how far 
into the page you were (0 offset as an exception means the page was full.)
Clever stuff, Steffen. :)

Making a fake accel buffer has it's appeal, but the kernel driver
would then have to figure out which registers were changed and load
them, more expensive than taking index,value pairs.

But all this has me concerned we are missing the potential of SMP and
IRQ driven psuedo-simultaneous access to the command queue.  Under an
SMP system one processor could load the accel engine while the other was
in userspace running the graphics program.  Under single processor,
during any IRQ the kernel could flush some or all of the command queue
and save a context switch for the app.  The problem here is beyond my
expertise -- how to semaphore the data so the processors/threads/whatever
are in sync about what commands are complete.

It is also probably worth looking into to have one buffer with semaphore
and index info and the other with data, so that the data gets to the kernel
in a DMA-ready format.  Then you have to worry about not letting the app
modify the data during DMA though.

Re: the VC switching stuff -- still would be nice to switch between apps;
not every app will use 56M of memory.  But that's something to worry about
in the future. Something like allocating a max amount of swap/disk used for
screen data might be the best....facility DMA up to that amount that direct
to disk if the app requests it, then block new app on the DMA engine till 
it's free would be optimal when hardware supports it.

--
Brian

Index: [thread] [date] [subject] [author]