Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Hasturtium

Pages: [1]
1
General Hardware Discussion / Libre SOC, uh
« on: October 09, 2024, 10:19:14 am »
https://lists.libre-soc.org/pipermail/libre-soc-dev/

I wondered what happened with what appeared to be a promising project, and holy cow.

2
General CPU Discussion / 3U HSF End of Life'd
« on: October 02, 2024, 10:40:13 am »
Raptor's page has de-listed the 3U heatsink due to it being discontinued. Has the situation with the modified bracket to accommodate x86 heatsinks gotten to a point where they could offer those in their place? Feels like Raptor's in an increasingly awkward place.

3
Applications and Porting / RustiCL on Fedora 39
« on: April 01, 2024, 02:15:56 pm »
Ahoy. I've been trying to goad RustiCL into working with my Radeon RX 6600 on Fedora 39. To my knowledge I've installed all necessary prereqs for RustiCL to work, and setting RUSTICL_ENABLE=radeonsi does not seem to trigger any problems. Unfortunately when I run QGIS it still insists it cannot find a working OpenCL implementation. In running clinfo, both Clover and RustiCL report back, and one of them - probably Clover - barfs out the following message:

Code: [Select]
=== CL_PROGRAM_BUILD_LOG ===
fatal error: cannot open file '/usr/lib64/clc/gfx1032-amdgcn-mesa-mesa3d.bc': No such file or directory

I've determined that the compute kernel it's hunting for is not present, and looking for it online has been fruitless. I am not willing to create a symlink to point to something else, that sounds like an invitation to instability at best. The complete output from running RUSTICL_ENABLE=radeonsi > output.txt is here. It would be really nice if I could use my RX 6600 for something new. Anybody else gotten RustiCL working yet?

4
GPU Compute / Accelerators / Intel Arc Support in Kernel 6.8
« on: January 24, 2024, 09:01:53 am »
It looks like Intel's Xe driver is being mainlined in kernel 6.8. To this point Arc support's been officially limited to the i915 driver, which has had hard x86 dependencies. However the driver is confirmed to compile and work on aarch64, so we may be in luck. While the driver is chiefly intended for the to-be-released Battlemage hardware it does support the current Alchemist line; the only thing we'll likely miss out on is support for the HuC microcontroller. Without that support the video encoder is rather less capable... but given a choice between AMD and Intel's open graphics software stack, I know which way I'm leaning. Let's hope for good things.

5
Operating Systems and Porting / Debian 12 status?
« on: December 13, 2023, 10:17:19 am »
I am debating jumping from Fedora to Debian on my Blackbird machine, which would coincide with a nice storage upgrade. I've had plenty of Debian/Ubuntu family experience on x86 so that part doesn't give me heartburn, but there are a few questions I'd like to have answered before I make the switch.

- Does the stock kernel for Bookworm work with RDNA2 Radeons? What should I do to prevent Debian from trying to use the BMC video versus my RX 6600? (IIRC it installs kernel 6.1 but I don't know what the current version they're providing is - I assume it'll Just Work, outside of possibly coaxing x.org to properly init the Radeon with a config file)
- Are there any snafus or gotchas beyond what MauryG5 has experienced in this thread?
- Is Chromium actually working and installable?

6
Applications and Porting / GZDoom
« on: July 30, 2023, 12:49:02 pm »
I talked about this a bit in the #talos-workstation channel over on Libera.Chat, but here goes: the short answer is that GZDoom works. All of the many libraries GZDoom takes advantage of run natively in Power, save for Asmjit, which is used to speed up execution of ZScript. I was wrong in the crispy-doom thread: enforcing -mcpu=power9 made a significant performance difference over the stock build options, but -DNO_WARN_X86_INTRINSICS makes no difference because of a prior commit that disables intrinsics outright for non-x86 architectures (apparently tied to disabling AsmJit for those platforms). With that limitation in mind, the biggest single issue for GZDoom speed comes down to a lack of SIMD optimization, which apparently makes a small difference in the hardware renderer and a very big difference in the true color software renderer. From what I've read the 8-bit software renderer doesn't leverage SSE2, and it flies at 1440p or higher on my eight core machine.

GZDoom currently detects Power9 as ppc64. Defining ppc64le as a platform and then forcing -DNO_WARN_X86_INTRINSICS specifically for it would probably be a lot less demanding than generating hand-tuned Power assembly, but I do not know whether that would break the current method of disabling AsmJit. Whether this would work on Power8 is up for debate - I don't know if its lack of VSX-3 would impact SSE translation. I need to allocate more time to scrutinize the source and figure out what needs patching, but if anybody wants to beat me to the punch, they are welcome to.

7
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.

8
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.

9
Blackbird / SATA ports on the fritz?
« on: January 28, 2023, 04:54:41 pm »
I purchased a PCIe to NVMe adapter, cloned the contents of my SATA SSD to the new drive on a different machine, installed the NVMe drive with my existing Fedora 37 install... and the new drive wouldn't boot past initializing the Radeon in my Blackbird. So, resigned to the incompatibility, I removed the NVMe drive, set up the SATA SSD again, and booted, only to see a new error appear in my Petitboot loader, kAFS not found, with an error code of -97. Booting afterward proceeds normally, up until the Radeon is initialized for the login screen, at which point the display signal gets flaky and visible artifacting occurs intermittently. Shutting the system down afterward proceeds more or less normally, as far as I can tell.

The issue appears to be limited to SATA0 and SATA1 - I can boot the machine normally from SATA2 or SATA3. I am genuinely flummoxed here - does anyone have any insight?

10
Applications and Porting / [GAMES] Quake II RTX!
« on: January 15, 2023, 12:16:10 am »
I can't believe I'm typing this, but - with some caveats - Quake II RTX compiles and runs under Fedora 37 with an RDNA2 Radeon on Power9. The gotchas:

* If you're copying your Windows folder over and you care about preserving your saved games, make sure the contents of Q2RTX/baseq2/save are moved to ~/.quake2rtx/baseq2/save. If you don't, and you leave the Windows save folder intact, the executable will throw an error when trying to load a new game or save because it can't rectify the presence of the Windows folder with the presence of the Linux folder.
* For some reason I can't get timedemo functionality to work - attempting to load a timedemo from the console results in "Couldn't load maps/demo1.dm2.bsp: No such file or directory".
EDIT: * The game may bomb out at startup complaining that it can't find a Vulkan-capable GPU (despite the logs indicating it successfully queried both your Vulkan GPU as well as llvmpipe). In that case, manually edit ~/.quake2rtx/baseq2/q2config.cfg and change the line seta ray_tracing_api value from "auto" to "query". I tried setting this to “pipeline” on a lark to test the other raytracing method it supports, and that crashes the executable because it apparently can’t find the extensions it’s looking for.

Nevertheless it runs at around 60 fps at 1080p on an RX 6600 with resolution scaling set to 65%, which doesn't trail the Windows version with the same card too much at all. There is some minor visual corruption at the periphery of the screen, but with some more testing and bugfixes that can probably be fixed. Back to Stroggos I go...

11
edit: I had hit a stumbling block of frustration after a number of other stressors in my life built to a peak this past week. If I were to sell the Power9 so soon after getting it, I would regret it a lot. This machine's been a wonderful learning experience, and is a lot of fun to use.

After a period of initial experimentation I've come to the conclusion that the ppc64le architecture will not serve my needs the way I had hoped. All my equipment is in perfect working order, and has spent its life under light load and connected to a high quality UPS. Here is what I am offering.

- Blackbird mainboard, v2.00
- 8 core CPU (v2)
- 3U heatsink, with fan direction reversed to work better in most PC cases
- 2x16GiB ECC DDR4 registered memory
- 8GB Radeon Pro W5500 with original box and accessories
- screwdriver for installing the heat sink (optional)

I am in the continental United States - the Dallas area of Texas, specifically - and will pack all items well and securely for shipment. While I would prefer to ship within the U.S. I am not opposed to international shipping; we can work something out. PM me here, or email me at freontrip -at- live -dot- com directly. I have a specific price in mind, but I am willing to keep the graphics card and sell the rest if that works better for you. Thanks for looking.

12
GPU Compute / Accelerators / Necessary firmware for Navi14
« on: July 28, 2022, 12:34:30 pm »
Hey there! Now that I've got my Blackbird motherboard fully working and functional, I've turned my attention to getting my Radeon Pro W5500 up and running. The Skiroot BOOTKERNFW size is around 1.8MB, which doesn't pose any problems for older Radeons whose firmware fits neatly into that space. However, the full size of Navi14-affiliated files /lib/firmware in my Void install is around 3.8 MB, and there are a large number of files. There are a couple that obviously aren't needed for Skiroot - VCN's tied to the video transcoding engine, MEC(2) is for Micro Engine Compute - but I've had real trouble finding which of these would be needed for Skiroot without overflowing the space. Has anyone else wrestled with this themselves?

Pages: [1]