On Tue, 5 Oct 1999, Jon M. Taylor wrote:
> On Tue, 5 Oct 1999, Jos Hulzink wrote:
>
> > 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.
Hmmm... seems the Z buffer stuff is going to be a hard one. ViRGE Z buffer
is always 16 bit fixedpoint. (See other mail) In libs like GGIMesa &
LinGGI3D we'll have to provide a generic Z variable anyway, and for there
are several libs that use 3D accelleration, I think the KGI(con) driver
should convert some generic Z variable in a thing the accellerator can
handle. Remains the question: what is a good definition for the Z-buffer
values ?
>
> > 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.
Are PP buffers with KGIcon working again ? Last thing I heard was that
they are broken.
> 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.
>
Hmm I missed that one, so please tell me if I'm making no sense.
> > 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.
I do not completely agree with that. BECAUSE this stuff doesn't change
with every primitive, it is a pity that the accelleration driver has to check
all "back-end" states before launching an accelleration command. At the
moment, we have to deal with at least 6 checks already:
1) Foreground colour
2) Background colour
3) Clipping rect top
4) Clipping rect bottom
5) Clipping rect left
6) Clipping rect right
Indeed, still not much with current CPU power, but it seems to me that
-using PP buffers- it is faster to use an API-call. besides, the syncing
problem is gone. (I don't see how line / box drawing can be used in ASYNC
mode now, but I'll start digging the mail-history)
> > 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.
See above...
> > 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)
Okay, I'll add them soon. Things I'm thinking of:
1) How to pass the ROPs ? - By adding a "int rop" to kgi_box,
kgi_cbox and friends, or by defining new structs like kgi_rop_box or
something ?
2) How to pass the pattern for ACCEL_FILLPAT ?
> ...and so on. And we could remove ACCEL_DRAWCIRCLE, as I have never
> seen HW which draws accelerated circles |->.
And besides, who ever uses a huge amount of circles, for other reasons
than to show how fast circle drawing is ? :) I'll remove it (don't forget
to clean up all ACCEL drivers...)
> > 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.
ROP16 ? Never heard of that one... I guess we best add support for ROP256
and someday map ROP16 on ROP256 ? Or are my thoughts on ROP16 wrong ?
> 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.
I'm cleaning up my driver to be KGI0.9 compatible... It will take some
more time :(
>
> 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.
Cool ! Nice thinking ! *sigh* can't we just shutdown normal life for a few
weeks so we can spend all our time to working on this ?
I can't wait for the moment I play Quake II(I) accellerated om my Linux
console...
Jos
