Mesa's Vulkan driver for Intel, "ANV," has expanded the scope of presenting compressed memory types to general Vulkan buffers. Through two commits merged on August 18, a feature that was initially added as a setting for DXVK has moved to become the default behavior of the normal buffer path. According to Mesa's performance CI, Direct3D 11 traces routed through DXVK showed up to a 5.26% speedup on Battlemage and up to 4.85% on Panther Lake.
Looking at the numbers alone, one might assume that some form of "framebuffer compression" for Intel GPUs has been enabled. However, what ANV handles here is not the display framebuffer. This is a change that allows Vulkan applications to choose a compressed memory type accompanied by AUX metadata for CCS (Color Control Surface), applied to the VkBuffer used during rendering. This differs from the Linux kernel's display feature FBC both in target and in the layer that controls it.
DXVK is a layer that translates Direct3D 8, 9, 10, and 11 into Vulkan within a Wine environment. The measured values here are not a general performance guarantee for games, but results from Mesa performance CI's DX11 traces run four times each. Even so, they serve as material showing that a low-level choice—which memory type the driver presents to applications—can influence performance even through a translation layer.
From a DXVK-specific setting to ANV's default path
The first commit, ac512a9c, added anv_enable_buffer_comp=true for the DXVK engine to ANV's default settings file, 00-anv-defaults.conf. At this stage, it was a profile that only allowed applications running under DXVK to use compressed buffers. Similar exceptions had previously been placed for Source2 and vkd3d-proton, with vkd3d-proton being the project that implements Direct3D 12 over Vulkan for Proton.
The following commit, ab84cbe8, did not choose to further increase the number of DXVK-specific profiles. Instead, it removed the drirc setting anv_enable_buffer_comp itself and modified the code to always add the compressed memory type to the allowed memory types for general buffers. In other words, the scope of the change after this is no longer confined to the individual settings for Source2, DXVK, and vkd3d-proton. If an application's own allocation can select the compressed type, that option becomes visible through ANV's normal path.
This two-stage process differs from a simple understanding of "just adding a DXVK-specific optimization." The commit message records a decision to reduce configuration complexity and extend the behavior broadly, rather than keeping individual exceptions to rescue slightly slower traces. As described below, the negative values are under 0.6%, and it appears the development side did not consider that difference sufficient grounds to maintain per-application branching.
The merge destination is the Mesa 26.3 development branch. Mesa's public calendar schedules 26.3.0-rc1 for October 14, 2026, and rc4 or the final release for November 4. However, this is only Mesa's own schedule and does not determine when it will land in the packages of individual Linux distributions.
More memory types presented to VkBuffer
In Vulkan, when an application creates a buffer, the driver returns the memory types that can be bound to it via VkMemoryRequirements.memoryTypeBits. The application, or a translation layer such as DXVK, allocates memory from the types included in that bit set. This change is not an instruction that forces all buffers into a compressed state. Rather, it is an implementation that adds the compressed memory type as a visible option.
Before the change, in anv_buffer.c, returning the union of the default memory type and compressed_mem_types for general buffers only occurred when enable_buffer_comp was true. After the change, that condition was removed. Uses that require a dedicated dynamic-visible heap, such as protected memory or descriptor buffers, are handled in a separate branch, so it is not the case that the compressed type is indiscriminately presented for every use.
Within ANV, ANV_BO_ALLOC_COMPRESSED is defined as "a compressed buffer supported only on Xe2 and later." Compression here refers to a GPU memory path accompanied by CCS/AUX metadata, and the target is primarily buffers used during rendering. ANV's code comments explain that while the compressed memory type is generally advantageous for images, it can be disadvantageous for buffers, due to the cost of compression/decompression and metadata management, as well as compatibility with access patterns.
On the other hand, the Linux kernel's Intel display FBC is a feature that reduces the bandwidth and power consumption of the framebuffer scanned out by the display. Since i915 reserves a pre-allocated region called stolen memory, and the hardware manages compression and decompression, it operates transparently from user space. The only thing this shares with ANV's change is the potential to reduce bandwidth. The former operates in the kernel's display pipeline, while the latter is the memory type that the user-space Vulkan driver returns for VkBuffer; the location where performance manifests is not the same either.
Up to 5.26% improvement coexisting with roughly 0.5% degradation
The figures recorded in the first commit from Mesa performance CI are as follows. All are results of four measurements of DX11 traces via DXVK, but the resolution and quality settings are not disclosed in the commit body. The CPU, memory configuration, comparison baseline driver, and variance are similarly unknown.
| GPU | Trace | Performance Difference |
|---|---|---|
| Battlemage | Shadow of the Tomb Raider | +5.26% |
| Battlemage | Total War: Warhammer III | +4.62% |
| Battlemage | Total War: Pharaoh | +2.00% |
| Battlemage | God of War | -0.50% |
| Panther Lake | Shadow of the Tomb Raider | +4.85% |
| Panther Lake | Total War: Warhammer III | +2.60% |
| Panther Lake | Total War: Pharaoh | +1.63% |
| Panther Lake | Cities: Skylines II | +0.56% |
| Panther Lake | Borderlands 3 | +0.50% |
| Panther Lake | Mount & Blade II: Bannerlord | -0.58% |
Even with the same expansion of compressed memory type options, the performance difference varies significantly by title. Shadow of the Tomb Raider showed improvements in the high 4% to 5% range on both GPUs, while God of War and Mount & Blade II: Bannerlord dropped by about 0.5%. On the positive side too, there are small values such as 0.50% and 0.56%, and since the variance is not disclosed, these cannot be reliably read as a definite perceptible difference.
The explanation that the compressed type becomes advantageous in situations where transfer volume can be reduced is mechanistically consistent. Since Panther Lake, as an integrated GPU, shares system memory bandwidth with the CPU, there could plausibly be scenarios where the value of conserving bandwidth appears greater. However, the maximum values here are close—4.85% for Panther Lake and 5.26% for Battlemage. This alone does not provide material to explain the effect purely by the classification of dGPU versus iGPU.
Furthermore, the commit does not disclose measured memory bandwidth, compression ratios, or the types of buffers that were compressed. Therefore, one cannot definitively establish causation such as "it got faster because bandwidth was reduced." The measured values should be understood as the result of a combination of each trace's bottleneck and the memory allocation choices involved.
No regression in CTS is not a conclusion for real games
The second commit notes that no regressions were observed in the Vulkan Conformance Test Suite (CTS). This is significant in the sense that expanding the allowed memory types did not cause problems in Vulkan's specification conformance tests. As a premise for removing the drirc switch and moving to the default path, at least API conformance was confirmed.
However, CTS is not a test that comprehensively guarantees each game's rendering quality, stability during extended play, or performance. The performance values disclosed this time do not include 1% low or 0.1% low figures. Frame time distribution, power consumption, and VRAM usage are also not disclosed. DX11 traces are the condition where DXVK is most directly involved, and this cannot simply be extended as-is to other APIs, other game engines, or Intel GPUs prior to Alchemist. Compressed buffer support in the code is stated to apply from Xe2 onward.
Once Mesa 26.3 is actually distributed, verification will be needed that correlates the types of buffers selected for compression with frame times, in addition to average frame rates. Only then will it become possible to determine which workloads reproduce the upper-bound value of 5.26%, and to distinguish whether the roughly 0.5% regression is measurement noise or a genuine compatibility issue. What ANV has increased is not forced compression, but the options passed to applications. How that choice gets used in actual games will be the next piece of evidence to consider.