On Tue, 5 Oct 1999, Jos Hulzink wrote:
> On Mon, 4 Oct 1999, Andreas Beck wrote:
>
> > 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 sure can. But this means that we're gonna try to create a chipset
> independent 3D ioctl set after all ? IIRC this mailinglist once said that
> this was not done, for chipsets differ too much.
It cannot be done for all features, and especially it is hard to
support strange features like PowerVR infinite planes or parametric surfaces.
But for triangle-based hardware and OpenGL-based hardware, it is not too hard
to whip up a quick 'n dirty interface that should work just fine until KGI
0.9 arrives and we can easily give each card its own interface without
bloating the (single, unified) command space we all have to work with now.
> I think the 3D basics can
> be done by generic ioctl.
Yes.
> First thing to get anything working is that I must be able to pass 3D
> points, lines and triangles through the ioctl interface, so I think I'll
> start with proposing some definitions in kgicon/include/kgi/kgi_commands.h:
>
> struct kgi_3dpnt {int x,y,z; };
> struct kgi_3dline {int x,y,z,w,h,d};
> struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
The 3dline, 3dpoint issue is not yet clear in my head. I am not sure
if we should support these, as not all hardware supports them and most that
do just thunk to degenerate triangles internally. Hm... well, I suppore that
it would not hurt us to support these in any case.
> Problem I got with these is that 3dline uses width heigth depth (relative
> endpoint) while 3dtriangle uses absolute coordinates. Question: Is it OK
> that the Z value is an integer ?
No. Most modern cards use 32-bit floats, and some can also use
fixed-point with a variable mantissa value for extra precision. Also there
is often 16-bit and 32-bit options for the z-buffer as well. All of this
must be variable somehow. This is where the cross-platform issues come back
to bite us... we may need to use unions or somthing to get around this, or
decide to always use 32-bit floats and take the speed hit when we have to
thunk in the driver.
> Second thing I have been thinking about is that the current interface
> doesn't work with ping pong buffers: Colours are not modified by an IOCTL,
> but by reading the colours from the struct kgi_graphic, that is passed to
> the kgim_accel_command procedure. If ping pong buffers are used, there may
> be a huge delay between the moment the command is loaded into the PP
> buffer, and the moment the kgim_accel_command is called. (For the PP
> buffer is filled completely first). The value of gr->gc->fg_color is
> rather undefined when kgim_accel_command is called, for it may have been
> modified by other commands.
Yes, and this is exactly what happens. If you run demo.c with PP
buffers enabled, you will see normal behavior during the 'zigzag boxes'
demo (SYNC mode), but at the end in the ASYNC demo, you will see the
color change every N boxes.
Andy and I discussed this at length on the thread titled "Ping-pong
buffers on kgicon are here", on 8-18-1999 in the list archives. In
particular, Andy made a couple of excellent posts regarding the right way to
synchronize accels and the GC in ASYNC mode, as well as how to properly track
write pointers in PP buffering for maximum speed. Good stuff.
> My conclusion here is that there must come something like ACCEL_SETCOLOR.
> Maybe not only foreground and background colours, but also fogging, light
> colours ?
Any "back-end" state (state info which does not change with every
primitive) should be mapped into the GC, so we do not have to code
special-cases for every type of state info or flush condition into the API.
See my other post on how I propose to deal with abstracting the state flush
logic.
> ----
> Next I've been thinking about is that there are missing
> "ACCEL_SETCLIPPINGRECT" and "ACCEL_RESETCLIPPINGRECT", for the
> accellerator engine must know the clipping region too.
That is already in the GC, for 2D stuff.
> ----
> I was also thinking that it is a pity that there is a KGICOMMAND for
> standard 2D lines and 2D boxes, but that we need another KGICOMMAND for
> the same 2D lines and 2D boxes with ROP (those logical operations) or
> bit/pixmaps.
Well, usually these are different accel-ops in the hardware, so why
should we not handle them with separate kgicommands? We have enough
kgicommand ioctl space left to play with that I do not think it will hurt
us to flesh out the support for 2D accels a bit more. We could add:
ACCEL_DRAWBOXROP
ACCEL_DRAWLINEROP
ACCEL_COPYBOXROP
ACCEL_FILLPAT
ACCEL_DRAWTEXT (yes, newer HW accels this)
...and so on. And we could remove ACCEL_DRAWCIRCLE, as I have never
seen HW which draws accelerated circles |->.
> I think it is okay that the bit/pixmaps drawing remains
> separated, but a normal line is nothing but a line with the correct ROP
>
> I saw some logical operation definitions somewhere in a GGI header file (I
> forgot where). I think it is a pity that the defined numbers don't match
> the ROP numbers.
I support Microsoft's ROP16 and ROP256 standards in my Savage4
driver, for they are built into the hardware itself. But once again, this is
a cross-platform issue, and we really cannot deal with it properly until KGI
0.9. For now we must hack this into the KGI interface in as clean a manner
as possible and not worry about it too much.
I deal with this in Savage4 by taking advantage of the fact that
fbcon-kgi.c must be compiled into every driver module, and as such it is
possible to support driver-specific kgicommands with driver-specific data.
This adds bloat when multiheading, though, as well as introducing the
possibility that ACCEL_DRAWTRIANGLE on one card might not be the same ioctl
number as ACCEL_DRAWTRIANGLE on another card. Would this be a real-world
problem? I don't know. Maybe it would just be easier to give up on
standardizing 3D accels until KGI 0.9.
It would be nice if we could somehow pass the kgicommand tokens and
data through separate pipes, so that the command data format would not have
to be hard-wired into the KGI API itself. This would fix the above problem
quite nicely - the driver itself would "eat" the correct number of bytes out
of the command-data buffer, so the fbcon-kgi.c would not need to know that
info. Also, this would allow for many more kgicommands per ping-pong buffer,
and they would all be the same length (32bits per command, 32bits per pointer
into the data buffer), which would make command processing more efficient by
A) removing the need to handle command fragments, and B) keeping the physical
PP command buffer pages smaller. HMMMMMM... the more I think about this, the
more I like it! Modern video chipsets use indexed primitive and vertex
buffers this way, and it works quite well for keeping command buffer traffic
down. Anyway, something to consider for the future.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
