LLVMpipe Effectively At OpenGL 4.6 With Anistropic Filtering Now Supported

[zamadatix]

So llvmpipe is GL on cpu and lavapipe is Vulkan on cpu.
Gosh the namings in Mesa....

cpugl and cpuvk who have been more clear.

llvmpipe uses LLVM, there are other software rasterizers in Mesa that can do opengl as well (without LLVM) so "cpugl" would not only be more confusing but a naming conflict. Lavapipe doesn't use lava (just a reference to hot) but it's just hedging against the idea it probably won't be the only software Vulkan driver forever.

[Venemo]

So llvmpipe is GL on cpu and lavapipe is Vulkan on cpu.
Gosh the namings in Mesa....

cpugl and cpuvk who have been more clear.

Vulkan related things tend to have a volcano themed naming, or at least a 'v' in the name somewhere.

[illwieckz]

llvmpipe uses LLVM, there are other software rasterizers in Mesa that can do opengl as well (without LLVM) so "cpugl" would not only be more confusing but a naming conflict. Lavapipe doesn't use lava (just a reference to hot) but it's just hedging against the idea it probably won't be the only software Vulkan driver forever.

Indeed, unless I miss one there is currently three OpenGL CPU implementation on Mesa: softpipe, which I assume “soft” being for “software” to tell it's about “software rendering” and then naming it “softpipe” it's a bit like naming “cpugl” (and there was no Vulkan at the time, so GL was super obvious). Then we got “llvmpipe” wich is like “softpipe”, but relying on some llvm stuff for more efficiency. The last one is “swr” which was developped independently by Intel before merging it in Mesa, hence the different naming which also somewhat conflicts with “swrast” which is the filename of the driver providing llvmpipe and softpipe, because eh, people lack imagination.

So we can clearly see a pattern:

- softpipe because it's a software implementation (GL is assumed, is there anything out there?)
- llvmpipe because it's the same but with LLVM (GL is still assumed, that's still the only thing we do right?)
- lavapipe because we need another prefix, and it's about Vulkan ant not GL, and why not make a cool pun?

Dave Airlie talks about swrast as specific implementation itself in his blog post like if swrast would be living alongside softpipe and llvmpipe:

At the time we were trying to deprecate the classic swrast driver, and someone pointed out it had support for anisotropic filtering. This support had also been ported to the softpipe driver, but never to llvmpipe.

But I can't do LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=swrast like I do with others:

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=softpipe glxinfo -B | grep string
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: softpipe
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.3 (Compatibility Profile) Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL shading language version string: 3.30
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=llvmpipe glxinfo -B | grep string
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 10.0.0, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.1 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=swr glxinfo -B | grep string
OpenGL vendor string: Intel Corporation
OpenGL renderer string: SWR (LLVM 10.0.0, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.1 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=swrast glxinfo -B | grep string
libGL error: failed to create dri screen
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 24 (X_GLXCreateNewContext)
Value in failed request: 0x0
Serial number of failed request: 61
Current serial number in output stream: 62

Also, the Meson configuration option for softpipe and llvmpipe is named swrast, and the configuration for lavapipe is named swrast.

For example to build lavapipe, softpipe, llvmpipe and swr one would do:

meson build/ -D'vulkan-drivers'='swrast' -D'gallium-drivers'='swrast,swr'

So I don't know what means Dave Airlie when he says “the classic swrast driver, and someone pointed out it had support for anisotropic filtering. This support had also been ported to the softpipe driver, but never to llvmpipe” like if swrast, softpipe and llvmpipe was three different drivers. If he is around I would appreciate an answer on that. =)

[DebianLinuxero]

It would largely depends on the CPU and on the GPU, but expect the performance to be “very low”.

For example with my aging FX-9590 CPU and R9 390X GPU with Unvanquished (which only requires GL 3 anyway):

kind	model	driver	resolution	preset	fps
GPU	AMD R9 390X	radeonsi	3840×2160	ultra	110
GPU	AMD R9 390X	zink/radv	3840×2160	ultra	100
CPU	AMD FX-9590	llvmpipe	3840×2160	ultra	0.5
GPU	AMD R9 390X	radeonsi	640×480	lowest	300
GPU	AMD R9 390X	zink/radv	640×480	lowest	280
CPU	AMD FX-9590	llvmpipe	640×480	lowest	20

The 0.5 fps is not a typo, it's half of a frame per second, two seconds per frame. So unless you play on a VGA screen and are OK with textures having 64×64 resolution and can live with 20 fps, you may be able to play.

In fact the performance on that CPU with llvmpipe is close to what a Radeon 9500 from 2002 would bring (the Radeon 9500 can do 60 fps on some scenes but 10 fps on others, while the FX-9590 CPU does an average 20 fps across the scenes).

The llvmpipe driver is useful for debugging though. On the other hand I distribute llvmpipe with the Windows build of the NetRadiant level editor as an optional fallback for some broken Windows driver, for such application that is not a game, that can be usable.

I would like to know how performs the best ThreadRipper out there, though.

Side note: one may notice zink/radv seems to perform slightly less than radeonsi (not a big deal, it's really usable), and it's fun to notice zink/radv is somewhat matching amdgpu-pro or fglrx performances.

One may use LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=llvmpipe to run a game on llvmpipe, and AMD_VULKAN_ICD=RADV MESA_LOADER_DRIVER_OVERRIDE=zink to run a game over zink/radv. On my end it looks like zink/amdvlk does not work, and swr (alternative to llvmpipe) crashes, softpipe (another alternative to llvmpipe) is much much much slower than llvmpipe.

Thank you for your response.

[CochainComplex]

Its true the namescheme of the different mesa drivers can be quite confusing.....BTW does there exist some stacked overview ....like for these kernel up to window manager diagrams

[oibaf]

Indeed, unless I miss one there is currently three OpenGL CPU implementation on Mesa: softpipe, which I assume “soft” being for “software” to tell it's about “software rendering” and then naming it “softpipe” it's a bit like naming “cpugl” (and there was no Vulkan at the time, so GL was super obvious). Then we got “llvmpipe” wich is like “softpipe”, but relying on some llvm stuff for more efficiency. The last one is “swr” which was developped independently by Intel before merging it in Mesa, hence the different naming which also somewhat conflicts with “swrast” which is the filename of the driver providing llvmpipe and softpipe, because eh, people lack imagination.

So we can clearly see a pattern:

- softpipe because it's a software implementation (GL is assumed, is there anything out there?)
- llvmpipe because it's the same but with LLVM (GL is still assumed, that's still the only thing we do right?)
- lavapipe because we need another prefix, and it's about Vulkan ant not GL, and why not make a cool pun?

Dave Airlie talks about swrast as specific implementation itself in his blog post like if swrast would be living alongside softpipe and llvmpipe:



But I can't do LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=swrast like I do with others:

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=softpipe glxinfo -B | grep string
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: softpipe
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.3 (Compatibility Profile) Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL shading language version string: 3.30
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=llvmpipe glxinfo -B | grep string
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 10.0.0, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.1 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=swr glxinfo -B | grep string
OpenGL vendor string: Intel Corporation
OpenGL renderer string: SWR (LLVM 10.0.0, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.1 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.3.0-devel (git-6455ab6e5a)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=swrast glxinfo -B | grep string
libGL error: failed to create dri screen
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 24 (X_GLXCreateNewContext)
Value in failed request: 0x0
Serial number of failed request: 61
Current serial number in output stream: 62

Also, the Meson configuration option for softpipe and llvmpipe is named swrast, and the configuration for lavapipe is named swrast.

For example to build lavapipe, softpipe, llvmpipe and swr one would do:

meson build/ -D'vulkan-drivers'='swrast' -D'gallium-drivers'='swrast,swr'

So I don't know what means Dave Airlie when he says “the classic swrast driver, and someone pointed out it had support for anisotropic filtering. This support had also been ported to the softpipe driver, but never to llvmpipe” like if swrast, softpipe and llvmpipe was three different drivers. If he is around I would appreciate an answer on that. =)

There is also classic swrast: while softpipe and llvmpipe are Gallium based, classic swrast is using old mesa architecture, also used by old drivers like original radeon, r200, classic i915 and i965.

EDIT: source here: https://cgit.freedesktop.org/mesa/me...rc/mesa/swrast

So at least 4 OpenGL software renderers in mesa.

[tildearrow]

Typo: Mesa 20.3 should be Mesa 21.3!

How could I miss that!!!!!!

[JMB9]

How could I miss that!!!!!!

I just spotted it at second glance ...

We get old ... it's a good thing ...

[illwieckz]

There is also classic swrast: while softpipe and llvmpipe are Gallium based, classic swrast is using old mesa architecture, also used by old drivers like original radeon, r200, classic i915 and i965.

EDIT: source here: https://cgit.freedesktop.org/mesa/me...rc/mesa/swrast

So at least 4 OpenGL software renderers in mesa.

Oh great, thanks for such precious answer, now airlied's words sound more clear. Do you know how I can test that swrast like I do with others?

[oibaf]

Oh great, thanks for such precious answer, now airlied's words sound more clear. Do you know how I can test that swrast like I do with others?

You have to pass swrast to -Ddri-drivers , rather than -Dgallium-drivers .

IIRC you cannot build both softpipe/llvmpipe and classic swrast.

Note classic drivers are going to be removed in the future: https://gitlab.freedesktop.org/mesa/...requests/10153