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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]