Slashdot Mirror
Valve Sponsors Work To Greatly Speed-Up Linux OpenGL Game Load Times
An anonymous reader writes "Valve Software has sponsored some interesting improvements developed by LunarG for the Mesa OpenGL library on Linux for deferred and threaded GLSL shader compilation. What these changes mean for users of the open-source Linux graphics drivers when running their favorite games is that OpenGL games now load a lot faster. As an example, the time from starting Dota 2 until the time actually being within the game is reduced by about 20 seconds on an Intel system. While Direct3D has offered similar functionality for a while, OpenGL has not, which has given it a bad reputation with regard to game load times until all shaders are compiled and cached — fortunately it's now addressed for OpenGL if using the Mesa Linux graphics drivers on a supported game."
When people ask me why I think linux sucks, this is one of the articles I will show them, it's 2014 and they just implemented this now...
Nice to see that OpenGL is being improved on Linux. I wonder, if somebody will implement caching of the compilation results next? The ccache does exactly this for C/C++, and it really helps in re-compilations of the same source. Of course this is a bit harder as it sounds, since one needs to verify the compiler and all related component versions before using cached result of a compilation.
Now I can get tuxracer to play at 997 fps, woo hoo!
OpenGL probably need to move to an IR for shaders. For thost that don't know, shaders are compiled by the driver today. Many games generate shaders with a combinatoric explosion which creates a lot of work for the driver. You can cache the result, which is often done, but you'll end up recompiling when the user change settings, etc.
The solution is off-line compilation to an IR, but of course everyone need to be aboard. The downside is that an IR spec will probably add 'DRM' considerations whereas today OpenGL shaders are shipped in source form.
Hip, hip, horray! :-)
== Jez ==
Do you miss Firefox? Try Pale Moon.
Who are sponsoring Valve? And why are the sponsors working on speeding up OpenGL?
Off topic, I know, but English might possibly be the most ambiguous human language in the world.
Does an OpenGL shader go through a complex optimization process, though? *maybe* a cursory one, but no where near as complex as LLVM.
Of course it does. A lot of them go through exactly LLVM!
Lets hope OpenGL can seriously compete with DirectX now that it has Valve support.
Can someone say something about the development effort to develop for both OpenGL and DirectX?
Maybe Microsoft will start letting everyone use their newest version of DirectX.
Drivers to be renamed "Black Mesa OpenGL Library"?
Well, 10% is not that big of a deal if you look at frame rates or such. However, If you turn that into dollars by comparing how much you have to pay extra for a better video card or processor to get that additional 10% boost, well then the whole situation looks a bit different. Then again this is a bit of dumb way to look at it...
When I was working on this sort of thing a few years ago, we were experimenting with a RISC machine with a fairly deep pipeline for shader operations.
It worked pretty well, and wouldn't be surprised if the big boys used a similar idea but optimisation for these is very architecture dependent and can be an NP complete problem. Even register allocation can be quite slow and they'll have to deal with that.
...both have functionality for accessing (and saving) a compiled shader so that it can be loaded and used instantly on next run.
So that's what is taking so long when starting Dota. I was wondering what part of loading a game could max out a thread on the CPU.
As an example, the time from starting Dota 2 until the time actually being within the game is reduced by about 20 seconds on an Intel system.
A WTF comment if I ever saw one. One would prefer at least two numbers to know how good the improvement is, though a percentage would also be better. On my Intel system Dota2 takes about 15 seconds now. And what's with the pointless Intel name-drop anyway.
Caching seems like a better solution to me, but multithreaded compilation is also good. Well done Valve
It's not lack of quality assurance, it's hostility towards quality assurance. And with quality assurance I don't mean bugs (there are lots of them), I mean basic usability. I have been told they specifically won't implement certain basic functionality just to be different from MS. With that attitude is no wonder that Linux is only used by "cultists" that use it more as a sign of group identity than as an OS.
Im also hoping they deprecate the libraries in Team Fortress 2 that are patent encumbered before someone hauls them into a texas court. W have perfectly reasonable alternatives to S3TC.
Installation and posix portability are also on my wishlist but thats sort of offtopic and not likely to happen without a bit of ecosystem backlash..
Good people go to bed earlier.
I have been told they specifically won't implement certain basic functionality just to be different from MS. With that attitude is no wonder that Linux is only used by "cultists" that use it more as a sign of group identity than as an OS.
Yes, because anyone wanting to avoid getting sued by Microsoft for infringing their patents is clearly a "cultist".
>
On Mac, OpenGL wins 100% complete, hands-down. Unless you count boot-camp, which is really just Windows.
You can try to paint a different picture all you like - fact is that OpenGL is not only "the same" as DirectX when you're on Windows, but also runs in a ton of other places.
Don't forget iOS and Android. Both of those use OpenGL ES.
So 20 seconds off the start of a game you'll probably play the next two hours. Duh!
Yes, there are some dickheads in charge of major Linux projects that refuse to do things users want. There are also dickheads in charge of major Microsoft proejct that refuse to do things users want. Same with Apple, Adobe, Oracle, and many other companies.
and no, it's not only used by cultists. It's used by smartphones, GPS, DVRs, servers, supercomputers, and other places. The desktop is more of an exception than a rule, but the desktop is the place where the OS is more visible.
This is my signature. There are many like it, but this one is mine.
Actually, for DOTA2 the load times were a pretty big issue for me. I could join the same games as the windows folk, but loading assets took a noticeably longer time, to the point where sometimes I'd get dropped from the game at start and then have to reconnect. This would only apply to the first game (afterwards I'd assume assets are cached). Ironically, performance on Linux once assets loaded is actually better, but this caused some pretty annoying issues.
FWIW, the Nvidia proprietary drivers have had a shader cache on Linux since the 290.03 release in late 2011 (search for GLShaderDiskCache). It probably helps Mass Effect 2 under Wine somewhat (here's a bug report from before the cache was added to the driver: http://bugs.winehq.org/show_bu... )
The DirectX texture format was based on S3TC, which is where the linux requirement for S3TC support came from. Everybody baked their textures into DDX(?) files and it was less of a hassle to just have linux support it than to either include raw or rebaked assets for OGL platforms (I'm including OSX here, since the two major porting platforms when this was going on were OS9/OSX and to a lesser degree Linux for Loki, Hyperion, VV, and the various other smaller companies who put out the effort.) As a result linux ended up supporting S3TC, albeit infringingly, and various games/ports/whatever else were set back by years/indefinitely.
you would potentially need to precompile for every chipset, driver version, and opengl version combination. its just a lot easier to do it for one. you could cache them between runs as well, as long as the video card, the driver, libopengl, and the os has not changed.
W have perfectly reasonable alternatives to S3TC.
I thought S3TC used the same concept as Apple Video (RPZA), which shipped as part of QuickTime 1.0 in 1991. Each 4x4 pixel block has two 15- or 16-bit colors and an array of sixteen 2-bit coefficients as to how these colors are mixed to produce the sixteen pixels in the block. What's the inventive step from RPZA to S3TC?
At least in 2D image manipulation, part of the reason that free software appears to lag by 20 years is that that's the duration of a patent.