[Mesa-dev] Four questions about DRI1 drivers

Jose Fonseca jfonseca at vmware.com
Thu Mar 1 01:06:15 PST 2012


There is one thing you didn't cover in your questions/myths: old hardware is often very limited by today standards, and removing it allows the code to become simpler (less fallbacks, more shared code, uniform code paths), as we can raise the assumptions of what a driver can and cannot do. And this has happened already.

I'm not familiar r128 so I can't answer your effort estimation questions, but IMO support for old Mesa drivers development should happen in a separate branch/tree (forked from the point where the driver existed), so that development of new features for modern GPUs is not hindered by limitations of ancient hardware.

I'm not sure how easy it would be to physically separate libGL.so into a separate repository. It might still be be possible to produce a xxx_dri.so from such legacy branch, that can be loaded by a modern libGL.so. This could be accomplished by referring to Mesa master's libGL.so headers from that branch.

Another alernative would be for that legacy branch to just build both libGL.so and foo_dri.so. It creates a bit of extra work for distros, but distros already need to cope with that for the proprietary nvidia/amd drivers anyway, so it would be one more case. It won't solve the case of your docking station though.


Concerning some of the myths/rants, I think that there's no merit in arguing retrospectively what we should have done, so I won't.  If there are enough people interested and capable of maintaining old drivers I'm sure that the community as a whole can find some technical solution to accommodate those interests, as everybody benefits indirectly from a bigger development community.  But it's unrealistic to expect that individuals/companies working on Mesa to put large amount time on unmaintained code, as simply there is no return.  After all, we're all scratching our itches one way or the other..


Jose

----- Original Message -----
> I am a first time mailing list joiner, long time user of exclusively
> free video drivers. I was very upset to see the DRI1 drivers removed
> from the codebase in August and I waited until now to complain
> because I
> wanted to see if the good changes like OpenGL3 would at least make it
> into the 8.0 release. My questions (mainly about r128) are the
> following:
> 
> 1. If someone learns how to port a DRI1 driver to DRI2 and does this
> (which in my case would take years), will it be accepted back into
> mesa?
> Or would this person have to personally maintain r128_dri2.so forever
> after with no help from other mesa developers?
> 
> 2. Is there any realistic hope that a current mesa developer will
> undertake this task? MostAwesomeDude spoke about looking into this
> one
> day but says he does not have the time right now. Has this changed
> yet?
> I should add that if your full time employer doesn't pay you to work
> on
> mesa I'd be willing to pay you to work on this aspect of it.
> 
> 3. Would hacking r128 into compatibility with DRI2 only require
> changes
> to the mesa code or would one need to hack the kernel and the DDX as
> well?
> 
> 4. In all honesty, are the 2D X drivers and DRM kernel modules
> corresponding to the DRI1 drivers that got axed slated for removal as
> well?
> 
> ======
> 
> Please don't think that I feel entitled to the fruits of your labour.
> I'm sure many of you develop mesa on a volunteer basis and choose the
> parts of the code that are interesting to you. I'm not saying that
> you
> should work on something less enjoyable because the free software
> community depends on you (even though it does) and I'm not asking you
> to
> make regular updates to r128 or anything else. I just think that the
> reasons for removing these drivers are based on enduring myths.
> 
> Myth: "The drivers never worked to begin with." I haven't tried all
> of
> them but I know r128, mga and i810 did. While my r128 driver was
> clearly
> not perfect, it led to a dramatic performance increase with 3D
> screensavers and video playback. Unlike radeon drivers that were
> being
> worked on heavily, the r128 driver did not break for me with any mesa
> update.
> 
> Myth: "Nobody uses this hardware anymore." I'm not the only example
> of
> someone who still uses an r128 card (in a laptop where it cannot be
> upgraded). When phoronix covered this story some people who posted in
> those forums had complaints that were similar to my own. Every time I
> see the death sentence discussed in distro forums, there is at least
> one
> person upset about support for one of their old cards being dropped.
> I
> know this is a sampling bias because people happy with the changes
> tend
> not to post but one of the triumphs of free software is that it can
> free
> people from the endless cycle of having to upgrade hardware. Is it so
> hard to believe that people save money because of this and want such
> freedom to stay around?
> 
> Myth: "People who use this hardware already have a system frozen in
> the
> past." I use kernel 3.2.7, gcc 4.6.2, a 2012 ffmpeg build from git
> and a
> 2012 mplayer build from svn. If I have to freeze my mesa package at
> 7.11, it will become one of the first programs that I have to freeze.
> 
> Myth: "Freezing mesa at 7.11 does no harm to users of legacy
> hardware."
> I may be a special case here but I use r128 AND radeon hardware in
> the
> same machine. When my laptop is docked I use an r500 card in the
> docking
> station which would still benefit from updates to radeon. When my
> laptop
> is not docked I need the r128 card to be functional.
> 
> Myth: "Anyone who wants an old driver can maintain it." Sure I've
> told
> people to patch their own programs before. When I suggest doing this
> on
> a mailing list it's common to hear the groan "but I don't {want, know
> how} to." In the case of mesa though, I think it is justified as it's
> hard enough for people with a decade of experience to maintain.
> Here's
> an idea. If you want to drop r128 and never have to add a line of
> code
> to it again and never have to worry about whether a diff to the mesa
> core is going to break it, take the one time effort of making mesa
> modular! Then I'll be able to download r128_dri.so source from
> another
> site and neatly add it to a three-driver-mesa that is already
> installed.
> Then when updates to mesa make this impossible, it will be my
> responsibility to fix the source in this external tree. And in all
> honesty, doing this on a case by case basis is the best way to make
> me
> learn an unfamiliar API.
> 
> Okay, maybe the subject should've been "four questions and five myths
> /
> rants" but when it comes to the myth arguments I have heard it all
> before. Please try to answer my questions.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


More information about the mesa-dev mailing list