Mesa's Rusticl Lands Support For Shared Virtual Memory & Intel Subgroups
([Mesa] 4 Hours Ago
Rusticl)
- Reference: 0001549817
- News link: https://www.phoronix.com/news/Rusticl-SVM-Merged-Mesa-25.2
- Source link:
Rusticl as Mesa's Rust-based OpenCL driver implementation for Gallium3D drivers is ending the month of May on a high note... Merged this week was support for the Intel Subgroups OpenCL extension (cl_intel_subgroups) and before getting to that on my TODO list, an even bigger item was merged: Shared Virtual Memory (SVM) support.
Merged yesterday was [1]cl_intel_subgroups support for Rusticl . This was sought after as the Intel version of the subgroups OpenCL extension is needed for software like Intel's oneDNN.
The [2]extension spec explains of cl_intel_subgroups:
"The goal of this extension is to allow programmers to improve the performance of their applications by taking advantage of the fact that some work items in a work-group execute together as a group (a "sub-group"), and that work items in a sub-group can take advantage of hardware features that are not available to work items in a work-group. Specifically, this extension is designed to allow work items in a sub-group to share data without the use of local memory and work-group barriers, and to utilize specialized hardware to load and store blocks of data."
Separately, merged today for Mesa 25.2-devel for the Rusticl code is implementing [3]Shared Virtual Memory (SVM) support! After being under review the past four months, the SVM support for Rusticl has been merged! This is thanks to the great work of lead Rusticl developer Karol Herbst of Red Hat.
Before getting too excited over Shared Virtual Memory support in Rusticl, SVM driver support for the AMD RadeonSI and Intel Iris Gallium3D drivers is still pending. There are open merge requests but as of writing those driver-specific pieces haven't been merged.
The [4]SVM merge request implements cl_ext_buffer_device_address, the Shared Virtual Memory requirements by Shared Virtual Memory for OpenCL 2.0+, and then preps for the Intel cl_intel_unified_shared_memory extension that is needed by some SYCL implementations.
Quite an exciting week in Rusticl land and hopefully the SVM hardware driver pieces will all be sorted out in time for next quarter's Mesa 25.2 release.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31772
[2] https://registry.khronos.org/OpenCL/extensions/intel/cl_intel_subgroups.html
[3] https://www.phoronix.com/search/Shared+Virtual+Memory
[4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942
Merged yesterday was [1]cl_intel_subgroups support for Rusticl . This was sought after as the Intel version of the subgroups OpenCL extension is needed for software like Intel's oneDNN.
The [2]extension spec explains of cl_intel_subgroups:
"The goal of this extension is to allow programmers to improve the performance of their applications by taking advantage of the fact that some work items in a work-group execute together as a group (a "sub-group"), and that work items in a sub-group can take advantage of hardware features that are not available to work items in a work-group. Specifically, this extension is designed to allow work items in a sub-group to share data without the use of local memory and work-group barriers, and to utilize specialized hardware to load and store blocks of data."
Separately, merged today for Mesa 25.2-devel for the Rusticl code is implementing [3]Shared Virtual Memory (SVM) support! After being under review the past four months, the SVM support for Rusticl has been merged! This is thanks to the great work of lead Rusticl developer Karol Herbst of Red Hat.
Before getting too excited over Shared Virtual Memory support in Rusticl, SVM driver support for the AMD RadeonSI and Intel Iris Gallium3D drivers is still pending. There are open merge requests but as of writing those driver-specific pieces haven't been merged.
The [4]SVM merge request implements cl_ext_buffer_device_address, the Shared Virtual Memory requirements by Shared Virtual Memory for OpenCL 2.0+, and then preps for the Intel cl_intel_unified_shared_memory extension that is needed by some SYCL implementations.
Quite an exciting week in Rusticl land and hopefully the SVM hardware driver pieces will all be sorted out in time for next quarter's Mesa 25.2 release.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31772
[2] https://registry.khronos.org/OpenCL/extensions/intel/cl_intel_subgroups.html
[3] https://www.phoronix.com/search/Shared+Virtual+Memory
[4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942
coder