Ben Widawsky of Intel's Open-Source Technology Center graphics team raised a new mailing list thread this morning entitled "[RFC] algorithm for handling bad cachelines." The comments he's seeking is how to enable support for a feature on Ivy Bridge and newer with there being an interrupt to tell the driver when a cache-line is going bad and to then use a new mechanism to re-map the bad cache-line. Widawsky's original plan was to add a module parameter that could read a file from user-space that is a simple list of the bad cache-lines to re-map. However, it doesn't look like that implementation will work but rather the list of bad cache-lines would need to be passed as a parameter itself.
The technical details isn't what's deserving of this article, but rather one of the comments made by Ben. "This is primarily for GPGPU, or perhaps *really* accurate rendering requirements." This work to handle bad cache-lines for Ivy Bridge and newer is primarily for GPGPU, such as OpenCL.
Besides being offering up even more compelling performance improvements, the integrated graphics processor on Ivy Bridge is also expected to debut OpenCL support (specifically, OpenCL 1.1). With current-generation Intel graphics not having OpenCL capabilities, Intel's open-source graphics driver developers haven't yet worked on any code. However, now with Ivy Bridge coming forward and the open-source graphics for it already being in place on Linux, it looks like they may be aspiring towards GPGPU/OpenCL support.
How they intend to implement the user-space side of the OpenCL support for Ivy Bridge and newer would be interesting. Intel's Linux graphics driver is the only major driver still relying upon a classic DRI driver in Mesa rather than Gallium3D. The Radeon and Nouveau (open-source NVIDIA) drivers are on Gallium3D and that's where they have the Clover state tracker for doing OpenCL. The Radeon/Nouveau OpenCL support is finally coming along and will hopefully be in shape by year's end. Clover / Gallium3D OpenCL won't work for Intel's classic Mesa driver so they would need to make some change.
For Intel CPUs on Linux there is currently an Intel OpenCL SDK for Linux with Sandy Bridge, but for now at least that's CPU-only and is not open-source software. If the Intel Linux graphics driver developers based their implementation on an open-sourced Intel OpenCL SDK that would be interesting since this multi-platform SDK is already in great shape and fully-conformant against the OpenCL 1.1 specification. However, we'll have to wait and see what ends up coming about for GPGPU on Intel Linux as Ivy Bridge enters the spotlight.
Times are certainly great for Intel on Linux with work going towards new features like GPGPU, catching up in OpenGL / GLSL compliance, continued work on performance optimizations, and open-source support already arriving for hardware that's still a ways from release: Haswell and Valleyview.