Valve Funds Glassy Mesa Development For Better Driver Performance

[vrodic]

I'm not conviced this will help that much for Intel GPUs. Developers from Intel have been optimizing shader compilers specifically for Dota 2 for some time without much impact on performance.

Dota 2 is probably memory bandwidth limited on Intel/Linux/OpenGL and that is likely the case for other games too.

So maybe modifying the OpenGL part of the game engine a bit to take memory bandwidth constraints of Intel GPUs into account would help more.

When I was looking into the issue of Intel GPU peformance on Linux many months ago there were no tools to profile memory bandwidth bottlenecks.

[log0]

I'm not conviced this will help that much for Intel GPUs. Developers from Intel have been optimizing shader compilers specifically for Dota 2 for some time without much impact on performance.

Dota 2 is probably memory bandwidth limited on Intel/Linux/OpenGL and that is likely the case for other games too.

So maybe modifying the OpenGL part of the game engine a bit to take memory bandwidth constraints of Intel GPUs into account would help more.

When I was looking into the issue of Intel GPU peformance on Linux many months ago there were no tools to profile memory bandwidth bottlenecks.

It would have been great if he had more numbers (Intel has a shader db, they use for benchmarking).

But he is already getting up to 20% performance improvements, after just 10 weeks hacking on it. Given how much time Intel devs spend on shader optimization, they should be quite interested imho.

It should be quite interesting for the gallium fraction too. They are already using llvm, would be only natural to switch to it completely.

[ssokolow]

And yet you guys fail to see where Steam isn't using a DRM scheme that violates a damn thing. Getting your games through steam is like buying direct download .flac files from bandcamp.

Steam keys can only be redeemed using the Steam client (as opposed to, for example, Desura keys, which can be redeemed at http://www.desura.com/gifts and downloaded within the browser). That violates the "no new closed-source non-games may be installed" part.

As for the rest, the hassle of manually keeping track of which games will still work if burned to DVD+R and then installed on a system that has never seen Steam or the Internet would make Steam a bigger hassle than just sticking to sites like GOG.com... and that's not even counting how time-intensive it would be for me to raise a stink and try to force a partial refund if a game update added DRM, forcing me to live with my DVD+R backups only.

There's a reason I don't buy the offerings marked as DRM-free on Gamesrocket. (They only let you redownload for a year after purchase. If I wanted DRM-free content where my "offsite backup" would eventually die off, I'd just torrent.)

Hell, if it weren't for my obsessive DVD+R backup habits, I would have lost the ability to play my GOG.com copy of Unepic when the most recent patch caused it to crash on startup under Wine.

You have a strict code of honour regarding software on your PC, yet you have some of the dirtiest piece of closed source buffoonary!

And then not use Steam!?

I did say "grandfathered". This stuff has been on my PC since I before I enacted that policy and what you see is the last dregs of closed-sourceness I haven't managed to kick out yet.

• BIOS: Next mobo I get, I'm going to specifically source something that can be reflashed with CoreBoot... especially since I don't trust something as big, bug-prone, and endowed with its own network drivers as UEFI. (My current mobo is the last pre-UEFI generation.)
• nVidia Drivers: I'm keeping a close eye on Nouveau and agonizing over whether to stop shunning Intel's CPU department for all of the nasty things they've done in the past.
  (eg. Their "So sue us. We'll bankrupt you in court." refusal to honor their part of the deal to borrow AMD's fabs to meet demand for the 486, their attempt to distract from the ARM-based OLPC XO foist with an expensive, half-assed Intel-based competitor, etc.)
• Flash: As soon as things like the HTML video tag, Shumway, and Gnash can handle my university's embedded video players, I'm gone. (I haven't been able to find any evidence that the Lightspark backends for PulseAudio-free audio have made it into a release yet)
• Skype: I'm still trying to figure out what about my NAT router breaks everything else. As soon as I do, I'm switching to something WebRTC-based as my "must Just Work?" solution for voice conferencing with non-technical people.
• Opera 12.x: Living on borrowed time. I only use it to test my creations and the Presto engine's status as a relevant slice of the browser market (outside the Opera Mini simulator Java applet) could drop below my threshold any day now. (I test for WebKit/Blink hiccups by using Midori, Arora, Chromium, and hoping Safari and Opera 15.x don't have any bugs over and above that.)

You use skype, then you might as well be using windows... backdoors ahoy.

First, I only turn it on for short periods of time (maybe 1-4 hours, every couple of months) when voice chat has been pre-arranged via an IM network I can connect to using Pidgin's unified UI.

Second, as I mentioned above, I'll be replacing it as soon as I can figure out why WebRTC doesn't work for me.

Finally, when I do get rid of it, I'll use it as an excuse to stop procrastinating a somewhat belated full system reinstall.

[curaga]

Here a list, if you fee like counting, but from a quick look it look more like at least 5% don't require steam. http://steam.wikia.com/wiki/List_of_DRM-free_games

Interesting, 337 titles (removing the GFWL one). List rendered via links: http://pastebin.com/raw.php?i=QJeQYByh

Quick google says there are (were) 3278 titles total. That'd be 10% are DRM-free, much better than what I expected, though a sizable portion is emulated, which doesn't really count.

[chinoto]

It's neat how LLVM seems to be leaking into everything providing interesting ways of speeding stuff up. Emscriptem is pretty awesome as well.

[tarceri]

It would have been great if he had more numbers (Intel has a shader db, they use for benchmarking).

But he is already getting up to 20% performance improvements, after just 10 weeks hacking on it. Given how much time Intel devs spend on shader optimization, they should be quite interested imho.

It should be quite interesting for the gallium fraction too. They are already using llvm, would be only natural to switch to it completely.

It seems there are a few people working on SSA for the existing IR's it will be interesting to see if this provides the same type of performance increase once optimisations have been applied without using llvm and adding yet another IR into the mix.

[log0]

It seems there are a few people working on SSA for the existing IR's it will be interesting to see if this provides the same type of performance increase once optimisations have been applied without using llvm and adding yet another IR into the mix.

I understand the desire to go with a custom solution, most certainly resulting in leaner code. But someone will have to implement the optimizations for the new IR first. And then there is OpenCL and SPIR(LLVM IR) which will be using LLVM anyway I think.

[tarceri]

I understand the desire to go with a custom solution, most certainly resulting in leaner code. But someone will have to implement the optimizations for the new IR first. And then there is OpenCL and SPIR(LLVM IR) which will be using LLVM anyway I think.

Yes there are pros and cons to each approach. But as far as "someone will have to implement the optimizations" you can also say the same thing about Glassy Mesa, I don't know all the details but as far as I understand it still requires quite a bit of work to get it up to par with the current glsl front end. I'd imagine it will be a big job just on the testing side to not cause a large amoung of regressions. One other interesting thing is that it completely replaces the current glsl parser also albeit with the official reference front end.

[przemoli]

albeit with the official reference front end.

There is NO official reference front end for GLSL. Sadly.

(Though if Mesa succeed with creating one, then maybe, just maybe AMD will use it for fglrx. Which would be really nice.)

[log0]

There is NO official reference front end for GLSL. Sadly.

(Though if Mesa succeed with creating one, then maybe, just maybe AMD will use it for fglrx. Which would be really nice.)

Look here: http://www.opengl.org/sdk/tools/glslang/