> Hmm. Interesting situation.
> I wonder if Microsoft will get mad that wine has working directX? :)
> [even direct3D based on Mesa IIRC :]
I talking about writing directX library for linux. Wine translates the
Direct X into X window protocol. This is a very different thing.
> 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*).
Yes DRI is a very bad idea. I agree. Well its time to think up a GGI
interface for this stuff.
> 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
Actually 3Dfx is MMIO only.
> - 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. Try most low end cards. On the G400 you can send a DMA command to
copy the 16 megs of framebuffer memeory to the first 16 megs of teh system
memory. Also I seen a post on GLX where one of the registers on a G400 was
misprogrammed it fried the card.
> - 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.
Yes. I have one of those cards.
> 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 :)
I'm also working on a clone of SGI direct rendering engine.
> 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.
DRI uses something very similar approach based on a IPC shared memory
model.
> Maybe some of the problems with DRI could be solved by only allowing
> superuser access but this kind of duplicates the svgalib problems.
> Ideas?
Read http://www.precisioninsight.com/dr/ for details on this
implemenation.
> And anyone know if the DRI method solves the current security holes
> (denial of service/crashes) possible with userspace X?
Well its ups to the driver writers to handle that. The true is DRI sells
out security and stability for performace.
