Recent Posts

51

Operating Systems and Porting / [DEV] Any interactive REPL tooling for OpenPOWER assembly

« Last post by tle on March 15, 2025, 11:12:34 pm »

I am learning PowerPC assembly by playing around with assembly inlined in C code. Wondering is there any interactive tool that shows the full list of registers and other useful information for assembly language? Many thanks in advance

52

General Discussion / POWER11, "Cirrus+" Can any of this be substantiated?

« Last post by Borley on March 15, 2025, 08:28:10 pm »

From a speculative write up on big data processor roadmaps:

Just for fun, and to show what a different world it is that Big Blue operates in, we added the Power and z processors to the middle of the Arm pack. We expect “Cirrus+” Power11 and “Telum II” z17 processors before the end of this year to boost the performance of the Power Systems and System z mainframe lines. The Power11 chip, which we will cover shortly, is all about increasing memory bandwidth and memory capacity compared to the Power10 chip the has been in the field for nearly four years now. The z17 processor has a bunch of tweaks, including an integrated DPU to speed up I/O operations for mainframes, which we covered back in August 2024. Both of these chips are etched by Samsung, IBM’s processor fab partner, and both have sixteen cores on a socket and are implemented in machines that have four sockets in a node, four nodes in a single system image, and tens of terabytes of main memory hanging off of them.

Big iron is truly different.

I'll admit to not having been paying attention to things after IBM mucked up with nonfree memory controllers, but was surprised to see sixteen cores being referenced. Despite other material suggesting 25% more cores as compared to POWER10 (which was also configured with 16 cores).

53

Applications and Porting / [DEV] Using Java's Vector API on PPC64LE

« Last post by icbts on March 14, 2025, 12:59:40 pm »

Wanted to share this video I made on our experiences with Java's Vector API (incubating) on PPC64LE:
https://www.youtube.com/watch?v=auqYQdul52k

Its a mixed bag at this point in time - some workflows benefit, while some others do not.

The implementation of Vector API is x64/AArch64, with allowances to let other architectures provide implementation in the future. Perhaps this video will help encourage JVM implementations to address the shortfall.

54

Firmware / Re: Messing with WOF Tables

« Last post by ejfluhr on March 14, 2025, 12:05:51 am »

>That link doesn't seem to work, do you happen to still know how to navigate to it or know the name of the paper.

Sorry, I don't.  As I recall, it was an educational presentation/paper on how processor power is modeled.  It is pretty well known material, maybe you can find other references.

Nominal mode is just a lower power TDP.  Turbo mode is a higher power TDP.   WOF should be able to boost from both, the proc will just start and get to higher frequencies sooner with the TM table.

It's been a long time, but I believe VRATIO just means the number of ON cores (a.k.a. active) relative to the maximum available.  As the # of active cores goes down, the power from those cores is applied to the remaining cores, allowing them to boost to higher frequencies.   Depending on the system & power limit, the proc could pretty quickly apply so much power credit from offline cores that it flat-lines at the maximum possible frequency, i.e. it becomes technology limited not power limited.  It sounds like, for that table, the processor is only power-limited when >= 12 cores ON.    Technically VRATIO is "voltage ratio" intended to handle quads using the internal voltage regulator at some % below the input voltage, but it ended up not getting supported and devolved to tracking # of cores.   A core in a stopped state with the power headers off has voltage of 0v hance VRATIO=0 for that core, and you add up the # of ON vs OFF cores to get he VRATIO.

FRATIO, or "frequency ratio" was intended to handle some cores operating at lower frequencies than processor-level frequency target, since each quad has it's own clock generation.  I don't believe Linux ever implemented support for different quad frequencies so they all just run at the same frequency?   If true, WOF only uses FRATIO=1.0 indices.


>And I think the number 1 question is "how does one know which CSV gets selected for a given CPU"?

WOF has a bunch of cross-checks between the data table and the module VPD data....I'm not exactly sure which, but possibly core count, nominal/turbo/max frequencies, & the sort power target?    E.g. each table is designed to manage to a certain power target, and the processor code is trying to find a table appropriate for that processor

Cool 3D plot!   For reference, CORE_CEFF is the ratio of the workload switching power relative to TDP, where TDP=1.0.   So 0.5 means the workload has half the switching power of TDP.     If the workload is using less power, the WOF table should attempt to raise frequency, up to the maximum allowed, where it flatlines.   Similarly, if there are fewer cores active, the frequency will go up, and if both are true, the frequency will go up more.   So that explains the shape of that plot.

55

User Zone / Re: Calling for gaming experiences

« Last post by Borley on March 12, 2025, 09:33:21 pm »

Just want to bring to attention the excellent discovery of Valhalla, which I believe to be built on Tesseract. It is very well polished with beautiful 3D maps.

For anyone interested, building involves

* libGL (OpenGL)
* SDL2 (>= 2.0.0)
* SDL2_image
* SDL2_mixer
* libpng
* libjpeg
* zlib

And git clone the game date into the ~/main directory of the game repo.

Run in-place:

Code: [Select]

~/main$ ./source/tess_client

56

General OpenPOWER Discussion / Re: It looks like you have 1 guarded cores

« Last post by ClassicHasClass on March 12, 2025, 07:44:48 pm »

Likely there was some glitch that caused one of your cores to get guarded out. You can clear this condition from the BMC: https://www.talospace.com/2020/05/the-case-of-disappearing-core.html

57

General OpenPOWER Discussion / It looks like you have 1 guarded cores

« Last post by dmoreno on March 12, 2025, 01:22:49 pm »

I own a Talos II running Linux 6.6.62.
Since a week ago, I'm getting the following message on the logs:

Code: [Select]

mar 12 19:53:48 kernel:   _     _______________
mar 12 19:53:48 kernel:  | |   /               \
mar 12 19:53:48 kernel:  | |   |    WARNING!   |
mar 12 19:53:48 kernel:  | |   |               |
mar 12 19:53:48 kernel:  | |   | It looks like |
mar 12 19:53:48 kernel:  |_|   |  you have   1 |
mar 12 19:53:48 kernel:   _    | guarded cores |
mar 12 19:53:48 kernel:  (_)   \_______________/
I didn't get those before, and I haven't installed a new kernel for months.
Also, I can't find much information about it on Google, other than a couple of references to kernel's source code.

Can anyone shed some light on this?
Thanks!

58

Applications and Porting / Re: Porting the Dolphin Emulator to the modern OpenPOWER systems

« Last post by tle on March 12, 2025, 07:24:13 am »

Great news! I am too slowly learning Assembly in hope one day I could port the existing PPC64BE QVM code of Quake 3 engine to PPC64LE. Please keep us up-to-date with your progress

59

Operating Systems and Porting / Re: [NEWS] Fedora 41 is out!

« Last post by tle on March 12, 2025, 03:17:36 am »

Fedora 42 is still a bit rough, the whole GCC15's new C23 has introduced quite a number of breaking changes / regressions in many softwares. I am still in the progress of going through all softwares that I am actually using to see if I could get them properly working before the final release day. I greatly welcome extra hands from the community in beta testing

60

Applications and Porting / Nazi Zombies Portable

« Last post by Borley on March 11, 2025, 09:43:43 pm »

I decided to have another go at building Nazi Zombies Portable starting with QuakeC portion for the game logic.

They hardcode most of their tooling for specific target architectures. For example, the build script for Linux platforms at ~quakec/tools/qc-compiler-gnu.sh sets a variable explicitly to an x86 version of the FTEQCC executable included in the repository.

Code: [Select]

../bin/fteqcc-cli-lin: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=48ccbb62862f094e0f04da54935de367c88b7c63, stripped
Not a big problem, on Debian we can supplement fteqcc out of the the Debian archive. And then change the qc-compiler-gnu.sh script to use that instead:

Code: [Select]

FTEQCC=/usr/bin/fteqcc
And remove the relative paths for fteqcc calls as it no longer uses the project-supplied x86 binaries:

Code: [Select]

$FTEQCC -srcfile ../progs/csqc.src | grep -E -i "warning |error |defined |not |unknown |branches"
echo "Compiling FTE SSQC.."
$FTEQCC -O3 -DFTE -srcfile ../progs/ssqc.src | grep -E -i "warning |error |defined |not |unknown |branches"
echo "Compiling FTE MenuQC.."
$FTEQCC -O3 -DFTE -srcfile ../progs/menu.src | grep -E -i "warning |error |defined |not |unknown |branches"
echo "Compiling Standard/Id SSQC.."
$FTEQCC -O3 -srcfile ../progs/ssqc.src | grep -E -i "warning |error |defined |not |unknown |branches"

The build script calls for three python libraries; python3-colorama, python3-panda and python3-fastcrc.

python3-fastcrc isn't packaged in Debian, so I try substituting python3-crc instead. Changing the relevant bits in ~/quakec/bin/qc_hash_generator.py:

from fastcrc import crc16
to
from crc import Crc16

ctField('crc_strlen', ITY
to
ctField('Crc_strlen', ITY

etc...

It doesn't like that.

Code: [Select]

Generating Hash Table..
Traceback (most recent call last):
  File "/home/Borley/NaziZombies/quakec/bin/qc_hash_generator.py", line 177, in <module>
    main()
  File "/home/Borley/NaziZombies/quakec/bin/qc_hash_generator.py", line 173, in main
    csv_data = read_csv_data()
               ^^^^^^^^^^^^^^^
  File "/home/Borley/NaziZombies/quakec/bin/qc_hash_generator.py", line 143, in read_csv_data
    value[0] = int(Crc16.IBM_3740(str.encode(value[0])))
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'Crc16' object is not callable
Compiling FTE CSQC..
../progs/csqc.src:1: warning: Unknown pragma 'noref'
../progs/csqc.src:2: warning: Unknown target 'fte_5768'. Ignored.
../progs/csqc.src:5: warning: Unknown pragma 'includedir'
../progs/csqc.src:6: warning: Unknown pragma 'includedir'
../progs/csqc.src:7: warning: Unknown pragma 'includedir'
************ ERROR ************
Error in ../progs/csqc.src on line 9
Compiling FTE SSQC..
../progs/ssqc.src:3: warning: Unknown target 'fte_5768'. Ignored.
../progs/ssqc.src:9: warning: warning id not recognised
../progs/ssqc.src:10: warning: Unknown pragma 'noref'
../progs/ssqc.src:12: warning: Unknown pragma 'includedir'
../progs/ssqc.src:13: warning: Unknown pragma 'includedir'
************ ERROR ************
Error in ../progs/ssqc.src on line 15
Compiling FTE MenuQC..
../progs/menu.src:1: warning: Unknown pragma 'noref'
../progs/menu.src:2: warning: Unknown target 'fte_5768'. Ignored.
../progs/menu.src:5: warning: Unknown pragma 'includedir'
************ ERROR ************
Error in ../progs/menu.src on line 7
Compiling Standard/Id SSQC..
../progs/ssqc.src:9: warning: warning id not recognised
../progs/ssqc.src:10: warning: Unknown pragma 'noref'
../progs/ssqc.src:12: warning: Unknown pragma 'includedir'
../progs/ssqc.src:13: warning: Unknown pragma 'includedir'
************ ERROR ************
Error in ../progs/ssqc.src on line 15
End of script.

  All of the errors fail at lines for #includelist

I suspect I'm going to need to begrudgingly install python3-fastcrc through python-pip. And probably also to compile an up to date ppc64 executable of FTEQCC directly from the project's repo. Usually stuff in C is a lot more straightforward than this.