NVIDIA's OpenGL Shader Disk Cache For Linux

[phoronix]

Phoronix: NVIDIA's OpenGL Shader Disk Cache For Linux

One of the features that NVIDIA introduced in the 290.03 Beta Linux driver that was released on Friday is support for an OpenGL shader disk cache...

http://www.phoronix.com/vr.php?view=MTAwNDk

[deanjo]

Hmmm, Crosshair Formula V motherboard. Looking forward to that review to see how much stuff does not work in linux.

[rohcQaH]

Sounds like a feature that'd be pretty straightforward to include in mesa as well. Though I'm curious to know which applications it's supposed to improve?

If it was just about shaders being recompiled too often during a single application run, a memory-based cache would have sufficed. Moving the cache to disk sounds more useful to improve application startup times - but in those cases, trading CPU-load for IO-load isn't always better.

So does it actually improve things? And if so, by how much?

Michael! To the Benchmark-Cave!

[Shining Arcanine]

Sounds like a feature that'd be pretty straightforward to include in mesa as well. Though I'm curious to know which applications it's supposed to improve?

If it was just about shaders being recompiled too often during a single application run, a memory-based cache would have sufficed. Moving the cache to disk sounds more useful to improve application startup times - but in those cases, trading CPU-load for IO-load isn't always better.

So does it actually improve things? And if so, by how much?

Michael! To the Benchmark-Cave!

Edit: I misread your post. Anyway, the disk cache would probably help here.

[BlackStar]

Finally! This feature has been in discussion since 2003.

It also goes to show how the new shader binary extensions are all but useless. *This* is the way to go, not binary (precompiled) shaders and not application control of shader caching: the former because precompiled shaders are a bitch to optimize (the drivers decompile and recompile them, so no loading speed improvement either) and the latter because (a) most drivers don't expose the extensions, so (b) applications don't bother using them and.

Shader caching in the binary is logical, simple and efficient. Hash the shader and check if it's already available - done! (No need to reimplement this in every single application, when the driver can do it more efficiently anyway!) Hope the other IHVs follow suit.

[FreeBooteR69]

Hmmm, Crosshair Formula V motherboard. Looking forward to that review to see how much stuff does not work in linux.

I am using that motherboard right now on Archlinux with AD Phenomtm II X6 1100 processor. Works great so far.

Edit - opps i'm blind, mine is a crosshair IV. Still works great so far

[crazycheese]

Hmmm, Crosshair Formula V motherboard. Looking forward to that review to see how much stuff does not work in linux.

Sound chip, probably; the rest should do. But its SO overpriced and overmarketed like WOW I'd invest in board with ECC properties instead.

[deanjo]

Sound chip, probably; the rest should do. But its SO overpriced and overmarketed like WOW I'd invest in board with ECC properties instead.

Ya, for me personally the Sabertooth looks like a better buy. I need a lot of pci-e slots and the extra sata connectors are also appealing as well. I haven't looked yet but do the newer kernels support the Realtek 8111E yet?

BTW the Crosshair V like pretty much every other AMD board out there supports ECC ram.

[efikkan]

Interesting, needs some testing.

BTW: is anyone else having problems with creating 4.2 contexts in the recent drivers?

[rohcQaH]

Apparently mesa already has an in-memory shader cache:

http://cgit.freedesktop.org/mesa/mes...m/prog_cache.c

I still don't understand why this cache would benefit from being written to disk, though.