On Wednesday 17 April 2002 09:46, José Fonseca wrote: > For the record, > > I just want to say I'm really sorry for started this thread. When I did it > I had hope to bring Robert Lunnon (which is currently working on the > Utah-GLX's Mach64 driver) to join efforts, as I though he wasn't using DRI > due to using Solaris. > > As the thread proceeded it become clear that there wasn't really a > interest in a long-term solution for 3D graphics on Solaris, and (after > reading the Utah-GLX archives) I also realized my mistake - Robert Lunnon > wasn't supporting DRI because of a different OS, but because he believes > that DRI is too complicated and inefficient. > > Of course that I don't share the same opinion, although I respect his. I'm > convinced that it's not necessary to comprimise security to achieve > performance and I'll keep working on that sense, with the confidence that > I've had so far. Just not as fast as it could be...
Whoa nellie.... Words that did not leave my mouth. I have no particular objection to DRI, however from my investigations it is not documented well enough or structured well enough to be supportable by the few people available, primarilly due to the need for kernel level drivers for each individual video susbsystem. Because the different OSes have different kenel infrastructure this means a rewrite of each kernel mode drriver for each platform (YUK). Better to have a common kernel infrastructure so the bulk of the card specific code can be common between OSes. Utah gives this by simply using raw access to the framebuffer, since the hardware has a common look on each platfom, it provides the commonality. Probably the easiest way to acheive this with DRI would be to define a set of Kernel mode wrappers that hook into each platforms kernel mode services using common semantics. I don't necessarily mean card specific, I mean file mapping, dma, physical address translations, service setup and tear down, device creation and linkage etc. To my knowledge DRI deliberately avoids this approach to get the last few ergs of performance from the kernel drivers, making inter OS ports difficult. My opinion therefore is not that DRI is inefficient but rather it is TOO EFFICIENT and it is that way at the expense of portability. Utah is easy, It took me about a week to actually see the Rage driver "work" in software mode, though I still have some dma problems obstructing a final hardware solution but I am homing in on it. Biggest problem at the moment is that it takes me about 6 months to do a weeks work on it (Not enough free time). In short I would be happy to support DRI if it were as easy to use as Utah-GLX (IE within my very limited capability as a developer). Bob _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
