On 2002.04.21 03:35 Robert Lunnon wrote: > On Wednesday 17 April 2002 09:46, José Fonseca wrote: > > ... > > > > 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. > > ... > > Whoa nellie.... Words that did not leave my mouth. >
I know... I should have address you directly from the start... > 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. > It's a fact that DRI lacks some code documentation. This is something that I proposed myself to improve in the beginning and it's not a forgoten promise. To add more comments and generate reference manuals automatically from source is something I plan to do when the Mach64 work is more advanced, this way I'll have more know-how to do better job documenting too. > 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. Yes. When there is will to porting to a new platform, this would probably be the better way to go. One thing in favor is that many of these OS operations are already encapsulated by the DRM templates. > 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). Well, it's not so difficult. Most of the more dificult things are common to all drivers and are ready-to-use. I think that most of its complexity comes from the fact that it makes the bridge between three so complex and distinct code bases: the X system, the Kernel and Mesa. Although this is the best way to achieve goals such as security and multiple clients, it's really a lot of stuff to grasp when one tries to get into it. Perhaps, when the DMA is working on DRI as well and the DRI driver reaches the same level of speed & completness of the Utah-GLX, you may consider to redirect your little free time to DRI instead, as your contribution will be more rewarded here - working together with us and achieving bigger goals -, than just by yourself. > > Bob > Best regards, José Fonseca _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
