Initial Linux Aarch64 port (PPU only) #11315
Conversation
Nekotekina
changed the title
Nekotekina
force-pushed
the
master2
branch
2 times, most recently
from
76197f5
to
b53ba27
Compare
|
Wow, PPU interpreter works now. |
Nekotekina
force-pushed
the
master2
branch
14 times, most recently
from
b726ad6
to
6e77597
Compare
|
|
| enabled_features.shaderClipDistance = VK_FALSE; | ||
| } | ||
|
|
||
| if (!pgpu->features.shaderStorageBufferArrayDynamicIndexing) |
There was a problem hiding this comment.
lavapipe has this implemented on mesa-git and will be part of Mesa 22.0 release in February. It's best if you test lavapipe with mesa-git, Mesa's current stable has an issue that crashes most games on lavapipe (https://gitlab.freedesktop.org/mesa/mesa/-/issues/4855)
There was a problem hiding this comment.
I tested on ubuntu 21.10 aarch64 and it does have all this stuff working. For some reason neko's system does not work right, but yea, this is not really a fix. We do invariably use these features unconditionally and there is no reasonable workaround for it as it is core fixed function stuff. I'll re-review when this is all ready for review.
There was a problem hiding this comment.
I use Ubuntu 22 container which seems to have outdated Mesa but there is no PPA for this version yet or I couldn't find it.
Nekotekina
force-pushed
the
master2
branch
7 times, most recently
from
b58de63
to
ad1a69b
Compare
Nekotekina
force-pushed
the
master2
branch
14 times, most recently
from
4e8b59d
to
f8ebbbd
Compare
Nekotekina
changed the title
* Update asmjit dependency (aarch64 branch) * Disable USE_DISCORD_RPC by default * Dump some JIT objects in rpcs3 cache dir * Add SIGILL handler for all platforms * Fix resetting zeroing denormals in thread pool * Refactor most v128:: utils into global gv_** functions * Refactor PPU interpreter (incomplete), remove "precise" * - Instruction specializations with multiple accuracy flags * - Adjust calling convention for speed * - Removed precise/fast setting, replaced with static * - Started refactoring interpreters for building at runtime JIT * (I got tired of poor compiler optimizations) * - Expose some accuracy settings (SAT, NJ, VNAN, FPCC) * - Add exec_bytes PPU thread variable (akin to cycle count) * PPU LLVM: fix VCTUXS+VCTSXS instruction NaN results * SPU interpreter: remove "precise" for now (extremely non-portable) * - As with PPU, settings changed to static/dynamic for interpreters. * - Precise options will be implemented later * Fix termination after fatal error dialog
|
There's user reports that Java mode setting got flipped with this PR, causing issues like #5289 to reappear when default settings are used. |
|
@Nekotekina Are their any brief write ups on compiling for ARM64? I understand performance will be broken at best, but would like to start tinkering around with this as I have access to a decently powerful ARM workstation with a Radeon GPU. My problem in the past building this was always with the VulkanSDK being only available for x86 platforms. Appreciate any info on this, and apologies if this isn't the correct thread for this. |
|
@Wooty-B I used pretty much out-of-the-box Ubuntu 22.04 container to cross compile for arm64. I think separate Vulkan SDK isn't required. |
|
@Nekotekina I'm currently running on Debian 11 aarch64, been playing around and I'm getting further but seems like it's failing related to ARM NEON. I'm not sure if I need to dig around and try to exclude NEON support, but here is the make failure in question: Goal would be to get this built locally, however if there's any private builds uploaded anywhere I'd really just like to test a couple of things on this hardware. Thanks again for your ARM64 efforts and feedback! |
You must set -DUSE_NATIVE_INSTRUCTIONS=OFF in your cmake command. Also, wrong forum for discussion. |
|
@kd-11 Setting -DUSE_NATIVE_INSTRUCTIONS=OFF and -DUSE_SYSTEM_FFMPEG fixed my compile errors, thank you |
No, nothing works.
