The patch doesn't go to the game, it goes to the Steam Client. Valve doesn't patch the 3rd party games they sell, those games developers do, Valve just hosts the files.
Originally Posted by kpedersen
Disabling the call home would take a single patch only a few lines long that turned it off permanently. Thus leaving the only games that may give you any trouble being those that use 3rd party DRM, which is always clearly stated on their purchase page, these games are usually those put out by EA and Ubisoft.
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.
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.
Originally Posted by Kivada
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.
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.
Originally Posted by stiiixy
- 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.)
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.
Originally Posted by dee.
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.
Interesting, 337 titles (removing the GFWL one). List rendered via links: http://pastebin.com/raw.php?i=QJeQYByh
Originally Posted by iniudan
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.
It's neat how LLVM seems to be leaking into everything providing interesting ways of speeding stuff up. Emscriptem is pretty awesome as well.
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.
Originally Posted by log0
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.
Originally Posted by tarceri
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.
Originally Posted by log0
There is NO official reference front end for GLSL. Sadly.
Originally Posted by tarceri
(Though if Mesa succeed with creating one, then maybe, just maybe AMD will use it for fglrx. Which would be really nice.)