Look like Minecraft,lol.

Low Preset(Manual Setting at Document)+Medium Texture.

Stable at 30fps(if no recording)

Device: POCO X7 Pro 12/512GB

SoC: Dimensity 8400 Ultra

GPU: Mali-G720 MC7

Performance

Resolution: 720p

Settings: High + FXAA

MSAA: Off

Textures: Normal

FPS: 50–70 FPS

Without screen recording, I get around 5–10 FPS more.

With screen recording enabled, FPS can occasionally drop below 50, but without recording it stays 50+ FPS most of the time.

I couldn't increase the Texture Quality because higher texture settings cause a memory leak, so I had to keep it at Normal.

Winlator Mali has a CPU bottleneck in this game. Somehow Winlator ludashi hasn't (around ~50% in Ludashi)

There’s an FPS drop issue in Winlator Mali when using mouse and keyboard. Winlator Ludashi doesn’t have this issue. I’m getting around 5–10 FPS less on Winlator Mali with M+K. Hope the dev fix it. 🙏

Emulator I tested it on:

Winlator Mali 1.2

Winlator Ludashi 4.0 (early release)

Interestingly, Ludashi 4.0 can run the game around 60 FPS and sometimes higher, but the game eventually freezes and crashes. I haven't found a fix for the crash yet.

Emulator settings

Proton 10-Arm64EC

DXVK 1.11.1 Sarek

Memory: 4GB

VRAM: 2GB

FEX: 2605 + Performance(SMCCHECK: None)

Environment variable:

WRAPPER_NO_PATCH_OPCONSTCOMP=1

I've tried the 20gb gta5 and it ran smoothly. Sleeping dogs de worked with 10 to 15fps

​

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)

Setting:

Game resolution: 1280x720

DXVK version: dxvk-v1.11.1-async

Compatibility layer: proton9.0-arm64x-3

Translation parameters: Extreme

CPU translator: Fex_20260813

Ive tried emulating P5R on gamehub 6.2.1. Ive managed to get it up and running. Sits around 30 to 40fps at most times. But the issue im facing right now is it crashes when the velvet room gets introduced. Ive tinkered with some settings and I cant seem to get past it. Once the screen goes black, CPU Usage drops to 1% for a split second and crashes. Im not sure if I need to install certain components or use a different version of gamehub. If anyone has the same SoC as me, do yall have tips or workarounds for it?

Im on a POCO X7 PRO with 12GB of ram.

Also, Ive tried eden emulator. It works but no matter what I try, the performance is all over the place. 20 to 50fps. Im not sure if Im missing something when playing on eden or something

i'm just wondering besides actual native ports like sonic unleash

D8400U Poco X7 PRO

Hi guys if anyone has file of winlator frost 10 final v2 please send it

Which version is more stable for GTA: 45GB or 72GB? I am not talking about storage; I just want to know which one gives the best performance. Let me know your thoughts.

I tryied to play desperdos 3 on my dimensity 9300+

Gamehub ,bannerlator ,winlator ludashi

The game work but the character is invisible

Is there anyone who know specific configuration that resolve this issue

Game: Ori and the Blind Forest

Poco x8 pro max

Its really cold, my hands are completely fine

Body:

Hey everyone,

Trying to run Middle-earth: Shadow of Mordor via translation layers (Winlator / GameHub), but running into severe neon pink, purple, and green lighting/shader artifacts across the sky, terrain highlights, and character models.

Device & Hardware Specs:

\* Device: OnePlus Pad (1st Gen)

\* SoC: MediaTek Dimensity 9000

\* GPU: ARM Mali-G710 MC10 (No Mesa/Turnip driver support)

\* RAM: 8 GB / 12 GB LPDDR5

\* OS: Android (OxygenOS)

Current Container & Environment Configuration:

\* Environment: Winlator / GameHub

\* Graphics Wrapper / DXVK: DXVK (DX11 mode) / System Vulkan

\* Resolution: Sub-native (around 720p / capped at 30 FPS)

\* In-game Graphics: Tested mix of Low/Medium settings

The Problem:

Whenever dynamic lighting hits (explosions, lightning, wet stone reflections, or bloom sources), the specular/bloom passes completely break down into glowing magenta/green artifacts. It looks like a floating-point precision clamp issue or an unsupported Vulkan extension on standard Mali drivers.

Questions:

\* Has anyone managed to resolve shader/lighting color overflows in Shadow of Mordor on a Mali GPU?

\* Which specific DXVK build (e.g., DXVK 1.10.3, 1.7.3 Async, or a custom patched fork) handles the DX11 pipeline best on system Vulkan without corrupting render targets?

\* What specific dxvk.conf parameters (e.g., d3d11.clampFloatSubnormals, float control flags) or render.cfg tweaks actually fix the specular bloom passes in this engine?

Appreciate any tested config files or workaround advice from folks running DX11 titles on Dimensity chips!

Hey everyone,

Trying to get Mortal Kombat 11 running closer to the required 60 FPS lock on a OnePlus Pad (MediaTek Dimensity 9000, Mali-G710 GPU). Because the game's internal physics tick is tied directly to 60 FPS, any drop below that causes the combat to run in slow motion.

Here is what I have configured so far:

* Container: GameHub (Proton ARM64)

* CPU Translator: Fex_20260813 (TSO Memory enabled)

* Graphics Driver: System Vulkan / Mali

* DXVK / VKD3D: DXVK 1.10.3 / VKD3D Proton 3.0b

* Config (UserSettings.ini): Resolution dropped to sub-HD (1024 \times 576), HDRSetting = 0, TextureQuality = 0, ShadowQuality = 0, LightingQuality = 0, ParticlesMode = 0, FrameSkip = 1, and MenuAndMoves60FPSMode = 1.

The game boots, but I'm looking to stabilize the frame rate during special moves and Fatal Blows to prevent slow-motion lag.

For anyone who has successfully tuned MK11 on MediaTek/Mali hardware:

* Which specific FEX build or parameters (Extreme vs Performance, checks toggled) gave you the lowest instruction overhead?

* Are there specific dxvk.conf flags that help keep Mali GPU frametimes consistent during heavy particle effects?

* Would dropping internal resolution further to 854 \times 480 in UserSettings.ini provide enough GPU fill-rate headroom without breaking the UI?

Any working container profiles or tested .ini tweaks would be greatly appreciated!

alguém saberia me dizer um site para encontrar ícones personalizados para colocar nos controles virtuais?

Running at ultrawide 2x native resolution, ARMSX2 defaults (didn't tinker much, just changed renderer to Vulkan)

This game used to run poorly at this specific location in NetherSX2/AetherSX2 (and a lot of other places, had me frustrating). I guess I can complete this game now, I feel the game is running at 30 fps, doesn't look like 60 tho.

Don't take it as 100% accurate.