It's The Season For Cleaning & Restructuring Within The Intel Linux Kernel Graphics Code

With Intel's Icelake/Gen11 graphics support considered production-ready when on the latest Linux graphics driver components and ahead of the real enablement around their highly anticipated Xe Graphics discrete hardware, it's making for a summer of clean-ups and restructuring within their kernel Direct Rendering Manager (DRM) driver.

There's still bug fixing and other minor work going into the Intel Gen11 Linux graphics driver code (along with new PCI IDs and the like), but now with the driver developers in the period between introducing major generational work and in particular Intel's dGPU plans that will require a lot of new driver code, there's been a lot of low-level code clean-ups and restructuring going on within the i915 DRM driver.

Among the sizable clean-up/restructuring patch series so far this month have been about splitting GT and display register access, compartmentalizing and changing around more code, and other work, on top of their usual swarm of patches each month. In particular with the patch series working to further compartmentalize the driver code, we can't help but wonder if it's gradually stepping in the direction of the necessary restructuring needed for their discrete graphics support.

A few months back I wrote about the patches underway in preparing the Intel Linux graphics driver for supporting device local memory that was later confirmed to indeed be preliminary work towards the Xe dGPU support. There's still much more driver work needed (contrary to some seeming to indicate the Linux kernel already has Xe support in place), and we're certainly expecting more in the months ahead.

If Intel is still on course for their initial graphics cards in 2020, we would expect initial enablement patches to be coming out in the next few months, certainly by year's end. Intel traditionally has been quite good about beginning to introduce new open-source "Gen" graphics support 1~2 years ahead of launch (at least for the original release schedules of the intended CPUs) to allow time for the code to propagate in the mainline Linux kernel and Mesa releases as well as then appearing in released Linux distributions. We certainly hope that will continue moving forward with the discrete graphics but wouldn't be surprised if the window is a bit narrower for the initial dGPU debut.

Anyhow, stay tuned for what will surely be an interesting open-source ride over the months ahead with Intel Linux graphics driver work.