Hi Robie, Thanks for the review. Responses to your questions inline below.
> First, you haven't said what kind of upstream version / release policy exists, what that means for users, and which type of upstream releases you want included. Each project requested handles release versions slightly differently, but we are not requesting any particular type of upstream release. Enablement efforts would focus on bringing in the latest stable, tested version of each package with support for the new hardware in question. > For example, will you expect to SRU a major version bump from upstream? Yes, for instance, the media driver has been bumped to 25.1.0 in Plucky already, so I presume that our next hardware enablement cycle will involve a major version bump. The same can be true of compute runtime, which has had three major version bumps since August. It would be difficult to avoid in the more active projects. Generally speaking, our intent is to submit whichever version of each package is recommended for hardware enablement. > Does upstream release policy allow such a release to change behaviour for existing users? This will depend on the package. I cannot say “no”, since compute runtime recently introduced a build flag to either build for everything before Gen 12 or everything after. On the other hand, packages like the iHD media driver offer pretty consistent support going back to Broadwell despite being discontinued 7 years ago. Since we have a complex graphics stack, we can understand that something of this nature will eventually occur. However, the intent of our partnership is to reduce these instances by collaborating earlier in the enablement process. This allows us to ensure that we approve of any behavior changes early on before we get to the point of SRU submission. > What about upstream policies on dropping (or not) support for existing hardware that they might consider EOL? What assurances can Ubuntu users have that *their* hardware won't regress in support as a result of an upstream decision that Ubuntu, as a distribution, is supposed to insulate our users from? According to Intel: “Intel has a long-standing commitment to supporting open source graphics, and we have been actively contributing to the open source community for many years. Our open source drivers and software are designed to provide robust and reliable support for a wide range of hardware, and many of these packages have been maintained for over a decade. This commitment helps ensure that our hardware continues to be supported across various distributions, including Ubuntu. For any of our releases we do our best to ensure that newly added HW support does not result in regression in any of previously supported use cases. While upstream decisions can sometimes influence hardware support, we work closely with our partners and the broader open source community to minimize any potential impact. Our goal is to provide a seamless experience for users and to ensure that your hardware remains supported and functional.” > For example, something I think we must avoid is to do a version bump in > an SRU and then get a user bug report telling us that their hardware is > regressed, only to find that upstream made a deliberate decision to drop > support for that hardware because they consider it to be EOL, and we > didn't notice. If we're going to take new upstream versions into our stable > releases without further review, we must have some assurance that, through > our process or documented upstream > policies as appropriate, that situation cannot arise. Agreed that this is a good concern to track, since it can be easy to miss less-emphasized details in a version bump and end up with an unpleasant surprise. We can add that point to the SRU bug template mentioned in the wiki (https://wiki.ubuntu.com/IntelGraphicsUpdates), which would ensure that this conversation is had before submission and can be an easy basis for rejection if a potential EOL is unreasonable for an LTS release. > How does this apply in the context of your statement "The smaller > projects listed are dependencies of the larger projects, so full version > bumps will be needed in order to meet minimum build requirements"? If the previous suggestion of adding EOL information to the SRU template, we would apply the same concept to smaller projects and larger projects by listing any new EOL in any package. Though if the smaller projects EOL a particular platform, that will presumably carry forward to at least portions of the functionality of the larger project. By tracking any such instances early on, we would be able to list these concerns in the HWE request. > Along similar lines, since these SRUs are for hardware enablement, > what's the hardware testing matrix you intend to use? Are you relying on > sampling, or do you intend to test against all hardware that you have > previously "enabled"? How will you ensure that support for older, more > obscure hardware will not be regressed? At the moment, we are sampling Intel TGL, ADL, RPL, LNL, and BMG for validating our integration. As our process matures with increased test coverage, we will begin expanding to more hardware variations, which will allow us to automate our hardware support verification process. On a package level, Intel validates new versions on all platforms for which they claim support. > Major changes should be called out in the SRU template, especially > where changed behavior is not backwards compatible. > How do you intend to detect these cases? Either through Intel’s documentation, testing done by our partner team at Intel, or testing we do ourselves. Any major changes we have encountered so far have been clearly communicated before any request for version bump. > What is upstream's test coverage like, especially for the dependency > packages? Our normal requirements to take upstream microreleases are > documented at > https://documentation.ubuntu.com/sru/en/latest/reference/requirements/#new-upstream-microreleases . > Are those conditions met for all of the packages listed? According to Intel: “For every package we release, we conduct comprehensive testing across all supported hardware. Our testing encompasses conformance tests, applications, and benchmarks, ensuring full coverage of all APIs and ABIs. We utilize a variety of test suites and tools, including open-source options such as Khronos CTS and ffmpeg/gstreamer, as well as open-source solutions developed by Intel, such as Level Zero CTS, Cassian, libvpl-tools (https://github.com/intel/libvpl-tools), and various other samples, applications and benchmarks. Some examples for the testing done below: Conformance tests Level Zero Level Zero CTS https://github.com/oneapi-src/level-zero-tests/tree/master/conformance_tests OpenCL KhronosCTS https://github.com/KhronosGroup/OpenCL-CTS/tree/main/test_conformance Compute Samples https://github.com/intel/compute-samples Compiler Cassian https://github.com/intel/cassian Performance Microbenchmarks https://github.com/intel/compute-benchmarks Applications: Examples: BLENDER, Compubench, Geekbench, Luxmark” >From a per-package perspective, here are the packages that will be covered by the listed tests and tests being developed at Canonical: - intel-gmmlib - KhronosCTS, Compubench, Geekbench, Luxmark, Cassian, and Compute Samples (via intel-compute-runtime) - ffmpeg vaapi-enabled testing - Gstreamer testing - VPL Tools - libva - libva-utils (vainfo) - FFmpeg testing - Gstreamer testing - VPL Tools - libva-utils - Provides vainfo, a tool to check proper media stack initialization and provide information about that stack – tested with libva-utils samples - intel-media-driver (free and non free) - libva-utils (vainfo) - FFmpeg testing - Gstreamer testing - oneVPL sample - level-zero - Level Zero CTS - Cassian, and Compute Samples (via intel-compute-runtime) - intel-compute-runtime - KhronosCTS, Compubench, Geekbench, Luxmark, Cassian, and Compute Samples - onetbb - Blender (blender.org) testing and level-zero-raytracing-support unit tests (https://github.com/intel/level-zero-raytracing-support) via level-zero-gpu-raytracing - libvpl - Ffmpeg testing - Gstreamer testing - VPL Tools - onevpl-intel-gpu - Ffmpeg tools - Gstreamer testing - oneVPL sample - libvpl-tools - Is a package for libvpl validation tools - intel-vc-intrinsics - KhronosCTS, Compubench, Geekbench, Luxmark, Cassian, and Compute Samples (via intel-compute-runtime) - level-zero-gpu-raytracing (added to the request since it is a package now) - Blender testing - Level-zero-raytracing-support unit tests: https://github.com/intel/level-zero-raytracing-support In addition to the testing that Intel performs, they are helping to develop more testing for the Intel graphics stack at Canonical. In the initial stages, there will be a fair amount of overlap with Intel’s testing (such as conformance tests) since we also want to take advantage of extensive open-source test suites to validate integration efforts. Later on, we can develop further testing to address additional, Ubuntu-specific cases that may not be handled elsewhere. Thanks, Shane (@mckeesh) On Thu, Feb 20, 2025 at 8:57 PM Robie Basak <[email protected]> wrote: > Hi Shane, > > FTR, there's a related discussion happening in > https://bugs.launchpad.net/ubuntu/+source/intel-gmmlib/+bug/2098413 > > For a more general documented special case, I think there are some other > things we need to specify. > > First, you haven't said what kind of upstream version / release policy > exists, what that means for users, and which type of upstream releases > you want included. For example, will you expect to SRU a major version > bump from upstream? Does upstream release policy allow such a release to > change behaviour for existing users? What about upstream policies on > dropping (or not) support for existing hardware that they might consider > EOL? What assurances can Ubuntu users have that *their* hardware won't > regress in support as a result of an upstream decision that Ubuntu, as a > distribution, is supposed to insulate our users from? > > For example, something I think we must avoid is to do a version bump in > an SRU and then get a user bug report telling us that their hardware is > regressed, only to find that upstream made a deliberate decision to drop > support for that hardware because they consider it to be EOL, and we > didn't notice. If we're going to take new upstream versions into our > stable releases without further review, we must have some assurance > that, through our process or documented upstream policies as > appropriate, that situation cannot arise. > > How does this apply in the context of your statement "The smaller > projects listed are dependencies of the larger projects, so full version > bumps will be needed in order to meet minimum build requirements"? > > Along similar lines, since these SRUs are for hardware enablement, > what's the hardware testing matrix you intend to use? Are you relying on > sampling, or do you intend to test against all hardware that you have > previously "enabled"? How will you ensure that support for older, more > obscure hardware will not be regressed? > > > Major changes should be called out in the SRU template, especially > > where changed behavior is not backwards compatible. > > How do you intend to detect these cases? > > What is upstream's test coverage like, especially for the dependency > packages? Our normal requirements to take upstream microreleases are > documented at > > https://documentation.ubuntu.com/sru/en/latest/reference/requirements/#new-upstream-microreleases > . > Are those conditions met for all of the packages listed? > > The resolution for my comments in LP: #2098413 also need incorporating > into this document once they are resolved; no need to duplicate that > discussion here. This includes ensuring that the test plan is public, we > do not SRU "partial" enablements by only testing parts and not the full > deliverables, etc. > > Robie >
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
