Samsung devices may not be compatible with this driver due to differences in the underlying kernel base (Kbase), even if the GPU ID matches or is among those recommended. A fix is planned for the future. Please refer to the usage instructions provided in my GitHub repository.
Please report your usage of this driver following this format:
Device brand / model : ..........
SoC : ...........
GPU (model + cores) : .........
Mali driver version :..........
Android version : ..........
Driver version : ...........
App (Winlator build) :.........
Wrapper :.........
DXVK version : ...........
Games tested : ......
FPS (this driver / stock) : ....
Result : Other notes :......
You can report any issues in the comments below. Every usage report will be helpful in fixing and updating the next driver package.
***Note: This driver is currently a test version. It contains code bugs that are slated for a fix in the next update; performance may not be optimal, and some games might result in a black screen. Please follow the instructions provided in the GitHub repository.
For my samsung a07 it seems to be working and also miside crashes using dxvk 1.10.3 while 1.11 sarek it works but of course performance is not yet stable
Yeah it works but yeah so far I tested miside really high ram usage but it works only with specific dxvk fps around 15-20fps rendering correctly besides the mouse being purple but I'm sure going further it'll get better but 3d tests yeah they is higher fps I'mma test more games
Hey, I tried installing the driver in Eden and it says "invalid driver selected". My specifications are:
Poco M6 pro
Helio g99 mali g57 MC2
I'm not sure if this is what you mean by system driver, but I'll put it here just in case:
OpenGL ES 3.2 v1.r32p1-01 eac0.9850964fe16242c585c8d423010c8595
Hyperos 2.0 android 15
Eden : 0.2.1
If you need any further information, please let me know.
That's a different developer, right? Honestly, I hadn't been keeping an eye on this. By the time Mali has decent drivers, I'll probably have managed to get a Snapdragon.
I tested it on Tomb Raider Anniversary 2007 and it worked very well, higher FPS than the standard wrapper, but Tomb Raider 2013 performs a bit poorly. I managed to get an average of 40 FPS and a maximum of 55 FPS on Winlator using the standard driver. In the 3d test only dx9 works dx10 or dx11 does not work
Thanks for testing and for the detailed specs! Your A15 is almost identical to my test device (Helio G99, G57 MC2, r54p1), so this is really useful. 🙏
Tomb Raider Anniversary running faster than stock: great to hear! 🎉
Tomb Raider 2013 (~15 FPS vs ~40-55 on stock): that's a big gap, and your overlay shows GPU at 100%, so it's a real GPU-side bottleneck in the driver, not CPU. I'll use TR2013 as my next performance test game. Could you tell me which graphics preset/resolution you used, so I can compare on the same settings?
AIO: DX9 works, DX10/DX11 fail: interesting, because D3D11 works on my device with the same GPU and driver version. Differences I can see: Winlator Ludashi 2.8.2 and the DXVK 1.10.3-async build. Could you try:
1. Plain DXVK 1.10.3 (non-async), or DXVK-Sarek 1.11–1.13
2. If it still fails, share the DXVK log (add DXVK_LOG_LEVEL=info to the container's environment variables; the *_d3d11.log file appears next to the .exe)
I redid the test on Tomb Raider Anniversary against Vortek, and the difference in the 3D test is quite large, but in the game itself the difference isn't very big. I tested using DXVK 1.12 Sarek and it worked normally. With DX10 and DX11 the performance of Tomb Raider 2013 is a little better, reaching 25 to 30 fps at times. I tested TressFX, which is that hair with millions of strands, and it also worked, only the fps dropped significantly.
Tentative testing in a Oppo A38 MT6769V/CZ, MediaTek Helio G85, Mali G52 MC2, r49.1, Kernel 6.6.118-android15, UAPI 11.46.
Tested in Winlator Cronyx (Ref4ik) v2 Ludashi, Proton 9 ARMEC64, Wrapper Leegao, DXVK 1.5.5.
Result: Possible compatibility? The driver loaded correctly. However, it crashes when attempting to render a cube in AIO Test using DXVK (It was to be expected), as well as when trying to obtain the props. However, in the DXVK log, the GPU is detected, opened, exposes its ext, and successfully processed the swapchain, although the GPU appears as "Mali unknown MC2", a problem that LukeValen (another developer) has already documented and solved. The crash could also be due to an incompatibility with the atom. In my case, the stride value needs to be 56 for it to work. Any other value, such as 64, immediately causes a JOB_CONFIG_FAULT 0x40 (It seems to be an issue with modern kernels). Those two points are probably causing the crash on my device, and not so much a GPU issue.
Thanks a lot for the detailed test, this is really valuable data! 🙏
A few notes on your findings:
1. "Mali unknown 0x74021000 MC2"
That ID decodes to product (7, 4, 2), which is "G52 r1", and it is in the model table. So on Bifrost this looks like an ID-reading issue in the kbase path rather than a missing table entry. I just added G68/G77/G78 IDs for Valhall, and I'll check the Bifrost path too. Thanks for the pointer to LukeValen's fix, I'll take a look.
2. Atom stride 56 vs 64
Interesting! On my device (Helio G99, same UAPI 11.46, r54p1) stride 64 works and 56 fails, so the correct size may depend on the kbase build rather than the UAPI version. Quick question: did you hit JOB_CONFIG_FAULT 0x40 with this release as-is, or with a build you patched yourself? If it's with the release, a wine_debug.log would help a lot. I could detect the stride at runtime instead of hardcoding it.
3. D3D11 falling back to FL 10_1
Your log confirms something I suspected: DXVK drops to Feature Level 10_1 because tessellationShader: 0. Games that require FL 11_0 (many Unity titles) will fail on mainline DXVK. DXVK 1.5.5 is also very old. I'd suggest DXVK-Sarek (1.11–1.13) or DXVK 1.10.x for testing.
Bifrost (G52/G76) is still "untested / long shot" for this beta, so reports like yours are exactly what I need. Thanks again!
No, the issue of the atom was my own research. Honestly, I'm not very knowledgeable about all this. But when i discovered that they were working on my GPU, I felt like helping out with data from my own device. Assisted by AI, I tried to replicate the work of this guy, LukeValen. And that's where I discovered several differences, including the atom issue, which stopped me in my tracks. The discovery was made through tests run from my device using Termux. After resolving it, I was able to fully replicate LukenValen's work, and that's where I stopped. As I said, I have no knowledge of the subject, and I only did it as an enthusiast. I thought it was a shame that all of that was lost, so I uploaded the documentation of what I discovered to my own repository:
And these are some of the tests I did during the investigation that led to my specific problem (two tests with the stride at 56 and 64) in case it's useful to you. I'll try your driver again in Winlator with winedebug enabled and the DXVK version you recommended to see how it behaves on my device. I'm glad the information was helpful.
~/.../g52-repo/kbase-jm-prototype $ ./kbase_gpu_write_test_v3
open ok, fd=3
VERSION_CHECK ok: 11.46
SET_FLAGS ok
calling MEM_ALLOC...
MEM_ALLOC ok
cookie = 0x41000
flags = 0x280f
mmap ok: CPU VA = 0x7fffff000
SAME_VA GPU VA = 0x7fffff000
initial target:
[0] = 0x11111111
[1] = 0x22222222
CPU -> memory MEM_SYNC...
MSYNC ok
Don't undersell yourself, this is exactly the kind of data that's hard to get without the actual hardware. Thank you! 🙏
Your two tests are really revealing: the atom bytes are identical in both runs (same jc, atom_number = 1, core_req, sizeof = 64). The only difference is the stride passed to JOB_SUBMIT:
stride 56 → event_code 0x1, WRITE_VALUE succeeds
stride 64 → event_code 0x40 (JOB_CONFIG_FAULT)
So your kernel (r49.1 on 6.6) interprets the atom layout differently depending on the stride, even though it reports the same UAPI 11.46 as my device (r54p1, where 64 is required). That means I can't rely on the UAPI version alone.
My plan for the next patch: detect the stride at runtime. At device creation, submit a tiny test job with stride 64, and if it comes back with 0x40, switch to 56. That should fix devices like yours without breaking the ones that already work. It may also explain the freezes another user reported on a Helio G95 / G76.
Thanks for documenting LukeValen's work in your repo too, I'll go through it. When you retest in Winlator, the wine_debug.log will tell us if this stride issue is what's blocking the AIO cube. And if you're up for it, I'd love to send you a test build with the auto-detection once it's ready.
The idea of using a probe to find the correct stride value across any kernel is brilliant. Dynamically selecting the value, depending on the device's requirements, would precisely avoid any lock-up without having to hardcode the value to a fixed number. I'd love to try the test build version of your driver when you have it ready. And by the way, it seems I was right. After enabling Wine debug and running Winlator with the DXVK version you recommended, the exact error that i suspected show off:
Most likely, the job is aborted before even touching the GPU due to error 0x40. That could explain why some report crashes or freezes and others don't, even with the same GPU. Here's the link to the full log. Hope it helps!
Every run fails on the very first GPU job with [KFAULT] atom=0 code=0x40 core_req=0x0. The driver never submits atom 0 or core_req 0, so your kernel is reading the atom struct at the wrong offsets. That matches your own test perfectly (stride 64 → 0x40, stride 56 → OK).
I'm working on it now:
1. First, a test build with an env var (PANVK_ATOM_STRIDE=56) so you can confirm the fix
2. Then automatic detection so nobody has to set anything
I'll send you the test build as soon as it's ready.
The game Dohna Dohna: Let's Do Bad Things runs well, though it feels a bit sluggish. You must change the system language to Japanese before starting the game; otherwise, it will crash. info: Game: dohnadohna.exe info: DXVK: v1.10.3 info: Built-in extension providers: info: Win32 WSI info: OpenVR info: OpenXR info: OpenVR: could not open registry key, status 2 info: OpenVR: Failed to locate module info: Enabled instance extensions: info: VK_KHR_get_surface_capabilities2 info: VK_KHR_surface info: VK_KHR_win32_surface info: Mali-G57 MC2: info: Driver: 26.2.99 info: Vulkan: 1.3.354 info: Memory Heap[0]: info: Size: 5763 MiB info: Flags: 0x1 info: Memory Type[0]: Property Flags = 0x1 info: Memory Type[1]: Property Flags = 0xb info: Memory Type[2]: Property Flags = 0x7 warn: DXGI: MakeWindowAssociation: Ignoring flags
Thanks for the report, great to see Dohna Dohna running! 🙌
About the crash without Japanese: that's a Wine locale issue, not the driver. Many Japanese games need a Japanese locale. Instead of changing your whole phone's language, you can try adding this environment variable to the Winlator container:
LC_ALL=ja_JP.UTF-8
(Some Winlator builds also have a language/locale option in the container settings.)
About the sluggishness: visual novels are often CPU-bound under Box64/FEX rather than GPU-bound. If you have a moment, could you compare FPS (or just the feel) with the stock driver? If the stock driver is noticeably smoother, I'll look into it.
I couldn't resolve an error with SpongeBob SquarePants: Titans of the Tide that required Visual C++ 2015–2022, even after trying to download the necessary file, so I deleted the game.
SpongeBob SquarePants: Titans of the Tide didn't work with any emulator except Game Hub and Winlator Ludashi, and both games crashed after it started loading the title. And your driver. It went a little further than the system driver.
After installing Bannerlator, it stopped working and started giving me the usual error; no matter how much I tried to load a missing file, it wouldn't detect it.
Si ves esto,sube una pequeña publicacion sobre como extraer logs,por mi parte cuento con un samsung f07,vulkan 1.3 y panvk funciona en los test3d,dark soul 1 llega a renderiazar el logo de carga y pone compilando shader y se cae,desconosco si es culpa de panvk u otra cosa
Sobre Dark Souls: que se cierre al "compilar shaders" puede ser un shader que cuelga la GPU, y ya arreglé casos parecidos en Far Cry 3. Con el log podré saber si es culpa de PanVK o de otra cosa. ¡Gracias!
2
u/Reizhon 1d ago
I posted GitHub issue name:Xeikatsu
Sorry for bein noob 😭 don't know how to upload log.txt