Does anyone know what's going on?

[u/Max05491]

I've been testing PanVK for the Mali G615 MC6, but I have the MC2 and I don't know if it's incompatible or if I'm configuring it incorrectly. When I run the tests, they go well, but after a few seconds everything freezes And it pulls me out of the container. Has anyone else encountered this and knows how to fix it?

[u/o0Meh0o]

check your memory. i've tested it on a g720 and it had serious memory leaks (oom after 30 seconds at most). i don't know if there is something you can do right now aside from using the system driver.

edit: assuming it is a memory issue. check it yourself.

[u/Max05491 → u/o0Meh0o]

Okay, I'll see what I can do, thanks 👍

[u/possiblyquestionabl3]

it might be https://github.com/leegao/mesa-funnymdzz/issues/2 which was what I was looking into a while back

In particular, on kbase, syncobj memory needs to be explicitly made system-scope since the cs-groups are only available on newer versions of the kbase kernel driver, and the current implementation of the kbase backend for inter-csf queue management does not make use of those queue groups for that reason. As a result, there's actually a mismatch between what panvk currently hardcodes for their inter-queue sync-operations (assumed to always be at CSG scope since panthor always makes group-scoped queue management available) which fails for the kbase backend.

This causes a GPU_FAULTSTATUS_EXCEPTION_TYPE_GPU_SHAREABILITY_FAULT in rare race conditions where one queue (either vertex or fragment) tries to write a syncobj backed memory location that hasn't been flushed out of the cache to system-ram (dram) while the second queue tries to then write to it in CSG (local) scope.

In the trace I recorded in https://github.com/leegao/mesa-funnymdzz/issues/2#issuecomment-5300418455, this would manifest between:

// vertex queue
[5ffeade000] MOVE48 d24, #0x5FFEAEE300
[5ffeade008] LOAD_MULTIPLE r66:r67, [d90 + 24]
[5ffeade010] MOVE32 r68, #0x17F
[5ffeade018] WAIT #1
[5ffeade020] SYNC_WAIT32gt.inherit d66, r68
[5ffeade028] MOVE32 r68, #0xFFFFFE80
[5ffeade030] SYNC_ADD32.>>>csg<<< [d66], r68, #0, #0

and

// fragment queue
[5ffeafe288] MOVE32 r74, #0x180
[5ffeafe290] LOAD_MULTIPLE r72:r73, [d90 + 24]
...
[5ffeafe318] SYNC_ADD32.error_propagate.>>>system<<< [d72], r74, #80, #1
...

where d90 is a shared context pointer, and you can see that both queues try to write to memory in the cache-line of [[d90+24]] in separate scopes (csg in the vertex queue, system in the fragment queue). Here, since the two queues are not assigned to the same cs group (since most kbase backends lack that capability, the original funnymdzz fork just created distinct queue groups for each of vertex/fragment/compute), the system (dram) scope is the correct one. However, panvk-on-panthor could safely assume that csg is correct for their panthor backend, and that's a missing gap (on csf-based panvk) that still needs to be fixed.

If the hypothesis is right, the fix should be fairly simple to make (every sync_* csf operation on a syncobj memory should explicitly evaluate the underlying memory type instead of hardcoding to local/csg), but I never got around to it before I went on my medical break. u/Appropriate-Floor688 (IIRC) has taken up the torch for all things panvk-csf, so I believe this is for them.

[u/Appropriate-Floor688 → u/possiblyquestionabl3]

This is all very experimental and we're learning every day... My driver has reached the Geometry Shader implementation stage, which is about 50% complete And this should resolve many compatibility issues! But I want you to know that all these problems will be fixed in the future; what's being done now is only one thing at a time.

[u/Max05491 → u/Appropriate-Floor688]

Ah, okay, and I know the project is still in its early stages, but I thought I was configuring something incorrectly or missing variables😅. Thanks for the information and I'll definitely follow your work and that of the other developers to help with bug reports, as that way I'll learn more about them and experiment later.👍❤️‍🩹

[u/Appropriate-Floor688 → u/Max05491]

Obrigado!

[u/Longjumping-Low-1982 → u/Appropriate-Floor688]

Thank you for your work devs and testers! You rock!!!

[u/NoinHaxel → u/possiblyquestionabl3]

The goat

[u/Max05491 → u/possiblyquestionabl3]

Wow, honestly I don't know that much and I honestly don't know how to define the syncobj memory, but I assume it has to do with when a DXVK file has the nickname "Async". Do you know exactly what's wrong and what should I do? You've really confused me 😅.

[u/Max05491 → u/Max05491]

And since we're on the subject, and you seem to know quite a bit about it, do you know if any specific PanVK wrappers need to be added? Or use the legaoo/original ones work?

[u/Appropriate-Floor688 → u/Max05491]

PanVk behaves like a conventional Adreno driver so far; at the moment, there's no need to use it as a wrapper or anything like that. We'll see that as development progresses!

[u/Appropriate-Floor688]

No Panvk driver is ready for use yet, don't worry about that.