dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_mag -- Pass
dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_min -- Pass

This one was a fun geometry puzzle.

The problem

Mesa’s u_blitter is the utility that drivers use for framebuffer blits – copying pixel data between surfaces, optionally scaling and filtering. It works by drawing a textured quad: set up the source as a texture, the destination as a render target, and draw a rectangle with the appropriate texture coordinates. Simple.

Except the quad is made of two triangles. And that diagonal seam between them is where the trouble starts.

 v2 -------- v3
  |  \   T2  |
  | T1  \    |
  |       \  |
 v0 -------- v1

For LINEAR filtering, this is fine – the interpolation across the seam is smooth enough that nobody notices. But for NEAREST filtering, a texel is selected based on which texel center is closest to the interpolated texture coordinate. At the diagonal seam, the two triangles can produce slightly different texture coordinates for pixels that sit right on the boundary. Different coordinates mean different nearest-texel selection, and that means an inconsistent stripe of wrong texels running diagonally across the blit.

The dEQP nearest_consistency tests specifically check for this: they blit with NEAREST filtering and verify that every pixel picks the same texel regardless of which triangle it fell into.

What others do

This isn’t a new problem. V3D already has a workaround in u_blitter: it sets use_index_buffer to reorder the triangle indices so that the shared edge of the two triangles is along a different diagonal. This changes which pixels land on the seam and can be enough to pass the tests on some hardware.

On GC7000, that wasn’t sufficient. The floating-point interpolation differences are large enough that the seam remains visible regardless of which diagonal you pick.

What the blob does

Looking at command stream traces from the proprietary Vivante driver, the answer was clear: they don’t draw a quad at all. They draw a single oversized triangle and let the scissor clip it to the destination rectangle.

No seam, no problem.

The single triangle transform

The idea is simple: take a rectangle and find a single triangle that fully covers it. The smallest such triangle is a right triangle with legs twice the width and twice the height of the rectangle:

 v2
  |\
  |  \
  | rect\
  |------+\
  |      |  \
 v0 -----|--- v1

Vertex 0 stays at the rectangle’s top-left corner. Vertex 1 extends to twice the rectangle width. Vertex 2 extends to twice the rectangle height. The original rectangle is fully contained within this triangle.

The math for transforming the blitter’s 4-vertex quad into a 3-vertex triangle is:

for (unsigned a = 0; a < 2; a++) {      /* pos and texcoord */
   for (unsigned c = 0; c < 4; c++) {   /* xyzw components */
      float v0 = ctx->vertices[0][a][c];
      ctx->vertices[1][a][c] = 2.0f * ctx->vertices[1][a][c] - v0;
      ctx->vertices[2][a][c] = 2.0f * ctx->vertices[3][a][c] - v0;
   }
}

This transforms both position and texture coordinates consistently, so the texture mapping across the visible (scissored) region is identical to what the full quad would have produced – minus the seam.

Scissor is essential

The oversized triangle extends beyond the destination rectangle, so we need scissor to clip it. The blitter doesn’t always have a scissor set up, so when use_single_triangle is enabled, we synthesize one from the destination box:

if (ctx->base.use_single_triangle && !scissor) {
   synth_scissor.minx = MAX2(dstbox->x, 0);
   synth_scissor.miny = MAX2(dstbox->y, 0);
   synth_scissor.maxx = dstbox->x + dstbox->width;
   synth_scissor.maxy = dstbox->y + dstbox->height;
   scissor = &synth_scissor;
}

Keeping it scoped

The single-triangle transform should only apply to blit operations, not to clears or other blitter draws. A transient single_triangle_active flag is set around the actual blit draw calls and checked in the vertex emission code. Drivers opt in by setting use_single_triangle on the blitter context at creation time.

For etnaviv, that’s a single line:

ctx->blitter->use_single_triangle = true;

The design

The implementation is split into two commits: the u_blitter.c infrastructure (vertex transform, synthesized scissor, gating flag, 3-vertex draw path) that any driver can opt into, and the one-line etnaviv enablement. Keeping them separate means another driver hitting the same seam can flip the flag without touching u_blitter code.

The work landed upstream in u_blitter: Add single-triangle draw mode for NEAREST blit consistency.

The takeaway

Sometimes the fix for a rendering artifact isn’t better math or tighter tolerances – it’s removing the geometric feature that causes the problem in the first place. Two triangles have a seam. One triangle doesn’t.

The problem

Vivante GPUs have a quirk: the Pixel Engine (PE) always writes pixels in BGRA byte order. When your API says “render to R8G8B8A8_UNORM”, what actually lands in memory is B, G, R, A. Every byte of every pixel, every frame. The hardware just works that way.

The question is: where do you fix it?

The etnaviv driver was doing it in the shader. Before the fragment shader writes its output, a NIR lowering pass swaps the R and B channels:

   alu->src[0].swizzle[0] = 2;   /* .r reads from .b */
   alu->src[0].swizzle[2] = 0;   /* .b reads from .r */

This works, until it doesn’t. The shader key needs a frag_rb_swap bitmask per render target. The blend color needs per-RT R/B swapping to match. And it falls apart entirely for scalar outputs - if a shader writes a single float, there’s no .z component to swizzle into .x. That’s exactly the NIR validation failure we hit:

Test case 'dEQP-GLES3.functional.fragment_out.basic.fixed.rgb8_lowp_float'..
NIR validation failed after etna_lower_io in ../mesa/src/gallium/drivers/etnaviv/etnaviv_compiler_nir.c:1296
1 errors:
shader: MESA_SHADER_FRAGMENT
source_blake3: {0x4d463d73, 0x4b27d742, 0x27a92b64, 0x375c010f, 0xb2ce3767, 0x2adc55cc, 0x6da8105b, 0x5b9fce29}
name: GLSL1
prev_stage: MESA_SHADER_VERTEX
inputs_read: 32
outputs_written: 4
perspective_varyings: 32
max_subgroup_size: 128
min_subgroup_size: 1
api_subgroup_size_draw_uniform: true
first_ubo_is_default_ubo: true
known_interpolation_qualifiers: true
flrp_lowered: true
inputs: 1
outputs: 1
decl_var shader_in INTERP_MODE_SMOOTH none highp float packed:var0 (VARYING_SLOT_VAR0.x, 0, 0)
decl_var shader_out INTERP_MODE_NONE none mediump float out0 (FRAG_RESULT_DATA0.x, 0, 0)
decl_function main () (entrypoint)

impl main {
    block b0:  // preds:
    32    %3 = load_const (0x00000000)
    32    %4 = @load_input (%3 (0x0)) (base=0, range=1, component=0, dest_type=float32, io location=VARYING_SLOT_VAR0 slots=1)  // packed:var0
    32    %2 = deref_var &out0 (shader_out mediump float)
    32    %5 = mov %4.z
error: src->swizzle[i] < num_components (../mesa/src/compiler/nir/nir_validate.c:217)

               @store_deref (%2, %5) (wrmask=x, access=none)
               // succs: b1
    block b1:
}

FATAL ERROR: Test program crashed

What the blob does

Looking at command stream traces from the proprietary driver, the answer is almost disappointingly simple. Instead of this:

  Texture format: A8B8G8R8     (read BGRA as BGRA)
  PE format:      A8B8G8R8     (write BGRA)
  Shader:         swap R <-> B

The blob does this:

  Texture format: A8R8G8B8     (read BGRA as RGBA - hardware swaps on read)
  PE format:      A8B8G8R8     (write BGRA - unchanged)
  Shader:         nothing

That’s it. Tell the texture sampler the data is A8R8G8B8, and it will correctly interpret the BGRA bytes as RGBA channels. The PE keeps writing BGRA because that’s what it does. No shader modification needed.

In our format table, the change is a single field:

  -  VT(R8G8B8A8_UNORM, UNSIGNED_BYTE, A8B8G8R8, A8B8G8R8)
  +  VT(R8G8B8A8_UNORM, UNSIGNED_BYTE, A8R8G8B8, A8B8G8R8)
                                        ^^^^^^^^
                                     texture format

The data flow

To understand why this works, trace a red pixel through the pipeline:

                          BGRA-internal byte order
                         +------------------------+
                         |                        |
  API: glClear(1,0,0,1)  |   Memory: [0,0,255,255]|   CPU: expects [255,0,0,255]
  "red = 1.0"            |   (B=0, G=0, R=255,    |   "RGBA order"
                         |    A=255)              |
                         +------------------------+

  +-----------+     +--------+     +--------+     +---------+
  | Shader    |     | PE     |     | Memory |     | Sampler |
  | out=RGBA  | --> | writes | --> | stores | --> | reads   |
  | (1,0,0,1) |     | BGRA   |     | BGRA   |     | as      |
  |           |     |        |     | bytes  |     | A8R8G8B8|
  +-----------+     +--------+     +--------+     +---------+
       |                |               |              |
    R=1.0            B=0x00          [00 00 FF FF]   R=1.0
    G=0.0            G=0x00                          G=0.0
    B=0.0            R=0xFF                          B=0.0
    A=1.0            A=0xFF                          A=1.0

The shader writes (1,0,0,1). The PE swaps R/B on write, so memory gets [0,0,255,255] in BGRA order. The sampler, told the format is A8R8G8B8, reads those same bytes back as (1,0,0,1). Round-trip complete, no shader involvement.

The CPU boundary problem

GPU-to-GPU is clean. But what happens at the CPU boundary - glReadPixels, glTexSubImage, glBlitFramebuffer to a CPU-mapped buffer? The CPU expects RGBA byte order. Memory has BGRA. Something needs to swap.

This is where the hardware copy/resolve engines come in - RS and BLT. Both can perform R/B swapping during their copy operations. The RS engine has a swap_rb bit. The BLT engine has per-side swizzle fields. We just need to activate this at the right moment.

The key insight: only transfer blits (tiled-to-linear copies for CPU access) need the swap. GPU-internal blits - glBlitFramebuffer between two render targets, TS resolve, mipmap generation - are all operating on data already in BGRA order on both sides. Swapping there would be wrong.

So we gate it with a context flag:

ctx->in_transfer_blit = true;
etna_copy_resource_box(pctx, trans->rsc, &rsc->base, ...);
ctx->in_transfer_blit = false;

And in the RS blit path:

.swap_rb = ctx->in_transfer_blit &&
           translate_pe_format_rb_swap(blit_info->src.format),

The texture shadow trap

With the basic approach working, tests passed on GC7000 (BLT engine). But GC2000 (RS engine) had a regression: fbo-blit showed blue where red should be.

After adding debug prints and tracing the code paths, the culprit was the texture shadow. Some resources can’t be sampled directly by the texture unit - for example, a render target might use a layout the sampler doesn’t understand. For these, the driver allocates a second copy of the resource in a sampler-compatible tiled layout. This is the “texture shadow”.

The shadow is a workaround that hurts performance - it means extra memory and extra copies. Ideally we wouldn’t need it at all. But while it exists, the driver uses it as a shortcut for CPU transfers: read directly from the shadow and detile in software, skipping the blit engine:

Passing probes:  PATH=temp_resource+RS_blit    swap_rb=1   -> correct
Failing probes:  PATH=texture_shadow                       -> R/B swapped

The texture shadow path does a software detile - raw byte copy, no R/B swap. With BGRA-internal byte order, that gives you BGRA bytes on the CPU side. Wrong.

The fix: skip the texture shadow shortcut for formats that need R/B swap, forcing through the blit engine path which handles the conversion:

if (rsc->texture && !etna_resource_newer(rsc, etna_resource(rsc->texture)) &&
    !translate_pe_format_rb_swap(prsc->format)) {
   /* Use texture shadow - safe, no R/B swap needed */
   rsc = etna_resource(rsc->texture);
} else {
   /* Use blit engine - handles R/B swap correctly */
   ...
}

Results

This is a net-negative patch series - 15 files changed, 76 insertions, 113 deletions. The etnaviv: Remove RB swap logic in the fragment shader contains all that’s needed:

1. blt: Use img->swizzle for CONFIG SWIZ fields - preparation for per-image swizzle support
2. Add translate_pe_internal_format helper - maps RGBA pipe formats to BGRA equivalents for clear color packing
3. Use BGRA-internal texture format with BLT/RS R/B swizzle - the main change
4. Compute blend color directly in etna_set_blend_color - simplifies blend color, no deferred update needed

Fixes the NIR validation failure with scalar fragment outputs. And as a nice side effect, removing the shader-based swap means fewer shader variants, fewer instructions and less overhead. glmark2-es2-wayland improves from ~835 to ~874 FPS - a 4.7% performance increase.

Sometimes matching what the hardware vendor does is the right answer. The blob driver figured this out years ago. We just needed to look at the traces.

That’s where I thought the story ended

The texture-format trick has a hidden assumption baked into it: that the GPU both writes and reads every resource. The PE writes BGRA, the sampler is told the format is A8R8G8B8, and the byte order cancels out. It’s a closed loop, and as long as the data never leaves the GPU, nobody outside ever sees the BGRA bytes.

dmabuf breaks the loop.

When a buffer is shared with another process - a Wayland compositor, a video decoder, a camera - the byte order is no longer our private business. It’s mandated by the DRM FourCC. An external producer writes honest RGBA bytes into the buffer. Then our sampler, still convinced the format is A8R8G8B8, reads them as BGRA. Red and blue swap. And on the way out, a transfer blit happily swaps data that was already correct. The optimization that made GPU-internal rendering clean made buffer sharing wrong.

  GPU-internal (closed loop):       dmabuf (loop broken):

  PE writes BGRA                    external producer writes RGBA
       |                                  |
  sampler reads as A8R8G8B8         sampler reads as A8R8G8B8
       |                                  |
  cancels out -> correct            reads RGBA as BGRA -> swapped

Step back out for shared resources

The first fix is the obvious one: when a resource is shared, don’t play the trick. Use the native A8B8G8R8 texture format so the sampler reads RGBA bytes as RGBA, skip the R/B swizzle in the BLT and RS transfer blits, and re-enable the texture shadow shortcut that the swizzle had forced us to disable. Internal resources keep the BGRA-internal optimization untouched.

That handles imports. But there’s a case it doesn’t cover: a resource we rendered into and then export. The PE wrote BGRA, because that’s all the PE knows how to do. The external consumer expects native order.

Here a second kind of shadow shows up. Just as the sampler gets a texture shadow when it can’t read the base layout, the PE gets a render shadow - a render-compatible copy - when it can’t draw into the base layout. (On some GPUs, like GC2000, no single tiling satisfies both the texture engine and the pixel engine, so a resource can end up carrying both shadows.) When an exported resource is flushed, that render shadow is resolved back to the base. So we hook etna_flush_resource() and do the R/B swap during that copy - using the BLT destination swizzle or the RS SWAP_RB bit. The swap rides along on a copy we were doing anyway.

One buffer, two byte orders

Now the same shared buffer can be in one of two states. Just imported, or just flushed for export? Native RGBA. Freshly rendered by the PE, not yet flushed? PE-internal BGRA. A static texture format chosen at sampler-view creation can’t be right for both.

So the format choice becomes dynamic. A shared_native_order flag tracks which order the bytes are currently in, and the sampler-view format follows from it:

Both texture paths - state-based and descriptor-based - pre-compute the native format variant at sampler-view creation, so picking the right one at emit time costs a single branch, not a per-frame format recompute.

The shader swap comes back

Which brings us to LINEAR_PE GPUs, and a twist I didn’t see coming.

On these GPUs, a linear shared resource is render-compatible. There is no render shadow - the PE writes straight into the buffer that gets handed to the compositor. So after a draw, the buffer holds BGRA, and flush_resource() would have to issue a full-surface blit to swap it. That’s real bandwidth, on every frame, that the old shadow-based path never paid.

There’s a cheaper place to do the swap: in the shader, on the way out. Which is exactly the thing this whole series set out to delete.

So it comes back - but only for this one case, and done properly. A per-RT frag_rb_swap bitmask in the shader key drives a NIR lowering pass that swaps channels 0 and 2 on the fragment output. The original shader swap fell over on scalar outputs, because there was no .z to swizzle from. This one widens the output variable to vec4 first, padding the missing components with undef, then applies the swizzle with an adjusted writemask:

   /* Pad source to 4 components (undef for missing) */
   nir_def *padded = nir_pad_vec4(&b, src);

   /* Swap R and B channels */
   unsigned swiz[] = {2, 1, 0, 3};

That’s the scalar rgb8_lowp_float crash from the top of this post - fixed, in the one path that now needs a shader swap at all.

Wiring it up is a check in etna_draw_vbo():

   if (VIV_FEATURE(screen, ETNA_FEATURE_LINEAR_PE)) {
      for (i = 0; i < pfb->nr_cbufs; i++) {
         struct etna_resource *rsc = etna_resource(pfb->cbufs[i].texture);
         if (rsc->shared && rsc->layout == ETNA_LAYOUT_LINEAR &&
             translate_pe_format_rb_swap(pfb->cbufs[i].format))
            key.frag_rb_swap |= (1 << i);
      }
   }

The bitmask is per-RT, so an MRT setup with a mix of shared and private targets does the right thing for each. And because the shader produced native bytes directly, shared_native_order stays true and flush_resource() skips its blit entirely.

The fixes for all of this live in a follow-up series, etnaviv: Fix dmabuf R/B byte order for PE_FORMAT_RB_SWAP formats.

So was removing the shader swap a mistake?

No - but it wasn’t the whole answer either.

The shader swap was wrong as the universal solution. It cost a shader-key dimension, per-RT blend-color fixups, and it crashed on scalar outputs. The texture-format trick is genuinely better for the common case, where a resource lives and dies on the GPU.

What the dmabuf work showed is that there is no single right place to fix R/B order. There’s a place that’s cheapest for each path: the texture format for GPU-internal resources, a transfer-blit swap at the CPU boundary, a flush-time swap for exported render targets, and - for LINEAR_PE, where the PE writes straight into a shared buffer - the shader, after all. The trick isn’t picking one. It’s knowing which boundary you’re standing on, and swapping there.

Spoiler: it was a busy one.

The landscape

PanVK - the Vulkan driver for Arm Mali GPUs (Valhall and newer) - is a collaborative effort. Collabora has been doing incredible work on the compiler backend and the foundational infrastructure. Arm themselves are actively contributing to the open source Mali GPU stack as well, reviewing patches and pushing driver quality forward. On the Igalia side, my focus this cycle was Vulkan extension coverage. The kind of work that doesn’t make for flashy demos but is absolutely critical for real-world application compatibility - especially for things like DXVK.

Why extensions matter

A Vulkan driver without extensions is like a car without wheels - technically complete, practically useless. Applications (and translation layers like DXVK, vkd3d-proton, and Zink) probe for specific extensions and adjust their behavior accordingly. Missing even one can mean falling back to a slower path or refusing to run entirely.

Three different things drove the extension work this cycle:

• The Proton stack - extensions consumed by DXVK and vkd3d-proton, the translation layers that make D3D9–12 games run on Vulkan.
• DDK feature parity - extensions Arm’s binary Mali driver exposes that PanVK didn’t yet, tracked in the DDK feature parity ticket.
• Catching up on mesamatrix.net - closing the visible gap with the other Mesa Vulkan drivers (RADV, ANV, Turnip).

So I set out to close gaps. Lots of them.

The Proton stack essentials

These are extensions DXVK and vkd3d-proton actually require - not just nice-to-haves on a recommendation list. Each one unblocks something concrete in the D3D-to-Vulkan translation path.

VK_EXT_conditional_rendering (!40452) was probably the most involved piece of work. D3D12 has predicated rendering (SetPredication), and vkd3d-proton uses this extension to implement it efficiently. It wasn’t a simple “flip a bit” situation - I had to add the core state tracking, wrap all draw and dispatch calls with conditional checks, handle inherited state in secondary command buffers, and make sure meta operations (like internal clears and resolves) properly disable conditional rendering so they don’t get accidentally skipped. That ended up being five patches touching draw paths, dispatch, and the secondary command buffer inheritance logic.

VK_VALVE_mutable_descriptor_type (!40254) is one of those extensions that exists purely because Valve needed it. In D3D, descriptor types are more fluid than in Vulkan - a descriptor slot might hold a sampler one frame and a storage buffer the next. vkd3d-proton enables this to avoid expensive descriptor set re-creation when types change. It’s a trivial alias of the already-supported VK_EXT_mutable_descriptor_type, so enabling it was a one-liner.

VK_EXT_memory_budget (!40246) lets applications (and both DXVK and vkd3d-proton) query how much GPU memory is actually available versus how much is in use. Without it, apps are flying blind on memory management, which can lead to over-allocation and stuttering. Getting the heap budget reporting right required hooking into the kernel memory accounting.

VK_EXT_attachment_feedback_loop_layout (!40498) - feedback loops let you read from an attachment that you’re simultaneously rendering to (think screen-space effects that sample the current framebuffer). DXVK uses this in its D3D9 hazard layout path to avoid artifacts in certain games.

VK_EXT_shader_stencil_export (!39944) - allows fragment shaders to write stencil values directly, rather than relying on the fixed-function stencil path. DXVK leans on this in its meta-copy and meta-resolve paths, and vkd3d-proton enables it too. The Panfrost stack already supported everything needed; literally a one-line advertisement in physical_device.c.

VK_KHR_shader_untyped_pointers (!40457, v9+) - a newer KHR extension that relaxes pointer type requirements in SPIR-V. DXVK calls this out as a dependency for descriptor heaps. Restricted to v9+ because Bifrost has issues with 8-bit vector loads through untyped pointers combined with 16-bit storage. Also needed to lower memcpy derefs before explicit IO lowering.

Catching up to the DDK

The panfrost keeps a DDK feature parity ticket tracking everything Arm’s binary Mali driver exposes that PanVK doesn’t yet. Four of those got crossed off this cycle:

• VK_ARM_scheduling_controls (!40063, CSF only) - an ARM-specific extension for controlling shader core scheduling on Command Stream Frontend (CSF) hardware. I also fixed the per-queue shader core count so CSF group creation uses the right values.
• VK_EXT_legacy_dithering (!39781) - implements ordered dithering in the blending stage, which some applications expect from legacy APIs. Wired up the existing Panfrost dithering infrastructure (pan_dithered_format_from_pipe_format()) — just plumbing the VK_RENDERING_ENABLE_LEGACY_DITHERING_BIT_EXT flag through the blend descriptor and color attachment internal conversion paths.
• VK_EXT_rgba10x6_formats (!40653) - a last-minute addition that just squeezed in before the branch point. This required adding the PIPE_FORMAT_X6R10X6G10X6B10X6A10_UNORM format to Mesa’s gallium format table first, then wiring it up in PanVK. Used for 10-bit per channel content in video and HDR scenarios.
• VK_EXT_astc_decode_mode (!39799) - controls the format used when decoding ASTC compressed textures, allowing apps to choose lower-precision decoding for performance. The Panfrost hardware already supports controlling ASTC decode precision via the Decode Wide plane descriptor field; just needed to parse VkImageViewASTCDecodeModeEXT from the image view pNext chain and set astc.narrow accordingly. v9+ only because the relevant ASTC plane descriptor fields only exist from Valhall onward.

Catching up on mesamatrix

mesamatrix.net tracks Vulkan extension support across the Mesa drivers. The remaining extensions this cycle were about closing the visible gap with RADV, ANV, and Turnip — extensions that don’t have a single big consumer driving them, but whose absence shows up as red squares on the matrix and as silent fallbacks in apps that probe for them.

• VK_EXT_color_write_enable (!39913) - per-attachment control over which color channels actually get written. The common Vulkan runtime already handled all the pipeline state and dynamic command plumbing, and panvk’s blend descriptor emission was already consuming color_write_enables, so this was effectively an “advertise the feature” change.
• VK_EXT_depth_clamp_control (!39925) - lets applications specify a custom depth clamp range instead of always clamping to the viewport’s minDepth/maxDepth. Mali GPUs have native LOW_DEPTH_CLAMP/HIGH_DEPTH_CLAMP registers, so it was a matter of wiring the existing runtime state through to those.
• VK_EXT_attachment_feedback_loop_dynamic_state (!40498) - the dynamic-state companion to VK_EXT_attachment_feedback_loop_layout above; lets you toggle feedback-loop state per draw call without pipeline rebuilds.
• VK_EXT_map_memory_placed (!40315) - lets applications control where in their virtual address space GPU memory gets mapped. This simplified pan_kmod_bo_mmap() to always map the whole BO, cleaning up the kernel module interface.
• VK_EXT_shader_atomic_float (!40506) - atomic operations on float values in shaders. The existing axchg instruction is type-agnostic, so no compiler changes were needed; image atomics are already lowered to global atomics. Just had to add R32_FLOAT to the storage-image-atomic format flag.
• VK_EXT_nested_command_buffer (!40120, v10+) - allows secondary command buffers to call other secondary command buffers. The CSF backend’s cs_call() is a hardware call/return instruction that nests naturally, and the existing CmdExecuteCommands already does the caller/callee state merging. The 8-level hardware call stack, minus one for the kernel ringbuffer call and two reserved for future driver use, leaves maxCommandBufferNestingLevel at 5.
• VK_EXT_image_view_min_lod (!39938) - allows clamping the minimum LOD at the image view level rather than just the sampler. Mali v6+ has per-texture-descriptor LOD clamp fields independent from the sampler’s, so this just plumbs vk_image_view::min_lod through pan_image_view into the texture descriptor — no shader lowering or descriptor merging needed.
• VK_EXT_zero_initialize_device_memory (!39658) - guarantees that newly allocated device memory is zeroed. The kernel side already does the heavy lifting — panfrost/panthor use drm_gem_shmem, which serves zeroed pages from the shmem subsystem. And since panvk treats layout transitions as no-ops, VK_IMAGE_LAYOUT_ZERO_INITIALIZED_EXT falls out for free. (Did need one format-table fix: dropping STORAGE_IMAGE support from compressed formats to avoid crashes in the new dEQP tests.)

By the numbers

That’s 18 extensions across roughly a dozen merge requests - ranging from single-patch additions to multi-patch series like conditional rendering. Collectively they represent a meaningful shift in what PanVK can claim to support: more of the Proton stack working out of the box, four more checkboxes against the DDK, and fewer red squares on the mesamatrix.

What’s next

The extension sprint isn’t over - there are still gaps to fill, and each one removed makes PanVK more viable for real workloads. But 26.1 was a good milestone. The driver is getting to the point where you can throw a DXVK game at it and have a reasonable expectation that it just works.

Back to it. ⚡

Where We Are

etnaviv has supported GLES2 on Vivante GPUs for a long time. GLES3 support has been progressing steadily, but the remaining dEQP failures are the stubborn ones - the cases where the hardware doesn’t quite do what the spec says, and the driver has to get creative.

These aren’t missing feature bits or unimplemented extensions. These are the problems where you stare at a command stream trace from the proprietary blob driver and realize they’re doing something completely different from what you’d expect, because the hardware has a quirk that nobody documented.

The Approach

My workflow for each fix follows a pattern:

1. Run the failing dEQP test, note the failure mode (wrong pixels, crash, GPU hang)
2. Capture command stream traces from both the blob (proprietary driver) and etnaviv for the same test
3. Compare the traces - what states differ? What draw calls differ? Is the blob doing extra work?
4. Understand why - read the spec, reason about the hardware behavior, figure out what the blob knows that we don’t
5. Implement the fix in Mesa, test, iterate

The blob traces are invaluable. Vivante’s proprietary driver has years of hardware workarounds baked in. When something doesn’t work, the answer is usually hiding in the trace.

The Hardware

The primary test target is a GC7000 rev 6214 (HALTI5 generation). This is a capable GPU found in the NXP i.MX8MQ SoC. It has a BLT engine, texture descriptors, and most of the features needed for GLES3 - but also its own set of rasterization quirks and interpolation behaviors that need workarounds.

In the future, I plan to expand the focus to the broader GC7000 GPU family.

Up Next

The first post will tackle the R/B swap problem - the PE always writes pixels in BGRA byte order, and we’ve been fixing it in the shader. The blob has a simpler answer. Stay tuned.

Following Along

All of this work happens upstream in Mesa.

If you’re interested in GPU driver development, these posts aim to show what the work actually looks like – not just the final patch, but the debugging, the trace analysis, and the reasoning that gets you there.

Why this extension?

A customer needed advanced blending support in lavapipe, so the extension choice was made for me. But it turned out to be a great fit for a first extension - useful, self-contained, and not a multi-month rabbit hole. Standard Vulkan blending is limited to basic operations like add and subtract with blend factors. That’s fine for most rendering, but if you want Photoshop-style effects - multiply, screen, overlay, color dodge, color burn - you’re stuck doing it manually in shaders or with extra render passes.

The extension adds 19 blend operations that handle all of this in the fixed-function pipeline. Useful for UI toolkits, image editors, and anywhere you need creative compositing.

The journey

What started as “just wire up an extension” turned into a proper refactoring adventure. The existing blend infrastructure in Mesa was scattered - OpenGL had its own enum definitions, Vulkan had separate conversions, and the actual NIR blend math lived in glsl-specific code.

So I took a step back and cleaned things up. Moved the blend mode enums into a shared util/blend.h header. Added proper helpers in the Vulkan runtime for converting between API types. Then came the fun part: implementing the actual blend equations in nir/lower_blend.

Each of those 19 blend modes has its own formula from the spec. Some are simple (multiply is just src * dst), others get hairy with conditionals and special cases for luminosity and saturation. About 570 lines of NIR code later, I had a lowering pass that any Mesa driver can use.

For example, here’s how the spec defines advanced blending. Each mode plugs into a general equation:

RGB = f(Cs,Cd) * X * p0 + Cs * Y * p1 + Cd * Z * p2
A   =            X * p0 +      Y * p1 +      Z * p2

Where p0, p1, p2 are weighting factors based on source/destination alpha coverage, and f(Cs,Cd) is the per-mode blend function. For overlay - probably the most recognizable blend mode from Photoshop - the spec defines:

f(Cs,Cd) = 2*Cs*Cd,              if Cd <= 0.5
           1 - 2*(1-Cs)*(1-Cd),  otherwise

And here’s that same formula expressed as NIR - Mesa’s intermediate representation:

static inline nir_def *
blend_overlay(nir_builder *b, nir_def *src, nir_def *dst)
{
   /* f(Cs,Cd) = 2*Cs*Cd, if Cd <= 0.5
    *            1-2*(1-Cs)*(1-Cd), otherwise
    */
   nir_def *rule_1 = nir_fmul(b, nir_fmul(b, src, dst), imm3(b, 2.0));
   nir_def *rule_2 =
      nir_fsub(b, imm3(b, 1.0),
               nir_fmul(b, nir_fmul(b, nir_fsub(b, imm3(b, 1.0), src),
                                        nir_fsub(b, imm3(b, 1.0), dst)),
                         imm3(b, 2.0)));
   return nir_bcsel(b, nir_fge(b, imm3(b, 0.5f), dst), rule_1, rule_2);
}

nir_fmul, nir_fsub, nir_bcsel - multiply, subtract, conditional select. Each call builds a node in the shader’s IR graph. This is what “lowering” looks like: translating a high-level blend mode into operations the GPU’s shader core can execute. The outer framework - the p0/p1/p2 weighting - is handled by the caller; each blend function just implements its f(Cs,Cd).

The Turnip surprise

Everything was working on Honeykrisp, tests were passing, life was good. Then the merge pipeline started failing - on Turnip (the Adreno Vulkan driver). Not my code, not my hardware, but my changes were breaking it.

I reached out for help, and Zan Dobersek stepped up. After some digging, he found the culprit: I was violating a subtle corner of the spec around attachmentCount. Turns out, when certain dynamic states are set and advancedBlendCoherentOperations isn’t enabled, attachmentCount gets ignored entirely. My state tracking code wasn’t accounting for that.

One fixup commit later, Turnip was happy again. This is the part they don’t tell you about Vulkan extensions - you’re not just implementing for your driver, you’re touching shared infrastructure that every driver depends on. And the Mesa CI will absolutely let you know if you break something.

lavapipe landed

One week later, lavapipe has it too. This was the original goal, and the shared infrastructure did exactly what it was supposed to - the lavapipe MR is mostly just flipping the extension on. The lowering pass, the enum plumbing, the runtime helpers - all reused as-is. The full dEQP-VK.pipeline.*.blend_operation_advanced.* test suite passes on both drivers.

Two drivers in two weeks. That’s what building the right abstractions gets you.

What’s next

The shared NIR lowering pass is there for any Mesa Vulkan driver to use. If your hardware doesn’t have native advanced blending support, enabling the extension is now mostly plumbing. I’m curious to see if other drivers pick it up.

For me, this was a good first step into Vulkan - and into working on Honeykrisp. I’m looking forward to what comes next.

The Honeykrisp/NIR MR and the lavapipe MR are both merged if you want to look at the code. Thanks to Alyssa Rosenzweig for the review and guidance, and to Zan Dobersek for debugging the Turnip regression with me.