Philip Brown wrote:
> Okay, long email, in two section:
> "Solaris limitations", and "ease-of-porting issues". Neither of which strictly
> require changes to the drm API, but most of which require changes to
> underlying code.
Wow, the fact that the drm API could support this is great news. It was
never intended that the underlying OS specifics be portable.
> ----- SOLARIS LIMITATIONS --------------
>
> Well, the biggie is that you cannot bind a custom driver to the video card:
> there is already a solaris video driver, and it has no exported bit-twiddle
> interfaces for other drivers. So, no using video card interrupts, and no
> tweaking the registers from driver level.
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.
> (I think. There might be a way to do register twiddles, but I dont
> know how to do it.)
>
> 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.
>
> You CAN (in theory) use /dev/agpgart, seeing as how it is a separate device
> that solaris does not normally bind to.
> I wrote a theoretical solaris version of the agpgart API, that is actually
> (in theory) completed. But I have had no working graphics progs to test it
> at this point. It would be best to get something working without AGP
> support, and then cautiously see how badly things blow up once you turn it
> on.
Enabling user level access to primary AGP buffers is where security goes
out the window for many AGP based HW solutions. If you want to throw
security out the window, you can expect some push back from a few strong
Linux kernel developers--however, you might get some praise from
dedicated console or game machine developers. You'll probably need the
permissions for this type of mode to be enable via a kernel patch that
may never show up in the standard Linux kernel.
The primary amount of additional work is to duplicate state and buffer
management in the client side 3D driver. This is a large amount of work
on a per driver basis, so I'd be real choosy about the number of
chipsets I attempted this on in the short term.
> ----- EASE OF PORTING issues --------------
>
> I think there are some card drivers under dri that "require" agp to work.
Yes.
> 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. Non-AGP support is a rare thing indeed, but
knock yourself out and implement some of it. However, don't expect
universal support.
> 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.
> Then of course there's the nasty bsd linking hack that I mentioned.
> If code is shared between OSs, it belongs in the 'shared' directory.
> Both so that porters know they probably want to use the code, and also
> that people working on it for existing platforms are aware that they
> cannot make some funky os-specific tweak in the code.
Sounds reasonable, but realize code factoring is an ongoing process.
It's hard to know what should be in common and what shouldn't with only
two OS's supported. Solaris could be the third and you'd be in the
perfect position to do a round of code factoring.
> > ... I got
> > the impression from your previous e-mails that you were looking for a
> > solution that did not require kernel level support. If security and
> > multiple direct rendering contexts are not a concern, and won't ever be
> > for Solaris; then we should talk about taking Utah-GLX like shortcuts
> > under the DRI.
>
> That would be good enough for me. Long-term, maybe others would be
> interested in fleshing out the other bits, but its not something I care to
> tackle. Heck, I dont technically even care about "direct" rendering.
> I'm perfectly happy to go through Xserver communication pipes, and
> thus solve the "security" issues by letting the Xserver handle it.
> I can play quake2 just fine with indirect rendering on my old TNT
> card and Utah-GLX.
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.
> Contrariwise... maybe use /dev/xsvc "directly", for direct mapping.
> Solaris has /etc/logindevperm that can be tweaked to automatically
> adjust ownership of /dev/xsvc to the person logged in on console.
> Perhaps that is the best way to go.
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.
> Anyways.... if the aforementioned limitations and needs were accomodated
> (for Matrox G400 suport, initally, anyways, since thats the card I have
> now), then I would be interested in looking at taking on the solaris port
> again.
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.
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
