Softpedia reports
Valve tasked LunarG with improving the Intel drivers [for Linux], which are lagging a little bit behind the competition, at least in terms of graphics. Some of the latest Intel processors are pretty powerful and you would expect them to be able to perform much better, at least as well as on Windows, but there was a problem.
The guys from LunarG worked on a piece of software called GlassyMesa, which drastically improved Intel's shader compiler stack. They also made a number of improvements in the past few months, but none of these changes was reflected in the driver's performance. This led them to believe that there had to be a bottleneck somewhere along the line.
"We started to suspect there was a bigger bottleneck masking the improvements, and sure enough we were able to generate a test program that showed a huge performance issue with how the hardware samplers were working as compared to the OpenGL driver running under windows. Something was slowing down the samplers on Linux, and we were determined to find out what," wrote the devs on their blog.
They did all sorts of testing, but they don't have access to the way the hardware is set up. Therefore, they sent the test program to Intel and the engineers found the problem and corrected it. As you can imagine, the people at Intel didn't say anything about what they actually corrected.
In any case, LunarG also published some of the improvements they saw, and one of them is a 20% increase in game framerate.
- Left4Dead2 with frames that have hordes of zombies we've seen an increase of 17-25%
- Counter-Strike GO: 16-20%
- Lightsmark increased on a GT2 by 60% (HD4600) 4770
A kernel patch is required to make all these improvements available to users. It's not clear whether it will be available in Linux kernel 3.18 or 3.19, but it's coming. It also means that the kernel patch will be backported to the SteamOS kernel as well.
(Score: 2) by cosurgi on Thursday November 13 2014, @05:59PM
If they don't say what they changed, then there's a binary blob somewhere there that can do random stuff, like spying?
#
#\ @ ? [adom.de] Colonize Mars [kozicki.pl]
#
(Score: 2) by frojack on Thursday November 13 2014, @06:23PM
Maybe they turned off the spying? ;-0
It may indeed be a binary, but if that were the case it wouldn't take all that long to introduce it to the kernal. You could just make it available for end users to download.
I'm guessing it also required kernel changes for dealing with what ever changes were in whatever blob that might be used.
LunarG seems to be able to test it, so they must have the revised driver.
Making your users wait for the next kernel release seems like a very android thing to do, and not all that linux friendly.
They could just as well publish them on their own Drivers' site https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=13815 [intel.com] or
the download site https://01.org/linuxgraphics/downloads [01.org] which already has driver updates as recent as two days ago.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Thursday November 13 2014, @06:42PM
That particular snarky remark is nowhere in the real source(the lunarG blog). Maybe the softpedia writer made it up?
Up till now the intel driver has always been open source. SInce they don't specifically mention any binary blobs I don't just assume they are there.
(Score: 0) by Anonymous Coward on Thursday November 13 2014, @08:31PM
Yeah. My reading of that part of TFA was that this has previously worked 20 percent better under Windoze, so, under Linux, there was a flag somewhere that wasn't being set or wasn't being cleared.
Maybe Intel's documentation on that point is vague; maybe the comments in the source code are unclear or non-existent; maybe the label applied to the flag is a bit cryptic in its naming.
-- gewg_
(Score: 2) by FatPhil on Thursday November 13 2014, @09:15PM
I'm pretty sure I, and others, 've told you this before.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2, Informative) by cesarb on Thursday November 13 2014, @10:24PM
If you look at the blog post, you see references to a "chicken bit".
A "chicken bit" is a bit, usually on an undocumented hardware register, which disables a specific hardware optimization or feature. They exist so that, in case a problem is found in the field, the optimization can be bypassed or the feature can be disabled.
In this case, looking at the patch linked to by another commenter here, the hardware optimization was disabled by default, probably because it was a new optimization and the hardware designers weren't sure yet that it wouldn't cause problems. The patch simply sets the undocumented bit 9 in the undocumented "chicken3" register. Only the hardware designers, who have access to the internal documentation, can tell what enabling that bit actually does.
(Score: 3, Informative) by moondrake on Thursday November 13 2014, @07:10PM
I do not get the remark about how intel somehow did not say what they changed in the driver. Its all their in the open on the mailing list.
Besides, this is only on haswell, and it might not work for libva:
http://lists.freedesktop.org/archives/intel-gfx/2014-October/054416.html [freedesktop.org]
(Score: 2) by Marand on Friday November 14 2014, @12:49AM
A 20% improvement on shit is still shit.
Joking aside, any improvement is good, because Intel GPUs need all the help they can get. Also cool that it's a result of Valve's work with Linux.