On Mon, 4 Oct 1999, Andreas Beck wrote:
[snip]
> > Want to help writing 3D accelleration in the KGIcon S3 Virge driver ?
>
> BTW: When designing new 3D ioctls, could you check with Jon and me ?
> We probably have manuals for other designs at hand and it might be helpful
> for finding a really generic interface.
I guess since people besides myself are starting to work on this
stuff, we should start get this stuff nailed down. I therefore propose
the following new kgicommand API extension, based on the quick 'n dirty
ioctl API I wrote for my Savage4 driver, plus some other things I think
might need adding to KGI in general in order to fill in a few gaps:
**************************************************************************
CHIPSET_MAPBUFFER: Creates or changes a kgi_mmio_region mapping (contexts,
z/w/texture/etc auxbuffers, command interfaces). Synchronous callbacks of
some type from the chipset driver to fbcon-kgi.c will be necessary to
change the kgiproc mappings.
**************************************************************************
CHIPSET_MAPSELECTOR: Creates or changes a selector mapping for the kgiproc
mapper to use when creating files that userspace can select() on to wait
for any hardware or driver-internal events (interrupts, timers,
conditionals, remap events) or event pipes (async buffer-flips,
performance monitors, etc) that the driver wishes to export notification
of to userspace. I am not sure if it is appropriate to use kgi_events for
this....
**************************************************************************
MULTI_SETCOMPOSEMODE: Hardware windowing (STREAMS, TV cards, etc.).
Probably needs to work in a setmode/getmode synthesis PLL also. We'll
need an additional level of viewport abstraction in KGI to handle this
properly. IMHO the new viewport data should go in the kgi_device struct.
It should be small and simple, something like this:
struct kgi_viewport
{
kgi_viewport *next; /* Linked list of viewports */
kgi_coord ul, lr; /* Physical dimensions of viewport */
kgi_display *dpy; /* Bound display struct */
int zorder; /* z-order */
}
**************************************************************************
ACCEL_DRAWPRIMITVE: Basic triangle/strip/fan/quad/etc drawing. Since KGI
is compiled into every driver module, we should be able to easily build
driver-specific primitive support into the abstract typing and namespaces.
Input data should look something like this:
struct kgi_primitive
{
KGI_PRIMTYPE type; /* tri/strip/fan/quad/etc */
union primdata
{
#if KGI_PRIM_HAS_FVFTRI
/* ... D3D flexible vertex format triangle info */
#endif
/* ... other standard kgi primitive types info ... */
#include "driver_prims.h"
/* ... #included driver-specific primitives info ... */
}
}
**************************************************************************
ACCEL_DRAWINDEXEDPRIMITIVE: Buffered primitive arrays/lists, looking
something like this:
struct kgi_primitive_buffer
{
KGI_PRIMBUFTYPE type; /* pointers or data, fixed or variable
/* field size, fixed or variable primitive
* types, etc. */
struct kgi_mmio_region *primbuf; /* Physical buffer region */
}
**************************************************************************
ACCEL_FLUSH: Generic flush-button for 2D, 3D, texture, etc. It would also
be nice to be able to construct dependency-trees for flushing mutiple
flush contexts atomically in the kernel. Again, this requires another
small struct type be added to KGI:
struct kgi_fc /* Flush context */
{
void *flushhook; /* This is how we do() it */
int synctype; /* SYNC or ASYNC */
struct kgi_fc *next, *child; /* Dependency tree */
}
These flush contexts could be attached to any kgi struct which
contains data that could reasonably be said to be "flushable". The reason
that we need to abstract the flushing stuff so much is that it varies
wildly from chipset to chipset. We need to embed the units of hardware
state (kgi_mmio_regions) into a dependency graph in order to represent the
real programming-order dependencies of the hardware.
**************************************************************************
ACCEL_COMMAND: For sending higher-level (i.e. OpenGL) commands which can
be handled directly by the hardware. Handled much as kgi_primitives are.
**************************************************************************
ACCEL_INDEXEDCOMMAND: Buffered commands arrays/lists, handled similarly to
buffered primitives.
**************************************************************************
Feedback is appreciated. This modest and mostly unobtrusive set
of addition to the base kgicommand set and abstraction system should allow
us to support essentially all hardware released to date and for at least a
year or two ahead. KGI 0.9 should be up and running well before then,
which will solve all these static interface related problems for good.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
