Repository navigation
packaging: fix LP E-core scheduling in OpenVINO 2026.2.1 - #72
Merged
Merged
Conversation
Include LP efficiency cores in shared executor accounting and allocation so GPU compilation does not dereference an empty streams table when the process affinity contains only LP cores. Keep feasible homogeneous stream widths when unused pools are smaller, preserve unpinned ECORE_ONLY restrictions, and distinguish the E/LP pair from legacy two-type mappings. Retain precomputed tables and pinned mixed stream behavior. Add native regression coverage and prepared-source guards for the corrected executor, and advance the OpenVINO provider RPM release to 2. Tracks openvinotoolkit/openvino#39088. Signed-off-by: Wisbendji Fimerlus <archledger236@gmail.com>
Regenerate the candidate manifest from the verified OpenVINO 2026.2.1-2 provider RPMs, retaining the three unchanged driver, firmware and loader providers. Align exact package dependencies and profile-generation policy with that provider set. Bump the candidate tools and metapackage release to 0.2.0-4 because their dependencies and embedded manifest change. Keep the CLI version, candidate stack release, production profiles and qualification status unchanged. Signed-off-by: Wisbendji Fimerlus <archledger236@gmail.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Backport the LP-efficiency-core scheduling fix to the OpenVINO 2026.2.1 provider introduced by #71. The original failure is GPU
compile_modelaborting when process affinity leaves only LP efficiency cores: openvinotoolkit/openvino#39088.Changes
ECORE_ONLYstreams representable by the existing arena interface.2026.2.1-2.0.2.0-4; the CLI remains0.1.1and the candidate stack remains0.2.0.Validation
The 40 repository recipe inputs and 13 archive/notice inputs match the previously validated release-2 build exactly. Its two independent builds produced 20 binary RPMs and one SRPM each: all 21 pairs are byte-identical, 40 SPDX documents were verified, and all 21 diffoscope checks passed. The actual RPM GPU runtime passed 54 cases against a fresh baseline with 12 expected crashes and 42 passing controls. Native coverage passed 437 active tests with one unchanged disabled test.
The regenerated manifest uses nine verified release-2 OpenVINO-family providers and three unchanged providers; it does not relabel old release-1 hashes. Profile generation first rejected this set under the old policy, then passed after the coupled policy/dependency updates.
Scope
Production profiles, historical hardware records and installed packages are unchanged. This does not qualify or promote a release. NPU/AUTO/HETERO, Windows, cgroups and physical multi-NUMA behavior are outside the GPU regression evidence. TBB reported its automatic core type in the physical probe, so no physical typed-placement guarantee is claimed. The type mapping assumes stable process affinity across topology initialization.
The tools RPM release-4 change has source/contract validation here; a new tools-RPM reproducibility or runtime-qualification result is not claimed. The existing paired-build evidence above applies to the OpenVINO provider RPMs.
Signed-off-by: Wisbendji Fimerlus archledger236@gmail.com