Page 12 of 15

Re: 64-bit operating system

Posted: Fri Dec 21, 2018 6:14 pm
by jdonald
Gavinmc42 wrote:
Thu Dec 20, 2018 2:56 am
Since I want to learn 64bit OpenGL coding, what choice do I have?
This got me thinking about what it takes to make this happen on Raspbian. In theory LXC can work with accelerated graphics but it's hard enough on desktops to begin with, and I haven't seen it done with Docker. So how about a less-restrictive chroot?

Start with Crazyhead's Raspbian + 64-bit kernel image, then:

Code: Select all

sudo raspi-config # enable OpenGL driver
sudo apt install -y debootstrap schroot
cat << EOF | sudo tee /etc/schroot/chroot.d/pi64
[pi64]
description=VC4 arm64 testing
type=directory
directory=/srv/chroot/pi64
users=pi
root-groups=root
profile=desktop
personality=linux
preserve-environment=true
EOF
sudo debootstrap --arch arm64 /srv/chroot/pi64
sudo schroot -c pi64 -- apt install -y mesa-utils minetest sudo

schroot -c pi64
That last command will open a (pi64)[email protected]:~ $ shell prompt where you can try:

Code: Select all

glxgears &
minetest &
Although the steps are simpler than LXC, be prepared to wait much longer when it first builds the chroot.

This is similar to what sakaki showed a few pages back, except her example was a 64-bit OS chrooting into a 32-bit one. Here we're going from 32-bit to 64-bit.

While this enables a wider variety of applications compared to Docker/LXC it's not perfect. For example firefox:arm64 crashed on me initially because it couldn't write to /dev/shm. I worked around that by running sudo schroot -c pi64 -- chmod a+w /dev/shm

Re: 64-bit operating system

Posted: Sat Dec 22, 2018 9:05 am
by Gavinmc42
Since I want to learn 64bit OpenGL coding, what choice do I have?

This got me thinking about what it takes to make this happen on Raspbian.
Well I guess if that made any sense for me I probably would not need a 64bit OS that works out of the box.

I did use Buildroot once, it took the whole weekend to make a kernel with one extra driver installed.
I have tried Crazyhead's stuff early this year, but I broke it :oops: .

Those who know how to make 64bit OS's or compile kernels are much lower in number than us who just use them ;)
Sometimes I can figure out dependencies and install them, sometimes the compiles work :D
But there is still lots of stuff not working on ARM yet, I think?

Will 32bit chroot stuff on 64bit talk to the camera stuff?
Can one of the 4 cores run in 32bit and the others in 64bit?
I know enough to ask dumb questions, I don't know enough to answer them.
That's what google is for :lol:

Re: 64-bit operating system

Posted: Wed Dec 26, 2018 6:51 am
by jdonald
Rascas wrote:
Wed Dec 19, 2018 5:12 pm
everything else that needs access to the Pi's firmware side GL driver (Broadcom) still doesn't work. That includes VLC and Chromium with hardware video decoding (via MMAL)
Though from the description, fake KMS is supposed to permit MMAL in 32-bit mode. I just tested VLC and fake KMS can play an H.264 mp4 with low CPU usage. By comparison full KMS gives up and only shows audio. As for Chromium, whether playing YouTube or a local MP4 file I get the same CPU usage in any of the three modes. Seems like that may have regressed in the years between Chromium 51 and 65?

In the VLC case, one issue with Fake KMS is that X feels less responsive during playback, perhaps due to time-slicing the GPU for the two uses. At least that's within expectations and regardless, video decode is working as advertised.
For Kodi to work with open source VC4 Fake KMS driver, you need to compile it yourself with OpenGL support instead.
Well that sounds like a lot of work. One can just download the standard GLES Kodi from the Debian repo:

Code: Select all

sudo apt install -y kodi # Raspbian Kodi with dependencies
wget http://http.us.debian.org/debian/pool/main/k/kodi/kodi-bin_17.1+dfsg1-3_armhf.deb
sudo dpkg --install kodi-bin*.deb
This almost certainly doesn't come with accelerated decode but it runs fine with CPU decoding on a Pi 3B+, so perhaps an adequate solution for those who aren't running other server processes while using the Pi as a set-top box. It works with an aarch64 kernel, except I had to remove a couple lines in the kodi wrapper script looking for armv7 in the lsb_release text.

I notice you keep referring to programs as "if compiled with OpenGLES". Because the Mesa VC4 driver enables both OpenGL and OpenGL ES this isn't an accurate comparison, but I take it you mean compiled with brcmGLES as opposed to standard GLES.

As for emulators, I've run brcmGLES-compiled pisnes through mcrpi-wrapper and the slowdown isn't noticeable. This can be done with a 32-bit emulator + wrapper binary on a 64-bit OS. I think the main emulators that suffer with the Mesa driver are 3D ones like Mupen64Plus, but that has issues on Pi regardless.
Gavinmc42 wrote:
Sat Dec 22, 2018 9:05 am
Will 32bit chroot stuff on 64bit talk to the camera stuff?
Not really. It allows one to directly run 32-bit camera programs like raspivid or uv4l without recompiling, but doesn't help getting the kernel side (the hard part) to work.

Re: 64-bit operating system

Posted: Wed Dec 26, 2018 7:01 am
by Rascas
jdonald wrote:
Wed Dec 26, 2018 6:51 am

Though from the description, fake KMS is supposed to permit MMAL in 32-bit mode.

Which description? What I have read is that fake kms allows access to dispmanX. DispmanX and MMAL are 2 different things. I know that there is work in progress to get MMAL working with the VC4 open source fake KMS driver, from the LibreELEC project, but it is not currently working good AFAIK.
jdonald wrote:
Wed Dec 26, 2018 6:51 am
I just tested VLC and fake KMS can play an H.264 mp4 with low CPU usage. By comparison full KMS gives up and only shows audio. As for Chromium, whether playing YouTube or a local MP4 file I get the same CPU usage in any of the three modes. Seems like that may have regressed in the years between Chromium 51 and 65?
In the VLC case, one issue with Fake KMS is that X feels less responsive during playback, perhaps due to time-slicing the GPU for the two uses. At least that's within expectations and regardless, video decode is working as advertised.

I don't know which tests did you do, but yes, with fake KMS, VLC and Chromium can play videos, h264 or not, but the performance is just much worse compared to the closed source drivers. Try, lets say, a h264 1080p 5Mbits video on both and you will see clearly the diference. With the closed source it will play perfect, with the fake KMS, you will get lots of frame skipping.
jdonald wrote:
Wed Dec 26, 2018 6:51 am
For Kodi to work with open source VC4 Fake KMS driver, you need to compile it yourself with OpenGL support instead.
Well that sounds like a lot of work. One can just download the standard GLES Kodi from the Debian repo:

Code: Select all

sudo apt install -y kodi # Raspbian Kodi with dependencies
wget http://http.us.debian.org/debian/pool/main/k/kodi/kodi-bin_17.1+dfsg1-3_armhf.deb
sudo dpkg --install kodi-bin*.deb
This almost certainly doesn't come with accelerated decode but it runs fine with CPU decoding on a Pi 3B+, so perhaps an adequate solution for those who aren't running other server processes while using the Pi as a set-top box. It works with an aarch64 kernel, except I had to remove a couple lines in the kodi wrapper script looking for armv7 in the lsb_release text.
In case you don't know, I am the Kodi package maintainer from the Raspberry Pi Foundation repos, so I have a fairly good knowledge about that and I have run alot of tests with it. Yes, you can downgrade and install the Raspbian version, which will work with the fake KMS, but the performance, is just much worse. Yes, it doesn't have hardware video decoding, again, of course. Probably with a Pi 3B+ you can play some h264 (or older codecs) 1080p very low bitrate videos fine, but it is just unusable on the first generations Pies, like 1, 0 or even the 2B. Let's not talk about higher bitrate videos, higher framerates (like 50 or 60fps) or more demanding/modern codecs like h265.
jdonald wrote:
Wed Dec 26, 2018 6:51 am
I notice you keep referring to programs as "if compiled with OpenGLES". Because the Mesa VC4 driver enables both OpenGL and OpenGL ES this isn't an accurate comparison, but I take it you mean compiled with brcmGLES as opposed to standard GLES.
Yes, by compiled with OpenGLES, I mean against brcmGLES. The Mesa VC4 driver doesn't have GPU acelerated 3D, all is done on the ARM side, I though that was clear.
jdonald wrote:
Wed Dec 26, 2018 6:51 am
As for emulators, I've run brcmGLES-compiled pisnes through mcrpi-wrapper and the slowdown isn't noticeable. This can be done with a 32-bit emulator + wrapper binary on a 64-bit OS. I think the main emulators that suffer with the Mesa driver are 3D ones like Mupen64Plus, but that has issues on Pi regardless.
Pisnes may run fine, it is not very demanding and supports dispmanX, but others are slower or have problems. More info here:
https://github.com/RetroPie/RetroPie-Setup/issues/2093

And don't get me wrong, I am not defending the closed source drivers or something. It would be great if everything worked with the open source driver and/or the performance would be similar, but it isn't yet. But that may change in the future...

Re: 64-bit operating system

Posted: Sat Dec 29, 2018 5:30 pm
by jdonald
Rascas, thanks for the info and especially the advice to try videos with a higher resolution and framerate.
Rascas wrote:
Wed Dec 26, 2018 7:01 am
Which description? What I have read is that fake kms allows access to dispmanX. DispmanX and MMAL...
Inferred from dom's text that you looked at earlier: "This means that tvservice, dispmanx, omxplayer(*), raspivid etc should work as before." RaspiVid.c is largely an MMAL program.
Try, lets say, a h264 1080p 5Mbits video on both and you will see clearly the diference. With the closed source it will play perfect, with the fake KMS, you will get lots of frame skipping.
Tested a few 1080p 60fps bird videos (4 Mbps ~ 14 Mbps) from this site. Much like omxplayer, I get the identical playback experience on fake KMS compared to the closed source driver by running:

Code: Select all

vlc --vout mmal_vout Birds_9.mp4
If you display using the window system via --vout mmal_xsplitter (the default on Raspbian's VLC) it is much more choppy. Is this the frame skipping you're referring to? I've only used Kodi in fullscreen, but can see it being a problem for LibreELEC if they need to support a windowed mode.

Indeed, Chromium remains slow with fake KMS on these videos even if I press F11 for full-screen. Considering what omxplayer and VLC can do it should be possible for Chromium to support full speed playback in fake KMS. However, based on the progress reports in 6by9's recent posts I imagine the team would be more inclined to spend time porting to new APIs to support true KMS.

Re: 64-bit operating system

Posted: Sat Dec 29, 2018 5:59 pm
by Rascas
Fake KMS support MMAL, the problem is that the implementation in some programs don't work yet. Raspivid is a small program, but much more complex programs like VLC, Chromium, Kodi, etc. won't be easy to get hardware video decoding to work. VLC fullscreen mode, with that option, I didn't tested, but without it, the performance is much worse (no HW video decoding), fullscreen or not. Chromium, is the same, no hardware video decoding, fullscreen or not.
Kodi on the Broadcom drivers is compiled with OpenGLES, so no X11 support and no window mode. Comparison can only be made on fullscreen mode on both, and the performance is much worse on fake KMS. No hardware video decoding on fakeKMS and other optimizations made over the years for the RPi.

Re: 64-bit operating system

Posted: Sat Dec 29, 2018 11:06 pm
by sakaki
For those still harbouring an urge to experiment with WebGL blobs ^-^, the 1.3.1 release of gentoo-on-rpi3-64bit I mentioned earlier in this thread is now available for download. This has chromium-71.0.3578.62-r2 and firefox-63.0.3 pre-installed, and comes with a GUI utility to allow the graphics driver to be easily switched between fkms, kms and framebuffer. Screenshot (on an RPi3B+):

Image

Please see this post for further release notes and download information. Although this is Gentoo, there's no need to configure or compile anything to have a play: the image boots straight to an Xfce4 desktop (with vc4-fkms-v3d, 256MiB CMA active by default).

Best, sakaki

PS: kodi-18.0_rc1 is on the image too.

Re: 64-bit operating system

Posted: Sun Dec 30, 2018 3:15 am
by Gavinmc42
Thanks Sakaki , I broke the previous version trying to install Warzone2100, an OpenGL game.
Why is "apt-get install Warzone2100" much faster than "emerge Warzone2100"?
Using Gentoo's emerge stuff seems to take hours to do.

Messed up some emerge options, but I figured out what i did wrong, still learning Gentoo.
I am sometimes to busy using it to learn it ;)
But I keep breaking Raspbian too, trying to get OpenGL working, so very hard to benchmark 32bit/64bit OpenGL.

Gentoo64 wins any OpenGL benchmark by default :D

Re: 64-bit operating system

Posted: Sun Dec 30, 2018 10:10 pm
by jdonald
Great work getting out the recent release, sakaki.

With a somewhat better understanding from the recent discussion, this brings up the question why have fkms driver as the default on Gentoo64? If firmware-based features like DispmanX or accelerated decode require a 32-bit kernel, isn't there zero benefit to running Fake KMS here? It seems like this might only cause issues when developing and testing true KMS apps (?)

Re: 64-bit operating system

Posted: Mon Dec 31, 2018 3:18 am
by Gavinmc42
If firmware-based features like DispmanX or accelerated decode require a 32-bit kernel,
"require"? Only in the sense of using 32bit pointers/tables etc instead of 64bit ones.
To make a 64 to 32bit translation layer you do need a 64bit OS to then talk to the 32bit VC4 stuff.
For accelerated stuff these days with Ultibo I still use 32bit but don't need a Linux OS.

But that is not why I wanted a 64bit OS, I want to play with NEON and the extra registers etc 64bit give us.
A 64bit OS with fkms is a start to making a better Pi with kms, whatever that is ;)
h.265 in software instead of h.264 in hardware, use NEON and 4 cores?
Exploring NN/ML using Arm's Compute Library?
Learn OpenGL then OpenGLES which is a subset?

True, no real performance benefit using 64bit instead of 32bit code when using 32bit SDRAM external memory.
But there are more registersand4 cores, can they be used to speed things up other ways?
Comparing Pi's to Android, there is still lots of improvements that can be optimized.

Re: 64-bit operating system

Posted: Mon Dec 31, 2018 4:28 am
by ejolson
Gavinmc42 wrote:
Mon Dec 31, 2018 3:18 am
If firmware-based features like DispmanX or accelerated decode require a 32-bit kernel,
But that is not why I wanted a 64bit OS, I want to play with NEON and the extra registers etc 64bit give us.
I've been wondering whether 64-bit NEON and the extra registers could be used to create an assembly optimized version of

Code: Select all

static bignum
mul_bn( const bignum a, const bignum b ) {
    if( a.n == 0 || b.n == 0 )
        return new_bn(1);
    bignum x = new_bn( a.n + b.n + 1 );
    x.n = a.n + b.n - 1;
    for( int i = 0; i < a.n; ++i ) {
        for( int j = 0; j < b.n; ++j ) {
            x.d[i+j] += a.d[i] * b.d[j];
        }
        if( (a.n - i) % 16 == 1 )
            for( int k = 0; k <= x.n; ++k )
                if( x.d[k] >= base ) {
                    const qword c = x.d[k] / base;
                    x.d[k] %= base;
                    x.d[k+1] += c;
                }
    }
    if( x.d[x.n] )
        ++x.n;
    return x;
}
or a similar numerical kernel that could be used as a building block for the computation of million-digit Fibonacci numbers discussed here and here. Are you still working on such a program with 64-bit NEON-optimized assembler?

Re: 64-bit operating system

Posted: Mon Dec 31, 2018 9:04 am
by jahboater
NEON works fine in 32-bit mode.

For 32-bit code GCC often passes 64-bit integer arithmetic over to NEON for execution (more so with -mneon-for-64bits).

In 64-bit mode, NEON has double the number of registers (32) and the register layout is changed to the modern way of doing things.

Re: 64-bit operating system

Posted: Mon Dec 31, 2018 9:30 am
by Gavinmc42
Are you still working on such a program with 64-bit NEON-optimized assembler?
Broke my last Gentoo64 1.3.0, now have the new 1.3.1 but still to install ARM's Compute Library.
Was hoping for some examples in that?

Need to read up on NEON too, most of it is way above me at the moment.
In fact all this multicore, multithread, SIMD stuff is new.
So used to 8 bit code optimization, 32/64/128 is new territory.

http://projectne10.github.io/Ne10/
https://developer.arm.com/technologies/neon
Seems to be lots of image stuff in the NEON can it be used to jpeg/h.264 the raw data from a camera sensor?
Can raw image data be got from the sensor in 64bit mode?

Re: 64-bit operating system

Posted: Mon Dec 31, 2018 5:54 pm
by code_exec
I've built an Ubuntu MATE 18.04 ARM64 image. Built-in WiFi works, as well as wireless periphearls. Bluetooth currently doesn't work, but I'll release an updated image if I discover a fix!

https://github.com/CodeExecution/Ubuntu-ARM64-RPi

I'm currently uploading an Xubuntu image as well that I built earlier, so expect to see that available for download as well soon.

Re: 64-bit operating system

Posted: Tue Jan 01, 2019 9:19 am
by jdonald
Nice work code_exec. I skimmed through the saga on https://ubuntu-mate.community/t/status- ... b/18054/31 and this seems like no small feat.

Your image boots for me on a Pi 3 but I get stuck on the rainbow screen with a 3B+. In the other thread you mentioned you got around this by upgrading the bootloader?

The choice of going with the linux-raspi2 kernel seems to come with a lot of tradeoffs. I actually liked the Ubuntu MATE 16.04 approach of using the Raspbian kernel and bringing in a lot of Raspbian functionality. However it looks like Wimpy is onboard with using Ubuntu-provided kernels too, so wishing for all the best with that.

Re: 64-bit operating system

Posted: Tue Jan 01, 2019 7:25 pm
by sakaki
Gavinmc42 wrote:
Sun Dec 30, 2018 3:15 am
Why is "apt-get install Warzone2100" much faster than "emerge Warzone2100"?
Using Gentoo's emerge stuff seems to take hours to do.
That's because with Gentoo, which is primarily a source-based distribution, unless the package in question has previously been built as a binary with the same version, USE flags, deps etc. as you require, and has then been placed in an accessible binhost, emerge will compile it locally, from source - which, obviously, takes much longer to do than installing a pre-built binary (which is what you will essentially always be doing on binary distros like Raspbian).

For the gentoo-on-rpi3-64bit image, I maintain a set just over 1,000 prebuilt packages on the isshoni.org binhost. At approximately weekly intervals, on my main buildserver I automatically update the Portage tree (a list of "ebuilds", official Gentoo recipes for building packages from source), and attempt to build any revbumped or version-bumped packages. This generally thows up a few problems which are fixed with masks (inhibiting certain versions), keywording (stating that certain packages notionally only available on amd64 will also build OK on arm64, for example), USE flags (specifying which high-level configuration directives should apply to each package), patches etc. Once done, the resulting binary packages (most of which are built using an RPi3 and distcc, but some of which (e.g., chromium) require a QEMU user-mode binfmt_misc chroot) are pushed to the binhost, the tweaks (masks, keywords, USE flags etc.) are added to the custom profile, patched ebuilds are released into the rpi3-overlay tree, and finally the "gated" copy of the main gentoo tree is updated. Once this is done, gentoo-on-rpi3-64bit users are able to pick up the changes using genup, and (unless they have gone off-piste with USE flags etc.) will find all necessary packages already available as binaries on the binhost. In this way the update time for end-users is kept manageable, whilst still providing the full flexibility of Gentoo should that be required (turning off the "bindist" USE flag to build patent-encumbered codecs, for example, should the end user want to so this (at their own risk!!) for one or more packages).

This basically means that the gentoo-on-rpi3-64bit system is more a 'mini-distribution' than an image. There are just over 1,000 packages used on the image (almost all of which are maintained on the binhost). This is << the 35,000 contained in a full-blown binary distribution like Raspbian, and also << the 20,000 or so packages for which Gentoo maintains ebuilds (with, however, generally multiple versions and often multiple slots, and with the customization flexibility of USE flags of course, so the number of available variants is much larger than 20k) so, if you ask Portage to emerge something that isn't prebuilt, you'll end up compiling it locally.

There are other points to note too, however. Looking at the ebuild for games-strategy/warzone2100 I notice that it isn't keyworded for arm64. If you accepted Portage's default "resolution" to this (which would be to keyword this package and any similarly-disposed deps "**") you'll end up with a nasty dependency tangle - "**" means to use the "tip of source-control" builds: it is much better to create explicit "*" or "* ~*" entries for each affected package (this means to accepts as a build candidate a version that has been marked as stable on any architecture, or as stable or testing on any architecture, respectively). You do this by creating entries in /etc/portage/package.accept_keywords/<pkgname>. You can see examples of doing this in the custom profile.

hth, sakaki

Re: 64-bit operating system

Posted: Wed Jan 02, 2019 1:24 am
by Gavinmc42
Thanks for the explanation Sakaki.
Probably stuff every Gentoo person already knows.

Gentoo64 still has way more ebuilds than PiCore tcz's, another Linux OS I use for single purpose apps.
As Gentoo64 is for my 64 bit Pi code learning developments, tools are more important than apps.
A mini distribution is just fine for my purposes, compared to PiCore Gentoo64 has a cornucopia of apps :D
Over time more ebuilds for ARM64 will be more common.

Keywording is something I am trying to get my head around.
Porthole handles emerge stuff fine but then keyword message pop up and I get confused.
At the moment I do - echo keyword >> to file
But sometimes emerge CLI works better than Porthole.

Geany is my favorite cross platform code editor, so that is my next thing to get going.
Thanks for custom profile links, something to study.

Re: 64-bit operating system

Posted: Thu Jan 03, 2019 5:34 am
by jdonald
Rascas wrote:
Wed Dec 26, 2018 7:01 am
The Mesa VC4 driver doesn't have GPU acelerated 3D, all is done on the ARM side, I though that was clear.
See Eric's brief overview of how rendering works with Mesa's vc4_dri.so. Apparently the vertex shaders, pixel shaders, primitive rasterization and much of the graphics pipeline still run on the GPU.

Compared to the legacy driver there may be more buffer setup work on the CPU side. Furthermore, shader compilation has gone from the VideoCore firmware to the host side, making it much like any other GPU vendor's driver.

Another source of confusion is that Mesa does have a software renderer (swrast_dri.so) that it can fall back on. When a user runs a GL or standard GLES program while neglecting to enable the driver, or if the vc4 kernel module has failed to load for any reason, the open-source driver will proceed with its slow CPU rendering fallback.

Regardless, vc4_dri.so is an accelerated graphics driver for VC4, hence its name.

Or as jamesh said a few posts back:
jamesh wrote:
Thu Dec 20, 2018 10:14 am
The OGL driver uses the Quads - they do the heavy 3D lifting, that is what they were designed for, whilst the ARMs control them. In the firmware version, that control is done by the VC4 itself.

Re: 64-bit operating system

Posted: Thu Jan 03, 2019 8:46 am
by 6by9
jdonald wrote:
Thu Jan 03, 2019 5:34 am
Rascas wrote:
Wed Dec 26, 2018 7:01 am
The Mesa VC4 driver doesn't have GPU acelerated 3D, all is done on the ARM side, I though that was clear.
See Eric's brief overview of how rendering works with Mesa's vc4_dri.so. Apparently the vertex shaders, pixel shaders, primitive rasterization and much of the graphics pipeline still run on the GPU.

Compared to the legacy driver there may be more buffer setup work on the CPU side. Furthermore, shader compilation has gone from the VideoCore firmware to the host side, making it much like any other GPU vendor's driver.
Define GPU. It's a term that is used very loosely because most people don't need to know the detail.
The VideoCore IP includes:
- H264 and JPEG Codec blocks
- ISP
- Video scaler (HVS)
- HDMI output
- DPI output
- DSI output
- CSI2 Camera receiver
- a dual-core general purpose 16-way SIMD processor (known as the VPU - Vector Processor)
- 3D hardware (known as V3D), which in turn is composed of Quad Processing Units (QPUs), shaders, texture units, and various other blocks that I can never remember.

On the Pi many people refer to the VPUs as the GPU, and the VPUs drive the V3D block in the legacy mode.
Eric's driver takes control of the V3D, HVS, HDMI, and DSI blocks. The VPU is still there and controlling the codecs and camera.

So what exactly do you wish to call the GPU?

Re: 64-bit operating system

Posted: Thu Jan 03, 2019 11:22 am
by Gavinmc42
So what exactly do you wish to call the GPU?
All of the above ;) GPU - Great Pile of Useful (mostly Unknown) stuff?

Did I see something about Eric's driver doing CSI as well, V4L2?
Been curious if that raw CSI peripheral can be used in 64bit mode.
I started compiling the raw CSI code and it calls mmal.h first?
Need to relearn C again, path include issues ;)

Not sure if anyone has tried the CSI in ARMv8 yet?
Is it a missing piece of info needed to get OpenVX to work the way Khronos would like?

Took out the brain dump stuff, I have been warned ;)

Re: 64-bit operating system

Posted: Thu Jan 03, 2019 11:34 am
by jamesh
Gavinmc42 wrote:
Thu Jan 03, 2019 11:22 am
So what exactly do you wish to call the GPU?
All of the above ;) GPU - Great Pile of Useful (mostly Unknown) stuff?

Did I see something about Eric's driver doing CSI as well, V4L2?
Been curious if that raw CSI peripheral can be used in 64bit mode.
I started compiling the raw CSI code and it calls mmal.h first?
Need to relearn C again, path include issues ;)

Not sure if anyone has tried the CSI in ARMv8 yet?
Is it a missing piece of info needed to get OpenVX to work the way Khronos would like?

Took out the brain dump stuff, I have been warned ;)
Didn't take out enough - still makes very little sense. Please read your posts through before posting so they actually make sense or contribute something.

Eric drivers doesn't do CSI. AIUI, all HW blocks o nthe VC are upto 32bit, but clearly, with the right software, you can access them from a 64bit host.

Re: 64-bit operating system

Posted: Thu Jan 03, 2019 4:57 pm
by 6by9
Gavinmc42 wrote:
Thu Jan 03, 2019 11:22 am
So what exactly do you wish to call the GPU?
All of the above ;) GPU - Great Pile of Useful (mostly Unknown) stuff?

Did I see something about Eric's driver doing CSI as well, V4L2?
Been curious if that raw CSI peripheral can be used in 64bit mode.
I started compiling the raw CSI code and it calls mmal.h first?
Need to relearn C again, path include issues ;)

Not sure if anyone has tried the CSI in ARMv8 yet?
Is it a missing piece of info needed to get OpenVX to work the way Khronos would like?
Eric's stuff doesn't do csi, but mine does (bcm2835-unicam). Pass as to whether it will work in 64bit mode, but if it doesn't then it'll only be the final memory addressing stuff getting the physical 32bit address to program into the peripheral.

Be aware that that only receives the raw data from the csi2 bus, no resizing, format conversion, or codecs. Those require mmal or similar.

Re: 64-bit operating system

Posted: Thu Jan 03, 2019 11:03 pm
by Gavinmc42
Eric's stuff doesn't do csi, but mine does (bcm2835-unicam). Pass as to whether it will work in 64bit mode, but if it doesn't then it'll only be the final memory addressing stuff getting the physical 32bit address to program into the peripheral.

Be aware that that only receives the raw data from the csi2 bus, no resizing, format conversion, or codecs. Those require mmal or similar.
Thanks for that, I keep losing track. google "unicam". Found it, hmm a bunch of v4l2 includes, my memory is not totally gone yet.
Raw data is perfect, actually interleaved 8/10bit pixel ADC values is crap, who thought of that?
It allows me to learn how to use NEON etc to make codecs, do jpegs etc.
There are some filter effects I want to try that are not in the start-x.elf.

er those brain dumps are me mostly thinking out aloud so a search will find it again.
They make sense to me, sort of an online diary.
A search finds them 6, 12, 24 months later, "Hey I know how to do that now" or "it is a bit closer to being doable".

With Khronos wanting to use the Pi3 as a OpenVX reference platform, I could just wait for someone smarter to figure it out :D
Arm's Compute Library has a bunch of filters that run on NEON and OpenCL, I can learn and hack them, I cannot hack the VC4 blob.
Getting raw image data to SDRAM is great, then the full power of4 x 64bit ARMv8 cores can be thrown at the data.

I don't even know how jpegs work, vague memory of DCT, discrete cosine transfer?
If I learn how to do it in software on Arm then those DCT/Quantize registers in the VC4 register list becomes more understandable.
Then perhaps one day more blob has an open source version, ok, don't tell it's 500 man years, I know, you have told me before, before,before.

From stuff I learned this week peak CPU speed was reached 10 years ago.
Now any advances will be in parallelism and software.
This old hardware guy needs to learn software :(
These brain dumps are just me splashing about in the deep end, trying to keep my head up.

Re: 64-bit operating system

Posted: Fri Jan 04, 2019 1:04 pm
by Will5455
I am just surprised that this thread has not bean turned into a do this rpf argument and has not bean locked. :D

Re: 64-bit operating system

Posted: Fri Jan 04, 2019 2:29 pm
by jamesh
Will5455 wrote:
Fri Jan 04, 2019 1:04 pm
I am just surprised that this thread has not bean turned into a do this rpf argument and has not bean locked. :D
Keeps everything on one place...if it were locked another thread would spring up in its place, the another one, then another one....a bit like a Hydra.