Experimental options

[Vladimir Dergachev]

>> The reason this is useful is that such trick greatly accelerates 3d on
>                                                                   ^ 2? :)
>> large resolution screens as 2d driver can also use DRM driver and this
>> works perfectly well. This also facilitates work on 3d driver.
>>
>>      The 2d speedup is quite considerable, however one would expect all GL
>> apps to break because of this, as even software rendering won't work.
>
> libGL should fall back to GLX when the *_dri.so isn't around.  Is it
> not?  Even so, it would be nice to make some sort of change to make

I don't think it does. At the very least this was broken for me - or maybe 
I screwed up something else.

> libdri not advertise DRI support to clients in this case, but use the
> rest of the facilities within the server.  Seems like it should be
> pretty possible.

This is possible, but then I would want another option to export the 
driver name anyway - this is useful to facilitate work on R300 driver.

At the moment locations and functions of most registers are known, 
what is needed is a lot of meticulous effort on getting Mesa driver to 
use them and catching bugs.

I am hoping that by not requiring patching X.org and by allowing R300
drm use to be switched on and off I can help those who wish to tinker with
it but either got bogged down in details or can't have unstable X or GL 
on their primary machine.

                        best

                           Vladimir Dergachev

>
> -- 
> Eric Anholt                                eta at lclark.edu
> http://people.freebsd.org/~anholt/         anholt at FreeBSD.org
>