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:
http://packages.debian.org/cgi-bin/search_contents.pl?word=libGL.so.1&searchmode=searchfiles&case=sensitive&version=unstable&arch=i386
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],
libs/xlibmesa-gl,
libs/mesag3
(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
X-server.
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
implementation.
AFAIK, the -xorg package is byte for byte the same thing as the -mesa
package.
> 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
packages.
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.
--
Marcelo
Reply to: