Intel Linux Graphics Driver Adding Device Local Memory - Possible Start of dGPU Bring-Up
A big patch series was sent out today amounting to 42 patches and over four thousand lines of code for introducing the concept of memory regions to the Intel Linux graphics driver. The memory regions support is preparing for device local memory with future Intel graphics products.
The concept of memory regions is being added to the Intel "i915" Linux kernel DRM driver for "preparation for upcoming devices with device local memory." The concept is about having different "regions" of memory for system memory as for any device local memory (LMEM). Today's published code also introduces a simple allocator and allowing the existing GEM memory management code to be able to allocate memory to these different memory regions. Up to now with Intel integrated graphics, they haven't had to worry about this functionality not even with their eDRAM/L4 cache of select graphics processors.
This device-local memory for future Intel GPUs is almost surely for Intel's discrete graphics cards with dedicated vRAM expected to debut in 2020. For the past several generations of Iris Pro with eDRAM, the Intel Linux driver has already supported that functionality. The patch message itself makes it clear that this is for "upcoming devices" but without enabling any hardware support at this time. This memory region code doesn't touch any of the existing hardware support such as the already mainlined Icelake "Gen 11" graphics code.
It's clear from the patches that this upcoming hardware is a ways out. With not hooking into any actual hardware support at this time, one of the patches is for providing fake LMEM (local memory) regions in order to exercise this new code path. Meanwhile we know that for months already Intel's Linux graphics driver developers have been running Icelake pre-production hardware in their labs, thus making us think this is early stage work for the dedicated "Xe" graphics upbringing as opposed to some magical Gen11 level addition the company hasn't talked publicly about yet. It would also be rather late for Intel to only now be publishing this code if it's for a product in the months ahead considering they are usually much more punctual in their Linux driver support in order to align it with the kernel release cadence and the kernel adoption cycles used by the major Linux distributions. This fake local memory region is just carving memory out of the system RAM for testing the new infrastructure. That fake support is also indicated that it will be upstreamed rather than a quick hack not for merging to the kernel, likely indicating it will be some time at least before their developers will have real Intel hardware locally with device local memory.
It wouldn't be surprising to see Intel's open-source Linux driver developers already preparing for future Intel discrete GPU products. With past generations of Intel graphics, we generally see the first Linux kernel patches roughly a year or so out from the actual hardware debut -- or the originally estimated debut for said products. While the design of their initial discrete graphics processor might not be finalized yet, it would make sense for their developers to begin making the necessary code restructuring such as for device local memory with discrete GPUs. That said, I wouldn't expect until later in 2019 at least before seeing more definitive open-source driver work around their discrete GPU efforts. Stay tuned to Phoronix for my close monitoring of the open-source landscape.
The concept of memory regions is being added to the Intel "i915" Linux kernel DRM driver for "preparation for upcoming devices with device local memory." The concept is about having different "regions" of memory for system memory as for any device local memory (LMEM). Today's published code also introduces a simple allocator and allowing the existing GEM memory management code to be able to allocate memory to these different memory regions. Up to now with Intel integrated graphics, they haven't had to worry about this functionality not even with their eDRAM/L4 cache of select graphics processors.
This device-local memory for future Intel GPUs is almost surely for Intel's discrete graphics cards with dedicated vRAM expected to debut in 2020. For the past several generations of Iris Pro with eDRAM, the Intel Linux driver has already supported that functionality. The patch message itself makes it clear that this is for "upcoming devices" but without enabling any hardware support at this time. This memory region code doesn't touch any of the existing hardware support such as the already mainlined Icelake "Gen 11" graphics code.
It's clear from the patches that this upcoming hardware is a ways out. With not hooking into any actual hardware support at this time, one of the patches is for providing fake LMEM (local memory) regions in order to exercise this new code path. Meanwhile we know that for months already Intel's Linux graphics driver developers have been running Icelake pre-production hardware in their labs, thus making us think this is early stage work for the dedicated "Xe" graphics upbringing as opposed to some magical Gen11 level addition the company hasn't talked publicly about yet. It would also be rather late for Intel to only now be publishing this code if it's for a product in the months ahead considering they are usually much more punctual in their Linux driver support in order to align it with the kernel release cadence and the kernel adoption cycles used by the major Linux distributions. This fake local memory region is just carving memory out of the system RAM for testing the new infrastructure. That fake support is also indicated that it will be upstreamed rather than a quick hack not for merging to the kernel, likely indicating it will be some time at least before their developers will have real Intel hardware locally with device local memory.
It wouldn't be surprising to see Intel's open-source Linux driver developers already preparing for future Intel discrete GPU products. With past generations of Intel graphics, we generally see the first Linux kernel patches roughly a year or so out from the actual hardware debut -- or the originally estimated debut for said products. While the design of their initial discrete graphics processor might not be finalized yet, it would make sense for their developers to begin making the necessary code restructuring such as for device local memory with discrete GPUs. That said, I wouldn't expect until later in 2019 at least before seeing more definitive open-source driver work around their discrete GPU efforts. Stay tuned to Phoronix for my close monitoring of the open-source landscape.
6 Comments