Mesa for Linux PPC

[sailorMH]

Finally!

before I test to deny libglamoregl.so I used your idea and copy r300.dri.so from Debian 7.11 installation (with Mesa 8.0.5-4) and it works!!!

Code: Select all

martina@pegasosa:~$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
5293 frames in 5.0 seconds = 1058.565 FPS
5408 frames in 5.0 seconds = 1081.404 FPS
5242 frames in 5.0 seconds = 1048.249 FPS
5402 frames in 5.0 seconds = 1080.234 FPS
5370 frames in 5.0 seconds = 1073.863 FPS
5378 frames in 5.0 seconds = 1075.499 FPS

My old beloved Pegasos 2 with 1.33 GHz CPU and Radeon 9800 PRO is pretty fast - 1080 fps !!!
@xeno74 - thanks for support!

[xeno74]

Finally!

before I test to deny libglamoregl.so I used your idea and copy r300.dri.so from Debian 7.11 installation (with Mesa 8.0.5-4) and it works!!!

Code: Select all

martina@pegasosa:~$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
5293 frames in 5.0 seconds = 1058.565 FPS
5408 frames in 5.0 seconds = 1081.404 FPS
5242 frames in 5.0 seconds = 1048.249 FPS
5402 frames in 5.0 seconds = 1080.234 FPS
5370 frames in 5.0 seconds = 1073.863 FPS
5378 frames in 5.0 seconds = 1075.499 FPS

My old beloved Pegasos 2 with 1.33 GHz CPU and Radeon 9800 PRO is pretty fast - 1080 fps !!!
@xeno74 - thanks for support!

Great idea! Well done!

[xeno74]

FYI: The Old ATI R300 Open-Source Driver Sees Improvements For OpenGL, WineD3D Apps/Games (The R300g driver supports Radeon X300 through Radeon X1000 (R500) series graphics cards)

[xeno74]

Hi All!

Mesa 23.1.2 has been added to the Fienix Evo repositories. I suggest upgrading for improved system performance.

You can also install the new Mesa 23.1.2 with the following commands on Debian and MintPPC:

Code: Select all

apt update

Code: Select all

apt install libgl1-mesa-dri libgl1-mesa-glx mesa-utils

[xeno74]

The latest Mesa for Debian Sid: libgl1-mesa-dri -- snapshot.debian.org

[Hypex]

Hi. Been reading through the thread. The updates are nice but it doesn't look like there is any change. Is the Radeon driver still broken indefinitely for 3d for R series and beyond? Is this one of those endian issues? I found a comment by Hans about endian being a big issue to deal with. But it has been solved and working on OS4 Radeon drivers. I wonder if it ever worked or if it never worked in Linux. I've read Mac people having major problems in later Linux releases.

[xeno74]

Is the Radeon driver still broken indefinitely for 3d for R series and beyond?

PPC BE Linux supports up to TeraScale 3 (called GFX5 by the X.Org project, see comments #2/#3). This includes Radeon cards up to HD 7670, HD 8350 to HD 8490 and R5 210 to R5 235X.

Linux supports up to Northern Islands (= RV9xx) is correct. This is because it supports up to TeraScale 3 GPU architecture. What's a bit misleading though is to correspond this with the HD6xxx cards when ⅓ of HD7xxx cards are also supported, and even some of HD8xxx and R5 cards, because they use TeraScale GPUs.
The first sentence in my previous comment was more of a general statement that there is no general correspondence between card family (HDXxxx, Rx etc.), GPU family ("... Islands", R(V)Xxx) and GPU architecture (TeraScale 1-3, GCN1-5 etc.), of which only the last really determines (non-)support. This is illustrated by the fact that MorphOS supports not all of Northern Islands GPUs (namely only those of TeraScale 2 architecture, but not those of TeraScale 3).

There was problem with Mesa big endian powerpc 3D drivers.
Working was only radeon (=r100) upto r600 (i.e. Northern Islands). Next gfx generations needs radeonsi 3D driver, which not worked on Big endian.

PCIe Video Cards - Check in -- morph.zone

Hi All,

I think the AMDGPU firmwares are little endian, so we'll probably need to byte swap it before interpreting it in the driver.

Byte swap source code for the RADEON firmwares is available in the kernel source code [1] but I haven't found any byte swap code for the AMDGPU firmwares.

I compiled the RC6 without the AMDGPU support today. Maybe the missing byte swap code for AMDGPU firmwares is the problem.

Download: vmlinux-4.9-without-AMDGPU.tar.gz

Please test this kernel with your SI graphics cards.

Thanks in advance,

Christian

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/vce_v1_0.c?id=55ce625fc5e3a87e46a14c2cb062a3579f79b7e0

But ...

we get more and more often new Mesa versions with many improvements for our old graphics cards supported by the "radeon" kernel driver. We don't need to compile and release unofficial Mesa versions anymore.

[Hypex]

But ...

we get more and more often new Mesa versions with many improvements for our old graphics cards supported by the "radeon" kernel driver. We don't need to compile and release unofficial Mesa versions anymore.

Thanks for all the research. I did come across some of those recently in the thread. This confirms my suspicions. I read a lot online about Radeon issues with G5 Macs. My R7 250 shows up as SI Oland.

The code patch shows a sign object and data array being both LE. By the looks of the code the sign object should be in native endian but is injected with LE values. This makes it awkward to deal with and must run deep. I don't know if patches with cpu_to_le32 macros would be judged as messing up the code since it disrupts the natural flow. People online tend to complain about network order being against x86 and slowing things down. It would need PPC specific patches, but I wonder if the PPC feature to map endian pages would help, if it can be supported?

I don't know enough about the firmware to see how it runs. I know it's needed for lots of devices. But I don't know if it's uploaded to the device to run or what else is done with it. Being microcode is foreign to any CPU and here native to a GPU I didn't expect the CPU to deal with it directly. Though I don't know how else it is used without further research.

[Hypex]

So, this has been a gripe for while, dealing with opposite endianess. Which I've had to go deep and fix code written for x86 when porting to PPC. But, I found from a search and this question that GCC already supports specifying endian in data.

https://stackoverflow.com/questions/673 ... r-c-struct

Some pragmas detailed here:
https://gcc.gnu.org/onlinedocs/gcc/Stru ... agmas.html

I wonder if this could help to greatly alleviate endian issues? The only caveat is getting this patched. Depending on GCC and what is considered a depreciated endian may mean it is not officially supported as a patch. But some defines could be introduced that setup up data types to be LE specific for GCC. In case GCC isn't used it defaults to blank. And then, obviously, the patch would need to be forward compatible so it isn't deleted.

On top of this, I wonder of we can leverage the power of IBM s390x? This is natively big endian. There are binary packages built for x390x in Debian for AMDGPU and to a lesser extent Radeon. But I don't know know how functional they are. This looks to be the largest CPU used with big endian. Most people tend to think of big endian being in an old Mac from 20 years ago, Of course we know this isn't the case.

This article, just over 2 years old, encourages developers to write cross endian portable code and support big endian. A shocking stance in our little endian world. Unfortunately some links are broken. But perhaps this could be used as a gateway? Did the "big" amount of "little" people get the memo?

https://community.ibm.com/community/use ... e-projects