On Mon, 13 Dec 1999, James Simmons wrote:
>
> > > If not what
> > > features do you feel libGGI lacks to have this happen?
> > >
> > > Also can libGGI handle DMA transfers, AGP?
> >
> > LibGGI can handle anything the hardware supports, it's a SMOP.
> > There are currently no such features implemented for any target.
>
> How would one go about implementing DMA transfers to do things like draw a
> object thats textured mapped in libGGI?
The DMA part is handled in the device driver code. Presumably,
one you get to the usersapce LibGGI level you'll just be firing ioctls at
the driver, bursting command words, mmap()ing files, etc. The physical
DMA handling will be completely hidden from the user-level code, as it
should be.
So, your user level code will consist of:
* A base LibGGI target which manages the per-target resources
(DirectBuffers, non-muxed filemappings, locking/synchronization handling,
etc).
* If necessary, some helperlib code for your base target to deal with more
subtle variances in the same overall target framework, like DirectX
Immediate Mode vs. Retained Mode or DirectX 3 vs. DirectX 5/6 vs. DirectX
7.
* The extension library target/helper code. This code will be much more
high-level and abstract than the base LibGGI/LibGII taget code. For
example, the GGIMesa KGI target code should not directly map hardware
buffers, but should instead traverse the already-generated list of DBs
which is attached to the current visual structure.
> Should I just look in detail at
> Mesa-GGI?
Yes, and the general concept of LibGGI extensions. GGIMesa will
not be the only layer on top of LibGGI.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
