In that article over the weekend I noted that all of the various Linux graphics components within the kernel, Mesa, xf86-video-intel DDX, libdrm, and libva (VA-API) can now handle the Ivy Bridge hardware that will be launching within the next few months. The concern though was how reliable the initial hardware enablement actually is, since there's been recent reports of an IRQ issue that is being fixed in Linux 3.3, etc. With Sandy Bridge the Linux support was technically there at launch, but we all remember the early issues there.
To hopefully alleviate some of these concerns, Eugeni Dodonov of the Intel Linux graphics team at the Open-Source Technology Center, clarified some things in an email to me, which I have shared below.
The issue is the https://bugs.freedesktop.org/show_bug.cgi?id=38862 bug, back from June 2011. It manifests itself as some occasional hick-ups in rendering when running some 3d workloads and intel-gpu-tools test suite. This is not specific to Ivy Bridge, it happens on Sandy Bridge as well, but as SNB GPU is much slower than IVB, it is much less often and more difficult to observe.
For example, to illustrate what happens, when you run openarena benchmark, it is possible to observe a half-second delay between some frames, it could happen roughtly once each 10 benchmark runs (on my test machines). Nothing too critical, but very annoying, at least to me.
What happens here is the following sequence of events (on a very high level description):
- the kernel setups a workload to process to the GPU, and associates a seqno with it
- when processing finishes, GPU sends an interrupt saying that it is done, and specifies which seqno this workload is corresponding to.
- during some rare circumstances, what happens is that GPU sends the interrupt request, but the seqno number (which is stored in a different page) is not yet updated with correct number, therefore kernel receives an interrupt, but the corresponding seqno was not yet updated to a correct value. So kernel print the 'missed IRQ' message in dmesg, and goes on. Later, the next irq arrives, this time the seqno is already updated, and everything continues. But this delay between different interrupts is responsible for a small noticeable rendering delay (around a quarter-second delay in rendering).
Daniel's fix (along with Chris and Eric ones) solve the issue in different ways. Chris' patch adds a new kernel parameter to setup a delayed timer, which detects such missing seqno updates and starts a backup timer, which keeps re-reading the same memory page until the right seqno arrives. Eric's patch does the same, but without a timer (e.g., it read the same page in a busy loop until the seqno arrives). And Daniel's patch solves the issue but telling the GPU not to sleep when we expect to read the seqno number - and this seems to solve the issue for good.
Besides this issue, we haven't had any other Ivy Bridge-related critical issues for a couple of weeks now. There are still some rendering corruption and failing piglit tests, but as far as I know, we don't have any truly blocking or critical bug related to Ivy Bridge support. For the past year, we also have a periodic once-a-month call with all our OSVs (Canonical, Red Hat, Novell, HP, Google, etc, among many others) to discuss all the topics related to our drivers, and so far, things look pretty much stable for Ivy Bridge and Sandy Bridge.
So it looks like the "out of the box" support for Intel Ivy Bridge hardware will hopefully be good at launch! Well, assuming you're using Ubuntu 12.04, Fedora 17, or other new distributions out there when Ivy Bridge begins shipping in the next few months. Stay tuned for some Phoronix benchmarks and plenty of other Linux tests of the next-generation Intel CPUs that I'm very excited about.
At yesterday's Intel press conference for CES 2012, Linux didn't get any mentions at all. Hopefully soon I'll have a new Intel ultra-book soon to run a battery of Linux tests.
Now if Intel would just provide a Medfield Linux support update and clarify the driver situation/plans...