[Mesa-users] Trouble compiling MesaGL : llvm intrinsics seem to be missing.

[Albert Freeman]

The other thing is: does swr work with osmesa? I can't test right now.

On 6 November 2016 at 20:33, Albert Freeman <albertwdfreeman at gmail.com> wrote:
> Okay seems you are right, either configuration options have at some
> point changed or I somehow with my mesa configs magically got by. In
> the case of the latter it must seem pretty funny/sad that I am
> imagining configure flags.
>
> Thanks for the information on llvmpipe vs swr it is interesting
> (assuming those numbers are on a single PC). Sorry I mispredicted the
> quality of swr.
>
> On 4 November 2016 at 23:34, Chuck Atkins <chuck.atkins at kitware.com> wrote:
>>> So you should actually do (without removing anything out of files like
>>> I said to): --with-gallium-drivers=swrast,llvmpipe
>>
>>
>> Still no.  llvmpipe isn't a driver option.  --with-gallium-drivers=swrast
>> specifies to use the gallium software rasterizer.  This will eable softpipe
>> AND, if llvm is enabled (i.e.  --enable-gallium-llvm) also llvmpipe.  If you
>> want the fastest software render usable with osmesa then use swr.  OSMesa
>> requires that at least swrast be enabled, hence enabling swrast and swr.
>> This will give you OSMesa with softpipe, llvmpipe, and swr, with llvmpipe
>> being the default.
>>
>>
>>>
>>> I actually don't know terribly much about openswr I just assumed it
>>> would be optimized in someway for distributed systems that hinders non
>>> distributed ones or designed with distributed as priority leaving out
>>> minor optimizations or something.
>>
>>
>> Nope.  It's a common misunderstanding though since large distributed systems
>> without GPUs was the target as most other environments will have GPUs.  It's
>> developed entirely though for a single node with no awareness to distributed
>> systems.  Anything beyond that is the applications responsibilty.
>>
>>
>>
>>>
>>> And I am also not sure which version
>>> of OpenGL it supports or the extensions.+ the fact that it is the
>>> cause of a compilation error on the compilers system.
>>
>>
>> They're vary close to feature parity.  From the current git / master (just
>> past the 13.0 release):
>>
>> llvmpipe:
>> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8, 256 bits)
>> OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.1.0-devel
>> (git-e3e5b1a)
>> OpenGL version string: 3.0 Mesa 13.1.0-devel (git-e3e5b1a)
>>
>> swr:
>> OpenGL renderer string: Gallium 0.4 on SWR
>> OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.1.0-devel
>> (git-e3e5b1a)
>> OpenGL version string: 3.0 Mesa 13.1.0-devel (git-e3e5b1a)
>>
>> As for extensions, llvmpipe -> swr:
>> -GL_AMD_vertex_shader_viewport_index
>> -GL_ARB_copy_image
>> -GL_ARB_enhanced_layouts
>> -GL_ARB_fragment_layer_viewport
>> -GL_ARB_texture_buffer_range
>> -GL_ARB_texture_cube_map_array
>> -GL_ARB_texture_gather
>> -GL_ARB_texture_view
>> -GL_ARB_viewport_array
>> +GL_ARB_pipeline_statistics_query
>>
>>
>>> For mesa 12.0.1
>>> swr is behind llvmpipe with extensions (at least from 4.0 core). So I
>>> still say llvmpipe is probably preferable but perhaps swr does have
>>> some performance advantage or is less buggy.
>>
>>
>> It's come a long way since 12.0.1.  The current 13.0.0 release is a major
>> step forward since the inital release.  While I'm not one of the swr
>> developers we do make extensive use of it in production environments.
>> Regarding performance diffferences, you'll likely see an increase by a
>> factor of 10x - 100x over llvmpipe, that's typically what we see in VTK and
>> ParaView.