PanVK Mali-G720 / Kbase-CSF — desenvolvimento, progresso e próximos passos

[wonderkast02]

PanVK Mali-G720 / Kbase-CSF

Estou abrindo esta discussão para acompanhar e conversar sobre o desenvolvimento do PanVK para Mali-G720 usando diretamente o Kbase/CSF.

A ideia aqui não é fazer atualizações diárias. Vou usar esta discussão para compartilhar avanços importantes, resultados de testes, problemas encontrados e decisões de implementação, além de ouvir sugestões de quem acompanha ou entende dessa área.

Estado atual

O PanVK já está executando de forma nativa na Mali-G720 através do Kbase/CSF.

Caminho atual:

Vulkan → PanVK → Kbase/CSF → Mali-G720

Já foram validados, entre outras coisas:

• Vulkan básico
• compute
• graphics pipeline
• render offscreen + readback
• texture sampling
• depth/stencil
• blending
• MSAA
• swapchain X11
• vkcube
• testes mais longos no hardware real

O wrapper antigo não faz mais parte do caminho principal do driver. Ele continua preservado no repositório como uma PoC histórica.

Tessellation

Esse é o principal trabalho atual.

Já temos:

• VS → COMPUTE
• TCS → COMPUTE
• TES → VERTEX
• metadata TCS/TES
• descriptors e estado
• poly sysvals
• kernels precompilados do libpan
• correções necessárias para Physical64
• infraestrutura inicial do poly_heap

O runtime ainda precisa ser concluído antes de anunciar tessellationShader=true.

Os próximos passos incluem os buffers por draw, poly_vertex_params, poly_tess_params, os dispatches VS/TCS, COUNT, prefix sum, WITH_COUNTS e o draw TES final.

Sobre o projeto

Ainda estou aprendendo bastante enquanto desenvolvo, compilo e testo cada parte. Então também quero usar esta discussão para entender melhor algumas decisões técnicas e receber sugestões quando fizer sentido.

Se alguém estiver trabalhando com PanVK, Panfrost, Mali CSF, Kbase ou algo relacionado, fique à vontade para participar.

[leegao]

Are you mainly focused on getting tesselation shader support implemented now?

One thing I'm a bit concerned about is how to port all of this forward once upstream Mesa moves on (e.g. to 26.3, 26.4, etc). Over the past few years, they've stopped keeping a clean separation between panvk and the actual panthor uapi (especially with libdrm-specific things, but there are even a few stray direct ioctl calls made outside of libkmod). This makes it hard to cleanly separate out kbase vs panthor specific things, and I'm worried that it'll be a sisyphian uphill climb every time we need to rebase onto newer branches of Mesa.

I think half of this could potentially be shimmed out with libdrm hooks (e.g. ship a set of fake drm-functions on the kbase build that redirects/translates that side to equivalent kbase/linux APIs). There are some hard uapi calls (especially in gpu_queue.c) that will still remain tricky, though perhaps we can ask Mesa/Collabora to try to abstract out the uapi layer there into kmod as much as possible (just for the sake of cleaner code, better separation of concerns)

However, the more feature work we start implementing wtihin panvk (specifically, just generic missing features/extensions), that gets more and more difficult to port forward.

[wonderkast02]

Thanks for your attention! Yes, my focus right now is mainly on wrapping up tessellation, but I agree with the concerns regarding maintenance; I think that aspect is even more important than simply piling on feature after feature. I don't want this project to turn into a parallel PanVK full of custom changes that become a nightmare to port whenever Mesa updates its version. The idea is to keep as much of the generic logic aligned with upstream as possible and isolate anything truly specific to kbase at the lowest possible layer. I'm working on tessellation because there is already significant infrastructure in Mesa/libpoly that we can reuse, rather than creating something entirely from scratch; however, going forward, I’ll avoid implementing generic features just because they’re missing from PanVK if it significantly increases the fork's divergence. Regarding the libdrm hooks/shims, I also think that’s a very interesting approach—especially if we can get the panthor/kbase differences to resolve into a common interface within libkmod. gpu_queue.c will likely remain the biggest headache since the UAPI leaks through quite a bit there; so, if we can eventually take this discussion to Mesa/Collabora and push more of those differences into the kmod abstraction, that would be ideal. My priority is to keep the fork as easy to update as possible; if upstream later implements something we’ve already done here, I’d rather drop our version and adopt theirs than maintain a perpetual patch. If you spot any specific area where the panthor/kbase separation is becoming too messy—especially outside of libkmod—please let me know, as I want to address that now while the codebase is still relatively manageable.