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

[Albert Freeman]

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.