[Mesa-users] osmesa swrast windows/linux

Mon Mar 7 06:36:25 UTC 2016

> -----Ursprüngliche Nachricht-----
> Von: Brian Paul 
> Gesendet: Donnerstag, 3. März 2016 19:04
> Betreff: Re: AW: AW: [Mesa-users] osmesa swrast windows/linux
> 
> On 03/03/2016 03:26 AM, Andreas Fänger wrote:
> > Hi Brian,
> >
> > I will try to check what's necessary to undo part of commit 69db4222.
> >
> > However, before I start investing time into that task: will it be
> > possible to put a patch into an official release again?
> 
> Probably.
> 
> >  I don't know
> > what the reason was to remove osmesa/swrast from the scons build so
> > I'm not sure if you and the others would accept a patch which reverts
> > the previous commit (in parts).
> 
> I think it was removed just to simplify things.  If it's still of use to people,
> that's good enough for me.
> 
> 
> >
> > If you would accept it: how should the scons target be named as
> > there
> now is another "osmesa" target? Should it be "osmesa-swrast". Or should
> the current "osmesa" renamed to "osmesa-gallium"?
> 
> The later would be more consistent with what we have for autoconf/make.
> 
> 
> >
> > Regarding the problems with the missing symbols in gallium I think
> > I'm
> going to file a bug report as I'm also quite busy and don't have much
> insight into the gallium project.
> >
> 
> OK,
> 
> 
> > Just a question regarding the current state of gallium/llvmpipe: I
> > have now created a working version and it seems the llvmpipe has no
> > anisotropic filtering. Are there any plans to implement it in the near
> > future?
> 
> Not that I know of.
> 
> > And are there plans to support GL_POLYGON_SMOOTH?
> 
> No.
> 
> > If not, is
> > there an alternative antialiasing method available which creates
> > comparable results to GL_POLYGON_SMOOTH and is not too slow? A
> method
> > that is not simply blurring the whole image but affects only the edges
> > of the polygons?
> 
> Well, the "old" way before MSAA was the accumulation buffer.  You'd
> render the scene N times with a sub-pixel jitter factor, then average
> the N images together.
> 
> -Brian
> 
> 

> >>>>
> >>>> At some point, the SCons build changed from building the old/swrast
> >>>> version of OSMesa to building the new gallium-based OSMesa.
> >>>> Actually, the commit in question was 69db4222 (from March 24, 2015).
> >>>
> >>> I see, that explains the different behaviour. How can I compile the
> >>> older swrast version of osmesa on windows and linux with the latest
> >>> mesa? Or is that not possible anymore?
> >>
> >> It still works with Linux autoconf, but not scons on Windows.
> >>
> >> With autoconf, you'd do something like
> >>
> >> ./configure --enable-xlib-glx --disable-driglx-direct --disable-dri --enable-
> >> gallium-osmesa --with-gallium-drivers=swrast
> >>
> >> For Scons, it would require undoing part of commit 69db4222.  I don't have
> >> time for that right now but perhaps you could try.
> >>
> >>
> >>>
> >>>>> On windows, the new osmesa.dll only contains the OSMesa specific
> >>>>> symbols but non of the GL symbols:
> >>>>>
> >>>>> C:\>dumpbin /EXPORTS
> >>>>> build\windows-x86-debug\gallium\targets\osmesa\osmesa.dll
> >>>>
> >>>> For both Windows and Linux, the solutions is to probably also link your
> >> app
> >>>> with the GL library (libGL.so or opengl32.dll).  Can you try that?
> >>>
> >>> Anyways, I've tested a bit more and mesa-11.1.2 actually contains
> >>> more symbols on windows now; there must have been some changes
> >>> between 10.6 and 11.1.2 so that they are exported. It now seems to
> >>> contain all OpenGL 1.4 symbols but none of the OpenGL >=2.0 ones
> >>> (e.g. glCreateShader or glUniformXX). So it's still not fully
> >>> compatible with the older osmesa builds. Is it possible to export all
> >>> the symbols as in osmesa <10.6.0 ? >
> >>
> >> Typically on Windows, you have to use wglGetProcAddress() to get access
> >> to any post GL 1.3 functions.  Mesa tries follows that convention.  I
> >> guess that somehow got applied to OSMesa too.
> >>
> >> Again, I don't have time to investigate right now, but it may be related
> >> to patch 69db4222.
> >>
> >>
> >>>
> >>> However, I think that the linux version of osmesa/gallium is broken
> >>> asit doesn't contain even the OSMesa symbols, e.g.
> >> OSMesaCreateContext.
> >>>
> >>> mesa-11.1.2 # scons build=release
> >>> mesa-11.1.2 # find -name *.so
> >>> ./build/linux-x86_64/gallium/targets/graw-null/libgraw.so
> >>> ./build/linux-x86_64/gallium/targets/osmesa/libosmesa.so
> >>>
> >>> mesa-11.1.2 # nm build/linux-
> >> x86_64/gallium/targets/osmesa/libosmesa.so | grep
> OSMesaCreateContext
> >>> (no result)
> >>> mesa-11.1.2 # nm build/linux-x86_64/gallium/targets/graw-
> null/libgraw.so
> >> | grep OSMesaCreateContext
> >>> (no result)
> >>>
> >>> So there is no library in the build directory that contains the required
> >> symbols.
> >>>
> >>> Whereas in mesa-10.5.9:
> >>> mesa-11.1.2 # scons build=release openmp=true osmesa
> >>> mesa-10.5.9 # nm build/linux-
> x86_64/mesa/drivers/osmesa/libosmesa.so |
> >> grep OSMesaCreateContext
> >>> 000000000005db40 T OSMesaCreateContext
> >>> 000000000005d720 T OSMesaCreateContextExt
> >>
> >> Again, I don't know what's going on and I'm too busy to investigate
> >> right now.  Hopefully you can.
> >>
> >>>
> >>>

> >>>>
> >>>> With the gallium version of OSMesa, you'll probably want to use the
> >>>> llvmpipe driver.  It should be much faster than the old swrast driver if
> >>>> you use any amount of shaders/texturing.  However, this does require
> >>>> having LLVM installed on your machine.
> >>>>
> >>>
> >>> I will try to compile the llvm version now and will check the results.
> >>>

I've now compiled llvm versions of osmesa for windows and linux. On windows it is working (compiled with scons).

However, on linux the llvmpipe driver is never used even though it was compiled without errors and the osmesa.so
contains a lot of llvm symbols (compiled with make as the scons build is broken). I've tried both the statically and dynamically linked versions but
softpipe is always used.
Is there something else I have to do in order to activate the llvmpipe driver on linux for osmesa (env variable?)

> >>> What I've already noticed is that the softpipe version is a lot slower than
> >> the swrast version (in my first tests with fixed-function pipeline &
> texturing
> >>> 2 times slower at least) and anisotropic filtering doesn't work anymore
> >> (application crashes when it's turned on). Furthermore,
> >> GL_POLYGON_SMOOTH doesn't seem to work. Is it not implemented in
> >> gallium?
> >>
> >>
> >> Softpipe is slow.  It wasn't designed for speed.  Gallium has no support
> >> for GL_POLYGON_SMOOTH.
> >>
> >> Overall, it sounds like you'd be happies with the old swrast-based
> >> OSMesa.  I think undoing part of commit 69db4222 is the key.
> >
> >
> >