Re: KGI_COMMANDS, was: Re: Doesn't need vertical retrace!
On Wed, 6 Oct 1999, Andreas Beck wrote:
struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
What about the exta fields (W, specular/diffuse color, texture
coords, vertex fog)?
Extra commands (i.e. DRAW3DTRIANGLE_TEXTURED, *_GORAUD). We'd need to take
up too much bandwidth on PingPong or similar, if we always transfer the
full set.
Not if we used two pipes like I was suggesting
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
Re: Doesn't need vertical retrace!
On 1999/Oct/06, Andreas Beck wrote: screen blinking a lot, I think. Anyway, there is another bigger problem, IMO, that switching to kernel mode, copying data structures, and returning back into user mode, may be too much time, and maybe when the ioctl returns, you haven't enough time to copy your buffer. No. That shouldn't matter much. I once measured a full ioctl round trip on my old 486 to take 600 cycles. Given even that machine (486/66), this gives an extra delay of about 10 microseconds. Shouldn't be the crucial point. If you are drawing objects with little polygons (i.e. a torus with many polygon resolution), where each polygon can take 300 cycles or less, it's very crucial, I think. In fact, in 2D accel, I only draw hlines by hardware when they are more than 100 pixels in length, because if they are shorter, drawing by hardware is mucho more slow (because of the ioctl call?). -- Come to GPUL http://ceu.fi.udc.es/GPUL _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
Re: KGI_COMMANDS, was: Re: Doesn't need vertical retrace!
On Tue, 5 Oct 1999, Andreas Beck wrote:
struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
Comments please !
I don't like this kind of 3dtriangle at all, it needs 9 copies of
data to draw a triangle, maybe it's insignificant when you must call later
ioctl, which surely eats up more cpu. But when you implement multiple
commands (one call for each triangle is very slow), it will be more
significant. I would propose this alternative:
struct kgi_3dvertex { int x,y,z;};
struct kgi_3dtriangle { kgi_3dvertex *v0, *v1, *v2; };
The passing of pointers is undefined for KGI. It is not possible to
transparently pass pointers across protection ring boundaries.
Something similar would be possible, though by allowing a kind of "upload"
of a vertex array that is accessed by (numeric) indexes later on.
However I suppose the above call might be enough for the simple "common
ioctl" layer. If you want to be really fast, you will need a card-specific
communications layer anyway.
Which call ? :)
And... int? Aren't there cards that use float?
Good point. I do not know about cards that use float. Should be pretty rare,
as floats are very expensive to handle and rarely needed, unless the card
has an internal geometry processor.
ViRGE uses some fixedpoint 16 bit value, that's all I know... The format
of this fixpoint value can be modified though (if anyone can tell me the
use of this...) so you can call it floating point :)
However most cards allow for fixedpoint, as this is how they work
internally. Would 16.16 fixedpoint be o.k. ?
Well... All I can say is that on my ViRGE I'd have to drop the fractional
part of the Z value, and create a signed fixpoint value of the integer
part... Still thinking if this would have consequences besides loss of
resolution. I know... I should buy another videocard... :)
Jos
Re: KGI_COMMANDS, was: Re: Doesn't need vertical retrace!
struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
What about the exta fields (W, specular/diffuse color, texture
coords, vertex fog)?
Extra commands (i.e. DRAW3DTRIANGLE_TEXTURED, *_GORAUD). We'd need to take
up too much bandwidth on PingPong or similar, if we always transfer the
full set.
CU, ANdy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Re: Doesn't need vertical retrace!
On Mon, 4 Oct 1999, Jos Hulzink wrote: On Fri, 1 Oct 1999, [iso-8859-1] Rubén wrote: Ah, ok, well, it does what I want, its enough for me. Anyway, I will continue reading docs and learning how to include vertical retrace support into KGIcon, it's best (I have readed the GGI tech. docs, and it seems to be a bit difficult). Actually, most code is already in the KGIcon ViRGE driver to support that. The ViRGE has completely functional vertical retrace interrupt code, but at the moment, nothing is done with it. Reason: I have not seen a mechanism to get the sync to userspace neatly. (Maybe some CHIP_WAITFORRECTRACE ioctl ? We never intended to be real-time, so some while not in retrace schedule (); can do the job here) Perhaps we need a new class of exportable KGI data structures, which can in turn be exported by fbcon-kgi.c's procfs code so that userspace can select() on a file to wait for any interrupt the chip can generate? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: Doesn't need vertical retrace!
On Mon, 4 Oct 1999, [iso-8859-1] Rubén wrote:
On 1999/Oct/04, Jos Hulzink wrote:
into KGIcon, it's best (I have readed the GGI tech. docs, and it seems to be
a bit difficult).
The ViRGE has completely functional vertical retrace interrupt code, but
at the moment, nothing is done with it. Reason: I have not seen a
mechanism to get the sync to userspace neatly. (Maybe some
CHIP_WAITFORRECTRACE ioctl ? We never intended to be real-time, so some
Not, FB has now a good way of use it:
[ /usr/include/linux/fb.h ]
#define FB_ACTIVATE_VBL16 /* activate values on next vbl */
It can be *very* usefull to do page flipping.
*Simple* page flipping, sure. Basic double buffering. But what
if you want to triple-buffer? What if you have to use the vblank
interrupt to balance a FIFO or flush texture state in addition to buffer
swapping? What is needed is full user and kernel level asynchronous
notification and kernel-only callback system.
Modern video chipsets can do quite a bit of stuff with interrupts,
hardware semaphores, AGP fault notification, etc. It seems a shame to
restrict this wonderful generalized capability to the ancient idea of VGA
pageflip-on-vsync. See my other post on 3D KGI ioctls for how I propose
to handle this in KGI.
You still have the
problem of dumping buffers into video memory, but at least, this is
something... I understand that a waitretrace ioctl makes no sense.
It makes sense with manual userspace buffer flipping using VGA
splitline. IIRC, that is what informed the original design. However,
these days the vblank IRQ is just one of many sources of hardware RT
events that can come from a video card, and I do not see why it must be
treated differently or the async notification subsystem should not be
generalized.
Well, let me imagine a bit. Applications has two main ways of
writing his data into video memory, either with page-flipping (very easy to
handle, I think) or with double (triple, ...) buffering, right, or I have
*very* old ideas?.
I have always considered the terms "pageflipping" and "double
buffering" to mean basically the same thing.
So, _maybe_ it would be a good idea if kernel could
handle and dump the memory buffer for you...
You only call the FBIODUMP_BUFFER ioctl, passing as parameter, a
structure like this:
struct kgi_buffer{
void *buffer;
uint16 x0, y0;
uint16 width, height;
}
and the buffer is dumped when it's possible, getting the proccess locked
until this is done.
Blocking I/O sucks and should be avoided like the plague wherever
possible, especially in quasi-RT situations like this.
In some cards it it could be done with HW accel by AGP?
Yes, on some cards you can schedule pageflips on vsync. On lots
of cards you cannot, but the vsync IRQ is still available. You will drown
in a mess of spacial cases if you don't abstract this stuff carefully.
It's a very simple idea, and surely more people thought in it
before, what's the problem with it?
The problem is that it is a card-specific feature. Card-specific
features must be abstracted carefully in order to be able to support al
features of all cards while not losing performance. In particular,
though, exporting random asynchronous callback hooks from the kernel is a
real PITA unless you have something like devfs or procfs where you can
dynamically create files at will. We have this now, so I figure we might
as well do it right.
I know that the idea of kernel doing it wouldn't like many people,
and I know that in some systems it isn't possible to dump big buffers in a
vertycal retrace/blank, but I can't see a best solution.
Dynamic asynchronous notification selector files.
I'm still porting 3D routines from DOS to Linux, I have finished
flat and gouraud, and will start with zbuffer. And a Cube is the easyest
way, IMHO, for finding bugs in the ported routines, it isn't the demo itself
:-D
You're talking about software emulation of the functions you describe or
hardware support ?
Both. In the port I'm using extensive the hardware accel if possible
(is for demos, I _may_ use as much resources as available)
On new cards, you cannot really squeeze performance optimizations
unless you do extensive run-time balancing of the hardware state, and
without a good system to get the hardware info to the kernel and/or
userspace quickly much of the benefits will be lost.
Want to help writing 3D accelleration in the KGIcon S3 Virge driver ?
Yes, I really want, where can I start searching the HW specs of the
3D commands?
See the draft proposal for 3D kgicommands that was recently
posted. Also read the techincal documentation on whatever video chipset
you want to work with.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
