On Tue, Apr 16, 2002 at 04:17:49PM -0600, Jens Owen wrote: > I haven't touched Solaris in over 6 years, but back in the day it was > possible to provide a unique driver. This was done for Sun's high end > 3D sparc platform and included kernel level support for page faults > based context switching. There was lots of sophisticated stuff, and I'd > be surprised if they've completely removed the ability to handle this.
That is for solaris sparc. It has a known API for "framebuffer" devices. Solaris x86 does not have that. > > The good news is that /dev/xsvc still works for register fiddling. > > So you can take the IO register mapping that the Xserver does, and use > > the mmaped regs at user level still. > Enabling user level access to primary AGP buffers is where security goes > out the window for many AGP based HW solutions. Security is not a problem in this area. The same mechanism that limits access to /dev/xsvc for console users, can be used to limit access to /dev/agpgart [But there is no /dev/agpgart on sparc, because of course there is NO AGP on sparc] > > ----- EASE OF PORTING issues -------------- > > > > I think there are some card drivers under dri that "require" agp to work. > > This has got to be fixed. For every card, there should be a > > "fall back to using on-board video memory" mode. Similarly, a > > "fall back to no DMA" mode. > > With some hardware, that is a very limited amount of functionality that > doesn't even include 3D. I would like to know what card made in the last 5 years cannot do 3d operations to its own video memory. [as opposed to "Well, dri doesnt implement that, for that card"] > > Similarly, I believe that there is a check for custom card-specific > > kenel-level extensions, and if they are not there, DRI does not install > > itself for that card. That needs to be optional, not a drop-dead issue. > > Some hardware will not provide 3D functionality without extensions. > Expecting every vendor to support 3D via MMIO is unlikely. I'm not objecting to "using extensions". I'm objecting to requiring card-specific tweaks **at kernel level**. How many of these cards you mention, cannot be programmed for 3d by mmaping the registers? > If all you want is a very basic level of 3D support, I recommend you > support 3Dfx only. That's where FreeBSD support started. No AGP, DMA > or interrupts required. Just straight MMIO. I dont intend to go out and buy yet another card. I have TNT and g400 cards. I've already got TNT working with Utah-GLX. The only question in my mind now is whether I start working on the g400 stuff in Utah-GLX, or in DRI. > The xsvc driver might make a good cruch for 3Dfx support, but "others" > will need to get it out of the way in order to persue the functionality > provided by newer hardware. There's "optimum" use, and then there's "accelerated" use. The TNT support in Utah-GLX does not support the features available in "newer hardware", like TNT2, or Geforce. But it does **WORK** with those cards, and provide reasonable hardware acceleration, for basic Quake^H^H^H^H^Happlication testing :-) Thats what I (and others) would be looking for. > If all you want if your card to work and you don't care about the long > term viability of your preferred OS and/or the underlying 3D > infrastructure, save us all a bunch of headaches and get a 3Dfx card > from ebay, port the glide layer, then the 3Dfx DRM driver and be done > with it. I'm looking to work on a project that cares about cross-platform support. "saving you a bunch of headaches" does not seem like an indication of that. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
