Ghostty Raspberry Pi 5 support via (OpenGL es3.1 or vulcan)

[mattkanwisher]

Ghostty's Linux renderer requires desktop OpenGL 4.3. The Raspberry Pi 5 family tops out at GL 3.3, so ghostty exits with "Unable to acquire an OpenGL context" there. The same GPUs do expose GLES 3.1 and conformant Vulkan 1.3.

In #11370 (Android support) a maintainer said a GLES-only renderer contribution "might" get a look. We built one. We also built a Vulkan backend to answer the presentation question, and benchmarked both on hardware. Both are public, reviewable, and running as daily drivers:

• GLES 3.1 port — TensorFleet/ghostty#1, 6 patches against v1.3.1. Runtime-detected: desktop-GL systems keep their current path byte-for-byte; GLES is used only when GL 4.3 can't be had. The GL 4.3 requirement in practice reduces to SSBOs + vertex-attrib-binding + #version 430, all core in GLES 3.1, with one hardware caveat: Mesa's v3d driver reports zero vertex-stage SSBOs, so the cell-background SSBO read moves to the fragment stage.
• Vulkan renderer with dmabuf presentation — TensorFleet/ghostty#2, experimental. GTK4 has no Vulkan drawing surface for applications, so the backend renders offscreen and presents via VkImage → dmabuf export (VK_EXT_external_memory_dma_buf + VK_EXT_image_drm_format_modifier) → GdkDmabufTextureBuilder → GtkPicture. Full write-up: VULKAN-PORT.md. Works on GTK 4.14 (the GdkDmabufTextureBuilder floor) through 4.22.

Benchmarks

Raspberry Pi CM5, live Hyprland session, ReleaseFast, medians of 3 (term-bench in the repo; full methodology in BENCHMARK.md):

workload	Vulkan-dmabuf	GLES 3.1
cat 50 MB ASCII	3.5 s	5.9 s
cat 200k colored lines	2.0 s	3.2 s
seq 2M	2.2 s	3.3 s
clear+redraw ×400	0.36 s	0.34 s

On x86/radv the Vulkan path benchmarks at parity with the stock desktop-GL renderer — the dmabuf presentation added no measurable cost in any workload we ran. Both backends are interactive-fluid on the Pi; software GL (llvmpipe) saturates all four cores and is not usable.

Bugs found during bring-up that affect upstream independently

1. src/Surface.zig calls finalizeSurfaceInit on a stack copy of the renderer after the renderer has already been moved into self.renderer. State set inside that call lands on a dead copy. The GL and Metal backends store nothing at that point, so the bug stayed invisible.
2. The GTK apprt sets GDK_DISABLE=gles-api before the GL-version gate, so hardware that could satisfy a GLES context never gets the chance — on the Pi, context creation fails twice over.

What we're asking

Is there appetite for the GLES renderer as a PR against main? It's the small diff, it changes nothing on desktop-GL systems, and per the earlier comment it appears to be the shape you'd consider. We'd rebase onto current main and adapt to the renderer changes since 1.3.1. The Vulkan branch is offered as data — it demonstrates the complete GTK-without-GL path and what it buys — rather than as a merge candidate; it lacks custom-shader and inspector support.

Hardware verified on: Raspberry Pi CM5 (v3dv, Hyprland, GTK 4.22) and x86_64/radv (GTK 4.14, sway). Happy to run additional workloads or targets on request.

TLDR: Add support for GLES 3.1 for Raspberry pi 5 support, smallest patch. Vulcan support for most performance. This should also unlock Android support #11370

[jcollie]

Re: bug #1, we'd certainly appreciate a PR fixing that. Bug #2 I think depends on accepting a rendered that supports GLES. I'll leave the decision on whether we want to support GLES to the rendering specialists.

[tristan957]

I think we (the GTK team) are definitely interested in a Vulkan renderer.

[pluiedev]

Seconding Tristan here, though I have some concerns regarding the code quality. First I think we need to come up with an alternative to GLArea that abstracts over the renderer so it works regardless of the graphics backend. src/apprt/gtk/surface.zig is already filled with stuff that should probably be encapsulated away. Secondly we want to use Zig's build system to compile the shaders to SPIR-V and then import them without committing them to the source tree (addImport works with arbitrary files, not just Zig modules). Lastly we need to use Zig-language bindings for Vulkan like https://github.com/Snektron/vulkan-zig instead of just rawdogging the C API. If you're able to make all of these changes we may consider including a Vulkan-based renderer for the 1.5 release.

[pluiedev]

Also I personally don't see much point in adding GLES support since mobile GPUs nowadays support Vulkan anyway. We can get the most bang for our buck if we just target Vulkan (more specifically Vulkan 1.2 + dynamic rendering, since 1.3 support is still spotty for targets like MoltenVK)