Re: [Dri-devel] Radeon

[Brian P. <br...@va...>]

"Mark B. Allan" wrote:
> 
> Nathan Hand wrote:
> > Do you have any details regarding the non-compliance you have found
> > with the DRI? Lots of effort is put into passing the GL conformance
> > tests. Reports of non-compliance are treated seriously.
> 
> Off the top of my head...
> 
>  When I last ran glean on my G400 (DRI drivers that came w/Mdk7.2 and
> RH7.0), it failed almost every test in the suite. Blending modes were
> causing me the most trouble in practical usage - there are huge visual
> differences between the DRI,Utah G400 drivers versus other cards and the
> Windows G400, Xig G400 drivers (specifically, it was
> glBlendFunc(GL_SRC_ALPHA, GL_ONE) that was giving me grief. Blended
> textures are far too transparent).
> 
>  With my Voodoo3 (RH7.0 and RPMs from 3dfx), the depth buffer was being
> updated when GL_DEPTH_TEST was disabled. Although not a compliance issue
> per se, the gamma changes to the desktop every time a context is created
> is very annoying and sometimes problematic. When I ran glean on the V3,
> the desktop would go completely black for long periods during the test.
> X crashed when I tried to run the SPEC tests.
> 
>  I'm not sure if line and point smoothing are required for compliance,
> but it is something that I require and isn't available in the DRI
> drivers I've tested.
> 
>  I'm aware that the drivers I've been testing are "old", and that some
> or all of these things may be fixed or irrelevant (in the case of the
> old tdfx driver). But I quite honestly don't have the time or bandwidth
> to keep up with the rapid changes with DRI development. I know that
> packaging the drivers isn't the DRI team's responsibility, but it is
> highly desireable, and there is a gap.

Understood.  It's unfortunate that there's such a long delay between
the time we fix/improve a driver and it appears on a RedHat/Debian/etc
CD-ROM.

BTW, I think our newest drivers would fare better on your tests.


> > As has been stated before, we don't want their driver, we want card
> > specifications.
> >
> > >  If NVIDIA were to release specs to their chips tomorrow, would that
> > > necessarily be a good thing?
> >
> > Yes.
> >
> > > and developer resources are thin. Would it be worth the effort to
> > > start a new driver from scratch when there is so much work to be done on
> > > the other ones?
> >
> > Yes.
> 
>  I dunno. It seems to me that there are far more important things that
> should take higher priority. If you put aside any idealogical or
> emotional considerations, what practical advantages would reimplementing
> an NVIDIA driver provide? If I were grand-poo-bah of 3D on Linux, I
> would probably prioritize things something like this:
> 
> * A Radeon driver that fully exploits the hardware.
> * A RagePro driver for all those laptop users out there.
> * Hardware accelerated off-screen rendering
> * Hardware accelerated indirect rendering
> * Creating small (<2MB), easily installable packages so 'normal' users
> can take advantage of driver improvements and bug-fixes.

That would be a nice project for a volunteer to pick up.


> * Make sure that vendors who have promised DRI support have actually
> deliver something usable (FireGL, Wildcat, etc)

I don't know how we could possibly do that.


>  When everyone is twiddling their thumbs, thinking "geez, I'm bored and
> have nothing to do",

Heh, I haven't experienced that since I've been with PI / VA! :)


> then it would be an appropriate time to think about
> reimplementing an existing, but binary only driver. It just doesn't make
> sense to me to spend valuable resources reimplementing a quality driver.
> Focusing efforts on the Radon seems to make a lot more sense because,
> although it may lose out slightly speed wise, its feature set is more
> interesting.
> 
>  But I'm not grand-poo-bah, and I know that open source purity is a
> near-religious issue for some, so that's just my $0.02.

If it was completely up to us, we probably would prioritize things
similar to your list.  However, we earn our salaries by fulfilling
contracts made with various companies.  We have to give top priority
to the projects that pay the bills.

-Brian