u/Appropriate-Floor688

​

After a long time working with Mali GPUs on Android, I decided to take a different direction.

Instead of trying to adapt an emulator that was mainly developed around other GPU paths, I went back to the architecture that was historically much friendlier to Mali: Skyline.

This is Strato Mali, a new fork based on Strato, which itself continues the original Skyline project.

The goal is simple: make a Nintendo Switch emulator specifically optimized around ARM Mali GPUs.

Strato Mali is not intended to be a generic emulator fork for every GPU. The focus is Mali first — especially modern Kbase/CSF devices such as the Mali-G615, with experimental Mesa PanVK integration.

I have already started modifying Strato's custom Vulkan driver system so it can detect /dev/mali0 and load external Vulkan drivers on Mali instead of limiting custom driver loading to KGSL/Adreno. The Adreno-specific KGSL memory-import path is kept disabled on Mali, while the normal Skyline/Strato memory path is used with PanVK.

The project is also being renamed throughout the application to Strato Mali.

The current plan is to work on:

PanVK/Kbase integration directly inside Strato Mali

Mali-specific Vulkan compatibility fixes

shader and texture correctness

performance optimizations specifically for tile-based Mali GPUs

synchronization and memory-management improvements

testing games that historically worked better on Skyline/Mali

This is still very experimental development. It is not a finished emulator, and I don't want to promise compatibility or performance numbers before we have proper testing.

But unlike my previous experiments, this time the emulator architecture itself is much closer to what I want for Mali.

Skyline's codebase isn't being officially revived — this is an independent continuation through Strato, focused entirely on Mali.

Welcome to Strato Mali. 🫐

More development updates soon.

​

Follow-up to my last post about getting AHB/gralloc import working on this driver. Since then I went after the actual packaging problem: getting the native .so to load inside Winlator (Mali fork) instead of just under my own test harnesses on-device.

This turned out to be its own multi-day debugging arc, mostly because the vendor Vulkan namespace Android loads custom drivers into (vulkan.<platform>.so, via the same hook mechanism AdrenoTools/Turnip use) is far more restrictive than a normal app's library search path. Every fix here was found by reading adb logcat output from the actual failed dlopen attempt — no guessing.

What broke, in order, and why:

libz.so.1 / libzstd.so.1 not found. My dev build linked against Termux's zlib/zstd for the shader disk cache. Neither exists in the vendor namespace. Fixed by rebuilding with -Dzlib=disabled -Dzstd=disabled -Dshader-cache=disabled -Dplatforms=android (also had to drop X11 support from this build — it was never going to be reachable from that namespace either).

Missing C++ symbols (basic_ostringstream, std::cerr) from SPIRV-Tools, which is statically linked and genuinely needs libc++. The system libc++.so on this device has a restricted internal ABI missing these. Bundled the NDK's real libc++_shared.so (found intact in Termux's own lib dir) alongside the driver .so in the same package — turns out the loader hook specifically recognizes and pre-resolves that exact filename.

libdrm.so symbol mismatch (drmCloseBufferHandle missing) — this device's /vendor/lib64/libdrm.so is an older build than what my driver was linked against, and (unlike libc++_shared) the hook doesn't special-case bundled libdrm, so the vendor copy always won name resolution regardless of packaging. Root-caused, then eliminated entirely: this driver never touches real DRM anyway (confirmed weeks ago — drmGetDevices2 always returns -ENOENT via the kbase-only path), so I wrote a ~35-line stub implementing the handful of drm* symbols SPIRV-Tools/vk_drm_syncobj code references, all returning clean -ENOSYS, and dropped the dynamic dependency on libdrm completely.

undefined symbol: HMI. This one was self-inflicted: an earlier packaging attempt had forced the driver to export the generic desktop-loader ICD symbol scheme (vk_icdGetInstanceProcAddr) instead of the real Android HAL scheme (hwvulkan_module_t, exported as HMI) — useful for dlopen-based local testing, fatal for the real Android Vulkan loader, which only ever looks for HMI. Reverted to the HAL symbol scheme for this build.

Driver loaded but reported 0 device extensions. Last mile: this driver gates Bifrost-v7 (G51/G52/G76) behind an opt-in env var (PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1, upstream's own experimental-GPU guard) — which can't be set from inside a sandboxed Android app process. Dropped the gate for this packaged build; the driver's been through enough validation on this exact GPU that the guard isn't buying anything here anymore.

Result: driver now loads successfully inside Winlator's own process, no fallback to the stock blob, and correctly reports ~140 real device extensions (matching what the same build reports under my own local harnesses, modulo a couple of context-dependent ones).

Haven't run an actual frame through it inside Winlator yet — that's next. But getting past silent-fallback-to-stock-driver and seeing real extension counts come back is the first confirmation that this thing behaves like a real driver from inside the actual target runtime, not just my own test scaffolding.

Repo with the full phase-by-phase writeup and patches: [link]

&#x200B;

WSI agora funcionando, primeiro quadro real exibido na tela

Há algum tempo, comecei a trabalhar para fazer o PanVK do Mesa (o driver Vulkan para GPUs Arm Panfrost) rodar em uma Mali-G52 MC2 que expõe apenas a interface proprietária `mali_kbase` — sem nó de renderização DRM, sem root, apenas via Termux, com compilação nativa `aarch64` no próprio aparelho. O objetivo final é um driver nativo que o Winlator possa, futuramente, carregar para jogos de Windows via Wine/Box64/DXVK.

Um breve resumo da situação anterior:

Pipeline de computação funcionando plenamente através do driver real (não apenas testes brutos de `ioctl`) — `vkCreateInstance` → despacho de shader → leitura de retorno (readback) correta.

Chamada de desenho gráfico real confirmada fora da tela (alvo de renderização 4x4, triângulo, leitura de pixels correta).

O WSI (exibição de pixels em uma tela real) estava travado: `vkGetPhysicalDeviceSurfaceCapabilitiesKHR` e as etapas subsequentes travavam indefinidamente, com todas as threads paradas em `futex_wait_queue_me`.

A causa raiz, após muita investigação com `gdb`, `strace` e `proc-fs` que acabaram sendo pistas falsas (não era um bug de WSI/X11, nem deadlock por `fork` após criação de threads, nem cache de disco, nem conflito DRI3-vs-SHM):

O loop de sinalização de semáforo após `vkQueueSubmit` presumia que todo objeto de sincronização de saída era um `drm_syncobj` (`assert(vk_sync_type_is_drm_syncobj(...))`). Como o `kbase` não possui nó DRM, este driver utiliza um `kbase_cpu_sync_type` personalizado — e, como as asserções são removidas em compilações de produção (*release builds*), a incompatibilidade de tipos passava despercebida silenciosamente. A função que efetivamente sinaliza os objetos de sincronização do `kbase` nunca era chamada. Qualquer semáforo no qual um aplicativo aguardava (como o semáforo de apresentação do WSI) simplesmente... nunca recebia o sinal. Para sempre. A correção foi simples depois de encontrada: basta verificar o tipo de sincronização e, no caso que não utiliza `drm_syncobj`, chamar diretamente a função genérica `vk_sync_signal()`. Isso é seguro aqui porque o envio de tarefas (*job submission*) do `kbase` já é síncrono (aguarda o evento de conclusão do `ioctl` antes de retornar); portanto, quando chegamos ao loop de sinalização, a execução da tarefa já foi comprovadamente concluída.

Resultado: `vkQueuePresentKHR` retorna `VK_SUCCESS`, os quadros são exibidos corretamente (3 de 3) em um teste mínimo de *swapchain* XCB e — a prova definitiva — o `vkcube --wsi xlib` (sem modificações) renderiza o cubo real da LunarG na tela. É o primeiro quadro real gerado por essa pilha de drivers nesta GPU, sem qualquer *blob* Vulkan do fabricante envolvido.

Repositório (o README contém a descrição detalhada fase a fase, os *patches* e a base de *ioctls* brutos sobre a qual isso foi construído): [link]

Não pretendo mexer no empacotamento para o Winlator até que essa solução esteja mais consolidada e eu tenha testado mais alguns caminhos de WSI, mas queria compartilhar esse marco. Fico à disposição para responder perguntas sobre o fluxo de envio do `kbase-JM`, a base de *ioctls* brutos ou o processo de depuração, caso isso seja útil para mais alguém que esteja lidando com configurações Mali semelhantes que não utilizam DRM.

Github (preciso atualizar)

Hey everyone, I’m sharing some progress made during a marathon debugging session over the last few days: I compiled the **PanVK** driver (Mesa's Vulkan driver for Arm Panfrost GPUs) directly on the device — a **Redmi 13C, Mali-G52 MC2** — using only Termux; no cross-compilation, no PC, and no NDK involved.

What is confirmed so far:

- The Kbase kernel driver responds correctly (UAPI 11.38, confirmed via actual ioctl calls)

- `libvulkan_panfrost.so` compiles 100% (required 5 specific patches — Mesa assumes a full AOSP environment, which Termux lacks: no actual `liblog`, `libsync`, or `libcutils`)

- The driver loads via `dlopen`, correctly exports the ICD interface, and **`vkCreateInstance` works**

What isn't working yet:

- `vkEnumeratePhysicalDevices` returns 0 devices — even with the `PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1` flag that PanVK itself uses to enable non-conformant hardware. I haven't found the root cause yet.

In short: **it's not a functional driver yet**; the GPU is "talking" to the driver at the most basic level, but the physical GPU isn't being enumerated. I've documented everything (patches, evidence, build config) in the repository for anyone who wants to reproduce it, test it on their own G52, or help figure out why enumeration is failing:

👉 Github here

If anyone here has another device with a Mali-G52 (or G31/G51/G57—the same Bifrost JM family) and Termux set up, testing and comparing results would really help determine if this is specific to my device or an issue with the driver/environment in general.

https://docs.mesa3d.org/drivers/panfrost.html

Um pouco de gameplay com o driver! Lembrando, ele ainda é experimental, por isso a performance é tão ruim no meu telefone

Estou fazendo um teste de clonagem sobre os drivers PanVk/PanFrost, por favor não reclamem de o driver decompilado não funcionar, além de ser só um teste, eu estou utilizando a claude AI e o gemini AI como ajuda, deixem suas respostas se funcionou ou não.

I'm running a cloning test on the PanVk/PanFrost drivers. Please don't complain if the decompiled driver doesn't work; besides, it's just a test. I'm using Claude AI and Gemini AI.

Link do driver https://github.com/Cadu0910/Driver-clone-test/releases/tag/Driver

O jogo funciona muito bem com 12gb de RAM, aqui estão as configurações

Proton 10 arm64

Dxvk 1.10.3 async

1280x720p

Fex 2601 compatibilidade

Wrapper Leegao

BCN Emulation Cache 1

Os crashs não acontecem! Você pode progredir com o game normalmente

Gravação reduz o fps significativamente, mas é alcançável uma taxa média de 42fps

I agree that she's not the best, but her playstyle is excellent for sacrifice and pact rooms.

Poco x6 pro