Hi Jon !
> > I already _do_ have an accelerated implementation for plain triangles
> > for my Permedia 2 chip. However it's pretty much dormant right now, as
> > you'd have to use the raw command interface to make use of it now.
> You know Steffen and I are working on that PM2 driver for the new
> KGI, right? Can we use that code?
Yeah sure. Though you knew. It in CVS ...
I will probably add VideoIO support for my ELSA Winner 2000 Office soon
as well, as I feel some need for it. This is however done using external
Chips from Philips. I already have working Code that just runs SUID.
> Yes. The /proc/gfx[N] code in the current CVS (disabled now)
> allows you to do this for KGIcon drivers. For each head number N, a
> /proc/gfx[N] directory is created. Inside each directory are files, some
> of which you can open() and then mmap() to expose a hardware buffer. I
> exposed every buffer the Savage4 could export (front, back, z, stencil,
> texture0, texture1, DMA command FIFO, MMIO command FIFO, you name it) in
> this fashion. These days we would probably ditch /proc in favor of devfs,
> but the principle would be mostly the same.
Yep. Good thing. Also enumerates the available buffers.
> One thing that sucked was that all the mappings were static. I
> chopped the 32MB video memory into a good common layout, generated a
> static list of kgi_mmio_regions to match, and got it to work in GGIMesa
> for textures.
Not really good, but that's just a question of some fine tuning.
> Mesa's device driver intraface didn't support physical z or
> stencil buffers at the time either, so I had to give up on those
> altogether, but otherwise it worked perfectly and I was happy. I don't
> think I ever tried having multiple processes open() and mmap() the exposed
> buffers, and I never figured out a good way to virtualize the exposed
> hardware resource mappings.
That can be taken care of using the methods I developed for the old "scrdrv"
releases of GGI. It's basically a question of invalidating all mappings
when another process accesses a mapping.
> resource // Generic untyped resource, like we have now
>
> You (hopefully) get the idea. A system like the one described
> above would have many advantages. In particular, it would require only
> one minimal change the base LibGGI API. All we need to do is extend the
> ggiResourceXYZ functions to take one more parameter, which is a namespace
> string.
This isn't quite correct. The current ResourceXYZ functions are for acquiring
and releasing _access_ to a ressource. Not quite for allocating/freeing it.
We would need a few more functions to make this distinction.
Another point about it is mode setup feature negotiation should be possible
before and after mode setup, and it should be possible to indicate, that
a feature is possible, but it would require re-setting the mode.
> This scheme would distribute the necessary intelligence to parse
> and understand the resource type strings only to the code which needs to
> understand that part of the namespace.
Yes. I perfectly agree with that thought. IMHO you should just be able to
query all possible features/resources and then pick those you are interested
in.
> The simple top-level resource strings (resource-lock, resource-db,
> resource-target, etc) can be easily handled by LibGGI.
As said, this is a little tricky, as the current function work on already
allocated ressources and just arbitrate access.
> When it becomes necessary to extend those strings to
> be able to handle target-specific or extension-specific resources or
> resource categories (e.g. resource-db-z-16bit), only the target or
> extension (or extension target) code which needs to understand what that
> last '-z-16bit' really means will have to deal with it.
Correct.
> GGIMesa would need to know what a z-buffer is, and what is the difference
> between a 16 bit z-buffer and other types of z-buffers, but LibGGI itself
> would not have to know anything beyond "there is a type of resource called
> a DirectBuffer".
Yes. Please have a look at SANE (http://www.mostang.com/sane/). It pretty
much does what you want including enumerating available resources(your term)/
features(mine)/options(SANE), getting their current state and modifying it.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
