Replies: 1 comment
-
You are correct that we don't currently provide 32-bit armhf user-space binaries for OpenGL/vulkan/etc; we only currently provide aarch64 binaries. Is it viable to use compatibility layers like FEX to translate 32-bit x86 binaries to aarch64? Or does that not make sense (e.g., too invasive to the emulator to change pointer size)? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
For the past couple of years I have been using an ARM64 workstation as my primary desktop, and it has honestly met all of my daily computing needs including light to medium gaming. Up until recently, I have been limited to using AMD GPU's solely for the fact nVidia cards didn't have much aarch64 support, and with the recent release of open nVidia drivers I ran out to my local electronics reseller and picked up a small RTX 3060.
The performance gains have been noticeable compared to my previous GPU's in the 64-bit applications I've tested, and moreover been extremely excited to have team green working happily on my ARM platform. One thing that's been prevalent since ARM SBC's have gained PCIe is beginners and experts alike wanting to run desktop class GPU's to improve gaming performance. Many current and past ARM SBC's have PCIe 1x and 4x capabilities without the proper specs for running GPU's, leaving users wanting for the next generation of SBC's with better PCIe support.
Outside of Workstation, Data Center, Scientific and Compute workloads, there's one big elephant in the room for gamers, and it's name is Steam. Since nVidia drivers in the past have included both support for 32-bit x86 and 32/64-bit x86_64 setups, applications like Steam and Wine run flawlessly on Linux regardless if the application is 32 or 64-bit, extending the vast back-catalog of games and applications. Currently, this is achieved on ARM platforms by running a compatibility layer such as Box86/Box64 or FEX. Using the compatibility layers, I am able to run games through Wine like Crysis 2, GTA IV, and Skyrim, many games through Steam, as well as 32-bit x86 native Linux games.
Currently, it seems I am missing 32-bit armhf libs needed by 32-bit Linux games and applications including the compatibility layers mentioned above. As far as I know this is due to the official drivers only supporting x86, x86_64 (multi-lib), and aarch64 (pure 64-bit). Since AMD GPU's support 32-bit systems via Mesa, it seems like this is the only way I can continue to run any GPU bound 32-bit applications, but hope I am severely mistaken. I see many people jumping on the ARM bandwagon once more devices gain proper PCIe support, leading many to use GPU's that have access to a larger software library due to lack of driver support.
My goal with this post is to shed light on the fact gaming is going to become a big part of the ARM platform moving forward, and most gaming setups require 32-bit support to support decades of older titles. (Titles that run GREAT on lower performant ARM CPU's!) Not only this, but by having another option besides AMD will help mature the ARM platform with the byproduct of more users choosing nVidia when these SBC's, desktops, and laptops hit the market.
If there are 32-bit armhf libs I am unaware of, or I have overlooked something simple, the error I am getting on all my 32-bit applications is below:
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 117
Current serial number in output stream: 116
I am currently running a SolidRun HoneyComb LX2K w/ 8x PCIe 3.0 bus paired with an RTX 3060. Here is my channel where I have uploaded a couple of videos showcasing gaming on ARM with my older AMD GPU: LINK
Beta Was this translation helpful? Give feedback.
All reactions