Re: Trouble compiling MesaGL : llvm intrinsics seem to be missing.
Albert Freeman <[email protected]>
| Newsgroups | gmane.comp.video.mesa3d.user |
|---|---|
| Message-ID | <CAHD8uZP-B0UOXMeo3H-KsBPGCpa=kyYP463M+euQUYcJpQ8eHA@mail.gmail.com> |
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 <[email protected]> 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. _______________________________________________ mesa-users mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-users