While the Intel 830GM and 845G chipsets were first introduced more than one decade ago, their graphics driver support has been botched for much of the time. As of today though, Intel Linux driver developers think they have taken care of the longstanding stability issues with this now ancient hardware.
Since the introduction of the Graphics Execution Manager (GEM) in 2008 for managing the memory used by the Intel Linux graphics driver, the old i830/845 support has been a mess. Various attempts were tried by Intel Open-Source Technology Center developers like doing a GEM-free UMS driver
and various other shots to hopefully stabilize the support and make hardware acceleration work well. These attempts though haven't been a great success.
Back in August they worked their xf86-video-intel X.Org driver finally to a point where they could re-enable hardware acceleration by default
. However, with this enabled acceleration support, Intel developers still knew the hardware would hang at some point. "Enable acceleration by default on 830gm/845g. The GMCH on this pair of chipsets is notoriously incoherent, so the GPU is almost certainly going to hang at some point, though unlikely to hang the system and should automatically disable acceleration (and thence behave identically as if the acceleration was disabled from the start). Option NoAccel can be used to disable all 2D acceleration and Option DRI can be used to disable all 3D acceleration."
To some surprise when waking up this morning, it turns out that they think they have finally countered the i830GM/845G stability issues once and for all.
Chris Wilson began the announcement
for today's xf86-video-intel 2.20.16 release by rejoicing over this old Brookdale chipset support finally being stabilized. By making a small change, they discovered they can actually provide stable support for this hardware that is painstakingly slow by today's standards.
Rejoice! We have found a trick to make 830gm/845g stable at long last. Ever since the switch to GEM and dynamic video memory, those early second generation chipsets have been plagued by instability. The lack of flushing cachelines from the CPU to GMCH was eventually solved by using an undocmented bit, but 830/845 were still hanging under memory pressure. These deaths were all due to garbage finding its way into the command streamer, and they go away if we take a leaf out of the original driver and never reuse those pages for anything else. So for the first time ever, I have been able to complete running the test suite on an 845g, even whilst thrashing the page and buffer caches!
Other changes to the weekend release of xf86-video-intel 2.20.16 include running the SF stage as a single-thread for "Gen4" hardware to workaround some bugs, scanout fixes for Gen6/Gen7, tune batch flushing, and a handful of other fixes.
As usual, Intel's Chris Wilson continues to be the dominant developer working on this 2D X.Org driver with him taking responsibility for 53 of the changes in this latest point release while Jesse Barnes was the only other contributor with just one change.