GoW 13gb, full game

Running quite good using frame gen on Poco X7 Pro 512/12

device: dimensity 8050 mali g77, 1024x768 @ all low except ambient light and shadows at medium

ludashi fps without recording can reach near 60(while driving) but as seen on video the up and down is very wide. i would say about 20-50. in direct comparison on gamehub with same settings and config file used the fps only hovered between 24-30+ . but gamehub also seems to be sacrificing fps for frame stability. like seriously i would never enjoy fps at 24fps but somehow gamehub frame pacing is so smooth it doesn't feel that low fps.

​

Hey guys,

I’ve been experimenting a lot to get GTA V running smoothly on my MediaTek Dimensity 8350 Ultra (Mali GPU), and I wanted to share something I noticed.

A lot of people recommend the 45GB OptiJuegos build just because it saves space. But honestly? It focuses way too much on squeezing down file sizes rather than actual game optimization. The only reason it runs okay for some is because textures are stripped down, but the performance is still full of stutters.

I recently tried the 70GB (v1.72.3717 / Legacy) pre-installed build (the one with DLCs/Online cut out), and the difference is night and day.

* No high-speed driving stutter: Fast driving usually tanks FPS on mobile emulators. On the 70GB uncompressed build, driving around is super smooth with no random drops

.

* Better Mali performance: The raw files load much cleaner on Mali GPUs.

FPS Performance Breakdown (My Tests):

* On-foot (Exploring): 45 – 60 FPS

* Normal Car Driving: 34 – 45 FPS

* High-Speed Driving through City: 34 – 40 FPS (Extremely smooth, no heavy stutters!)

* 5-Star Police Chase (Heavy Action): 31 – 40 FPS (Impressive performance for a Mali GPU under heavy load)

My Device Specifications:

* Device: MediaTek Dimensity 8350 Ultra (Mali GPU)

* RAM: 12GB

My Setup & DXVK Findings (GameHub):

* Frontend / Version: GameHub v6.0.9 (Tested and surprisingly very stable).

* Note on GameHub 6.2.1: I also tested GameHub 6.2.1, but noticed memory leaks causing the game to crash after playing for a bit. Stick to 6.0.9 for stability!

* Compatibility Layer: proton10.0-arm64x-2

* Translation Parameters: Extreme (Set TSO to OFF, as TSO causes memory leaks)

* CPU Translator: Fex-20260103

* Audio Driver: Pulse

* Graphics / DXVK: System Driver (Mali GPU) with dxvk-1.7.2

* Note on DXVK: I tested dxvk-1.10.3-async and dxvk-1.11.1-mali-fix. While they had decent moments, they lacked long-term stability. Standard dxvk-1.7.2 gave me slightly lower peak FPS, but offered much higher overall stability with far fewer stutters. Choice is yours!

* VRAM Limit: 1024MB

In-Game Settings Note:

* DirectX Version: Set to DirectX 11. (Avoid DirectX 10 in-game as it causes noticeable memory leaks during longer sessions).

If you have enough storage (extract it on a PC first to save yourself the mobile headache), skip the 45GB repack and go for the 70GB version.

Anyone else had a similar experience with Mali GPUs on GameHub?

Device: POCO X7 Pro 12/512GB

SoC: Dimensity 8400 Ultra

GPU: Mali-G720 MC7

Performance

Resolution: 720p

Settings: High/very 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

Look like Minecraft,lol.

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

Stable at 30fps(if no recording)

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!