opencl in mandelbulber2

Post Reply
meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

opencl in mandelbulber2

Unread post by meister ivar » Sun Mar 03, 2019 3:48 am

Hi all,

i'm using mandelbulber2 (https://github.com/buddhi1980/mandelbulber2) for fraktal-rendering with opencl on my desktop-pc. thats a lot of fun! ;-)

If i try to do the same with my XU4, the image seems to be chopped as you can see below.

The programm finds the correct ocl-arm/mali drivers and other ocl-enabled programms like hashcat are running fine (and yes, naturally sloooow).

I'm using the latest git-build of mandelbulber2, but have no clue whats wrong. The cpu-only programm-instance is working correctly on XU4 and also the ocl-version of my desktop-pc.

Any ideas out there?

Thanks,
Ivar
Attachments
mandelbulber 3.png
this is example how it could look like
mandelbulber 3.png (4.75 MiB) Viewed 954 times
example.jpg
result of my xu4's opencl rendering
example.jpg (31.67 KiB) Viewed 954 times
Last edited by meister ivar on Mon Mar 04, 2019 5:18 pm, edited 1 time in total.

lazlo
Posts: 143
Joined: Sun Oct 01, 2017 11:32 am
languages_spoken: english
ODROIDs: XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: opencl in mandelbulber2

Unread post by lazlo » Sun Mar 03, 2019 4:53 am

I do't know anything about opencl on the mali GPU. For mandelbulber I remember the build scripts used to define default CFLAGS that included "-O3" which made the program very unstable. I never had much success with it until I changed that to "-O2" and then I was able to render scenes without artefacts and it fixed all the crashes as well.

meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: opencl in mandelbulber2

Unread post by meister ivar » Sun Mar 03, 2019 5:47 am

Thank you for that hint.

But the Makefile already uses -O2 instead of -O3.

lazlo
Posts: 143
Joined: Sun Oct 01, 2017 11:32 am
languages_spoken: english
ODROIDs: XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: opencl in mandelbulber2

Unread post by lazlo » Sun Mar 03, 2019 9:47 am

OK, I just looked at https://github.com/buddhi1980/mandelbul ... common.pri and you might want to reread lines 89 through 92.

meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: opencl in mandelbulber2

Unread post by meister ivar » Sun Mar 03, 2019 8:19 pm

So I changed the line of CXXFLAGS from -O3 to -O2 too (before it was only for CFLAGS -O2) and recompiled it.

Unfortunately the result is the same :-(
Last edited by meister ivar on Mon Mar 04, 2019 5:17 pm, edited 2 times in total.

User avatar
odroid
Site Admin
Posts: 32360
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID
Has thanked: 147 times
Been thanked: 325 times
Contact:

Re: opencl in mandelbulber2

Unread post by odroid » Mon Mar 04, 2019 9:46 am

Can you try Mali OpenCL examples?
viewtopic.php?f=95&t=5559

What is the minimum OpenCL version to run that software?

meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: opencl in mandelbulber2

Unread post by meister ivar » Mon Mar 04, 2019 5:15 pm

Hi odroid,
the minimum required ocl-version for mandelbulber seems to be 1.2.
Mesa with 1.1 on my desktop would fail too. Therefore i can use POCL (1.2) or ROCM (2.1) there. (BTW POCL is working well on the C2 with mandelbulber).
The mali-ocl-driver of the XU4 is at 1.2 and actually should work.

The OpenCL examples you suggests would work, I think. Clinfo already did, as I tested it in the past.
But they need to install mali-fbdev instead of mali-x11.
Unfortunately mandelbulber depends on mali-x11.

User avatar
meveric
Posts: 10492
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2
Has thanked: 17 times
Been thanked: 134 times
Contact:

Re: opencl in mandelbulber2

Unread post by meveric » Mon Mar 04, 2019 5:18 pm

I've compiled mandelbuilder2 for the XU3/XU4 running on my OGST image.
It's not very fast but at least it seems to work fine. I haven't seen any of the issues above.
Sadly I don't know if it's using OpenCL or not.
I've build the mandelbuilder2-opencl.pro project from the git repository, and after fixing some issues with the OpenCL headers everything works fine.

Never found anything that looks remotely as your first picture though. I'd love to see that rendered on the ODROID.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: opencl in mandelbulber2

Unread post by meister ivar » Mon Mar 04, 2019 5:26 pm

If it is using OCL in the rendering process, it is arranged in tiles starting from the middle.
If it is using the CPU, it is starting with the hole frame and sliding from rough to fine.

You can adjust the usage of OCL at preferences and the quality at the right side of your main window (I recommend to use "full").

hominoid
Posts: 306
Joined: Tue Feb 28, 2017 3:55 am
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1, N2
Location: Lake Superior Basin, USA
Has thanked: 9 times
Been thanked: 20 times
Contact:

Re: opencl in mandelbulber2

Unread post by hominoid » Sun Mar 10, 2019 1:55 am

meister ivar wrote:
Mon Mar 04, 2019 5:26 pm
If it is using OCL in the rendering process, it is arranged in tiles starting from the middle.
If it is using the CPU, it is starting with the hole frame and sliding from rough to fine.

You can adjust the usage of OCL at preferences and the quality at the right side of your main window (I recommend to use "full").
Did not see your post until today. With the additional information you posted I was able to see there is a problem with OpenCL with this app. FYI, I'm running Ubuntu 18.04 minimal with a Xfce desktop. Originally I expected in compiling the OpenCL version of the program that OpenCL would be used which was incorrect. After enabling it, the status line clearly indicates that it is compiling OpenCL kernels and loading them during render. I can also confirm this by watching the core temps as they are not spiking during render. Again as I reported in the N2 thread, many of the examples worked fine. When I tried the Mandelbulber 3 I got an error during the OpenCL kernel compile:

Code: Select all

Error: Error during compilation of OpenCL program
OpenCL Build log:
In file included from <source>:19:
/usr/share/mandelbulber2/formula/opencl/mandelbulb2.cl:18:11: error: casting to void is not allowed
        Q_UNUSED(fractal);
                 ^

error: Compiler frontend failed (error code 59)
Trying different examples, some of them would work and some would give me the same error so I went and looked at the offending file. What I found is that all the ones that failed had pre-generated OpenCL kernels, at least in part.

Code: Select all

/**
 * Mandelbulber v2, a 3D fractal generator  _%}}i*<.        ____                _______
 * Copyright (C) 2017 Mandelbulber Team   _>]|=||i=i<,     / __ \___  ___ ___  / ___/ /
 *                                        \><||i|=>>%)    / /_/ / _ \/ -_) _ \/ /__/ /__
 * This file is part of Mandelbulber.     )<=i=]=|=i<>    \____/ .__/\__/_//_/\___/____/
 * The project is licensed under GPLv3,   -<>>=|><|||`        /_/
 * see also COPYING file in this folder.    ~+{i%+++
 *
 * Fractal formula created by Buddhi

 * This file has been autogenerated by tools/populateUiInformation.php
 * from the function "Mandelbulb3Iteration" in the file fractal_formulas.cpp
 * D O    N O T    E D I T    T H I S    F I L E !
 */

REAL4 Mandelbulb3Iteration(REAL4 z, __constant sFractalCl *fractal, sExtendedAuxCl *aux)
{
	Q_UNUSED(fractal);

	aux->DE = aux->DE * 2.0f * aux->r;

	REAL temp, tempR;

	REAL sign = 1.0f;
	REAL sign2 = 1.0f;

	if (z.x < 0.0f) sign2 = -1.0f;
	tempR = native_sqrt(mad(z.x, z.x, z.y * z.y)); //+ 1e-030f
	z *= native_recip(tempR);
	temp = mad(z.x, z.x, -z.y * z.y);
	z.y = 2.0f * z.x * z.y;
	z.x = temp;
	z *= tempR;

	if (z.x < 0.0f) sign = -1.0f;
	tempR = native_sqrt(mad(z.x, z.x, z.z * z.z)); //+ 1e-030f
	z *= native_recip(tempR);
	temp = mad(z.x, z.x, -z.z * z.z);
	z.z = 2.0f * z.x * z.z * sign2;
	z.x = temp * sign;
	z *= tempR;

	z *= aux->r;
	return z;
}
By commenting out the offending call

Code: Select all

//	Q_UNUSED(fractal);
I was able to compile and display all the examples I tried that had previously failed. I'm still not sure that there are not other problems with these pre-generated kernels because there does appear to be some distortion in the rendered image as far as I can tell. In your post example, it looks like your zoomed up on the Mandelbulber 3.
Mandelbulber 3.jpg
Mandelbulber 3.jpg (80.75 KiB) Viewed 732 times
Can you post the settings your using for that particular view so I can try it and see if the images are the same. Or, post a image of what it's supposed to look like zoomed out viewing the whole fractal. I have no experience with this application so I'm not sure what is correct or not when it comes to the nuances of the image. Also try editing the OpenCL kernel as I did above and see what the result is on your XU4. The pre-generated OpenCL kernels may have a problem or we might be looking at difference on how the OpenCL stacks are implemented between ARM and AMD/INTEL; my best guess right now.

meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: opencl in mandelbulber2

Unread post by meister ivar » Mon Mar 11, 2019 1:22 am

Thank you for still working on it.

You solved a problem I never posted... ;-)
By commenting out the pre-generated kernels as you suggests the mandelbulb 3 formula now is compiling.
Before that it stucks with the error-message you posted.

But the resulting image is chopped as allways.

(For clarification: the first picture I posted I called "mandelbulber 3.png" because it was my third image I saved on hdd. there was no link to the mandelbulb 3 fomula, sorry for confusing. the original source is the mandelbox002.fract, wich is an example fractal with pre-calibrated settings.)
Attachments
mandelbulb 3 OCL.jpg
"chopped" as allways
mandelbulb 3 OCL.jpg (115.29 KiB) Viewed 707 times

meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: opencl in mandelbulber2

Unread post by meister ivar » Mon Mar 11, 2019 1:31 am

I think the problem is OpenCL/mali related...

hominoid
Posts: 306
Joined: Tue Feb 28, 2017 3:55 am
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1, N2
Location: Lake Superior Basin, USA
Has thanked: 9 times
Been thanked: 20 times
Contact:

Re: opencl in mandelbulber2

Unread post by hominoid » Mon Mar 11, 2019 1:02 pm

meister ivar wrote:
Mon Mar 11, 2019 1:31 am
I think the problem is OpenCL/mali related...
I’m not so sure. I have had no problem using OpenCL on a XU4 to render the madelbox002.fract or any other fractal, other than the ones with the externally pre-generated CL kernel code.
mandelbox002.jpg
mandelbox002.jpg (331.08 KiB) Viewed 679 times
I think there might be 2 separate problems here. One is problematic CL kernel code from this external source. It is not that uncommon in my experience. Over the years AMD and Nividia both have had many propriety OpenCL extensions. Some have been adapted into the specification but until that happens their OpenCL is not platform agnostic. A lot of OpenCL developers use these extensions to optimize performance or write code that is optimized for a specific architecture. Also supporting this premise is none of the other OpenCL applications I have used on the XU4 have had problems. And, then there is this from the Mandelbulber OpenCL options menu. “OpenCL support is still alpha and lacks the following features present in the non-OpenCL mode...”

The issue your having with the blocking seems to me to be a separate issue and unique to your XU4...so far. Balanced with the fact that I’m not having that issue, it could possibly be related to a configuration issue on your XU4 or differences in drivers. I’m running the mali-x11-gbm-fbdev_13.0.6-1_armhf driver from @AreaScout’s GBM thread. It would be interesting for you to start with a fresh image on a sdcard to see if the problem could be isolated to your current software load. This would also allow for the trial of the driver I’m using if the problem still persisted. Just my thoughts and some possible ideas if you care to pursue the issue further. The amount of effort has to be weighted against the fact that the 8 Armv7 cores are faster at rendering images then the Mali T-628. :)

meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: opencl in mandelbulber2

Unread post by meister ivar » Wed Mar 13, 2019 3:25 am

I think there might be 2 separate problems here. One is problematic CL kernel code from this external source. It is not that uncommon in my experience. Over the years AMD and Nividia both have had many propriety OpenCL extensions. Some have been adapted into the specification but until that happens their OpenCL is not platform agnostic. A lot of OpenCL developers use these extensions to optimize performance or write code that is optimized for a specific architecture. Also supporting this premise is none of the other OpenCL applications I have used on the XU4 have had problems.
OK, with commenting out the pre-compiled kernels we can bypass this in this case, right?
And, then there is this from the Mandelbulber OpenCL options menu. “OpenCL support is still alpha and lacks the following features present in the non-OpenCL mode...”
A couple of month ago this list was just 3 times longer...
The amount of effort has to be weighted against the fact that the 8 Armv7 cores are faster at rendering images then the Mali T-628. :)
Yeah, that's right. Since I have a Radeon RX 580 the XU4-OCL stuff is just for educational reasons... ;-)

Today I flashed a new SD with ubuntu-18.04.1-4.14-mate-odroid-xu4-20181203.img.xz image, upgradet it, installed depandancies:

Code: Select all

sudo apt-get install build-essential libqt5gui5 qt5-default libpng16-16 libpng-dev qttools5-dev qttools5-dev-tools libgomp1 libgsl-dev qtmultimedia5-dev libsndfile1-dev libqt5multimedia5-plugins liblzo2-2 liblzo2-dev git opencl-headers ocl-icd-libopencl1 opencl-c-headers
than

Code: Select all

git clone https://github.com/buddhi1980/mandelbulber2.git
and made package > qmake mandelbulber-opencl.pro > make and finally ./install

And the result is the same crippled as you imagine.
I think I'am resigning at this point. :(

meister ivar
Posts: 17
Joined: Fri Jan 05, 2018 7:27 pm
languages_spoken: english german
ODROIDs: xu4q c2 n2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: opencl in mandelbulber2

Unread post by meister ivar » Sun Sep 22, 2019 5:39 pm

Update:

After waiting half of a year I retried and I'am happy to say, now it's working!

System:

-Ubuntu 18.04.3
-Kernel 4.14.141-169
-Mali-x11 20190715-r17p0-a5
-Mali-x11-gbm-fbdev 13.0.6-1
-Mandelbulber2 up to date git

The following animation shows the rendering of an 1920 x 1080 frame.
That needs about 27 minutes plus one or two minutes of compiling the ocl-kernel for the two GPU-devices of XU4.
So every half hour you can generate your own high definition wallpaper! :D
xu4_ocl.gif
Rendering Process with dual GPU on XU4
xu4_ocl.gif (1.32 MiB) Viewed 246 times
Compared to OCL rendering the CPU rendering of the same frame with XU4 took ~40 minutes.
I think it could be much faster, but its only using the four big cores while the four little cores are at idle state.
Regardless it's running 8 threats! Every big core is at 2x 49%... :?:

And there is an other point. With CPU rendering there is much more thermal exhaust compared to OCL.
These users thanked the author meister ivar for the post (total 2):
hominoid (Mon Sep 23, 2019 6:41 am) • odroid (Mon Sep 23, 2019 8:22 am)

Post Reply

Return to “Issues”

Who is online

Users browsing this forum: No registered users and 4 guests