How to do Opencl programming with AMD CPU? - Solved

[enrique]

Objective of the thread: Opencl programming.
To use old AMD GPU on recent kernel. At best to have full control of 3D graphics. But to be honest I do not need Graphics. I only need the GPU to do Opencl programming.

What is Opencl
In 1 CPU you do amazing computing. Imaging your PC take 1000 days( more of less 3 years) to find a complex result. So then what about if you can split the work load in 1000 PC. Then you could finish in only 1 day. So this is what Opencl try to accomplish. Use the 1000 cores inside a good GPU to reduce the time from 3 years to 1 day of work!!!

Puppy Distro in use: ANY
People this apply to any Puppy or Debiandog. As a driver it only concern is with the Kernel version. But I will personally like to be using it on Busterdog or Stretchdog.

Hardware in used: Dual GPU
* Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, this has buildin HD3000 GPU
* VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6730M/6770M/7690M XT] [1002:6740]

Problem
AMD suspended support on old GPU. In general OLD none free AMD drivers should not install on Debian Stretch/Buster or Ubuntu Xenial/Bionic. In theory AMD-Catalyst-15.9 could be install in kernels less than version 4.2 with minimal manual patching.

What's working
The script can build fglrx.ko kernel module for any kernel up to 4,19. It will patch automatically depending on your own kernel installed. Main Objective: This will enable OpenCL on new kernels for AMD Pre GCN Architecture GPU.

Working Solution on this post

Tested on DebianDogs jessie, stretch and buster. Need to test it on Puppys.

[enrique]

For those of those that may interest the driver. The error that prevents Xorg to load at the moment is:

Code: Select all

[    35.507] (EE) Failed to load /usr/lib/xorg/modules/drivers/fglrx_drv.so: /usr/lib/xorg/modules/drivers/fglrx_drv.so: undefined symbol: xf86Initialising

If you know whats to do let me know. I did try to to include

Code: Select all

extern bool xf86Initialising 
&
bool xf86Initialising = FALSE;

But I still with same error.

I guess one possibility is to downgrade Xor.
https://www.x.org/archive/individual/xserver/

[fredx181]

Hi Enrique,

** AMD-Catalyst-15.9-Linux-installer-15.201.1151-x86.x86_64 seems to install on https://github.com/DebianDog/Jessie/rel ... -10-16.iso . This has kernel 3.16.0-4-686-pae

** I have manually patch catalyst_15.9 to accept kernel 4.1.38. If I try to activate graphics on AMD catalyst driver, Xor Server will fail. But I can load kernel module and do Opencl. This is fine with me. So I manage to have it working on Stretch with 4.1.38 kernel.

I may be able to help you with the porteus initrd1.xz creating (from any kernel installed that has aufs included, builtin or not) and creating separate .squashfs for the kernel, you say you have 4.1.38 kernel working with Stretch, but i'm not sure what exactly your goal is.
Can't help with graphics drivers issues etc.. (very limited knowledge).

Fred

[enrique]

Hi fredx181

The goal is NOT to produce a working Graphic Driver from proprietary AMD on new Kernels.. I have read that there are a number of reasons why that will be close to not possible.

The Goal is to allow the use of the cores on the AMD GPU to work for parallel programming computing in Opencl. In general I use this capability to crack encryption.

Regards what seems a contradiction. But it does not.
Here is where you may see a contradiction. In order to have a working Opencl the kernel module gflrx has to load!! So it need to be able to compile for the kernel version, but not necessary do graphics works. Clearly if you got a PC with only one GPU this is a conflict. No GPU no Monitor. But in my case, my Discrete AMD OLD GPU is also accompany by the original GPU on the CPU. So the Laptop will continue to have Monitor output using the CPU internal graphics. In my case Intel HD3000.

Now on my current setups, lsmod show that at kernel level, the new Free Drive Radeon load at the same time with the None Free AMD gfrlx!! They do seems to survive, Weird no!! Now I believe that is not much of trouble anyway. After Xorg takes over it in fact uses separate Xorg dedicated drivers for X. Yes another Radeon driver.

Now Why I am asking about porteus file structure? Because I have some how working opencl drivers for x86 on 4.1.38 & 4.4.87 i386. Kernels that I downloaded from https://archive.org/download/Puppy_Linux_Stretch. And I need now to port the Idea to 64bit kernel. And will try to see If I can make it work on Buster. Where the new PIC make all breaks up.

[fredx181]

Hi enrique,

Well, I wasn't very clear, with "goal" I just meant what sort of help you need, I still don't understand what you got so far and where you got stuck to accomplish what you want.

Fred

[enrique]

When I started the thread, I wanted to know about Debiandog File structure.

...
Question
...
My question is if I am using porteus-boot what will be the correct files
structure and what is included in each squach. ...

I did ask because the kernel files I was using did not have a standard way. Clearly they are old. I was having trouble booting 64bit kernel 4.4.87. It hang up & do not boot. And I was looking for explanation. Was thinking porteus-boot was the problem. But after a day of work I see that porteus-boot is NOT the cause. It seems that even when I build the kernel without errors, wmlinuz is in fact broken. So as I am having trouble with 4.4.87 I will see if I can make it work with 4.5.1. One I had used in the past with my satellite project. This is where I am now at.

...I just meant what sort of help you need...

At the moment Please forget my initial question. But now that I have build so many kernels, it is not necessary. As in fact your porteus-boot building system does in fact take care of all the output files.

NEW Question.
1) What does the flags files are for? My best guess is initrd1.xz. But can you tell me what section used those files? What happen If i do not used it or put the wrong one.

Code: Select all

buster-i486.sgn
buster-x86_64.sgn
stretch-i486.sgn
stretch-x86_64.sgn
jessie-i486.sgn
jessie-x86_64.sgn

2) Is the initrd1.xz a generic one? Can it be used with different versions of debian dogs?

[fredx181]

At the moment Please forget my initial question. But now that I have build so many kernels, it is not necessary. As in fact your porteus-boot building system does in fact take care of all the output files.

Ah, Ok, just a tip for now, maybe you've seen (or use) already, see here for automated creation of initrd1.xz from (choice of) any installed kernel (in /lib/modules)
(mk-initrd part of upgrade-kernel2)
http://murga-linux.com/puppy/viewtopic. ... 60#1049860

NEW Question.
1) What does the flags files are for? My best guess is initrd1.xz. But can you tell me what section used those files? What happen If i do not used it or put the wrong one.
buster-i486.sgn
buster-x86_64.sgn
stretch-i486.sgn
stretch-x86_64.sgn
jessie-i486.sgn
jessie-x86_64.sgn

For buster and latest stretch these are actually not needed anymore (searching now for initrd1.xz as "sgn") so kept these .sgn files for backwards compatibility, just in case.

2) Is the initrd1.xz a generic one? Can it be used with different versions of debian dogs?

No, not generic, the initrd1.xz has the required kernel modulles to boot, matching with vmlinuz1 kernel version, so different for all debian dog variants.

Fred

[enrique]

I always download from kernel.org mirrors. Now I see this is the second time you pointed me to https://github.com/torvalds/linux/releases. Just in case you do not know. Torvalds gits is a live system, it keeps getting changes all the time. I can see last commits is on Feb 25, 2020. So my point is that the kernel source that you use when you build your original kernel may not be the same as the current one. So we may have then new issues.

I'm almost sure that https://github.com/torvalds/linux/releases/tag/v4.9 is an archived release, not being updated (I checked, and all files inside tar.gz are from 11 dec 2016)
Btw, for clarity, I didn't build any kernel (just modified from Debian stock kernel by adding aufs and replacing squashfs kernel modules)

Now that you show me this. I recalled reading that maybe the last number in version is ignore by modules revision check. So I this is right it will be easier to grab last updated Like for 4.9 in kernel or will be
linux-4.9.209.tar.xz 12-Jan-2020 10:32 89M

I don't really know, I guess so that 4.9.209 is updated version of 4.9.

P.S. in case you didn't notice, your thread "How to do Opencl programming with AMD CPU?" has been moved to the Programming section

Fred

Waoo I am back here. I thought that I got another thread deleted. Any place moderators think is the best is fine with me. I guess after we get a working driver, and I can post the final patch info, then the best best place should be in Forum index » Advanced Topics » Hardware » Video. As the primary objective of the thread is NOT Opencl Programming. But to patch the Video Driver so that it can allow the Video GPU Hardware to be used for Opencl. Yet it seems the future driver will not do graphics.

fredx181 You are correct I misinterpreted

Code: Select all

torvalds tagged this Dec 11, 2016 · 266122 commits to master since this tag 

Is the master the one that has extra commits.

I did not answer sooner because I been busy using your script to build a 64bit stretch. As I wanted StretchDog64 to look just as BusterDog64 do. Your original stretch uses LXDE + Puppy Menus. Buster uses OpenBox. And I got trouble with Github. I kept getting 404. I guess the got tire of my many tries and block me out. I got it just now. Hopefully I will make some more advance today. As I said on the other tread I work in 32 bit 4.5.1 kernel and did not required more patches. I am so close to make it work in Stock Stretch 64 bit.

[enrique]

Even when at the moment no one has show interest, I do feel the need to report. Just in case.

I have not posted because I been pretty busy searching the net for answers. Yes I am no expert on kernel nor have knowledge on GPU drivers. So I search for similar problems on other drivers and how they overcome the new changes in Kernels. With the hope that it does not affect the original functions of our driver. This remind me that before posting any patch or driver, I have to add a warning at 1rst post Reading Experimental.

Where I am. I had patched the driver enough for it to show no more errors. But I been unable to load the driver in to the default StretchDog64 kernel. This would had been easier if I had the original Kernel sources. But using Kernel from https://github.com/torvalds/linux/releases/tag/v4.9. As results I received error on mismatch version. And if I force it I get wrong exec. So I may have to fix at least two more issues.

So if you are interested know I am working on it. Just hang around a few days more, I hope to have it resolve soon.

[fredx181]

But I been unable to load the driver in to the default StretchDog64 kernel. This would had been easier if I had the original Kernel sources

Hi enrique, didn't think of it earlier, not sure if it may help you but looking here:
https://packages.debian.org/en/stretch/ ... 0-12-amd64
On the right of the page it shows the source [linux_4.9.210.orig.tar.xz], so apparently 4.9.0-12-amd64 is matching with v 4.9.210 https://cdn.kernel.org/pub/linux/kernel ... 210.tar.xz
Also for me 'uname -v' shows similar

Code: Select all

root@live:~# uname -v
#1 SMP Debian 4.9.210-1 (2020-01-20)

EDIT: I guess it's best to do the following. Had to refresh my memory (long time ago since I did this)
To get the source including the Debian patches:
- uncomment this line in sources.list, so become this:

Code: Select all

deb-src http://deb.debian.org/debian/ stretch main contrib non-free

- refresh package lists

Code: Select all

apt update

- install dpkg-dev

Code: Select all

apt install dpkg-dev

- get linux source

Code: Select all

apt source linux

Code: Select all

......
dpkg-source: info: extracting linux in linux-4.9.210
dpkg-source: info: unpacking linux_4.9.210.orig.tar.xz
dpkg-source: info: unpacking linux_4.9.210-1.debian.tar.xz
dpkg-source: info: applying debian/version.patch
dpkg-source: info: applying debian/uname-version-timestamp.patch
.....
.....
etc... long list of patches

Fred

[enrique]

You are always so nice. I do really appreciate your help.

Let me see how I do not complicate this.
The final output version not only is influence by the correct source but also in the environment where it was build original. I been told that gcc & glib version are important.

We been in this same situation before. Yes you where in the past helping me and I was in this same predicament. When I build my kernel for linux-image-5.4.0-rc1-udl+_5.4.0-rc1-udl+-1_amd64.deb. At the time I fail also to build modules and I end up building the new kernel.

Here is the main issue now, I build kernels or 1386 and get the porteous build. And all works as it should.

But when I try to do the same with amd64. My kernels/porteous build but they failing to boot!! Strange, as the script that I am using where build and worked for my -5.4.0-rc1-udl+_amd64. See it was amd64. I do not know what I am doing wrong now.

So, this was the reason for me to try going back to create the modules for default stretch kernel.

I recalled

Code: Select all

make clean
cp /usr/src/linux-headers-$(uname -r)/Module.symvers .
cp /boot/config-4.19.0-6-amd64 .config
make modules_prepare
make scripts
mpath=drivers/media/usb/au0828
make M="$mpath" modules
strip --strip-debug drivers/media/usb/au0828/au0828.ko	

But the way module compilation in the Catalyst driver is thru a make.sh script not make. And the driver is not part of the original kernel.

Let me resume. I do not know what I am doing wrong at this time. Need to figure that out. I only post to let every one know that I am still working in the project. But I have good hopes. One more time THANKS for you support.

[enrique]

Where I am?
As I explained I got trouble with default stretch 4.9.0 in amd64. If I try making driver for default kernel, I get mismatch on kernel version. On the other hand when I compile my own Kernel, it builds without problem but it will not boot. I suspect there is something wrong with AUFS patch.

1) So to take a break, I decided to test and try the required patch I prepare for 4.9.0 AMD64, but patching the driver for kernel 4.5.1. Reason is that I know 4.5.1 works. The idea behind is to test those scary changes that I found as suggestion for 4.9.0. Guess what simple test shows fglrx driver loads and clinfo post that GPU is available. Then I test with a small Opencl program and it works. Clearly driver does not work for graphics. Xorg reports:

Code: Select all

[   261.938] (EE) Failed to load /usr/lib/xorg/modules/drivers/fglrx_drv.so: /usr/lib/xorg/modules/drivers/fglrx_drv.so: undefined symbol: xf86Initialising

This is expected as this old driver is not compatible with current version of Xorg. The driver expect and old version of Xorg that uses old xf86 libraries. Here you see it failed to detect xf86Initialising.

2) The I decided to try on Stretch 4.9.0-12-686-pae. And only required a small manipulation of the source. version.h was move to:
/usr/src/linux-headers-4.9.0-12-686-pae/include/generated/uapi/linux/version.h

But old driver ( previous of UEFI ) expect it at:
/usr/src/linux-headers-4.9.0-12-686-pae/include/linux/version.h
So I temporary link Linux folder to include. I guess this should be included in the patch.

Again similar positive result, clinfo detects the GPU and small opencl program did execute. Now even when it execute as is. I have my concern with some of the suggested patches. Old system used "page"+"address" new way use ONLY "address". I expect that we have to manipulate the "page" info to be included in a combine "address". That is what my logic feel. But suggestion ask to only pass "address". For the moment I will leave it as it. Latter I need to learn more on the issue to make a proper conclusion.

Tomorrow I will start working on why I failed to make it work in amd64.

[enrique]

Another day. So I did search the web as always. And I found the following. Have not tested but it is promising.

Code: Select all

https://github.com/ssvb/xf86-video-fbturbo

I thinks this is incomplete as I found

I have already ported the DMA, MC, GFX module and the DCE. I tested modeseting in my desktop computer with a HD 7770 graphics cards and the framebuffer console is already working. What is missing is the SMC module(I belive this is related with power management), the UVD and the VCE. What it is also missing is making mesa work. I was not able to run X11 because it uses glamor on my distro. Mesa is not working, it seems to hang the GPU when dispatching the draw array command. I am leaving my modifed version of mesa in this repo: https://github.com/ronsaldo/mesa and the modified ddx driver https://github.com/ronsaldo/xf86-video-amdgpu with the SI PCI IDs.

And he also posted a full Linux 4.5-rc2

Code: Select all

https://github.com/ronsaldo/linux-amdgpu-si

People his work as the objective to make the graphics works. While my objective is to have Opencl active. So I do not know if it will work for me, but I have always assume that I only need the kernel driver to be loaded to have access to the computing cores.
Funny this show up now that I am almost finishing my research. Yes now That I have it working on stretch.

[enrique]

fredx181 I only have thanks to you. If the method you currently suggest does not work, there is always another one you had mention previously that do end doing the magic. Yes, I end up using your upgrade-kernel_0.0.9_all.deb. I do not know why I did mot though on it. So I upgrade from 4.9.0-11 to 4.9.0-12. And now there is no problem with kernel version.

Sadly the patch for the driver I made and work in x86, Does not work on amd64. Weird. So I went back to browsing the net. This brought me to a patch that brought me to a git that end up here: https://aur.archlinux.org/packages/catalyst-dkms/

That my friends have to be my solution. It is a collection of patches to upgrade fglrx on Arch linux. I have not been able to try them. Most of then, the kernel related, should work for us. Or at least I would have a good reference at what others had done regards fglrx. I was so happy to find this out that I had to post it before try even one. But As always I find it after a week of work.

I had not post any thing jet as all is in testing. But if any one is interested just ask and I will post what I have.

[enrique]

Wao that list catalyst-dkms patches from arch linux works perfect. And I made a script to unpack, patch sources, build & install driver using DKMS. Then finally making new directories, only copy the files that we need for opencl.

Now the only issue is one known. GPU will make the fan run as it consume more power. And there is the possibility that GPU is on and competing with Intel. I did not remember seen this issue in i386 stretch version. There are ways to disable GPU, both using ATI scripts, or Catalyst Software. And there is a way to do it using /proc directory. I need to study this phenomena.

If some one ask for the script I will post it as is. But I will like to test it further. There are patch to raise kernel to 4.14. And there is a comment that suggest it work to 4.17. I did try with 4.19 and it complains on some symbols.

See you guys around.

Edit:
Today ( a day after I posted ) the temperature are as it should be! The normal temp of my laptop is about 55C. If I run a Opencl program my temp jump almost instantaneous to 68C. Then as soon as the program stops it goes back to 55C. Today, in the short period of test my fan did not turn on. This my friends is normal. Using the full 480 core units inside the GPU for computational will create a lot of heat.

So I have no explanation as why yesterday my fans where on. My best guess is that the CPU was running something extra.

[enrique]

Did not have much time. Today I am closer to my goal of working flgrx on BusterDog64 default kernel 4.19.

That link from Arch Linux is homerun hit. So at the moment I have it working BusterDog 4.16.0 Just as the Arch people claimed on the files.

[enrique]

I have succeed to patch fglrx.ko up to the default kernel of BusterDog64:
Linux live 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28 ) x86_64 GNU/Linux

So at last I have free my GPU from AMD absurd incompetence. Or more like forcing my GPU to expire when it is in good working condition. Now I can use my 480 compute cores at 750Mhz. Just to show you lets do some calculation.

480 cores x 750 Mhz (speed of the cores)
----------------------------------------------------------------- = 180
2000Mgz ( Speed of my CPU Cores)

So it is like having a 1 CPU with 180 cores!.
or equivalent to 45 quadcore CPUs!! Not bad for an old computer.

Now the truth is that I will never used my Laptop in Full Use. Neither with my CPU nor The GPU. The Laptop can not handle continues Heat dissipation required for such a task. But I do prefer to program using my Laptop. Then do Brute-forcing/cracking on a Desktop that have a Better GPU with 1792 cores @ 900Mhz.

So what's next. I need to test a little more. Then see how much of the Graphic Driver survive ( Catalyst ). As it seem the possibility that it could be in working conditions as the Arch Link/Patches are for graphic purpose. So one more time, I will be working a little more the patches. Latter I will post the final results. But if any one is interested now, just let me know and I will post what I have as is.

[enrique]

Well I clean up my script. And even change the concept. Originally I was using dkms to install driver. I am substituting the method for a sfs/squashfs package instead. In this way it is simpler to enable/disable the driver by just removing the sfs/squashfs package.

How to build squash. You need to have your devx and Kernel Sources installed.

1) Untar the atachement to a directory. It will create a directory called fglrx-driver-module_sfs_builder_for_Puppy_v0.1.

Code: Select all

tar xf fglrx-driver-module_sfs_builder_for_Puppy_v0.1.tar
cd fglrx-driver-module_sfs_builder_for_Puppy_v0.1

2) Now Download & install the original driver package.

Code: Select all

wget --referer='http://support.amd.com/en-us/download/desktop?os=Linux+x86' \
https://www2.ati.com/drivers/linux/amd-catalyst-15.9-linux-installer-15.201.1151-x86.x86_64.zip
unzip amd-catalyst-15.9-linux-installer-15.201.1151-x86.x86_64.zip

3) Now run the script to build the squash

Code: Select all

./runme.sh

After a minute or so you will end with a file called fglrx-driver-module.squashfs Install this on your DebianDog. I have not tested on puppy yet but I guess you will have to rename "squashfs" to "sfs".

4) Reboot and test by doing

Code: Select all

dmesg | grep fglrx
lsmod  | grep fglrx
clinfo

5)you can now test your own Opencl program. I may add a sample latter.

[enrique]

I did quick test using Bionic 8 64 bits. The scripts build the squash. But Bionic 8 failed to boot safely fglrx. It seems there are mayor differences in the initrd of Puppy compare to DebianDog that will prevent the squashfs to do its job. My best guess is that to make it work in Puppy we will have to patch the kernel so that the driver gets build wi the kernel. Or modify initrd to include fglrx.ko.

People no one has show interest on this. So I will not work any more on this project. I have it working on ButserDog where I need it myself. But if any of you send me a PM I will be willing to help you make it work for you on Puppy in the future.

[wiak]

Nowadays it can take a long time before anyone takes interest in a new project, especially if it is something other than providing a ready to use iso. You really need to provide simple scripts, at least, allowing anyone to immediately try new project out. Even then you might only get a few regulars providing their feedback and comments. But if you only create for yourself then long term survival of any project will end, of course, as soon as you lose interest in it.

wiak