We currently use Samsung Tablets running an android-based app for automated task training. Every so often, given my unease using Java and the android API, I yearn for a PTB-based tool. For another project, I just built a custom system with a RPi 4 for recording video automatically with a manual dexterity task. So given a running system had a go again using PTB on the Raspberry Pi. As my current toolset depends on the new libcamera interface for the RPi camera’s, and given general improvements with 64bit and performance / memory utilisation, I had a go at compiling PTB for the current 64bit Bullseye release running Octave 6.2. Many core mex files build just fine, I had to make some small tweaks to IsARM.m and the build script to add search paths etc., I made a branch with these changes (with the mex files if anyone want them):
I also had to rebuild the drawtext plugin file, and it also builds fine, it requires to be named libptbdrawtext_2_64.so.1 to be used.
Psychportaudio was the only major mex that I couldn’t wrangle to build:
octave:15> linuxmakeitoctave3(3)
Building plugin type 3 ...
/usr/bin/ld: cannot find -lportaudio
collect2: error: ld returned 1 exit status
error: mkoctfile: building exited with failure status
Adding -L/usr/lib/aarch64-linux-gnu/ to the build command didn’t help. Well for my needs audio isn’t required though I’m sure it will be an easy fix.
So in summary, PTB is working overall, however VBLSyncTest has very poor performance, and so i suspect the fixes Mario made for 32bit systems recently are not enabled on 64bit (it should trigger with PsychLinuxConfiguration and/or XOrgConfCreator, I used both). There is some tweaking to do to get it to work, so it is probably better to swap SD cards and stick to 32bit for the moment…
I’d expected it to work, I just don’t want to maintain yet another variant for free.
I think PTB 3.0.17 something ships with RPIOs 11? Outdated, but encodes build/runtime dependencies, so good for some convenience in setup, and ergo …
sudo apt build-dep psychtoolbox-3
…might do the trick of installing all required build dependencies and runtime dependencies. Might fix the PPA build. Well at least of the mex files that were shipped in 3.0.17 with a few exceptions.
libptbdrawtext_ftgl_arm64.so.1 should be the standard search name on ARM64.
Wrt. libcamera, it includes a gstreamer plugin, which once installed should allow PTB to access libcamera-supported cams. I use that on my MS Surface Pro 6 tablet which also has an exotic camera to get it working with libcamera. Can also be used with gstreamer video4linux2 loopback to make non-gstreamer aware apps work, e.g., Skype, MS-Teams, some web browsers…
Wrt. tearing, don’t know. It’s fine on my RPi400 RPIOS 11 32-Bit. Recent PTB master in my GitHub has further fixes for RPi4/400. Also make sure the kernel is as up to date as it gets, i guess? Anyway, not something i’m going to look into for free atm.
Yes, I posted more for general info if anyone else thought about trying this.
Yes, 3.0.17 and Neurodebian claims 3.0.18 (but only common, lib still seems stuck at 3.0.17). I decided to build from source more out of general curiosity, and a preference for the latest PTB whenever possible.
sudo apt build-dep psychtoolbox-3
Out of curiosity, how does that actually work? Looking at psychtoolbox-3-common/lib/dbg and I don’t see any build dependencies in the package info, so i’m obviously looking in the wrong place I worked out the required libs myself also to understand things from first principles more or less…
That’s what I built first but it wasn’t found, and the error message told me it was looking for libptbdrawtext_2_64.so.1, rebuild for that name worked fine…
The kernel is 5.15.76, the latest RPi OS ships. Mesa is also up-to-date (20.3.5 that ships with the RPi), it is easyish to install/build a later version but I didn’t test it with PTB: Install Vulkan on Raspberry Pi 4 - Q-engineering
Going back to the 32bit OS and PTB works well, and in the end it isn’t too much of a pain to swap SD cards. Thanks as always for all your work!
At least on Ubuntu 20.04/22.04 ND has all packages at 3.0.18.12, so maybe some weirdness on your side?
There is a psychtoolbox-3-src package (if i remember the name correctly), which provides the build-time dependency list. May need some opt-in setting in the software settings, to see it. Ofc. mex files that were added in 3.0.18+ won’t have their build deps encoded in the source package for the 3.0.17 shipping in RaspbianOS 11, but then some of the 3.0.18 stuff is not workable on RPi anyway, so probably gets you close to/(all) what is needed. Sometimes build deps for things like Screen also change with new versions, e.g., higher library versions or additional libs for new improvements.
Out of laziness I always install the ND packages or RPi packages on new development machines. Not for using them - i’ll only give them a very quick basic (“does it on/doesn’t crash/show some picture/make some sound?”) test drive, then ignore them and get my stuff from GitHub. But so i can do sudo apt build-dep psychtoolbox-3 and be up and running in a minute instead of having to hunt down all the build dependencies manually, or at least way less…
It suggests you or something has set Screen('Preference','TextRenderer', 2) somewhere for a non-default setting of 2 instead of 1. Meant if 3rd parties want to provide their own text renderer implementations for some reason, but I am not aware of anybody having ever used that. But maybe i just misremember something, because while typing this I just had a deva vue of having typed that in the past. Or sleep deprivation / lack of chocolate in the blood stream - too much work, no time to go to the supermarket and also its cold outside…
That website is a nice find. Might use their easy Vulkan instructions to see how Vulkan fares with PTB some point as a “hobby” project.
It is strange though, would not have expected a difference between RPIOS11 of 32-Bit vs. 64-Bit. You do have the latest PTB from my master branch with the updated PsychLinuxConfiguration, which brings new workarounds to unbreak pageflipping on os 11, right? But with all the tweaking going on by the RPi foundation, especially to get memory consumption down, maybe a switch to a 64-Bit address space may shuffle tweaks around. But that’s for some other day, if I ever decide to officially support 64-Bit RPi, or if somebody contracts us to look into this stuff…
Could very well be, I thought it was strange but it definitely had different versions for common and lib.
Yes, good advice!
Very likely while I was trying to first fix things as 'TextRenderer', 0 failed completely (X11 cannot find any fonts error, Screen cannot continue).
I restarted the 64bit and didn’t change TextRenderer settings and it then complained that libptbdrawtext_ftgl64.so.1 was missing, and renaming libptbdrawtext_2_64.so.1 and it worked, so your theory about 'TextRenderer', 2 sound about right. libptbdrawtext_ftgl64.so.1 still clashes with the 64bit linux name though, which may be a problem down the road if you ever do want to include them. EDIT: in fact there is an error in the log output I missed and libptbdrawtext_ftgl_arm64.so.1 is what it first looks for then falls back, i’ll tweak my modified build script now…
Interestingly PsychVulkanCore.mex built without adding doing anything with updating Mesa. I didn’t test it yet. As an aside, there is also a easy to use prebuilt Mesa 21.0.1 / Vulkan available from here: Releases · smartavionics/Cura · GitHub - untar then run octave with LD_LIBRARY_PATH=/opt/mesa/lib/arm-linux-gnueabihf octave --gui
Yes, PTB is your repo @ a6edbf2 — however while I thought I had disabled the compositor as part of my setup, it wasn’t actually disabled on my 64bit image, a quick sudo raspi-config and xcompmgr, reboot and now the timing seems as good. Just FYI, here are the logs for verbosity=10 for 32bit vs. 64bit:
[oh, i see there is a PTB-Warning about the drawtext plugin under 64bit, your proposed name is indeed the one it looks for first: /home/cog/Code/Psychtoolbox-3/Psychtoolbox/PsychBasic/PsychPlugins/libptbdrawtext_ftgl_arm64.so.1]
So it seems at least with the rebuilt mex’s 64bit is working as expected
As PTB 3.0.17 introduced the optional Vulkan display backend, the 3.0.17 source package would contain the needed build dependencies for PsychVulkanCore.mex, so it makes sense that building the mex file just works. I so far didn’t see a point in shipping it, as long as RPIOS doesn’t have a suitably up to date Mesa/X-Server for out of the box Vulkan support. Those 3rd party Mesa builds certainly call for a little test drive though. So far there also wasn’t any point of using the Vulkan backend, as it mostly enables features like HDR, advanced VRR, > 10 bpc framebuffers and such, which are all not supported by the current RPi hardware or Linux kms driver. However with the upcoming improved display mirroring support in PTB 3.0.19, Vulkan could be of some interesting use on a dual-display RPi 4/400 setup. It comes at a performance hit though, which is generally negligible on desktop class hardware from Intel/AMD/NVidia, but may be a tad severe on a RPi4/400 where video memory bandwidth is way lower - Only testing would tell.
Looks like that. Log output suggests proper operation and timing as well.
I worked out the required libs myself also to understand things from first principles more or less…