This is the start of a series about getting OpenGL ES 3.0 conformance on Vivante GC7000 hardware using the open-source etnaviv driver in Mesa. Thanks to Igalia for giving me the opportunity to spend some time on these topics.

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.