Intel Preps OA Sync, Panther Lake Workaround & Other New Graphics Code For Linux 6.13
([Intel] 3 Hours Ago
drm-xe-next)
- Reference: 0001501422
- News link: https://www.phoronix.com/news/Intel-More-Xe-DRM-Linux-6.13
- Source link:
For the upcoming [1]Linux 6.13 cycle there is [2]Xe2 Ultra Joiner and GPU temperature monitoring support along with [3]initial Xe3 graphics support for integrated form with Panther Lake among the Intel graphics driver changes expected so far. Another batch of the Xe kernel graphics driver changes were submitted today for modern Intel graphics with this upcoming Linux 6.13 cycle.
The newest weekly drm-xe-next pull request was sent out today of new feature code destined for Linux 6.13. The highlights include:
UAPI Changes:
- Define and parse OA sync properties
Driver Changes:
- Add caller info to xe_gt_reset_async
- A large forcewake rework / cleanup
- A g2h response timeout fix
- A PTL workaround
- Handle unreliable MMIO reads during forcewake
- Ufence user-space access fixes
- Annotate flexible arrays
- Enable GuC lite restore
- Prevent GuC register capture on VF
- Show VFs VRAM / LMEM provisioning summary over debugfs
- Parallel queues fix on GT reset
- Move reference grabbing to a job's dma-fence
- Mark a number of local workqueues WQ_MEM_RECLAIM
- OA synchronization support
There's a new workaround for the Xe3 Panther Lake (PTL) graphics, various low-level code improvements, and more. For the mentioned OA synchronization support, it's explained in the prior [4]patch series rather well on its own:
"OA stream configuration submits batches which can be queued behind other (say workload) batches. Also, in some cases, additional delay is needed for an OA configuration to take effect, even after programming batches have completed executing on HW.
Mesa has use cases where a single workload is replayed repeatedly on the GPU, each time with a different OA configuration (or metric set), in order to capture different aspects of workload performance. This requires that OA configuration takes effect at precisely the correct input batch and also userspace is correctly informed when a new configuration has been activated (at batch granularity)."
The GuC lite restore feature is another one likely of interest. But the patch there is just setting the "GUC_CTL_ENABLE_LITE_RESTORE" flag without elaborating much in the actual patch description:
"The lite restore feature is supposed to be enabled by default."
Presumably this graphics micro-controller "GuC" lite restore feature is a faster/lighter restore method when running into any problems.
The full list of this week's drm-xe-next Intel patches for Linux 6.13 can be found via [5]this pull request .
[1] https://www.phoronix.com/search/LInux+6.13
[2] https://www.phoronix.com/news/Linux-6.13-Xe2-Ultra-Joiner-ARL
[3] https://www.phoronix.com/news/Intel-Xe3-Graphics-Start-Linux
[4] https://lore.kernel.org/all/20240918195330.3167756-1-ashutosh.dixit@intel.com/T/
[5] https://lists.freedesktop.org/archives/dri-devel/2024-October/475407.html
The newest weekly drm-xe-next pull request was sent out today of new feature code destined for Linux 6.13. The highlights include:
UAPI Changes:
- Define and parse OA sync properties
Driver Changes:
- Add caller info to xe_gt_reset_async
- A large forcewake rework / cleanup
- A g2h response timeout fix
- A PTL workaround
- Handle unreliable MMIO reads during forcewake
- Ufence user-space access fixes
- Annotate flexible arrays
- Enable GuC lite restore
- Prevent GuC register capture on VF
- Show VFs VRAM / LMEM provisioning summary over debugfs
- Parallel queues fix on GT reset
- Move reference grabbing to a job's dma-fence
- Mark a number of local workqueues WQ_MEM_RECLAIM
- OA synchronization support
There's a new workaround for the Xe3 Panther Lake (PTL) graphics, various low-level code improvements, and more. For the mentioned OA synchronization support, it's explained in the prior [4]patch series rather well on its own:
"OA stream configuration submits batches which can be queued behind other (say workload) batches. Also, in some cases, additional delay is needed for an OA configuration to take effect, even after programming batches have completed executing on HW.
Mesa has use cases where a single workload is replayed repeatedly on the GPU, each time with a different OA configuration (or metric set), in order to capture different aspects of workload performance. This requires that OA configuration takes effect at precisely the correct input batch and also userspace is correctly informed when a new configuration has been activated (at batch granularity)."
The GuC lite restore feature is another one likely of interest. But the patch there is just setting the "GUC_CTL_ENABLE_LITE_RESTORE" flag without elaborating much in the actual patch description:
"The lite restore feature is supposed to be enabled by default."
Presumably this graphics micro-controller "GuC" lite restore feature is a faster/lighter restore method when running into any problems.
The full list of this week's drm-xe-next Intel patches for Linux 6.13 can be found via [5]this pull request .
[1] https://www.phoronix.com/search/LInux+6.13
[2] https://www.phoronix.com/news/Linux-6.13-Xe2-Ultra-Joiner-ARL
[3] https://www.phoronix.com/news/Intel-Xe3-Graphics-Start-Linux
[4] https://lore.kernel.org/all/20240918195330.3167756-1-ashutosh.dixit@intel.com/T/
[5] https://lists.freedesktop.org/archives/dri-devel/2024-October/475407.html
phoronix