Messages

46

Applications and Porting / Re: Clion, VSCode, IDE options?

« on: July 15, 2023, 01:37:38 pm »

It seems that VSCodium now supports ppc64le
https://github.com/VSCodium/vscodium/releases/tag/1.79.2.23166

This sounds really cool, but what do I do with the download? It appears to be partial compared to x86_64 and ARM64 - do I need to grab one of those tar.gz files, then unzip the contents of the ppc64le archive into it with some additional steps?

47

Applications and Porting / Re: S.T.A.L.K.E.R. / openXray

« on: July 14, 2023, 09:20:50 pm »

Awesome! I actually just found a LuaJIT fork modified to compile for ppc64le a little while ago and was going to try and compile it this weekend, but it looks like the community beat me to it. Is this the main branch of the project that now compiles for ppc64le? If so, I will try to do that in the next week instead.

48

Applications and Porting / Re: Chromium and Ungoogled Chromium DNF Repository

« on: July 10, 2023, 10:24:57 am »

Yeah, I'm also wondering what the best solution is. I don't like Chromium, but sometimes I need to have access to it, and hopping over to my MacBook Air or Windows desktop isn't necessarily the best solution.

49

GPU Compute / Accelerators / Radeon RDNA3 support?

« on: July 07, 2023, 11:14:09 am »

Anybody stepped up to the plate and tried an RDNA3 card with Power yet? Wondering if the RX 7600 or higher would work with a recent kernel.

50

Applications and Porting / Re: [games] DXX-Rebirth - frustrations

« on: June 10, 2023, 12:02:02 pm »

I installed d1x-rebirth and d2x-rebirth out of the Fedora repos and those worked fine. Any particular reason you want to build them?

Honestly, I didn't assume a package would be available, so I didn't look. But now I can't find a package by the name of dxx-rebirth, d1x-rebirth, or d2x-rebirth for F37.

edit: After various travails, determined the package names are literally "d1x" and "d2x." Well, at least that fixes things up. Now to test...
edit the second: Well, it's working. MIDI could sound better, but I'm an old OPLhead. What's the best solution for pointing the executable to the registered version - should I overwrite the contents of the demo files provided with the packages, or add a path entry to the dxx ini?

51

Applications and Porting / [games] DXX-Rebirth - frustrations

« on: June 10, 2023, 12:56:41 am »

So I'm trying to build DXX-Rebirth on Fedora 37, following the official directions posted here, and using the build instructions

Code: [Select]

scons 'CXXFLAGS=-O3 -mcpu=power9 -DNO_WARN_X86_INTRINSICS' 'CPPFLAGS=-O3 -mcpu=power9 -DNO_WARN_X86_INTRINSICS' opengl=1yields this error terminating compilation:

Code: [Select]

scons: *** Rebirth configured with OpenGL enabled, but SDL configured with OpenGL disabled.  Disable Rebirth OpenGL or install an SDL with OpenGL enabled.  See build/sconf.log for details.  Stop.I've tried a few Google searches but nothing conclusively indicates what I should do to configure or replace SDL2. I have not built it from source or installed it from alternative repos - this is stock Fedora.

52

Legacy POWER Hardware / Re: Dolphin Emulator banned from Steam

« on: May 31, 2023, 03:07:10 pm »

Dolphin running with close instruction parity on Power9 would be an unusually nice showcase for OpenPower at large. That project would be welcome - if you have the background to do it, we'd all love to see it.

53

Applications and Porting / Re: [GAMES] Ultimate Doom with all enhancements on crispy-doom client

« on: May 28, 2023, 01:19:48 pm »

Update: I am not really a programmer but did manage to crack the nut of inserting optimizations into GZDoom's byzantine build system. Follow the directions at this page, finish the initial build, and then navigate to ~/gzdoom_build/gzdoom/build/CMakeCache.txt (or wherever you're keeping the source code). Open that file, navigate to the line (possibly line 68):

Code: [Select]

//Flags used by the CXX compiler during RELEASE builds. The following line is, by default:

Code: [Select]

CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG Change it to:

Code: [Select]

CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG -mcpu=power9 -DNO_WARN_X86_INTRINSICS
Repeat this for the line (possibly line 94):

Code: [Select]

//Flags used by the C compiler during RELEASE builds.changing the subsequent line to:

Code: [Select]

CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG -mcpu=power9 -DNO_WARN_X86_INTRINSICS
Re-run the build instructions, which will overwrite the old executable with the improved one. This doesn't do anything about periodic performance issues for demanding wads using hardware rendering, but software rendering is much nicer!

Edit: In thinking about this since I have a sinking feeling that CMake is performing an early test to determine SIMD compatibility that Power9 isn’t passing, as there are versions of a number of software routines that are in individual files with and without SSE2 optimizations. It is also smart enough to determine ppc64 as a build environment, though this is tied to prior PPC Mac support… more investigation is under way, though -mcpu=power9 is already a big improvement. More info to follow.

54

GPU Compute / Accelerators / Re: Intel Arc A770 - failed experiment

« on: May 10, 2023, 09:10:55 pm »

There's a bit of hubbub over on Phoronix at the moment regarding Intel's driver maintenance decisions that's making people a little nuts. To wit:

- The current i915 driver, which is the official DG2 support release, has full support for the HuC microcontroller that is chiefly responsible for the low-power video encoding built into the chip. This driver presently only works with x86/x86_64, and is also not getting support for VM_BIND / sparse residency features in Vulkan. In other words, its full 3D performance capabilities will never be realized. Why, you ask? Well...

- The planned move to the Xe driver, which supports non-x86 parts, will have modern Vulkan support, but it sounds like Alchemist will not receive a port of the HuC support, as its handling has been described as "relatively annoying" and would require special effort. Meteor Lake IGPs and future discrete graphics cards have a different solution in place that has been implemented, and which will be consistently utilized going forward.

So, without access to the integrated video encoding, and with no FP64 support in hardware, Arc becomes a whole lot less interesting on Power. Looks like I'll be selling my A750 soon, along with the i3 it's been in to date, but that's the current status. Intel's let me down on this one. Ah well - at least Fedora's moving to support Rusticl for my RX 6600 soon...

55

User Zone / Re: WD Black SN850X not showing up in lspci

« on: May 10, 2023, 09:05:15 pm »

I did not run into that problem, but did have issues with a Western Digital SN700 and a no-name NVMe adapter a while back. That ended with me basically writing off NVMe storage on my Power9 build - currently everything is running off a 256GB SATA Samsung 870 and a 4TB Samsung HDD for storage/backups. But with the right adapter and a compatible drive, I'd love to try again.

Wishing you luck. I'll keep an eye on this thread.

56

Blackbird / Re: OpenBMC reporting critical error Proc.FSI.Error.MasterDetectionFailure

« on: May 01, 2023, 09:22:29 am »

You may be interested to know that Raptor weighed in on their Twitter after it was pointed out to them, with a first suggestion to try reseating the CPU.

The link:
https://nitter.poast.org/RaptorCompSys/status/1652858741635665920#m

57

Applications and Porting / Re: [GAMES] Ultimate Doom with all enhancements on crispy-doom client

« on: April 28, 2023, 09:13:40 am »

I like GZDoom for the 3D stereo support (I have a 3D-capable IPS secondary display), but I usually play Chocolate Doom, myself.

GZDoom performance on ppc64le is still lacking relative to comparable x86land, at least in Fedora 37. In software mode I'd chalk most of that up to a lack of SIMD optimization, and I’ve taken on a new job that's taken away a chunk of the tinker time I'd use to navigate its build system and figure out where to insert -mcpu=power9 -DNO_WARN_X86_INTRINSICS for the compiler. Hardware rendering absolutely chugs in big maps, though, and between what appears to be poor thread load in the Vulkan renderer and recent ZDoom forum drama, it's put me off of troubleshooting much when DSDA-Doom does everything I need right now.

58

Applications and Porting / Re: Chromium and Ungoogled Chromium DNF Repository

« on: April 27, 2023, 09:56:58 am »

I am building the RPM version for RHEL/Fedora.

Hey, any updates on this? Are these available anywhere? The parent post provides a repo, but try as I might I can't actually download or install anything from it.

59

Applications and Porting / Re: [GAMES] Ultimate Doom with all enhancements on crispy-doom client

« on: April 16, 2023, 12:31:19 pm »

these are some other ports I’ve had luck with:

- Woof is an effort to modernize and bring the venerable old MBF (Marine’s Best Friend, by Lee Killough) forward to the present day. It supports a number of compatibility levels, from vanilla Doom through various post-Boom incarnations, and it’s software-only so it will play nice with the AST onboard video. Mouse support isn’t the most responsive but it’s a good port.

- DSDA-Doom is a fork of PRBOOM+ meant for speedrunners, but it’s enjoyably flexible. OPL2 emulation isn’t great but Fluidsynth sounds nice, it supports software and OpenGL rendering at arbitrary resolutions, and screams along at 4K on an RX 6600. This is my go-to right now.

- GZDoom is the gold standard at large, but I’ve run into numerous scenarios where performance is underwhelming. Some big adventurous WADs like the tail end of Eviternity absolutely tank in the hardware renderer; whether OpenGL or Vulkan is used, performance dips down below 20 fps and shows low core usage. Software rendering fares a bit better but the lack of SIMD optimizations hurts. A while back I thought about using ClassicHasClass’s advice to insert intrinsic translation through gcc’s headers, but the port has a complicated CMake config (probably because it pulls in a half-dozen other libraries to enable all its functionality), and I never figured out where to insert a directive to the compiler to try it out.

That’s as far as I’ve gotten with kicking Doom source port tires on Power9 so far. Suggestions are welcome.

60

GPU Compute / Accelerators / Re: AMD OpenCL / ROCm

« on: March 26, 2023, 09:39:38 am »

Still no progress on my own attempt, unfortunately. AMD are releasing new versions faster than I can merge the little work I have already done.

I found this other page detailing another person's attempts to build ROCm on POWER9, which might be worth looking at.

 https://systems.nic.uoregon.edu/internal-wiki/index.php?title=Rocm_on_power9

ROCm is an organizational clusterfuck. Around two years ago I determined the best way to handle it on Ubuntu x86_64 was to sync to their repo, then when a new version was pushed, ppa-purge the repo, remove all folders and files ROCm left behind, then add the repo again and install from scratch. To my knowledge it hasn’t gotten better since, and that’s not even touching on other platforms. I respect the work you have put in, but I am not sure things will improve for AMD beyond this “beat to fit, paint to match” approach to software design.

God, I hope Intel sticks with Arc and gets OneAPI and their compute stack running everywhere. That’d save a lot of headaches.