For our bugs, the bug reporting guide is at http://intellinuxgraphics.org/how_to_report_bug.html.. It is not complete, I admit, but it should be enough to get started.Quote:
I found some bugs when I did this test but the reporting was to complicated.
If you have ideas or suggestions on how to improve it, I'd be interested in hearing that.
Also, I have some very basic scripts which help with automatically identifying i915_error_states traces and map them into known issues. When I finish them, I'll be certain to post here a guide on how to use them. This should help at least in the initial issue identification I suppose..
All our new GPUs (the ones which we develop the drivers for - e.g., Ivy Bridge, and some future ones I am not allowed to talk about :)) are intended to be provided with opensource drivers, as usual.Quote:
Since the new gpus come from a third party there is poor opensource support, is there any plan to fix this introducing new intel gpus that could be supported?
The GPUs which come with closed-source drivers are licensed from PowerVR, and the license does not allows to open-source their support as far as I know...
If by "usable" you mean that they will come with working 2d and 3d modes, modesetting support, external outputs, suspend-resume and all the othes usually expected set of features, then yes, the idea is to provide all of this.Quote:
Are you saying that Ivy Bridge and subsequent GPUs are expected to be fully usable at introduction going forward?
The definition of "usable" is very subjective though. I've been using intel GPUs far before I jointed Intel, and I never had much usability problems except for the i810 line of GPUs. But of course, it changes for everyone - some people expect to play more games, some use more media decoding...
One possible objective criteria would be the number of issues in open-source bugzilla (namely, freedesktop.org one). For Ivy Bridge, at this moment, we don't have any critical issues which do not have a solution. At the same time, there are bugs for some sort of misrendering in some applications or non-passing piglit tests. If it affects the usability of your workloads it is hard to say; but it is all open for everyone to check via bugzilla, and verify if the intended use cases are expected to work without any problems or it is possible to expect any sort of issues. It is all public and open for everyone - this is how open-source works :).
I don't know the exact translation, but I assume that RC6 term is similar to CPU's C-states, where R would stand for Render. So RC6 is equivalent to Render C-State 6 (Deep Power Down).Quote:
1) What exactly is RC6?
2) Why does it repeatedly turn out to be non-functional? Is it some unforeseen incompatibility on Intel's side? Are there some BIOS bugs to work around?
3) Can we expect universal support for RC6 (and/or semaphores) in the future?
(Most of my knowledge about this matter comes from http://www.hardwaresecrets.com/article/611 which is the best non low-level resource I found about such details)..
As for RC6 support and problems, here is a short overview.
RC6 is a technology which allows GPU to go to a very low power consumption state when GPU is idle (down to 0V), so it results in a considerable power saving when this stage is activated. When comparing under idle loads with machine state where rc6 is disabled, we can get up to 40-60% improved power usage.
As a bonus, when those states are reached, we have additional thermal and power space for both CPU and GPU to go into a more aggressive turbo mode, so it can also improve the performance of intensive workloads by around 10%, and a bit more in some cases. Michael was the first one to publicly observe this in his RC6 overviews on phoronix by the way (thanks a lot, again!).
To exemplify, on battery power, when your machine is idle, it uses 50% less power. And when you run a CPU/GPU intensive application (for example, openarena), it gets additional +10 fps under load.
However, in some hardware and software configurations this power state results in unexpected issues (such as hangs or graphics corruptions). One co-related situation when you are almost certainly can expect issues is when you have VTd enabled (e.g., intel_iommu != off kernel parameter). Most of all our reports related to rc6 were traced down to this, but we don't have an explanation of why this is causing issues.
With 3.2-rc6, we tried to enable rc6 by default for the kernel, but it was quickly had to be reverted, as it turned out that in some cases we still have random crashes and hangs. The down side of this is that we don't know at the moment what is causing those issues, as only very few users has reported this problem, and, like always with rc6-related issues, none of Intel employees computers can reproduce said issues for now. So hopefully, if we discover what causes the problem there, we'll be able to workaround it just like we did with VTd, and enable it by default for Sandy Bridge on 3.3 kernel.
In general, if you do not experience random hangs and graphics corruptions when rc6 is enabled - I mean, issues which you haven't seen previously, you shouldn't have any issues with it at all. But if you do, we'll be very interested in hearing about it, because we are on a quest to locate machines which can reliably reproduce rc6-related problems. But so far, I'd say that around 99% of all machines should "just work" with it enable.
About rc6 support on different generations of Intel GPUs, here is the short resume:
For Ironlake (e.g., Intel Core i - pre-sandy machines), rc6 is disabled by default in all cases as it can cause similar issues as well, but can be activated by the same kernel parameter. On my Acer TimelineX, the enablement of rc6 makes its battery last 9 hours instead of 6 (powertop reports 7.5W when idle, down from 11W without rc6 enabled manually), and it causes no advert issues, but the mileage may vary between Ironlake GPUs.
On Sandy Bridge, right now it is always disabled as well by default. On my Lenovo T420 (sandy bridge), powertop reports around 12.5W with rc6 enabled, and around 19.5W with rc6 disabled.
For older graphics cards, this parameter makes no difference as kernel ignores it.
I hope it clarifies the things a bit :).
As for expectation for an universal support for rc6 and semaphores, "there is always hope for the future as tainted by past experiences" :) ( (c) Chris Wilson)
I cannot comment about the details of Intel products which were not announced yet, but I won't reveal much secrets by saying that the universal trend is to improve both power efficiency AND performance in the future products.Quote:
4) Whereas Intel's integrated graphics are not really competitive in the performance segment, they are vastly ahead regarding power efficiency. Can we expect further driver improvement in that regard?
From technical side, nothing is blocking it. The problem is, as usual, with patents and the way they are being used in modern world. Sadly, as long as software patents for such features exist, I do not expect much innovation in this area anymore. Specially when talking about open-source projects. But this is just my opinion.Quote:
5) Will we get S3TC?
Full OpenGL 3.x support requires some cooperation from the hardware. It is available on Ivy Bridge, yes, so GL 3.x should be supported on that architecture with hardware acceleration. For previous generations (Sandy Bridge and Ironlake), some parts of it must go through software-only implementations.Quote:
When can we expect OpenGL 3.3 support on Sandy Bridge?
When do you expect to have OpenGL 4.2 support on Ivy Bridge?
As for GL 4.2, it is too early to say anything. Of course, the Mesa team is interested in supporting all the latest and greatest GL versions in full, but I cannot answer when it will happen at the moment.