Raspberry Pi 4 Thread - general discussion

[rhcev6]

There is a feature of the Pi4 SoC that I'm surprised hasn't had more (any?) comment. That is that the Ethernet connection no longer runs through the USB hub. This means that a USB-attached SSD and the network connection won't be fighting over bandwidth. That alone should make a significant performance boost in any number of use cases.

So...additional congratulations to the chip designers for that feature.

You can pretty much saturate a gigabit link in both directions simultaneously using the dedicated MAC hardware. The lack of jumbo frame support does mean that the hardware does spam you with quite a few interrupts, but an upgrade to the driver to support the max hardware frame size probably won't require too much plumbing.

This is FANTASTIC news! I can finally net boot or NFS mount all/parts of a retro gaming system and not have the USB issues I had before. Netbooting and NFS mounting game systems is just SO much better than having to worry about SDcard sizes, speeds, etc. Plus netboot makes it possible to have a single system be either multiboot or gming and desktop in one OS

I plan to try a KVM setup with a pretty bare SO that can run and actual OS as a VM as an alternative to multiboot with HDD images over ISCSI/NFS mounts once I can get a Pi4 4GB model.

[ShiftPlusOne]

There are some known issues with chromium which will be resolved. The video and WebGL performance you get out of it will improve greatly. It's currently running with --disable-gpu to work around a more serious issue.

[horizn]

Does new RPi v4 support SDHC UHS-x cards? Apparently that information is a secret because I can't find it in official paperwork.

[PeterO]

Do you know why they don't they work on the Pi4 ? I've just found that my own openGLES2 code doesn't work any more but I've not yet looked what has broken it.

When running with the legacy GL driver you needed proprietary setup to create a surface for GL to render to (the dispmanx calls).
With the arm side driver that isn't required, and any standard X GL apps should work without modification.

e.g. a quick search and I found this:
https://wiki.maemo.org/SimpleGL_example

which works without changes on Pi4 (or earlier Pi's with fkms enabled).

Thanks dom, that's very helpful.
PeterO

What I'm not clear about is how the new architecture interacts with the hardware..
The frames per second performance of that example is not what would have expected, which leads me to think it isn't using the hardware to
got the openGLES rendering but is using slower arm side "new" stuff ?.

PeterO

[wh7qq]

The enhancement I crave is to print the model number in a larger font on the board. My eyesight isn't what it was!

I was having that problem, but a lot of it was solved last year when I had cataract surgery on my eyes. (NOT that I'm suggesting seeking to do that, but talk to your opthamologist if you think you've a got a problem.)

Off topic a bit here but as great as IOLs are, they introduce a problem of their own...Zero accommodation...so with mine, distance is fine, reading is good with readers but computers require a separate correction and I almost never have the right pair at hand. Put off any (inc. cataract) surgery until you really need it.

That said, the RPi4 specs are exciting and the dev. team is to be congratulated. That fills my bill 100%. All I must do is figure out how to justify buying one (but working on that).

[DarkPlatinum]

There are some known issues with chromium which will be resolved. The video and WebGL performance you get out of it will improve greatly. It's currently running with --disable-gpu to work around a more serious issue.

Do you know how long this may take? My boss wants to run a chromium kiosk...

[W. H. Heydt]

The enhancement I crave is to print the model number in a larger font on the board. My eyesight isn't what it was!

I was having that problem, but a lot of it was solved last year when I had cataract surgery on my eyes. (NOT that I'm suggesting seeking to do that, but talk to your opthamologist if you think you've a got a problem.)

Off topic a bit here but as great as IOLs are, they introduce a problem of their own...Zero accommodation...so with mine, distance is fine, reading is good with readers but computers require a separate correction and I almost never have the right pair at hand. Put off any (inc. cataract) surgery until you really need it.

Same here with the varying focal distance. I keep a pair of +1.25 "cheaters" on my desk and +3.0 in a pocket in my pants that is probably meant for a cell phone. I also put a pair of +1.25 in the box with my portable Pi (Pi2Bv1.1, 7" RPF screen, mouse; battery and keyboard separate). At least the reading glasses are *way* cheaper than prescription if there are no other issues. I can get 'em at a hardware store for $4 per pair.

Likewise on the advice not to jump into the surgery, hence my point about talking with an opthamologist.

[ShiftPlusOne]

There are some known issues with chromium which will be resolved. The video and WebGL performance you get out of it will improve greatly. It's currently running with --disable-gpu to work around a more serious issue.

Do you know how long this may take? My boss wants to run a chromium kiosk...

No idea how long it will take, but it's serious so it's on top of the todo list.

Does it need to play video?

[dom]

What I'm not clear about is how the new architecture interacts with the hardware..
The frames per second performance of that example is not what would have expected, which leads me to think it isn't using the hardware to
got the openGLES rendering but is using slower arm side "new" stuff ?.

What resolution are you running and what framerate are you seeing?
I'm seeing about 24fps at 1080p.

That will be using hardware. For every pixel it is calculating

Code: Select all

vec4( 1., 0.9, 0.7, 1.0 ) *     \
        cos( 30.*sqrt(pos.x*pos.x + 1.5*pos.y*pos.y)   \
             + atan(pos.y,pos.x) - phase );

which is a *lot* of trig operations per second.

[HiassofT]

I was using and adapter then used a cable from Sony 4K camcorder in both cases it does 4K 30 at most, I know is not the cable or the adapter, in any case I went with 1080p 60 and the experience was not good at all

What kind of TV are you using?

I ran into a similar issue when testing LibreELEC on my LG 55C8 last week. 6by9 provided a last minute firmware fix that's included in LibreELEC but probably didn't make it into Raspbian. The fix should be included in lastest rpi-update firmware though.

A simple workaround was to enable the "HDMI ULTRA HD Deep Colour" option in my TV's settings, that made 4kp60 output working. Check if you have a similar option on your TV (could also be labeled HDR or something similar), this may be easier and safer than testing with rpi-update kernels/firmwares.

so long,

Hias

[PeterO]

What I'm not clear about is how the new architecture interacts with the hardware..
The frames per second performance of that example is not what would have expected, which leads me to think it isn't using the hardware to
got the openGLES rendering but is using slower arm side "new" stuff ?.

What resolution are you running and what framerate are you seeing?
I'm seeing about 24fps at 1080p.

That's odd, I'm seeing ~50fps. I converted it into C (I don't do C++) but had to add -I/opt/vc/include so gcc could find gl2.h
But it then goes on to link with libGLES2.so from /usr/lib/gnueabihf/libGLESv2.so

The c++ version wont compile as it complains about a couple of things...

Code: Select all

test.cc: In function ‘int main()’:
test.cc:287:62: error: invalid conversion from ‘Window’ {aka ‘long unsigned int’} to ‘EGLNativeWindowType’ {aka ‘void*’} [-fpermissive]
    egl_surface = eglCreateWindowSurface ( egl_display, ecfg, win, NULL );
                                                              ^~~
In file included from test.cc:22:
/opt/vc/include/EGL/egl.h:266:27: note:   initializing argument 3 of ‘void* eglCreateWindowSurface(EGLDisplay, EGLConfig, EGLNativeWindowType, const EGLint*)’
       EGLNativeWindowType win,
       ~~~~~~~~~~~~~~~~~~~~^~~

What did you do to get it to compile ?

That will be using hardware. For every pixel it is calculating

Code: Select all

vec4( 1., 0.9, 0.7, 1.0 ) *     \
        cos( 30.*sqrt(pos.x*pos.x + 1.5*pos.y*pos.y)   \
             + atan(pos.y,pos.x) - phase );

which is a *lot* of trig operations per second.

I didn't look at the shader code so I didn't realise it was quite so maths heavy !

PeterO

PS: Maybe we should take this over to the graphics programming/OpenGLES forum ?

[DarkPlatinum]

There are some known issues with chromium which will be resolved. The video and WebGL performance you get out of it will improve greatly. It's currently running with --disable-gpu to work around a more serious issue.

Do you know how long this may take? My boss wants to run a chromium kiosk...

No idea how long it will take, but it's serious so it's on top of the todo list.

Does it need to play video?

It is running javascript constantly. It shows the current time as well as a countdown until a next event as well as a slideshow. Basically, need to run that code.

[dom]

PS: Maybe we should take this over to the graphics programming/OpenGLES forum ?

Yep.

[DavidS]

While it will likely be years before I have the money for a 4K monitor, I am still looking forward to getting my hands on a 2GB RPi 4B. As soon as ROOL anounces a beta release for the RPi 4B I will be ordering one (need an OS to go with the HW). This should be truly impressive to test the new SMP support in RISC OS on (the RPi 3B is already almost too fast).

And I will be saving a couple milli-amps from not using WiFi at all (RISC OS means wired connection [means Vonets VAP11G bridge to access WiFi networks]).

I am very much looking forward to learning a lot about the new RPi, once there is a primary OS for it (*n*x is a secondary, always). I am especially looking forward to learning the changes in initialization and HW access with bare metal programming, that is always fun .

To the entire team of people behind the new RPi 4, I add my thanks for an extreme upgrade (I think a greater move than was the move from the Cortex-A7 RPi 2B to the Cortex A53 based RPi 3B, and the 3B to 4B upgrade is less likely to break any binary software [no change in the core AARCH32 ISA this time (the 2b to 3B upgrade broke everything with a SWP instruction)]).

[asandford]

Only SATA port is missing.

No it isn't. Missing would imply it should be there. It shouldn't. No need for it. USB3 is fine, and there isn't space on the board for the connector anyway. If you want SATA use a USB3->SATA adapter.

OK, then an official USB3->SATA adapter would be good accessory. With SATA+Power connectors powered by USB3. Also the official box may include screw holes for HDD/SSD externally attached at bottom or on top (plus appropriate shape). I think it is not normal to expect 4GB Pi to run with SD card instead of HDD.

You'll need to externally power the HDD/SSD as the current is limited (in my setup, a 3A PSU won't supply enough current for a Crucial SSD to happily boot from (/boot on SD, / on SSD)). The SSD is rated at 1.7A.

I've also tested a few USB3->SATA adapters with mixed results.

Here's what I'm getting on a 4GB Pi4:

Code: Select all

root@raspberrypi:~# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   1780 MB in  2.00 seconds = 890.04 MB/sec
 Timing buffered disk reads: 1106 MB in  3.00 seconds = 368.16 MB/sec
root@raspberrypi:~#

Code: Select all

root@raspberrypi:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       220G  6.1G  202G   3% /
devtmpfs        1.8G     0  1.8G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  8.6M  1.9G   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   40M  213M  16% /boot
tmpfs           386M     0  386M   0% /run/user/1000
root@raspberrypi:~#

[noggin]

I was using and adapter then used a cable from Sony 4K camcorder in both cases it does 4K 30 at most, I know is not the cable or the adapter, in any case I went with 1080p 60 and the experience was not good at all

What kind of TV are you using?

I ran into a similar issue when testing LibreELEC on my LG 55C8 last week. 6by9 provided a last minute firmware fix that's included in LibreELEC but probably didn't make it into Raspbian. The fix should be included in lastest rpi-update firmware though.

A simple workaround was to enable the "HDMI ULTRA HD Deep Colour" option in my TV's settings, that made 4kp60 output working. Check if you have a similar option on your TV (could also be labeled HDR or something similar), this may be easier and safer than testing with rpi-update kernels/firmwares.

so long,

Hias

Aah... This sounds like a clash of HDMI 2.0 flavours...

Some TVs that can run at 4K60 only accept 4K60 (aka 2160p60) in 4:2:0 8-bit mode, and won't accept the higher bandwidth 2160p60 4:2:2 or 4:4:4 (or RGB) variants (or higher bit-depth 4:2:0) This is because 4K60 4:2:0 8-bit mode just squeaks into the older HDMI 1.4b bandwidth, and doesn't need full HDMI 2.0 high bandwidth support. This limitation is often the case with older, non-HDR displays.

Newer displays with HDMI 2.0 2160p60 HDR support will usually support the higher bandwidth modes such as 4:2:2 12-bit (there isn't a 4:2:2 10-bit option in HDMI 2.0) or 4:2:0 10-bit or 12-bit - which are required for decent quality 10-bit HDR (and also add 4:4:4 and RGB 8-bit support)

Confusingly some TVs have a mix of HDMI functionality depending on the HDMI port, and also often this HDMI 'Enhanced' or similar mode has to be enabled (and isn't enabled by default). Also if you route through an AVR this will also need to have HDMI Enhanced mode, or similar, enabled too.

My Sony 2018 UHD HDR model supports full 2160p60 4:2:2 12-bit inputs on 2 of its HDMI inputs (when you enabled HDMI Enhanced mode in the TV), but only supports 2160p60 4:2:0 8-bit on the other 2 HDMI inputs. My Denon AVR also supports HDMI Enhanced - but both the TV and AVR need to have it enabled.

If the Pi4B is outputting 4:2:2 (which is a 12-bit-only format at 2160p60), 4:4:4 or RGB 8-bit, or 4:2:0 at higher bit depths than 8-bits then some TVs may not be happy, whilst others may need to be switched into an 'Enhanced HDMI' mode.

[chithanh]

Thank you for raising the bar again what kind of computing hardware you can buy for $35.
And setting the new reference for $45 and $55 too.

Any chance it supports DisplayPort over USB-C?

No, USB2.0 OTG only.

This is understandable given the low price point.

But I would like to kindly ask you to strongly consider going back to a full-size HDMI connector, and USB-C 3.0 with DisplayPort for a future Raspberry Pi (model 4B+?🥺), if at all possible. Single cable USB-C for power/data/display is now becoming the norm in smartphones and notebooks (even cheap Chromebooks), and having this for the RPi would be fantastic.

But even so, you will probably sell loads of these, congratulations! (Should have produced more of the 4 GB model though, it is out of stock everywhere.)

[leilei]

One thing I've been wondering: Can we get any more information on the expected computational capabilities and performance difference of the VC6 GPU compared to the VC4? I don't think I've seen anything concrete, except for one benchmark (OpenArena). Or do we simply need to wait for benchmarks to start coming in?

I'm also curious on the GPU benchmark front too. OpenArena is not a good benchmark as it's all fixed function GL 1.1+SDL1.2 with the assets not made with GLES in mind so there's a lot of texture switching overhead - a major critical bug that eternally burdens myself.

I'd give suggestions for appropriate benchmark choices, but unfortunately I don't know of anything that supports EGL in the repos besides Minecraft Pi Edition.

[Gavinmc42]

Should have produced more of the 4 GB model though, it is out of stock everywhere.)

I suspect the 4B4 is also more attractive for some users too, especially as a replacement for those that are currently happy with older PC's.
Two 4B4's will cut my home computing power bills

For OpenGL testing I have been using Gentoo64 and the mesa examples.
https://gitlab.freedesktop.org/mesa/demos
How does the new Raspbian Buster compare, let you know later, Pi4 arrives today

I can now start doing some serious OpenGL learning and coding

[6by9]

I ran into a similar issue when testing LibreELEC on my LG 55C8 last week. 6by9 provided a last minute firmware fix that's included in LibreELEC but probably didn't make it into Raspbian. The fix should be included in lastest rpi-update firmware though.

A simple workaround was to enable the "HDMI ULTRA HD Deep Colour" option in my TV's settings, that made 4kp60 output working. Check if you have a similar option on your TV (could also be labeled HDR or something similar), this may be easier and safer than testing with rpi-update kernels/firmwares.

Aah... This sounds like a clash of HDMI 2.0 flavours...

Some TVs that can run at 4K60 only accept 4K60 (aka 2160p60) in 4:2:0 8-bit mode, and won't accept the higher bandwidth 2160p60 4:2:2 or 4:4:4 (or RGB) variants (or higher bit-depth 4:2:0) This is because 4K60 4:2:0 8-bit mode just squeaks into the older HDMI 1.4b bandwidth, and doesn't need full HDMI 2.0 high bandwidth support. This limitation is often the case with older, non-HDR displays.

Newer displays with HDMI 2.0 2160p60 HDR support will usually support the higher bandwidth modes such as 4:2:2 12-bit (there isn't a 4:2:2 10-bit option in HDMI 2.0) or 4:2:0 10-bit or 12-bit - which are required for decent quality 10-bit HDR (and also add 4:4:4 and RGB 8-bit support)

Confusingly some TVs have a mix of HDMI functionality depending on the HDMI port, and also often this HDMI 'Enhanced' or similar mode has to be enabled (and isn't enabled by default). Also if you route through an AVR this will also need to have HDMI Enhanced mode, or similar, enabled too.

My Sony 2018 UHD HDR model supports full 2160p60 4:2:2 12-bit inputs on 2 of its HDMI inputs (when you enabled HDMI Enhanced mode in the TV), but only supports 2160p60 4:2:0 8-bit on the other 2 HDMI inputs. My Denon AVR also supports HDMI Enhanced - but both the TV and AVR need to have it enabled.

If the Pi4B is outputting 4:2:2 (which is a 12-bit-only format at 2160p60), 4:4:4 or RGB 8-bit, or 4:2:0 at higher bit depths than 8-bits then some TVs may not be happy, whilst others may need to be switched into an 'Enhanced HDMI' mode.

Yes, the firmware wasn't parsing the "YCbCr420_only" extended block of the EDID, so was seeing 3840x2160@60 in the detailed timings but then not filtering it out due to being YCbCr420 (which currently isn't supported).

[jamesh]

One thing I've been wondering: Can we get any more information on the expected computational capabilities and performance difference of the VC6 GPU compared to the VC4? I don't think I've seen anything concrete, except for one benchmark (OpenArena). Or do we simply need to wait for benchmarks to start coming in?

I'm also curious on the GPU benchmark front too. OpenArena is not a good benchmark as it's all fixed function GL 1.1+SDL1.2 with the assets not made with GLES in mind so there's a lot of texture switching overhead - a major critical bug that eternally burdens myself.

I'd give suggestions for appropriate benchmark choices, but unfortunately I don't know of anything that supports EGL in the repos besides Minecraft Pi Edition.

It's about 4x faster than the VC4 (pixel rate IIRC). So you if you are running full screen 4k, then you get about the same frame rate as the older devices at 1080p.

[AlbertX]

The TV is a Samsung KS8000, that I have also connected to my PC and works without a problem using etiher 4:2:0, 4:2:2 or 4:4:4 all HDMI ports have deepcolor (HDR) enabled, which I don't see how that should affect the resolution.

Also connected to my 4K Elgato capture card, that works without a problem again with xbox one x and ps4 pro.

I wanted to make a video about it for my youtube channel, but glad it didn't work or it would have been a frustrated video.

I am not angry at rpi group or anything I am just frustrating that it feels the OS is not ready at least from my point of view is a little bit disappointing and I believe it should have been a smoother release is all.

[timg236]

I ran into a similar issue when testing LibreELEC on my LG 55C8 last week. 6by9 provided a last minute firmware fix that's included in LibreELEC but probably didn't make it into Raspbian. The fix should be included in lastest rpi-update firmware though.

A simple workaround was to enable the "HDMI ULTRA HD Deep Colour" option in my TV's settings, that made 4kp60 output working. Check if you have a similar option on your TV (could also be labeled HDR or something similar), this may be easier and safer than testing with rpi-update kernels/firmwares.

Aah... This sounds like a clash of HDMI 2.0 flavours...

Some TVs that can run at 4K60 only accept 4K60 (aka 2160p60) in 4:2:0 8-bit mode, and won't accept the higher bandwidth 2160p60 4:2:2 or 4:4:4 (or RGB) variants (or higher bit-depth 4:2:0) This is because 4K60 4:2:0 8-bit mode just squeaks into the older HDMI 1.4b bandwidth, and doesn't need full HDMI 2.0 high bandwidth support. This limitation is often the case with older, non-HDR displays.

Newer displays with HDMI 2.0 2160p60 HDR support will usually support the higher bandwidth modes such as 4:2:2 12-bit (there isn't a 4:2:2 10-bit option in HDMI 2.0) or 4:2:0 10-bit or 12-bit - which are required for decent quality 10-bit HDR (and also add 4:4:4 and RGB 8-bit support)

Confusingly some TVs have a mix of HDMI functionality depending on the HDMI port, and also often this HDMI 'Enhanced' or similar mode has to be enabled (and isn't enabled by default). Also if you route through an AVR this will also need to have HDMI Enhanced mode, or similar, enabled too.

My Sony 2018 UHD HDR model supports full 2160p60 4:2:2 12-bit inputs on 2 of its HDMI inputs (when you enabled HDMI Enhanced mode in the TV), but only supports 2160p60 4:2:0 8-bit on the other 2 HDMI inputs. My Denon AVR also supports HDMI Enhanced - but both the TV and AVR need to have it enabled.

If the Pi4B is outputting 4:2:2 (which is a 12-bit-only format at 2160p60), 4:4:4 or RGB 8-bit, or 4:2:0 at higher bit depths than 8-bits then some TVs may not be happy, whilst others may need to be switched into an 'Enhanced HDMI' mode.

Yes, the firmware wasn't parsing the "YCbCr420_only" extended block of the EDID, so was seeing 3840x2160@60 in the detailed timings but then not filtering it out due to being YCbCr420 (which currently isn't supported).

The HDMI hardware does not support YCbCr420. So for 4Kp60 deep colour YCbCr422 is the only option

[i486]

No it isn't. Missing would imply it should be there. It shouldn't. No need for it. USB3 is fine, and there isn't space on the board for the connector anyway. If you want SATA use a USB3->SATA adapter.

OK, then an official USB3->SATA adapter would be good accessory. With SATA+Power connectors powered by USB3. Also the official box may include screw holes for HDD/SSD externally attached at bottom or on top (plus appropriate shape). I think it is not normal to expect 4GB Pi to run with SD card instead of HDD.

You'll need to externally power the HDD/SSD as the current is limited (in my setup, a 3A PSU won't supply enough current for a Crucial SSD to happily boot from (/boot on SD, / on SSD)). The SSD is rated at 1.7A.

I agree for SSD - they have peaks in consumption. But for HDD the new 3A PSU has to be enough.

[noggin]

Yes, the firmware wasn't parsing the "YCbCr420_only" extended block of the EDID, so was seeing 3840x2160@60 in the detailed timings but then not filtering it out due to being YCbCr420 (which currently isn't supported).

I understand - HDMI 2.0 can be a minefield, particularly as 4:2:0 is only supported for 2160p50 and 2160p59.94/60 modes and isn't used for any other resolutions or frame rates (2160p30 and below use 4:4:4, 4:2:2 or RGB only)...

So currently what 4K60 (aka 2160p60) and 4K50 modes are supported, if 4:2:0 is currently not supported?

RGB 8-bit?
4:4:4 YCrCb 8-bit?
4:2:2 YCrCb 12-bit? (With 8-bit content?)

The lack of current 4:2:0 support is worth flagging for those who have earlier SDR-only UHD displays (My first Sony UHD TV was 4:2:0 8-bit only for 2160p50 and 2160p59.94/60 inputs)