Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Graphics Intel Upgrades Linux Games

Valve Sponsors Work To Greatly Speed-Up Linux OpenGL Game Load Times 202

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."
This discussion has been archived. No new comments can be posted.

Valve Sponsors Work To Greatly Speed-Up Linux OpenGL Game Load Times

Comments Filter:
  • Re:Oh wow (Score:5, Informative)

    by Anonymous Coward on Monday May 05, 2014 @05:43AM (#46917455)

    This won't affect Tux Racer's FPS. This will affect the load time on DotA 2, as well as other games which compile many shaders during load time.

  • by TheRaven64 ( 641858 ) on Monday May 05, 2014 @06:05AM (#46917523) Journal
    Caching of compiled shaders is supported by the OpenCL spec, and I presume by GLSL as well (I've not looked, but they generally use more or less the same code paths). The application is responsible for asking the driver for the cacheable version and then loading it again later. The problem is that, on first load, the game is effectively doing ahead-of-time compilation of all of its shaders and, previously, these were all done in a single thread. The multithreading part is a bit odd, because most DRI GPU drivers use LLVM on the back end and LLVM has supported multithreaded compilation for a few years.
  • by 91degrees ( 207121 ) on Monday May 05, 2014 @06:25AM (#46917573) Journal
    I think the argument is that nobody does so for several years.
  • by ledow ( 319597 ) on Monday May 05, 2014 @06:34AM (#46917599) Homepage

    I think you miss something:

    On Windows, OpenGL already competes with DirectX. Especially with the indie-game revolution of the last 10 years.

    On Linux, OpenGL wins 100% complete, hands-down. Because DirectX can't even run, let alone come close on performance.

    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. That fact that it has slightly less performance than the ideal scenario on one of those (it has to be said) more obscure platforms is pretty inconsequential (and now fixed). I haven't seen anyone complain about the OpenGL performance on those millions of smartphones that run it. I haven't heard much about DirectX on smartphones, however.

    Cherry-picking the battlefield for a comparison is no worse than cheating because you know you're going to lose.

  • by dingen ( 958134 ) on Monday May 05, 2014 @06:58AM (#46917661)

    And that's just the desktop. On phones, OpenGL wins all. On tablets, OpenGL wins all. On consoles, DirectX is only relevant for the Xbox, the rest runs OpenGL.

    The sphere of influence Microsoft has on the computing industry as a whole has been shrinking with each passing year for at least a decade now. The diminishing relevance of DirectX is yet another proof of this.

  • by jones_supa ( 887896 ) on Monday May 05, 2014 @07:03AM (#46917681)

    And that also has little do with how shaders are precompiled I think.

    As far as I know, you cannot precompile shaders anyway because the compiled code is hardware-dependent. The shader processors are different among architectures and manufacturers, and do not have a common baseline like "x86-64" to target, like we have on the CPU side.

  • by carlhaagen ( 1021273 ) on Monday May 05, 2014 @07:41AM (#46917825)
    ...both have functionality for accessing (and saving) a compiled shader so that it can be loaded and used instantly on next run.
  • by 91degrees ( 207121 ) on Monday May 05, 2014 @08:15AM (#46917967) Journal
    Uhm.. no. It's fairly similar to OpenGL and is based on the same principles, but certainly not the same. You don't really want the same. You have no need for the level of abstraction OpenGL provides.

    The smartphones use OpenGL ES which is actually a different API from OpenGL although it is a variant used fro embedded systems.
  • by slack_justyb ( 862874 ) on Monday May 05, 2014 @10:12AM (#46918771)

    You are smoking crack. The reason is because non-open drivers have had this implemented since word "go". That's what people wanted to use. Hence, the whole supply/demand thing kicking in. That someone is doing it in the open-source drivers means that they aren't getting the love they expected from the third party, and suddenly there is a business interest in having better support in the open driver.

    To draw a parallel, would you use the default drivers that come "out of box" on a fresh install on Microsoft Windows whatever, or would you actually go to the vendor's website and download their specific drivers? I think we're done here.

  • by dkegel ( 904729 ) on Monday May 05, 2014 @11:53AM (#46919621) Homepage
    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... [winehq.org] )

It is easier to write an incorrect program than understand a correct one.

Working...