Intel Media Driver 2026Q3 Adds Crescent Island Video Support: 3 Pipeline Paths [2026]

By Indie Kings | September 30, 2026

Updated September 30, 2026: Intel Media Driver 2026Q3 version 26.3.5 landed overnight with initial Crescent Island platform support. The release covers video decoding plus video encoding plus video processing for the new CRI platform.

Image: Crescent Island hardware. Credit: Intel via Phoronix.

What Landed In 26.3.5

Intel Media Driver 2026Q3 version 26.3.5 was released overnight on September 30 2026 by Sherry-Lin on GitHub, per Phoronix reporting by Michael Larabel and per the GitHub release page for intel-media-26.3.5. The headline change is initial support for the CRI platform, which is short for Crescent Island. The release notes list three enabled pipeline parts for CRI, namely video decoding and video encoding and video processing. That trio matters because it signals that Intel considers the media block on Crescent Island ready for early software enablement rather than reserved for a later quarterly drop.

The rest of the release is unusually small. Per Phoronix and per the GitHub release page, the only other changes are cumulative fixes around AV1 decode slice count validation plus fixed out of bounds handling in the VVC slice path. There are no other new platforms in this media driver release. There are no advertised performance claims in the release notes. There are no changes to the supported API surface called out in the short changelog.

Dependencies are pinned in the release. The release needs GmmLib version 22.10.2 and Libva version 2.24.1, per the GitHub release page. Those pins are routine for Intel quarterly media releases, but they are worth stating exactly because Linux distributions and compute cluster admins package these pieces together. A mismatch between the media driver and GmmLib is a common source of build failures and runtime init failures, so matching the tested combination saves time. Users building from source should fetch the listed tags before reporting issues.

Context helps explain why this release is notable despite the short changelog. Crescent Island bring up has been underway for months inside the Xe kernel driver and inside the Compute Runtime stack, per Phoronix coverage. Media was the missing piece in that public enablement sequence. With 26.3.5, the video decode and encode and post processing hooks now exist in the open media driver for the first time. That does not mean the stack is finished or tuned, but it does mean developers can start exercising the media paths on CRI hardware and in emulation and validation flows that consume the open driver.

This site previously covered Crescent Island in the context of its AI accelerator focus. This article covers the media driver release only. That distinction matters because Crescent Island is primarily an enterprise inference product, not a desktop graphics card and not a gaming GPU. The addition of video decode and encode support does not change its market position. It simply reflects that modern accelerators still need media blocks for ingest and preprocessing and transcoding adjacent to inference, and Intel ships those blocks through the same media driver used by client and server GPUs.

For version trackers, the naming is consistent with Intel quarterly cadence. The 2026Q3 label maps to the 26.3.5 version number on GitHub. The publisher listed on the GitHub release is Sherry-Lin. Phoronix reporter Michael Larabel flagged the release overnight. Readers who follow Intel open source graphics should treat the GitHub release page as the primary source for file lists and hashes and dependency tags, and treat Phoronix as the secondary news source that called out the CRI addition.

The practical takeaway for the what landed question is narrow and firm. If you need CRI video decode or CRI video encode or CRI video processing in the open stack, 26.3.5 is the first media driver that claims to provide it. If you need anything beyond that, such as a published codec support table or performance guidance or power guidance for media workloads on CRI, that information is not in this release. The next sections separate what Intel has disclosed about the hardware from what remains expectation rather than fact.

The Specs That Matter

Crescent Island is an enterprise AI accelerator built for inference, per VideoCardz citing Intel specifications. It uses the Xe3P architecture. VideoCardz explicitly corrects earlier reports that described the product as Xe3LP, so readers should use Xe3P when describing the graphics and media architecture generation. Architecture labels matter here because media capabilities and driver code paths often follow the IP generation, and an incorrect label can send readers to the wrong prior generation for comparison.

The scale figures disclosed so far point to a large PCIe card aimed at datacenter inference deployments. The product carries 32 Xe cores and 256 XMX engines, per VideoCardz citing Intel specs. Memory capacity is listed as up to 480GB of LPDDR5X, which is up from 160GB at the time of announcement, per VideoCardz citing Intel specs. Power is listed at 350W for an air cooled PCIe form factor, per VideoCardz citing Intel specs. Customer sampling is planned for the second half of 2026, per VideoCardz citing Intel specs. Each of those figures is attributed inline because Intel has not published a single consolidated CRI product page that this article can cite directly.

The memory figure deserves extra care. The move from 160GB at announcement to up to 480GB in current specs is reported by VideoCardz based on Intel materials. That is a large increase and it changes how readers should think about inference capacity and about possible media adjacent uses such as batch preprocessing. It does not by itself imply anything about video memory bandwidth or about encode session counts. No media session density guidance has been published for CRI. Readers should not convert memory capacity into video throughput claims without vendor data.

The power and form factor figures also set expectations for deployment rather than for media quality. A 350W air cooled PCIe card fits familiar server power envelopes and cooling designs. That makes CRI easier to evaluate alongside existing accelerators from a facilities point of view. It does not tell us how power is shared between compute and media blocks, or whether sustained concurrent inference plus transcode hits thermal limits sooner than inference alone. Those behaviors are normally characterized much later with production firmware and production drivers.

The architecture correction from Xe3LP to Xe3P is worth repeating because it affects forward looking comparisons. Phoronix expects CRI media behavior to land roughly on par with Panther Lake and Nova Lake, but that is presented as expectation rather than as a published fact. Xe3P lineage is part of the reason that expectation is plausible, since nearby client products on related IP tend to share media block generations. Plausible is not the same as confirmed. Only a published codec table or exhaustive driver enumeration can confirm feature parity.

The release contents table above keeps versions and changes separate so readers do not conflate the driver with its dependencies. The media driver itself is the deliverable that adds CRI. GmmLib and Libva are the tested companion versions. The AV1 and VVC items are the only other functional changes in the media driver. The VPL runtime is a separate companion project with its own release tag, covered in detail later in this article.

The disclosed specs table above uses VideoCardz as the cited source for each row because that outlet summarized the Intel specification materials referenced in this article. Readers looking for primary Intel pages should watch for an official product brief or specification update as sampling approaches. Until such a page is available, the careful formulation is that these figures are reported by VideoCardz citing Intel specs, not that they were pulled directly from an Intel Ark style listing.

What Is Still Unknown

No Crescent Island codec table has been published yet. That is the single largest unknown for video users. The 26.3.5 release notes confirm that decoding and encoding and processing paths exist for CRI, but they do not enumerate which codecs are enabled or which profiles or levels or bit depths are supported. Without that table, no responsible article can list H.264 or HEVC or AV1 or VVC support for CRI as fact. Any codec list presented today would be invention rather than reporting.

Phoronix expects CRI media capabilities to land roughly on par with Panther Lake and Nova Lake. That expectation is useful context for setting priors, because those client platforms represent the nearby Intel media baseline that readers already understand. It should be read as informed expectation, not as confirmation. The same Phoronix coverage that notes the CRI addition does not publish a CRI codec matrix. Treating an expectation as a specification would mislead buyers and developers who plan ingest pipelines around specific format requirements.

Several adjacent details are also unpublished. There is no public session count guidance for concurrent encode or decode on CRI. There is no public throughput guidance in frames per second for common resolutions on CRI media paths. There is no public quality comparison between CRI encode and established client encode paths. There is no public power split between inference and media when both blocks are active. Each of those data points normally arrives later through product briefs or developer documentation or independent testing on sampled hardware.

The driver state itself should be treated as early. Initial platform support in a quarterly media release typically means basic enablement and identification and plumbing, followed by fixes and tuning in later quarters. The AV1 and VVC fixes in 26.3.5 apply to the driver generally and should not be read as CRI specific polish. Readers should expect additional CRI specific media fixes as validation expands. Production planning should wait for at least one more quarterly cycle plus documentation before assuming stability.

Another unknown is how much of the CRI media block will be exposed through the usual Linux VA API paths versus reserved for proprietary inference adjacent SDK flows. The open media driver plus the pinned Libva version suggest the standard path is intended to work, but enterprise accelerators sometimes gate features by firmware or by software stack. The release does not describe any such gating. The absence of a restriction in release notes is not proof that no restriction exists in product firmware, so deployment testing on real hardware remains the only firm answer.

For readers keeping score, the unknown list is therefore short but important. Codec table status is unpublished. Performance status is unpublished. Session density status is unpublished. Power behavior under combined load is unpublished. API exposure edge cases are unconfirmed on production firmware. None of that diminishes the milestone that media enablement has started. It only means the milestone is a starting flag rather than a finish line for video users.

VPL Runtime Companion

The companion release is VPL GPU Runtime 2026Q3, tagged as onevpl 26.3.5, per Phoronix. It adds CRI support in parallel with the media driver. That pairing is expected because VPL, which stands for Video Processing Library, sits above the driver in common Linux video stacks and needs platform awareness to route work correctly. Updating both pieces in the same quarterly cycle keeps the open video path coherent for early CRI testing.

The same companion release folds Wildcat Lake into the Panther Lake family, per Phoronix. In practical terms, that kind of family mapping tells the runtime to treat Wildcat Lake with shared Panther Lake code paths rather than as a fully separate target. For developers, shared family handling usually means fewer special cases and faster enablement. For users, it means behavior on Wildcat Lake should track Panther Lake behavior unless a later note calls out an exception.

The companion release also adjusts HEVC encoding reference structure in the RAB path for better quality, per Phoronix. RAB here refers to a reference structure detail inside the encoder path. The reported goal is better quality rather than higher speed or lower power. No numeric quality delta is provided in the news summary used for this article. Readers should not convert a qualitative better quality note into a specific BD rate or VMAF claim without measured data.

Version alignment helps keep the stack straight. Media driver 26.3.5 and VPL GPU Runtime 26.3.5 share the same 2026Q3 version numbering, but they are separate repositories with separate tags. The shared numbers reflect coordinated quarterly releases rather than a single monolith. System builders should update them together when testing CRI, alongside GmmLib 22.10.2 and Libva 2.24.1 where applicable. Mixing a new CRI aware runtime with an older media driver without CRI support is an obvious way to produce confusing init errors.

There is also a wider enablement backdrop worth noting in one line. Compute Runtime 26.35.397 enables LEO for Nova Lake plus PISA portable ISA work, which shows quarterly graphics and compute enablement moving on several fronts at once. That item is separate from media and separate from VPL, and it is mentioned here only to place the CRI media milestone inside an active quarter for Intel open source graphics. Readers should not infer media behavior from compute runtime notes.

What It Means For Linux Users

For Linux users, the immediate meaning is simple. The open media driver now recognizes CRI and exposes the three core media pipeline parts for it. That unblocks early testing on distributions that track Intel quarterly releases or that build the driver from source. It does not guarantee that a current stable distribution package already contains 26.3.5 on the day of release. Users should check package versions before assuming support is present.

Build from source users have the clearest path. Fetch Intel Media Driver tag 26.3.5 from GitHub, fetch GmmLib 22.10.2, fetch Libva 2.24.1, and build the tested combination. Keep the VPL GPU Runtime at onevpl 26.3.5 if the workload uses the VPL path. Record the exact tags used so regressions can be bisected later. Early enablement periods produce rapid follow up fixes, so precise version notes matter more than usual.

Distribution package users should wait for the 2026Q3 stack to flow downstream. Media driver updates normally arrive through distribution graphics or multimedia repositories rather than through kernel updates alone. The Xe kernel driver work for CRI is a separate layer from this user space media driver, so a new kernel without a new media driver will not provide the CRI video paths described here. Both layers need to be present for end to end video acceleration.

Developers writing VA API applications do not need to learn a new API for CRI based on this release. The change is platform enablement inside existing decode and encode and processing entry points. Application code that already enumerates devices and checks profile support should work unchanged, subject to what the CRI hardware and firmware actually expose. Defensive capability checks remain the right pattern. Hard coding expectations from Panther Lake or Nova Lake into CRI application logic would be premature while no CRI codec table is published.

Server admins evaluating CRI for inference clusters should treat media as a secondary but useful capability. Video ingest and transcode adjacent to inference can reduce host CPU load and simplify pipelines that handle camera streams or user uploads before model inference. The presence of media paths in 26.3.5 makes that architecture plausible on CRI. Plausible still needs validation with real media formats and real concurrency targets before capacity planning can rely on it.

Users who do not have CRI hardware can largely ignore this release except as a signal. The only other changes are AV1 decode slice count validation and VVC slice out of bounds handling, which are maintenance fixes rather than features. There is no new client platform in this media driver drop. There is no reason to rush an update on stable client systems unless the maintenance fixes address a specific observed issue. Tracking the next quarterly release for additional CRI polish is the more useful stance.

FAQ

What is Intel Media Driver 2026Q3 version 26.3.5?
It is the quarterly 2026Q3 Intel media driver release tagged 26.3.5 on GitHub and published overnight on September 30 2026. Per Phoronix reporting by Michael Larabel and per the GitHub release page, its headline is initial CRI platform support.

What does CRI mean and what did the driver add for it?
CRI means Crescent Island, the enterprise inference accelerator. The driver adds video decoding plus video encoding plus video processing enablement for CRI, per the release notes summarized by Phoronix and the GitHub page.

What are the tested dependencies for 26.3.5?
GmmLib 22.10.2 and Libva 2.24.1 are the pinned dependencies listed with the release. Builders should use those exact tags to match the tested configuration.

Is there a Crescent Island codec support table?
No published CRI codec table is available yet. Phoronix expects rough parity with Panther Lake and Nova Lake, but that is expectation rather than confirmed specification.

What changed in the companion VPL GPU Runtime 26.3.5?
The onevpl 26.3.5 companion adds CRI support and folds Wildcat Lake into the Panther Lake family. It also adjusts HEVC encoding RAB reference structure for better quality, per Phoronix.

Should Linux users update to 26.3.5 now?
CRI testers and source builders should move to the coordinated 2026Q3 tags. Stable client users without CRI hardware can wait unless they need the AV1 and VVC slice handling fixes.

Bottom Line

Intel Media Driver 26.3.5 starts the CRI media story by enabling decode and encode and processing in the open stack. The disclosed hardware story remains an Xe3P inference card with 32 Xe cores and 256 XMX engines and up to 480GB LPDDR5X at 350W, per VideoCardz citing Intel specs, with sampling in H2 2026. The missing piece for video planners is still the codec table, and Phoronix parity expectations for Panther Lake and Nova Lake should not be treated as fact. Track the VPL companion and the next quarterly driver for polish, and build CRI tests against exact tags rather than mixed stacks.

Sources

Primary and news sources for this article are listed below. The GitHub page is the primary source for version and dependency facts. Phoronix and VideoCardz are the named news sources for release reporting and specification reporting.

Phoronix news post on Intel Media Driver 2026Q3

GitHub intel-media-26.3.5 release page

VideoCardz news post on Crescent Island specifications