> > A big problem I've found with the GGI project is that noone really knows
> > how acceleration -should- be handled between kernel and userspace.
>
> Shared memory is the way to go. I think the general idea, though,
> since KGI will be multi-architecture, is to develop the metalanguage
> for the chipset separate from the method used to transfer it, and
> then KGI's core implements the methods that work best (or at all) for
> the OS/arch you are running. There may be a couple of places where it's
> advantageous to change the metalanguage to take advantage of a faster
> pipe, but not many.
I will try to get a document together explaining the details of KGI-0.9
accel handling this week. Unfortunately I have not time at the moment
to dive into details:
The basic idea is that applications and accelerators run fully
(ideal case) decoupled from each other. This is achieved by the
application filling DMA buffers, the drivers executing them and handling
context switches and the KGI core and mapping code taking care of the
synchronization. The latency to start a buffer execution is
basically a page-fault.
I started debugging this with the Permedia2 driver, but have a little
lack of time and a problem with the synchronization.
Nothing unresolvable, though.
So, the 'custom-API' -> KGI-driver API translation is completely left
to userspace.
> > Some issues I can think of:
> > - Some cards have -very- good DMA support (I think the permedia,
> > 3Dfx, and some others fall into this category but I'm not sure)
> > : these should be easy to code potentially and most work will be
> > done in userspace
Correct.
> > - Some cards are -dangerous- for DMA work but doable, some sort of
> > translation IP-stack-style would probably be good (S3 ViRGE comes to
> > mind here)
Two possiblities: a) trust the library, b) driver has to do security checks.
> > - Some cards are strictly PIO-based. Mostly old pre-3D cards really
> > ioctls work well here
> > : this is the current working accel format as far as I know.
> > Don't expect impressive performance, switching between kernel
> > and userspace has a fare bit of delay... but for a complex
> > accel this should work well.
>
> These issues really all pertain simply to the implementation of
> the KGI metalanguage -- that is, what kind of commands are allowed
> through the boundary between the driver and the app.
As for memory mapped I/O regions: fully device dependent.
As for accelerator command stream definition: fully device dependent.
KGI "only" provides the OS dependent services and 'glues' the application
and drivers together.
> (BTW Steffen,
> how hard to add support for a Permedia1? Those are available to me
> cheap.)
Not very. Mainly support for the DAC (TVP3026 or IBM <somenumber>).
The trickier thing is the delta support. What DAC's are on them?
Steffen
----------------- e-mail: [EMAIL PROTECTED] -----------------
