On Mon, 13 Dec 1999, James Simmons wrote:
>
> I had a interesting discussion on the possiblility of having a Direct X
> on linux with John Carmack. Well it appears Mircosoft will sue anyone that
> tries that. So I talked to him about Mesa-GGI and how Direct X support was
> added to libGGI. So to the person that wrote the Direct X interface. Do
> you think you have a enough of a bridge between Direct X and GGI to allow
> Mesa-GGI programs to run on top of Direct X completely? If not what
> features do you feel libGGI lacks to have this happen?
>
> Also can libGGI handle DMA transfers, AGP? Does it have enough of a API
> to implement textures and other 3D functions?
Hmm. Interesting situation.
I wonder if Microsoft will get mad that wine has working directX? :)
[even direct3D based on Mesa IIRC :]
Anyways as far as I know (and I don't know much):
- 3D accel within GGI is currently targetted at writing hw
drivers for Mesa.
[I'm going to look into this for 3Dfx Banshee driver
actually now that it's gone open-source :]
-> wonder if a fbdev/glide Mesa driver could be done? Then run an
X that runs under that....
- 2D accel is limited
- non-video buffers within the videocard (ie Z-buffers) are
afaik accounted for within the directbuffer api specs
but also afaik nobody's bothered writing an
implementation....
- AGP should be handled by some sort of libAGP extension. I
haven't seen even a proposal for how this should be done.
Incidentally, the 3Dfx driver seems to have AGP support...
A big problem I've found with the GGI project is that noone really knows
how acceleration -should- be handled between kernel and userspace. or
even which methods are most appropriate. And many of the interfaces
developed (ping/pong buffers as an example) are either currently unusable
or not really tested all that much. I'd -love- to see some sort of formal
FAQ/RFC on this issue... anyone? The DRI solution is a -bad- one
(unsecure and -dangerous- if something goes wrong. Such as mixing a DRI
driver with an fbdev driver *sigh*).
Some issues I can think of:
- Some cards have -very- good DMA support (I think the permedia,
3Dfx, and some others fall into this category but I'm not sure)
: these should be easy to code potentially and most work will be
done in userspace
- Some cards are -dangerous- for DMA work but doable, some sort of
translation IP-stack-style would probably be good (S3 ViRGE comes to
mind here)
- Some cards are strictly PIO-based. Mostly old pre-3D cards really
ioctls work well here
: this is the current working accel format as far as I know.
Don't expect impressive performance, switching between kernel
and userspace has a fare bit of delay... but for a complex
accel this should work well.
> Also on that last one, some cards are incredibly dangerous to allow
any kind of direct access; all commands should be controlled to
prevent abuse. Extreme examples are that it -is- possible to blow up
many cards by misprogramming graphics modes. Particularily older
cards. I've heard of (Paradise VGA?) cards being lost this way.
Approaches I can think about and have heard:
DRI - Open a direct-tunnel to graphics card, kernel directs data AFAIK
ping-pong - have a buffer of a group of accels, tell the kernel to read and
execute from buffer; should be fast. Does this work currently?
ioctl - Bad for small accels (eg. colour change) but should be good for
large renders.
> the kernel FB drivers fall under the last when accelerated at
all. Works well for me on my card :)
The new network drivers (2.3 current) have an extra option for
shared-memory access to network. I'd love to see how that works and see
if it could be implemented (or something similar) for graphics cards.
Maybe some of the problems with DRI could be solved by only allowing
superuser access but this kind of duplicates the svgalib problems. Ideas?
And anyone know if the DRI method solves the current security holes
(denial of service/crashes) possible with userspace X?
G'day, eh? :)
- Teunis
PS: Really take this message with a grain of salt. I'd -love- feedback.
I'm probably out to lunch on a lot of this - I haven't read the source
enough. (and last I played I was mucking about with ioctl accels under S3
ViRGE and I totally mucked my 3Dfx DRI driver up 'til I downloaded a
working one :)
