Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2022-12-03 18:30:45



Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4, 5
ARM64 port (was: Porting Difficulties) 
Author Message

Joined: 2009-03-17 18:42:51
Posts: 5097
Reply with quote
For people compiling their own ARM64 builds of the viewer, be aware that a breaking change is going to occur with next releases: a modified GLOD library version (that does not require the usage of fixed OpenGL function, making it compatible with the core GL profiles), will be used, that will prevent the next releases to compile for the ARM64 architecture until someone provides an ARM64 build of the new library.

If you are interested in compiling the new GLOD version, the sources have already been made available in the libraries source section of this site.


2022-04-18 21:08:11
Profile WWW

Joined: 2021-11-18 08:47:57
Posts: 7
Reply with quote
Thank you for explaining how to build the cef portion of it.
Due some Difficulties with some stupid RL events that are currently ongoing i sadly did not wanted to ghost but did due no net.. Oh well, things happen. Sorry.

Looking though the libraries, working on figuring out how to get it all build,
As of now, the linux build script contained checks for x86 current and have to bypass this, adjust maybe the configuration a bit, only to find such things as it might be too old to even have aarch64 in the supported system type.
I only have time on weekends but will try to hammer out the build libs as soon i can, possibly update older ones that do arch checking and lack aach64.. or add the check..


2022-06-11 21:41:40
Profile

Joined: 2009-03-17 18:42:51
Posts: 5097
Reply with quote
Tanuki wrote:
As of now, the linux build script contained checks for x86 current and have to bypass this, adjust maybe the configuration a bit, only to find such things as it might be too old to even have aarch64 in the supported system type.
Simply remove lines such as:
Code:
if [ `uname -i` != "x86_64" ] ; then
   echo "Sorry, 64 bits builds only, from now on !"
   exit 1
fi
in the build scripts. I already removed these from some scripts: this was used when deprecating 32 bits viewer builds, but is now history...


2022-06-12 09:20:08
Profile WWW

Joined: 2021-11-18 08:47:57
Posts: 7
Reply with quote
Only issue so far was apr and apr-util, from 2008? autoreconf -fi did not fix and had to pull upstream sources. Also noticed glib (last pre-meson build 2.56.4 has some code in it that GCC 10+ hates. used clang to bypass..)
in short, updated apr and apr-utils, also updated openssl for arm build. Otherwise just changed from -m64 to aarch specific settings. (someone with a RPi-4 should test it..)
I also pulled the sse2neon.h from the upstream git repo as i had some errors with the older one. Packaged it up like the rest.
I made a diff, its bit messy as i forgot to add few build files, but what i changed.. is here. In case anyone wants to recreate it. https://raccoons.tech/coolvlviewer/viewer-patches/libs.patch (place your newly build files into /var/tmp/$USER/install.cache )
Also edited the viewer install.xml to dl the newly build files. And include the updated apr/ap-util, and build for rk3399 specifically. . https://raccoons.tech/coolvlviewer/viewer-patches/viewer.patch

All these build files i build for ARM/rockchip (i tried to enable neon but threw interesting errors as armv8 neon is a bit different..) https://raccoons.tech/coolvlviewer/build-libs/

Actual Viewer DL for arm64 is https://raccoons.tech/coolvlviewer/CoolVLViewer-arm64-1.30.0.3.tar.bz2
md5sum 4b22c351889f35dafac631befc00ba60 CoolVLViewer-arm64-1.30.0.3.tar.bz2
The dir is browsable to grab any updated builds when i get to updating them. (sometimes i may miss a week as i simply forget)

PS: So far it runs faster for my application, previously i saw as low as 2-15 fps and now its 6-20 FPS. I am still waiting on an rk3588 board but shipping and supply chain issues... It takes a while.
PS2: sse2neon is a bit wonky, builds only with clang for me. The updated sse2neon.h helps building it with clang but gcc throws errors:
Code:
[  2%] Building C object libopenjpeg/CMakeFiles/openjpeg.dir/dwt.c.o
In file included from /home/void/source/coolvl/linden/indra/libopenjpeg/dwt.c:35:
/home/void/source/coolvl/linden/indra/../include/sse2neon.h: In function '_mm_crc32_u8':
/home/void/source/coolvl/linden/indra/../include/sse2neon.h:8440:5: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
 8440 |     for (int bit = 0; bit < 8; bit++) {
      |     ^~~
/home/void/source/coolvl/linden/indra/../include/sse2neon.h:8440:5: note: use option '-std=c99', '-std=gnu99', '-std=c11' or '-std=gnu11' to compile your code
In file included from /home/void/source/coolvl/linden/indra/libopenjpeg/dwt.c:35:
/home/void/source/coolvl/linden/indra/../include/sse2neon.h: In function '_mm_aesenclast_si128':
/home/void/source/coolvl/linden/indra/../include/sse2neon.h:8607:5: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
 8607 |     for (int i = 0; i < 16; i++)
      |     ^~~
/home/void/source/coolvl/linden/indra/../include/sse2neon.h: In function '_mm_aeskeygenassist_si128':
/home/void/source/coolvl/linden/indra/../include/sse2neon.h:8623:5: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
 8623 |     for (int i = 0; i < 4; ++i) {
      |     ^~~
make[2]: *** [libopenjpeg/CMakeFiles/openjpeg.dir/build.make:104: libopenjpeg/CMakeFiles/openjpeg.dir/dwt.c.o] Error 1
make[2]: Leaving directory '/home/void/source/coolvl/linden/viewer-linux-aarch64-release'
make[1]: *** [CMakeFiles/Makefile2:616: libopenjpeg/CMakeFiles/openjpeg.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

edit: still need to test chrome, it didnt work on my gentoo somehow. grabbing some other distro/manjaro/armbian to test. But should work....


2022-06-23 13:50:07
Profile

Joined: 2009-03-17 18:42:51
Posts: 5097
Reply with quote
The issue with gcc complaining will be fixed for next release since I already changed the standard for C sources compilation to c11 (because of this issue with old C standards and newer gcc versions). You can fix it in the current sources by changing all occurrences of "-std=gnu89" with "-std=c11" in indra/cmake/00-Common.cmake.

However, your change from "-march=armv8-a+fp+simd" to "-march=armv8-a+crc+crypto" makes you loose all vectorized optimizations in sse2neon (see their documentation, under "Usage", for the compile options to use): you do need fp+simd ! crc+crypto is useless for the viewer code (no assembly-level crypto or CRC operation used), and might make the final binary incompatible with SoCs without these extensions.
Finally "-mcpu=cortex-a72" is inappropriate since it means the final binary will only work on an A72 or better CPU (it's like if I built the x86_64 releases with '-mcpu=skylake': the binary would have AVX2 operations embedded and would crash on CPUs without AVX2)... There is also already an "-march=native" option that is added automatically by the linux-buid.sh script (meaning any -mcpu option becomes redundant and actually less adequate/efficient) when it is invoked with the '--tune' option (to be used only for personal builds, not for release builds, since this binds the binary to SoCs equal or better than yours).

Sadly, as it is, the diff for the libraries builds script is unusable... Beside, the changes you made renders those scripts incompatible with x86 systems. If you wish to contribute build scripts, simply post them here in full (zipped, of course), and rename them linux-build-arm64.sh or something in that vein, so that they can live along the Linux x86 build script equivalent...

The change you made to scripts/viewer_manifest.py breaks x86 builds packaging... You must add the proper detection for the library version to package, or use wild cards matching both the arm and x86 versions instead of changing the version number (which is in use by x86 builds), so that the script can work for both architectures. I got it right (using wildcards) for next releases.

There are also changes required in the viewer cmake files after the update to boost v1.79 and zlib-ng (see the comment in indra/cmake/*.cmake files about ARM64), else you fail to link against boost::atomic, and wrongly build against your system zlib instead of zlib-ng... Another change is needed in indra/media_plugins/cef/media_plugin_cef.cpp now that CEF got updated to the newest version. I got all those right for next releases.

I will update the install.xml file with your libraries for next releases. Thank you ! :D


2022-06-23 14:25:45
Profile WWW

Joined: 2021-11-18 08:47:57
Posts: 7
Reply with quote
Alright, will rebuild these libs with proper settings as soon as possible..
And the viewer too of course. The diff is is not properly useable i know, but i wanted to show what i done to change.
(but to be honest, there not many SOC's that are able to run the SL viewer. rk3399 is the top end for now.. as far i know)
Without them you would not bonk me on the head to do it correctly ;)
Edit:
Ok got it all the needed libs build with "-march=armv8-a+fp+simd" added. also redid the diff files to be actually usefull.. Yes i kinda took the if x86.. and adapted it to.. but uname -i shows unknown for me. soo .. hmm
https://raccoons.tech/coolvlviewer/viewer-patches/
and the build-files for aarch64 are updated once more with these options mentioned above ..
https://raccoons.tech/coolvlviewer/build-libs/
Also forgot to mention before, i grab the libs like this:
Code:
wget -r -nc --no-parent -nH --reject="index.html*,*.md5,*.meta4,*.mirrorlist,*.sha1,*.sha256,cef_binary*" -e robots=off http://sldev.free.fr/libraries/sources/
cd libraries/sources/
for f in *.tar.bz2; do tar -xvf "$f"; done
rm *tar.bz2

Should explain why it looks like so in the diff..

Edit2: i messed up the viewer manifest in the diff, wanted to include and started the build, sadly took ages till it finished and failed... ignore that part..


2022-06-23 18:00:21
Profile

Joined: 2021-08-18 09:56:48
Posts: 23
Reply with quote
Due to some issues going on in my life I pretty much had no time to look at this. I'm glad you had some luck and managed to keep a build up to date, Tanuki. I will try to build and test again once I get my Pi4 running again, but you're right. There aren't a lot of SOCs that are really able to run Second Life.


2022-09-21 05:07:28
Profile

Joined: 2009-03-17 18:42:51
Posts: 5097
Reply with quote
bjbdragon wrote:
There aren't a lot of SOCs that are really able to run Second Life.
Well, we are seeing new single-board computer models being released and using the RK3588, which is quite the little beast. These boards also often accept 8GB or more RAM, meaning they become quite capable to run a viewer, even if still at mid-range graphics settings...


2022-09-21 06:48:23
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 5097
Reply with quote
Note: I moved the posts dealing with how to run this ARM port on a PI4B to that separate topic; please post any reply dealing with it there.

Let's keep this topic (ARM64 port) for actual porting discussion and published ARM64 binaries.


2022-09-30 12:54:14
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 5097
Reply with quote
Today's v1.30.1.2 release introduced the usage of libepoxy and since the latter has not yet been built for ARM64 Linux, the experimental viewer branch cannot, for now, be built any more for ARM64 (*).
This will change as soon as an ARM64 build of libepoxy is made available.

On a brighter note, I fixed the bad MD5 sum for libcurl in install.xml, so the v1.30.0 release branch should build fine again for ARM64; do use the "--ignore-warnings" (or "-i" for short) option with linux-build.sh, if you encounter warnings that cause the build to fail (and please report those warnings here, so that I can fix them).


(*) In fact, it could still be built, but only by using system libraries (via the "--usesystemlibs" option of linux-build.sh) and on the condition libepoxy (and preferably the latest, v1.5.10 version) is installed on your system; such a build would likely only work on your own ARM64 system however.


2022-10-01 09:41:53
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 50 posts ]  Go to page Previous  1, 2, 3, 4, 5

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.