KosmicKrisp: pipeline-variants-per-topology-class fix for OpenGL workloads
Louis Montagne <[email protected]> Tue, 5 May 2026 13:50:20 +0200
| Newsgroups | gmane.comp.video.mesa3d.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Aitor, =
=
=20
=
=
=20
I've been running the Mesa Zink + KosmicKrisp stack on macOS / Apple =
=
=20
Silicon (M4 Max) as the OpenGL backend for AAASeed, a real-time =
C++/Lua
graphics engine. The stack is working well overall and OpenGL 4.6 =
=
=20
contexts are usable end to end. =
=
=20
=
=
=20
I have a fix queued locally that I'd like to upstream, but I wanted to =
=
=20
sync with you first because it touches the KosmicKrisp pipeline state
machine and I want to make sure my approach is compatible with where =
=
=20
you want the driver to go. =
=
=20
=
=
=20
=3D=3D Symptom =3D=3D =
=
=20=
=
=
=20
Apps that mix POINT, LINE and TRIANGLE primitive draw calls on the =
same =
=20
pipeline produce visual scramble (random vertex positions / wrong
primitive class rendered). Reproducible with anything non trivial: =
=
=20
lines from a UI overlay over textured triangles, point sprites, etc. =
=
=20
=
=
=20
=3D=3D Root cause =3D=3D =
=
=20=
=
=
=20
When VkPipeline is created with a single primitive topology, KK ends =
up =
=20
binding a Metal pipeline whose topology class doesn't match the live
primitive type at draw time. Metal silently picks something or skips =
=
=20
pixels depending on the GPU/driver, hence the "scramble". =
=
=20
=
=
=20
=3D=3D Fix shape =3D=3D =
=
=20=
=
=
=20
I changed `kk_graphics_state` to hold =
=
=20
=20
mtl_render_pipeline_state *pipeline_states[4]; =
=
=20
=20
(slots 1=3DPOINT, 2=3DLINE, 3=3DTRIANGLE; slot 0 unused for natural =
indexing =
=20=
by mtl_primitive_topology_class). =20
=
=
=20
`kk_shader.{c,h}` compiles three pipeline variants up front, one per =
=
=20
topology class. `kk_flush_draw_state` picks the matching variant per
draw based on the live primitive topology, so Metal never sees a =
=
=20
class/primitive mismatch. =
=
=20
=
=
=20
Local diff is ~80 lines across `kk_shader.{c,h}`, `kk_cmd_draw.c`, =
=
=20
`kk_cmd_buffer.h`. I can send it as a patch series for review.
=
=
=20
=3D=3D Questions before sending =3D=3D =20
=
=
=20
1. Is the "compile 3 variants up front" approach acceptable, or would =
=
=20
you prefer another option?
=
=
=20
2. For dynamic topology (VK_DYNAMIC_STATE_PRIMITIVE_TOPOLOGY), I treat =
=
=20
it the same way (variant chosen at flush time). Sounds OK? =
=
=20
=
=
=20
3. The diff currently ends + restarts the Metal render encoder when =
=
=20
the variant changes mid pass. With Apple Silicon's vertex layout =
=
=20
caches I haven't seen a way to swap pipeline class without that; =
=
=20
if you know better, I'd love an idea. =
=
=20
=
=
=20
Happy to open an MR straight away if you'd rather review on GitLab. =
=
=20
Otherwise I can send the patches inline. =
=
=20
=
=
=20
While I'm here, two trivial unrelated fixes on macOS are already up: =
=
=20
=20
* MR 41359: meson: allow DRI on darwin to enable Zink + EGL builds =
=
=20
* MR 41360: zink: guard driconf queries with driCheckOption
=
=
=20
(plus a third one in flight: zink build-id length fix for Mach-O.) =
=
=20
=
=
=20
Thanks for KosmicKrisp, it is just what we needed. =
=
=20
=20
-- =
=
=20
Louis Montagne =20
[email protected]