The correct behavior is to respect the setting in makepkg.conf
. Arch targets x86-64, so setting local still results in the wrong setting/behavior.
Search Criteria
Package Details: ares-emu 141-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/ares-emu.git (read-only, click to copy) |
---|---|
Package Base: | ares-emu |
Description: | Cross-platform, open source, multi-system emulator by Near and Ares team, focusing on accuracy and preservation. |
Upstream URL: | https://ares-emu.net/ |
Licenses: | ISC |
Conflicts: | ares-emu |
Provides: | ares-emu |
Submitter: | Snowstorm64 |
Maintainer: | Snowstorm64 (SoullessSentinel) |
Last Packager: | Snowstorm64 |
Votes: | 22 |
Popularity: | 0.138401 |
First Submitted: | 2021-02-21 21:36 (UTC) |
Last Updated: | 2024-11-04 20:12 (UTC) |
Dependencies (15)
- gtk3 (gtk3-no_deadkeys_underlineAUR, gtk3-classicAUR, gtk3-classic-xfceAUR, gtk3-patched-filechooser-icon-viewAUR)
- libao (libao-gitAUR)
- libgl (libglvnd-gitAUR, amdgpu-pro-oglp-legacyAUR, amdgpu-pro-oglpAUR, nvidia-340xx-utilsAUR, libglvnd)
- libpulse (pulseaudio-dummyAUR, libpulse-gitAUR)
- librashaderAUR (librashaderAUR)
- libudev.so (systemd-chromiumos-libsAUR, libeudevAUR, systemd-libs-selinuxAUR, systemd-libs-gitAUR, systemd-libs-fmlAUR, lib32-systemd-gitAUR, lib32-systemd, systemd-libs)
- libxv
- openal (openal-gitAUR)
- sdl2 (sdl2-gitAUR, sdl2-compat-gitAUR)
- vulkan-driver (nvidia-410xx-utilsAUR, nvidia-440xx-utilsAUR, nvidia-430xx-utilsAUR, swiftshader-gitAUR, amdvlk-debugAUR, nvidia-vulkan-utilsAUR, amdvlk-2023q3.3AUR, amdvlk-2021q2.5AUR, amdvlk-gitAUR, vulkan-nouveau-gitAUR, mesa-minimal-gitAUR, mesa-gitAUR, vulkan-amdgpu-pro-legacyAUR, amdvlk-binAUR, mesa-wsl2-gitAUR, nvidia-535xx-utilsAUR, nvidia-470xx-utilsAUR, amdonly-gaming-vulkan-radeon-gitAUR, amdonly-gaming-vulkan-swrast-gitAUR, vulkan-radeon-amd-bc250AUR, nvidia-390xx-utilsAUR, nvidia-utils-teslaAUR, nvidia-utils-betaAUR, vulkan-amdgpu-proAUR, nvidia-525xx-utilsAUR, nvidia-510xx-utilsAUR, nvidia-550xx-utilsAUR, amdvlk, nvidia-utils, vulkan-intel, vulkan-nouveau, vulkan-radeon, vulkan-swrast, vulkan-virtio)
- vulkan-icd-loader (vulkan-icd-loader-gitAUR)
- clang (llvm-rocm-gitAUR, llvm-gitAUR, clang-minimal-gitAUR, clang17-binAUR) (make)
- git (git-gitAUR, git-glAUR) (make)
- lld (llvm-rocm-gitAUR, llvm-gitAUR) (make)
- mesa (mesa-minimal-gitAUR, mesa-gitAUR, mesa-wsl2-gitAUR, amdonly-gaming-mesa-gitAUR, mesa-amd-bc250AUR, mesa-amber) (make)
Required by (0)
Sources (1)
xiota commented on 2024-06-09 16:39 (UTC)
Snowstorm64 commented on 2024-06-09 09:50 (UTC) (edited on 2024-06-09 10:19 (UTC) by Snowstorm64)
The use of -march=native
is intended by Ares developers for squeezing more performance from your CPU, at the cost of portability. This is critical for some core (e.g. N64), where some extra FPS could make the difference between a playable game and a less playable one.
Since this is AUR where one builds a binary for themselves, it makes sense to sacrifice portability for some more performance.
If you need to redistribuite the binary, you can edit the PKGBUILD by adding local=false
to the make line, like this:
make -C "${srcdir}/ares-${pkgver}/desktop-ui" hiro=gtk3 compiler=clang++ local=false
local=false
sets -march
flag as x86-64-v2
instead of native
.
xiota commented on 2024-06-08 22:58 (UTC) (edited on 2024-06-09 22:22 (UTC) by xiota)
When built on a different computer than installed, has potential to crash when run. Problem is -march=native
setting at desktop-ui/GNUmakefile#L15-L24.
Should be patched so that setting in /etc/makepkg.conf
is respected.
ares-emu-git
is also affected.
djranm commented on 2024-04-08 20:57 (UTC)
Yes! That did the trick, thank you.
Snowstorm64 commented on 2024-04-08 11:43 (UTC)
I have just pushed a new revision of librashader, with a new workaround, please update it on your system to make it work with Ares. Many thanks to TheGentlChainsaw for finding the root of the issue.
djranm commented on 2024-04-05 08:46 (UTC)
Same as @TheGentlChainsaw, re-building librashader with profile set to 'release' doesn't seem to change anything.
TheGentlChainsaw commented on 2024-04-04 20:57 (UTC) (edited on 2024-04-04 21:04 (UTC) by TheGentlChainsaw)
I'm having the same issue as djranm. I've just tried rebuilding librashader with the "release" profile, it didn't work. I'm using base Arch.
$ uname -a
Linux SnowyEagle 6.8.2-arch2-1 #1 SMP PREEMPT_DYNAMIC Thu, 28 Mar 2024 17:06:35 +0000 x86_64 GNU/Linux
$ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.4-arch1.2
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.4-arch1.2
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.0.4-arch1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix,
Snowstorm64 commented on 2024-04-04 15:09 (UTC)
It has been suggested that this could be a linking issue, one potential fix for it is rebuilding librashader, by editing its PKGBUILD and changing profile value (line 16) from "optimized" to "release".
Could you tell me if it has worked for you?
djranm commented on 2024-04-03 22:34 (UTC) (edited on 2024-04-03 22:36 (UTC) by djranm)
Thanks for your help.
Yes, librashader is installed to /usr/lib
~
❯ ls -l /usr/lib/librashader*
lrwxrwxrwx 1 root root 20 Apr 4 08:13 /usr/lib/librashader.so -> librashader.so.0.2.7*
-rwxr-xr-x 1 root root 14225888 Apr 4 08:13 /usr/lib/librashader.so.0.2.7*
I'm using CachyOS (sorry, I should have mentioned this).
~
❯ uname -a
Linux PC-MEDIA-LIN 6.8.3-3-cachyos #1 SMP PREEMPT_DYNAMIC Wed, 03 Apr 2024 19:06:44 +0000 x86_64 GNU/Linux
I tried reinstalling librashader, installing ares-emu-git instead of ares-emu, and clearing my ares config - no change.
This might be on the completely wrong track, but I also tried to preload librashader which revealed an interesting error.
~
❯ LD_PRELOAD="/usr/lib/librashader.so" ares
ares: symbol lookup error: /usr/lib/librashader.so: undefined symbol: glslang_initialize_process
If I add libglslang, the message changes. This is where I got stuck.
~
❯ LD_PRELOAD="/usr/lib/librashader.so /usr/lib/libglslang.so" ares
ares: symbol lookup error: /usr/lib/librashader.so: undefined symbol: sc_internal_compiler_glsl_new
Here's my OpenGL details.
~
❯ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.4-arch1.2
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.4-arch1.2
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.0.4-arch1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,
Grateful for your assistance, it'd be great to get this going!
Snowstorm64 commented on 2024-04-03 15:27 (UTC) (edited on 2024-04-03 15:27 (UTC) by Snowstorm64)
Hi @djranm, that's odd...Could you tell more: for example, where librashader is installed? Ares would expect it at '/usr/lib/librashader.so'.
Also, do you use Archlinux or some derivative (e.g. Void, Manjaro)?
Did you try to reinstall librashader?
Which version of OpenGL do you have? (with command "glxinfo | grep version")
Pinned Comments
Snowstorm64 commented on 2024-06-09 09:50 (UTC) (edited on 2024-06-09 10:19 (UTC) by Snowstorm64)
The use of
-march=native
is intended by Ares developers for squeezing more performance from your CPU, at the cost of portability. This is critical for some core (e.g. N64), where some extra FPS could make the difference between a playable game and a less playable one. Since this is AUR where one builds a binary for themselves, it makes sense to sacrifice portability for some more performance.If you need to redistribuite the binary, you can edit the PKGBUILD by adding
local=false
to the make line, like this:local=false
sets-march
flag asx86-64-v2
instead ofnative
.