[Mesa-users] osmesa swrast windows/linux

[Brian Paul]

On 03/06/2016 11:36 PM, Andreas Fänger wrote:
>> -----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?)

No, not that I know of.  I guess I'd compile with -g and debug with a 
debugger.  Set breakpoints on softpipe_create_context() and 
llvmpipe_create_context() and see how softpipe getting called.  If you 
go up the call stack you should be able to find where llvmpipe vs. 
softpipe are being chosen.

-Brian