Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2021-11-27 15:24:42



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

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
In the past few days I have tried to see if I could get Cool VL Viewer just a little more... portable. I haven't figured out a whole lot, but I have discovered a few workarounds and am looking for options to resolve a few problems.

1. Extensive use of Intel intrinsics. These obviously are totally unportable, but found sse2neon.h which does seem to be complete enough to handle the current codebase with one added ifdef guard.
2. Some plugins (cef, gstreamer) can simply be disabled or stubbed out, with some additional build options. Of course a complete port would need these or some alternative, but would like to expedite building the viewer proper.
3. Some libraries seem to not even care there's a system local library installed, even building with system libraries. Am working through the cmake files and some of them simply aren't sourcing the multilib paths. This of course breaks the system build even for amd64.
4. Some libraries like hunspell (on e.g. Debian Buster) are using deprecated functions which throw warnings, which become errors. These can be avoided, at least until the functions actually completely go away, with some pragmas.

There is of course an alternative to porting, but would require other work elsewhere...
1. Box86 could be used. I've run a 32-bit x86 Singularity Viewer with Wine+Box86 however, I am crashing on memory allocations and the maximum allocation (in the Statistics page, not OS level accounting) seems to be 2048. Yikes. Box86 fails for some missing GLIBC wrapping on a Linux x86 binary, yet most Linux viewers have totally dropped 32-bit support anyway.

2. Box64 could be used. However, this is far less mature and is going to take a bit more effort to get working. But, it won't depend on dwindling support of 32-bit builds... and it will probably be less crash prone due to the extra memory.

Basically, I want to know the following:
Aside from internal build stuff, is there a way to build the entire (or at least non-system libs) dependency set automatically? If not, this seems like a neverending treadmill of porting and my efforts seem like they'd be best focused on getting emulation in a more functional state.


2021-08-18 17:31:38
Profile

Joined: 2009-03-17 18:42:51
Posts: 4773
Reply with quote
I am confused... What architecture are you trying to port the viewer to ?... You mention Neon, so I would assume ARM, but then you mention 32 bits... AFAIK, modern ARM computers are ARM64 (v8+) ones...

In any case the 32 bits compatibility is a lost cause because boost::fiber is totally bogus in 32 bits mode and crashes instantly the viewer on startup... Back in the days when my viewer could still be compiled for 32 bits x86 platforms (which is no more the case: see this thread), I had to keep a dual-path code base, with LL's old modified boost::coro to replace boost::fiber when compiling for 32 bits. But this old coro code is no more compatible either with modern boost libraries.

Frankly, trying to port the viewer to 32 bits ARM platforms would be a total loss of time.

As for the use of non-system libraries, that's because some of the libraries in use need patching. You can find all the sources in use to build them here.


2021-08-18 21:42:27
Profile WWW

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
I am attempting to port Cool VL Viewer to armv8+, apologies if I wasn't clear. While I'd love to see a viewer that's truly portable in general, ARM is probably the greatest share of non-x86 computers and it's what I have.

I only mentioned 32-bit mode referring to the option of just using box86 to run the x86 version, assuming it would be easier to re-port since it was done before. However, what you have said seems to suggest it'd be an ordeal. Also, memory limitations are likely to be a concern even with a fully functional build. As box64 improves, that may be a viable option. Not sure of the exact technical reasoning but this sort of emulation does care about bit widths.

Thanks for pointing out the sources... saves me a lot of trouble finding the patched version and building scripts to compile and package them all properly. Of course, all the boilerplate arch stuff has to be added but that's nothing compared to doing it all.

Hopefully, the boost::fibers isn't also a problem. I am definitely considering stripping some of the media stuff out to get a somewhat sane test build... do not want to run into runtime problem with some boost stuff after fighting with media plugins.


2021-08-19 03:18:38
Profile

Joined: 2009-03-17 18:42:51
Posts: 4773
Reply with quote
bjbdragon wrote:
Hopefully, the boost::fibers isn't also a problem.
It depends on how well Boost.Context (which the fibers code depends onto) is supported/implemented on ARM64. And should it be an issue, then this would be a total show stopper (the HTTP code entirely relies on fibers in the viewer code)...

Quote:
I am definitely considering stripping some of the media stuff out to get a somewhat sane test build... do not want to run into runtime problem with some boost stuff after fighting with media plugins.
If porting to an ARM64 Linux platform, then you should be able to at least use the gstreamer plugins (the viewer uses the system gstreamer libraries). It should also be possible to rebuild Dullahan against an ARM64 version of CEF...


2021-08-19 08:31:50
Profile WWW

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
Right, it's just a low priority for my own purposes getting the web media working, if I can get the viewer to build then I will definitely be trying to. Have made some progress, got entire viewer code to compile just trying to get all the dependencies in line so it'll link.


2021-08-19 16:31:53
Profile

Joined: 2011-10-07 10:39:20
Posts: 141
Reply with quote
Sounds like a fun/crazy little project.

Whats the hardware target you aim for? Apple M1 hardware or some of the ARM based notebooks? Or a lowly Raspi 4?


2021-08-19 20:31:11
Profile

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
kathrine wrote:
Sounds like a fun/crazy little project.

Whats the hardware target you aim for? Apple M1 hardware or some of the ARM based notebooks? Or a lowly Raspi 4?


I am currently building on a RockPro64 with RK3399 SoC (4GB), as well as hoping to run on the Raspberry Pi 4 8GB. Obviously in terms of graphics, any armv8+ that has a Mesa supported hardware rasterizer should theoretically work with enough RAM.

The Pi 4 isn't absolutely terrible, as I managed to get about 15-30 fps in some mainland area with low graphics settings (windows x86 version of Singularity emulated). Not impressive, but okay for some light use... and other ARM systems are more powerful. Am hoping that native build will *help* performance, but that is no guarantee.


2021-08-19 22:02:39
Profile

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
Got a quick, completely untested successful build... going to test it but ran into one hitch which I fixed by manually editing makefiles that cmake generated. The linker seemed to want -x64 libraries yet the boost build created -a64 libraries. Just modifying the link line was enough for link and packaging but need to know how to make it select the right one.


2021-08-20 01:46:02
Profile

Joined: 2009-03-17 18:42:51
Posts: 4773
Reply with quote
bjbdragon wrote:
The linker seemed to want -x64 libraries yet the boost build created -a64 libraries. Just modifying the link line was enough for link and packaging but need to know how to make it select the right one.
The file to modify is: indra/cmake/Boost.cmake

As a quick and dirty workaround (that will need to be replaced with a proper and automated architecture detection later on), simply replace "-x64" with "${ARCH_SUFFIX}" everywhere in that file, and add a 'set(ARCH_SUFFIX "-a64")' line somewhere before the first ARCH_SUFFIX usage (e.g. after the 'include(Prebuilt)' line).


2021-08-20 07:42:12
Profile WWW

Joined: 2021-08-18 09:56:48
Posts: 22
Reply with quote
Thanks for all the help! My first build was broken because of SSE2 CPU detection, just stubbed out the fatal error for now and... well, it actually works on the RPi 4, and I was able to actually travel around the grid. It's definitely not very fast but seems to be pretty stable.

I managed to get a build of dullahan with the cef binaries that you mentioned. Next pass for rebuilding the viewer is going to be trying to do things in a cleaner fashion in order to minimize changes in the build and do proper architecture handling.


2021-08-20 09:42:55
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 38 posts ]  Go to page 1, 2, 3, 4  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.