Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2022-08-10 16:36:20



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

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
On another note... I've recently tried to rebuild against the latest version, with the proper SSE2 enable for ARM64. I've already uncovered a number of issues causing the build to fail:

parallel_hashmap - has to have include guards to use sse2neon.h. maybe there is a better solution than doing the include guards in every dependency?

boost simd.h - "Multiple SIMD architectures detected, this cannot happen!" because it detects SSE being enabled however boost actually has native support for NEON.

Before I try to rectify all the build issues, would like to know if there's a good resolution for dependencies that include the intrinsics headers.


2021-09-19 01:42:05
Profile

Joined: 2009-03-17 18:42:51
Posts: 4956
Reply with quote
Try this patch against v1.28.2.41 sources, it should solve all issues:
Attachment:
sse2neon-patch.txt [2.04 KiB]
Downloaded 189 times

Note that if you want to update the pre-built libraries like what was done for the x86_64 Linux version, and compile zlib-ng and boost v1.77.0 libraries for arm64, you will also have to edit the following cmake files:
  • indra/cmake/ZLIB.cmake: remove the 'if (ARCH STREQUAL "arm64")', so that 'set(ZLIB_INCLUDE_DIRS ${LIBS_PREBUILT_DIR}/include/zlib-ng)' is always used.
  • indra/cmake/Boost.cmake: remove the 'if (ARCH STREQUAL "x86_64")' around 'set(BOOST_ATOMIC_LIBRARY ...' so that the atomic library is properly linked against the binaries.


2021-09-19 08:01:59
Profile WWW

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
Awesome, will test this and let you know how it works!

On another note, I've started to think "SIMD Everywhere" might have been a better choice... it handles choosing the correct platform implementation on its own, is also a header library, and has various platform implementations - including software fallbacks. However, it would indeed be more work as it would require testing on *all* supported platforms, as you're essentially supposed to replace the *mmintrin.h with a header like #include <simde/x86/sse2.h> or #include <simde/x86/sse4.1.h>. If the "native" is available, it'll inline the native intrinsic.


2021-09-19 19:53:45
Profile

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
Thanks, the patch you provided works.

Other notes, it appear that at least on the Pi 4, the Mesh upload dialog causes the viewer to totally hang up. I'm looking into this.


2021-09-20 08:51:18
Profile

Joined: 2021-11-18 08:47:57
Posts: 7
Reply with quote
Currently, i mean thank for providing prebuilds, but for 128247 the elfio was not updated.
Resulting in a download not found, updating it manually, it builds almost everything but i get stuck with this linking error:
[100%] Linking CXX executable CoolVLViewer
/usr/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/../../../../aarch64-unknown-linux-gnu/bin/ld: cannot find -l
meshoptimizer
collect2: error: ld returned 1 exit status

The pre build binarry in this thread works btw. Login is possible, not the fastest but hey it works.
around 5 to 10 fps on Mali-T860! (the gpu is sadly resouce starved due bandwidth issues..)


2021-11-18 08:57:55
Profile

Joined: 2009-03-17 18:42:51
Posts: 4956
Reply with quote
Tanuki wrote:
Currently, i mean thank for providing prebuilds, but for 128247 the elfio was not updated. Resulting in a download not found,
My bad: elfio is a header-only "library" and as such does not need recompilation for every architecture, but I forgot to update the URL for linux64-arm in install.xml: in the latter, simply copy the URL and md5sum for elfio from linux64 to linux64-arm.
Fixed for next release.

Quote:
updating it manually, it builds almost everything but i get stuck with this linking error:
[100%] Linking CXX executable CoolVLViewer
/usr/lib/gcc/aarch64-unknown-linux-gnu/11.2.0/../../../../aarch64-unknown-linux-gnu/bin/ld: cannot find -l
meshoptimizer
collect2: error: ld returned 1 exit status
This is an issue with a bad packaging of the library (libmeshoptimizer.a is wrongly placed inside the lib/ directory instead of lib/release/), in the pre-built library tarball. Until bjbdragon fixes this, you can manually move libmeshoptimizer.a from linden/lib/ to linden/lib/release/ and the viewer should link just fine.


2021-11-18 09:57:53
Profile WWW

Joined: 2021-11-18 08:47:57
Posts: 7
Reply with quote
Thank you! doing the two things mentioned it did build, i mean i figured out the first, but i still wanted to mention that oops.
Just not familiar with the code base so its hard to debug still :)
Anyhow, I'd say performance on my RockPro64 is similar to an early Core i5, changing window size to 720 and lowering graphics gives an overall performance of 10-25 fps.
So perfect for logging in when traveling, as i do have a chromebook type laptop aswell with RK3399 chipset.

No difference using clang or gcc to build it, but big respect for maintaining the code so well, this must be the best/easist to build SL viewer out there.
Extremely curious how it would run on things like the Jetson Nano or ODROID-N2+
Here if anyone else is interested though highly don't reccomend downloading some random persons build:
Quote:
http://raccoons.tech/coolvlviewer/CoolV ... ng.tar.bz2
http://raccoons.tech/coolvlviewer/CoolV ... 47.tar.bz2
md5sum
02e024b22e7109963522321124bd90ff CoolVLViewer-arm64-1.28.2.47-clang.tar.bz2
151f9cd8df1a95dc44fa31078d7ddec4 CoolVLViewer-arm64-lto-1.28.2.47.tar.bz2


2021-11-18 14:46:20
Profile

Joined: 2009-03-17 18:42:51
Posts: 4956
Reply with quote
Tanuki wrote:
No difference using clang or gcc to build it
Under Linux x86_64, I get the best results (fastest viewer binary) with clang (v12 or 13: older versions are slower or equal to gcc) plus LTO, and of course the tuning option (./linux-build.sh -c -l -t). Interestingly, LTO does not bring any speed gain to gcc builds (I tried over time with gcc v9, 10 and 11). Without LTO, clang v12/13 builds are roughly equal to gcc v11 builds.

Quote:
Anyhow, I'd say performance on my RockPro64 is similar to an early Core i5, changing window size to 720 and lowering graphics gives an overall performance of 10-25 fps.
On my secondary PC equipped with an old Core-i5 2500K (OC @ 4.5 GHz) and a GTX660, I get much better frame rates than that (>25fps in pretty much all situations, including the worst/laggiest places, usually around 60fps in most places, up to 320fps in my skybox), and with a larger screen (1280x1024), 256m draw distance and all other graphics settings pushed to the max, excepted ALM (off).

Mali GPUs are way too weak, and ARM64 CPUs not (yet) fast enough to match an x86_64 @ 4+ GHz... But we are not speaking about the same power envelope either (150-300 Watts for the x86_64+discrete GPU system against half a dozen of Watts for the ARM SoC)...

Quote:
i do have a chromebook type laptop aswell with RK3399 chipset.
With this one, you will want to try the "MainThreadCPUAffinity" setting so to reserve the two A72 cores to the main thread...


2021-11-18 19:35:08
Profile WWW

Joined: 2021-11-18 08:47:57
Posts: 7
Reply with quote
Hi!
I am sorry to have to ask this, but i've been stumped on how to compile most of the pre-compiled sources for Linux..
Some i figured out where to get the source from, but its quite hard to get them to compile mostly static/stand-alone.
So i was wondering. Do you use any bash scripts to automate the sources rebuild?
What are the steps for each package to get it packaged alike yours?

I'm asking as, the Chromium package and various others, i should rebuild to have on ARM64 these updated packages too.
Ive been using it on ARM for a while now. As the homebrew list of my unofficial builds here shows... https://raccoons.tech/coolvlviewer/
I can host the updated ARM64 binaries too.

Thanks in advance!


2022-02-22 04:23:03
Profile

Joined: 2009-03-17 18:42:51
Posts: 4956
Reply with quote
Tanuki wrote:
Some i figured out where to get the source from, but its quite hard to get them to compile mostly static/stand-alone.
All pre-compiled library "sources" (they are often just build scripts and patches) are available from the libraries sources directory on this site.

Tanuki wrote:
So i was wondering. Do you use any bash scripts to automate the sources rebuild?
What are the steps for each package to get it packaged alike yours?
A Linux (x86_64) build script is provided for each and every library in use by the Cool VL Viewer, but there is no automated build process (not really needed since libraries are rebuilt individually whenever one of them gets updated). Be wary that you might need to slightly modify the build script for your ARM64 distro (there might be some references to usr/lib64 paths in the script, for example, which likely won't apply to ARM64 builds). You will also need to update in the build script the URLs to your other pre-built ARM64 packages as you build packages with dependencies on them (e.g. curl, ColladaDom, etc).

Quote:
I'm asking as, the Chromium package and various others, i should rebuild to have on ARM64 these updated packages too.
CEF is another story... While I do provide a build script for it as well (cvlv-dullahan/building-cef/mkcef64.sh which would require slight modifications to build the ARM64 target instead of the x86_64 one) in the cvlv-dullahan library sources, rebuilding it on an ARM64 could take hours (it takes over two hours for the x86_64 target on a 9700K @ 5GHz locked on all cores) and requires dozens of gigabytes (around 70GB for x86_64 non-debug builds) of free storage space...
You could reuse Spotify's builds (the "minimal" tarball) and build Dullahan against them, but be aware that those builds do not include all the media CODECs (the ones with a closed license are omitted) and that you then would likely (1) have to disable jemalloc usage in the viewer since default CEF Linux builds use tcmalloc (2) and it would crash when trying to use jemalloc together with it, which would be a shame because it makes the viewer slower.

Quote:
Ive been using it on ARM for a while now. As the homebrew list of my unofficial builds here shows... https://raccoons.tech/coolvlviewer/
I can host the updated ARM64 binaries too.
Thanks. I am moving this topic and merging it to the existing ARM64 contributions one.

If you ever provide updated pre-compiled ARM64 libraries, let me know, and I will change the links in the install.xml file of the official sources to match them.


(1) "likely" since I did not check this fact by lack of an ARM64 platform to test it on.
(2) The CEF sources also needs a patch to be made jemalloc-compatible (else, CEF would crash at random times while browsing or executing some JavaScript); the patching is performed by my mkcef64.sh script. See this CEF issue (still unresolved because the provided "solution" by Czarek Tomczak is totally inadequate).


2022-02-22 09:32:05
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 46 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

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.