Mesa 20.0 Now Defaults To The New Intel Gallium3D Driver For Faster OpenGL

[phoronix]

Phoronix: Mesa 20.0 Now Defaults To The New Intel Gallium3D Driver For Faster OpenGL

After missing their original target of transitioning to Intel Gallium3D by default for Mesa 19.3 as the preferred OpenGL Linux driver on Intel graphics hardware, this milestone has now been reached for Mesa 20.0!..

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.0-Defaults-Intel-G3D

[Aryma]

How about add support to Haswell and Ivy Bridge before discontinued i965 driver support ?

[Michael]

How about add support to Haswell and Ivy Bridge before discontinued i965 driver support ?

The graphics architecture is too different to trivially add it and no reward in doing so, so it will be left with i965 support.

[JacekJagosz]

I'm super happy, as this driver has been working without any problems for me, and in benchmarks it provided an improvement. I just wonder what will their support be going forward. Will Broadwell and Skylake still get updates or will it be consider old soon? What about new Vulkan features?

[Linuxxx]

I'm super happy, as this driver has been working without any problems for me, and in benchmarks it provided an improvement. I just wonder what will their support be going forward. Will Broadwell and Skylake still get updates or will it be consider old soon? What about new Vulkan features?

Contrary to popular belief, Intel's GPU architecture since Gen8 is actually quite advanced, as in supporting many modern concepts expected from a low-level API like Vulkan, which can be easily deduced from benchmarks:

Whereas nVidia's Kepler architecture is often faster in OpenGL workloads, Intel's newer GPUs see massive improvements from utilising Vulkan!

[ms178]

Contrary to popular belief, Intel's GPU architecture since Gen8 is actually quite advanced, as in supporting many modern concepts expected from a low-level API like Vulkan, which can be easily deduced from benchmarks:

Whereas nVidia's Kepler architecture is often faster in OpenGL workloads, Intel's newer GPUs see massive improvements from utilising Vulkan!

I am curious, what makes the Kepler architecture inherently worse for Vulkan workloads? I've had a GTX 670 2 GB VRAM and I guess 4 GB would have improved it on Vulkan quite a bit, I couldn't play Wolfenstein for a year due to their negelect of older generations with Vulkan drivers but at the end of the life of that card it did work eventually (also with some tricks to limit VRAM usage).

[ShFil]

@Michael
Imho vulkan and gallium nine is quite big deal for ivy bridge and haswell. Even igpu of sandy bridge is enough for fallout NV.

Broadwell is first gen with only "ultra slim" notebooks, there's quite big community preferring older design.

[Linuxxx]

I am curious, what makes the Kepler architecture inherently worse for Vulkan workloads? I've had a GTX 670 2 GB VRAM and I guess 4 GB would have improved it on Vulkan quite a bit, I couldn't play Wolfenstein for a year due to their negelect of older generations with Vulkan drivers but at the end of the life of that card it did work eventually (also with some tricks to limit VRAM usage).

Here's an interesting read from the YUZU (Nintendo Switch emulator) developers:

Vulkan and Its Shortcomings

While many uninformed users believe Vulkan to be a saviour and a single answer to all performance issues with OpenGL, even though their issues were because of their old hardware, Vulkan is not without any shortcomings. To understand these, let us first understand the situation with the Nintendo Switch’s GPU.

Maxwell and Pascal Nvidia GPUs are heavily optimized in hardware for D3D11 and OpenGL software. It seems that whenever Nvidia gets a chance to put something in the hardware, they take it. Since the Nintendo Switch’s GPU is a 2nd generation Maxwell GPU, it comes with additional features like ASTC textures and efficient half-precision float math.

Nvidia’s OpenGL driver is a scary monstrosity, it’s really fast. And to achieve this Nvidia has, over the years, invested resources heavily to make their OpenGL software (the driver) and their hardware really efficient. They have not only optimized their software to be fast for OpenGL, but also their hardware.

Both NVN and OpenGL expose Nvidia’s Maxwell hardware at its greatest. Lots of OpenGL features that are (sometimes wrongly) considered “legacy”, “old”, or even “emulated by the driver” are actually natively supported by the hardware (in the case of Nvidia). The problem arises when Switch games use these features.

Vulkan wasn’t designed with these features in mind. Some of these features were intentionally left out of the standard and the committee does not want to add them (not even as extensions) unless they really have to, or big companies behind CAD software require it. To sum it up, if a Switch game uses X feature supported natively by the hardware, and this feature is not available on Vulkan; it has to be emulated with a slower path or not emulated at all.

Here is a reduced list of features that are supported by Nvidia Maxwell hardware - exposed in OpenGL, but not supported in Vulkan:

Minus one to one depth space - (-1 to +1)	Used in nearly all Nintendo games
Quads, quad strips, polygons and line loops primitive topologies (e.g. rendering geometry with quads instead of triangles)	Used by Xenoblade Chronicles 2
Bindless textures	Used by Super Mario Party, Super Mario Odyssey and others
Legacy varyings (vertex attributes from the D3D9 era, like front colors and fog coordinates)	Used by Dragon Quest Builders
GL_CLAMP texture filtering	Used by Hollow Knight
uint8 indices (available as an extension, not supported on all vendors)	Used by Pokémon Let’s Go: Eevee and many others
Conditional rendering (available as an extension, but not exposed on AMD’s proprietary driver)	Used by Super Mario Odyssey and others
Copying depth images to color images and vice-versa (only on Nvidia)	Used by Super Mario Odyssey, Zelda Breath of the Wild and others
Alpha testing (eliminating pixels with some transparency)	Used by Smash Ultimate, Bayonetta and Astral Chain

Not having these features forces the Vulkan renderer to emulate them with slower techniques. At the moment of writing this article, features that are not known to be used by Switch games and some with extensions widely available, have been excluded from the above list.

In addition to these, Vulkan also doesn’t yet support a feature that has been supported by OpenGL since 1992 - a mutable pipeline state. In Vulkan, to define how a triangle is going to be rendered, you create a PSO (Pipeline State Object). For instance: “the clockwise side of a triangle is the front face”, “cull the back face of the triangle”, “render triangles”, “enable blending (transparency)”, “use these shaders”.

In case you want to change any of these attributes, an entire new pipeline has to be created. This has the advantage of eliminating “shader recompilations” that cause micro-stutter at boot on some games. The problem is that, again, Nvidia hardware can change this atomically.

If you want to change what faces of a triangle to cull (to render shadows for instance); you just queue the change on the GPU and it’s done. And on OpenGL too, it’s the same thing. yuzu currently doesn’t take much advantage of this feature, but we do have plans to optimize the current OpenGL backend for this.

In summary, for Switch emulation, OpenGL is the API to rule them all (unless Nvidia decides to release NVN on desktop, but that’s doubtful). Vulkan is great to take advantage of hardware that is not OpenGL friendly and it receives more love from some vendors and the market, so better tools, more extensions and better driver support will appear in the future.

[crymsonpheonix]

Here's an interesting read from the YUZU (Nintendo Switch emulator) developers:

There's a name for nvidia's behavior: "Embrace, Extend, Extinguish"

[nuetzel]

Here's an interesting read from the YUZU (Nintendo Switch emulator) developers:

If all of this would be really true --- how comes, that AMD's current GL Mesa driver (radeonsi) is in 'so many' cases faster than Nvidia's proprietary one? --- Even on cards with lower hardware specs?

The truth is that Nvidia had in so many cases there 'It's meant to play...' paths in place. Especially for OpenGL.