[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mesag3 <-> xlibmesa-gl / libgl1-mesa-dri <-> xlibmesa-dri / libglu1-mesa <-> libglu1-xorg

On Wed, Aug 31, 2005 at 02:41:05AM +0200, Michael Biebl wrote:

 > It seems that mesa (6.3.2) as well as xorg (6.8.2) both provide a
 > GL/GLU implemetation.

 If you look at:


 You'll notice:

    usr/X11R6/lib/debug/libGL.so.1          libdevel/xlibmesa-gl-dbg
    usr/X11R6/lib/libGL.so.1                libs/xlibmesa-gl
    usr/lib/dbg/i686/mmx/cmov/libGL.so.1    libs/libgl1-mesa-dbg
    usr/lib/dbg/libGL.so.1                  libs/libgl1-mesa-dbg
    usr/lib/debug/libGL.so.1                libdevel/xlibmesa-gl-dbg
    usr/lib/i686/mmx/cmov/libGL.so.1        libs/mesag3
    usr/lib/libGL.so.1                      libs/libgl1-mesa-dri,
                                            x11/nvidia-glx [non-free],

 (I have to upload the fix for the dbg thing, it's in svn now)

 xlibmesa-gl provides the DRI drivers shipped with the X.org X-server.

 mesag3 provides the software rasterizer shipped with mesa.

 nvidia-glx provides the hardware-accelerated driver for NVIDIA
 hardware (a second package is needed to support older NVIDIA hardware)

 libgl1-mesa-dri provides the DRI drivers that have been incorporated
 into Mesa upstream and which were formerly distributed only with the

 The GLU package is, uhm, I don't know.  At some point I talked with
 Branden about it, but we never did anything.  The xfree86 (and now the
 x.org) are the ones duplicating that code.  And this has nothing to do
 with some "my turf/your turf" thing.  It was more of a "this code
 works, that code doesn't" thing.  All three packages (libglu1-mesa,
 libglu1-xorg, xlibmesa-glu) are optional.  The -xorg thing is cute, but
 someone missed the point of -mesa (and I'm probably to blame).  -mesa
 is there because at some point there were two implementations shipped
 with Mesa.  The one by Brian Paul and the one from the OpenGL SI
 provided by SGI, so there were two packages (libglu1-mesa and
 libglu1-sgi).  The -sgi one was provided by a package that never made
 it thru the NEW queue and after some months I got sick of waiting and
 removed the package from the queue, so it never actually made it to the
 archive.  Anyways, it happened that at some other point Brian removed
 his implementation, fixed bugs in the SGI one and shipped that with
 Mesa.  That's why nowadays the -mesa package provides the SGI

 AFAIK, the -xorg package is byte for byte the same thing as the -mesa

 > IIRC the xorg GL/GLU code is based on (older) mesa code.

 Mesa is merged every now and then into the X tree.  For example the 6.3
 release has been merged into the 6.9 X.org tree.  But in *general* Mesa
 contains code that's newer than whatever is in the X tree.

 > Why this duplication of code and which of this two implementations is
 > the preferred one?

 "It depends"

 What hardware do you have and what do you want to do?

 On some machines I have NVIDIA hardware because it's the only hardware
 that supports current OpenGL features both in the hardware and in its
 driver (a recent Radeon card is useless to me if it supports OpenGL 1.5
 but its driver doesn't, which is the case with the DRI drivers).

 On other machines I have some Intel embedded POS, which can use the
 Mesa drivers.  I haven't had the chance to actually test the
 libgl1-mesa-dri with the X.org xserver packages, but as far as I can
 see from the docs, it should work.  Be my guest and beat me to it if
 you want.

 And on some situations I actually *want* the Mesa software rasterizer,
 which I use by installing the GL driver to an adecuate location and
 setting LD_LIBRARY_PATH accordingly.

 > Could I replace the xorg packages with the mesa packages without ill
 > effects resp. without loss of functionality?

 You mean replacing xlibmesa-gl by libgl1-mesa-dri?  It should work, but
 haven't tested it.

 If it works, it should gain functionality, not lose it.

 Performance is something else :-]

 > I noticed that Ubuntu renamed mesag3->libglu1-mesa and
 > xlibmesa-gl->libgl1-xorg.

 Hopefully libglu1-mesa is a typo on your side.  The driver provided by
 mesag3 is a software rasterizer and the package *should* be named
 something like libgl1-mesa-soft (or swr or whatever, something that at
 least gives a hint about the type of driver it provides)

 Daniel approached me about renaming and I told him that I didn't have a
 strong position in either way (renaming or not renaming).  In general I
 avoid cosmetic package renames, which is what this is.  I mean, there's
 hardly enough people around who even remember why mesag3 is called
 that, and there's less people around who can actually argue for a name
 change with something not cosmetic (and no, your "policy says so" card
 isn't good enough, since my "upgrade path" one beats yours to death).

 But if someone cares a lot about cosmetics, I'll probably rename the

 Daniel also said he'd send a package via email which I never got, so I
 went ahead and did my own thing.  (No Matt, I'm not happy with the idea
 of fishing patches out of some random, cluttered, and very unusable
 webpage; everything I've fixed in Mesa over the years has found its way
 to Brian Paul in the format he wants it over the channels he wants it,
 so I expect the same from my downstreams).

 > Is this an attempt to smooth the transition from the xorg packages to
 > the mesa ones and in the course of the X modularisation to get
 > completely rid of the GL/GLU code in xorg (and the libgl*-xorg
 > packages) and use mesa directly as an external library?  If there is
 > such a transition how will it take place?

 Not currently, or at least not one that I know of.

 1) Is such a transition needed?  OpenGL is OpenGL is OpenGL.  Packages
    should depend on libgl1, so no transition is needed.  And the user
    should know which driver he needs, so he can pick among the several
    ones.  I think atm this is "solved" with a task.  Do you mean dummy
    packages? xlibmesa-gl can depend on libgl1-mesa-dri (and the same
    goes for the hopefully not existant in Debian libgl1-xorg) one
    libgl1-mesa-dri is verified to work with the x.org xserver we
    provide (notice that by "work" I mean in direct rendering mode -- it
    *should* work in indirect rendering mode), which leads me to:

 2) Someone with the proper hardware should test the several (there's at
    least 8 of them IIRC) drivers that ship inside the -dri package with
    the current (6.8) and future (6.9, 7.0) x.org server.

 > Could someone with a deeper insight enlighten me?

 I'm sure Michel has an informed opinion, too.

 My interest in the mesa package comes from the fact that I develop
 OpenGL-based applications, which is why I picked it up when it was
 orphaned and why I've been maintaining it for the last few years.


Reply to: