On Thu, Aug 25, 2011 at 3:38 PM, Kenneth Graunke <kenn...@whitecape.org> wrote: > On 08/25/2011 07:03 AM, Ian Romanick wrote: >> On 08/24/2011 05:07 PM, Jakob Bornecrantz wrote: >>> On Thu, Aug 25, 2011 at 1:46 AM, Ian Romanick <i...@freedesktop.org> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 08/24/2011 12:11 PM, Ian Romanick wrote: >>>>> I'd like to propose giving the ax to a bunch of old, unmaintained >>>>> drivers. I've been doing a bunch of refactoring and reworking of core >>>>> Mesa code, and these drivers have been causing me problems for a number >>>>> of reasons. >>>>> >>>>> 1. The hardware is so old that it doesn't support a lot of features that >>>>> have been common for 12+ years. >>>>> >>>>> 2. The drivers are so unmaintained that even hacking in new features >>>>> with dummy implementations is painful. >>>>> >>>>> 3. The drivers are so buggy that many piglit tests hang the GPU. I >>>>> tried doing a piglit run on a Rage128 Pro that I have, but I gave up >>>>> after having to blacklist 15 tests. >>>>> >>>>> It also seems that at least some distros (e.g., Fedora) have stopped >>>>> shipping non-DRI2 drivers. If nobody is shipping it, nobody is using it. >>>>> >>>>> My specific proposal is: >>>>> >>>>> - Remove all DRI1 drivers: i810, mach64, mga, r128, savage, sis, tdfx, >>>>> and unichrome. >>>>> >>>>> - Remove all unmaintained Windows drivers: gldirect, icd. >>>>> >>>>> - Remove beos. >>>>> >>>>> - Remove fbdev (this is swrast on raw fbdev). >>>>> >>>>> Opinions? >>>> >>>> I've put up an initial branch at >>>> >>>> git://people.freedesktop.org:~idr/mesa kill-old-drivers >>>> >>>> The only thing that isn't deleted yet is BeOS. There are a bunch of >>>> stray BeOS bits here and there, so I want to extract it carefully. >> >>> If you actually kept the DRI1 stuff in glx you would be able to install >>> old DRI1 drivers from a old mesa release alongside DRI2 drivers and >>> libGL from a newer one, since we have been pretty good (AFAIK) at >>> keeping the backwards compatibility in the DRI and libGL interfaces.* > > Forgive my ignorance, but...doesn't changing dd_function_table break the > old libGL/new DRI driver API/ABI? Or, is that different? In > particular, the following functions have been dropped since 7.11: > - CopyTexImage1D > - CopyTexImage2D > - MapBuffer > > And these driver functions have changed: > - MapBufferRange > - FlushMappedBufferRange > - GetBufferSubData > - BufferSubdata > - UnmapBuffer > - ChooseTextureFormat > > If so, you couldn't build a 7.11 or 7.10 driver and use it with > master/7.12/8.0. I suppose people could grab a snapshot right before > the removal, but we'll certainly change this again... > >> That's a fair point. Since we have a clean mechanism to improve those >> interfaces (e.g., DRI2!), there's relatively little cost in keeping that >> code around. >> >> I'd usually be pretty stoked about deleting 842 lines of code, but it >> feels pretty insignificant right after deleting 85,811 lines of code! I >> may have now out ajaxed ajax. :) > > It may be insignificant in size, but it _does_ make it harder for people > trying to get up to speed with the DRI code. There are a lot of > structures, tokens, and functions which _look_ relevant for a DRI2 > driver, but are actually DRI1. It's not entirely clear, for example, > that dri_context and dri_screen are DRI1-only. I imagine Chad has an > opinion on this. > > So I'm still in favor of removing DRI1 entirely. People can just stick > with 7.11.
Makes it hard for distros though. Since you'd have to ship two libGLs, and then really we are condoning what the binary drivers do. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
