i486
Posts: 172
Joined: Sun Aug 28, 2016 3:41 pm
Location: BG

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 6:01 pm

jamesh wrote:
Tue Jun 25, 2019 2:01 pm
i486 wrote:
Tue Jun 25, 2019 1:43 pm
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.

AlbertX
Posts: 4
Joined: Tue Jun 25, 2019 5:32 pm

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 6:06 pm

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.

AS I mentioned there were different weird things happening, chromium any youtube video was slow with tearing and I could no select 4K youtube video at all only 1080p even for videos I know are 4K.

Using it as a Desktop is not my goal, but I expected a "smoother" experience

rhcev6
Posts: 1
Joined: Tue Jun 25, 2019 6:45 pm

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 6:52 pm

jdb wrote:
Tue Jun 25, 2019 5:16 pm
W. H. Heydt wrote:
Tue Jun 25, 2019 4:52 pm
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. :-D

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5789
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 6:55 pm

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
Posts: 7
Joined: Wed May 11, 2016 8:35 pm

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 7:01 pm

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

User avatar
PeterO
Posts: 4882
Joined: Sun Jul 22, 2012 4:14 pm

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 7:04 pm

PeterO wrote:
Tue Jun 25, 2019 1:12 pm
dom wrote:
Tue Jun 25, 2019 1:01 pm
PeterO wrote:
Tue Jun 25, 2019 12:28 pm
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. 8-)
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
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

wh7qq
Posts: 1299
Joined: Thu Oct 09, 2014 2:50 am

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 7:18 pm

W. H. Heydt wrote:
Tue Jun 25, 2019 4:49 pm
jbudd wrote:
Tue Jun 25, 2019 4:07 pm
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).
Last edited by wh7qq on Tue Jun 25, 2019 7:53 pm, edited 1 time in total.

User avatar
DarkPlatinum
Posts: 839
Joined: Thu Nov 02, 2017 2:30 pm
Location: Unknown
Contact: Website YouTube

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 7:25 pm

ShiftPlusOne wrote:
Tue Jun 25, 2019 6:55 pm
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...
1 * Raspberry Pi Zero W, 1 * Raspberry Pi 2, 1 * Raspberry Pi 3 1 * Raspberry Pi 3B + :mrgreen:

Check Out My Raspberry Site (Run on a Raspberry Pi 3B :) ): https://html.dynu.net

W. H. Heydt
Posts: 10603
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 7:30 pm

wh7qq wrote:
Tue Jun 25, 2019 7:18 pm
W. H. Heydt wrote:
Tue Jun 25, 2019 4:49 pm
jbudd wrote:
Tue Jun 25, 2019 4:07 pm
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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5789
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 7:40 pm

DarkPlatinum wrote:
Tue Jun 25, 2019 7:25 pm
ShiftPlusOne wrote:
Tue Jun 25, 2019 6:55 pm
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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5287
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 7:46 pm

PeterO wrote:
Tue Jun 25, 2019 7:04 pm
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
Posts: 201
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 8:04 pm

AlbertX wrote:
Tue Jun 25, 2019 6:06 pm
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

User avatar
PeterO
Posts: 4882
Joined: Sun Jul 22, 2012 4:14 pm

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 8:09 pm

dom wrote:
Tue Jun 25, 2019 7:46 pm
PeterO wrote:
Tue Jun 25, 2019 7:04 pm
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 ?
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
DarkPlatinum
Posts: 839
Joined: Thu Nov 02, 2017 2:30 pm
Location: Unknown
Contact: Website YouTube

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 8:18 pm

ShiftPlusOne wrote:
Tue Jun 25, 2019 7:40 pm
DarkPlatinum wrote:
Tue Jun 25, 2019 7:25 pm
ShiftPlusOne wrote:
Tue Jun 25, 2019 6:55 pm
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.
1 * Raspberry Pi Zero W, 1 * Raspberry Pi 2, 1 * Raspberry Pi 3 1 * Raspberry Pi 3B + :mrgreen:

Check Out My Raspberry Site (Run on a Raspberry Pi 3B :) ): https://html.dynu.net

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5287
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 8:22 pm

PeterO wrote:
Tue Jun 25, 2019 8:09 pm
PS: Maybe we should take this over to the graphics programming/OpenGLES forum ?
Yep.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 8:28 pm

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)]).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

asandford
Posts: 1997
Joined: Mon Dec 31, 2012 12:54 pm
Location: Waterlooville

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 9:13 pm

i486 wrote:
Tue Jun 25, 2019 6:01 pm
jamesh wrote:
Tue Jun 25, 2019 2:01 pm
i486 wrote:
Tue Jun 25, 2019 1:43 pm
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
Posts: 98
Joined: Sun Feb 21, 2016 1:55 pm

Re: Raspberry Pi 4 Thread - general discussion

Tue Jun 25, 2019 11:46 pm

HiassofT wrote:
Tue Jun 25, 2019 8:04 pm
AlbertX wrote:
Tue Jun 25, 2019 6:06 pm
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
Posts: 13
Joined: Wed Jun 26, 2019 1:39 am

Re: Raspberry Pi 4 Thread - general discussion

Wed Jun 26, 2019 2:06 am

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.
jdb wrote:
Mon Jun 24, 2019 10:50 am
smed wrote:
Mon Jun 24, 2019 10:49 am
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.)

User avatar
leilei
Posts: 17
Joined: Wed Jun 26, 2019 2:26 am

Re: Raspberry Pi 4 Thread - general discussion

Wed Jun 26, 2019 2:30 am

Mikael wrote:
Tue Jun 25, 2019 1:43 pm
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. :(

User avatar
Gavinmc42
Posts: 3455
Joined: Wed Aug 28, 2013 3:31 am

Re: Raspberry Pi 4 Thread - general discussion

Wed Jun 26, 2019 3:53 am

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 :D

I can now start doing some serious OpenGL learning and coding :D
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7025
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspberry Pi 4 Thread - general discussion

Wed Jun 26, 2019 7:01 am

noggin wrote:
Tue Jun 25, 2019 11:46 pm
HiassofT wrote:
Tue Jun 25, 2019 8:04 pm
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).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: Raspberry Pi 4 Thread - general discussion

Wed Jun 26, 2019 7:39 am

leilei wrote:
Wed Jun 26, 2019 2:30 am
Mikael wrote:
Tue Jun 25, 2019 1:43 pm
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.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

AlbertX
Posts: 4
Joined: Tue Jun 25, 2019 5:32 pm

Re: Raspberry Pi 4 Thread - general discussion

Wed Jun 26, 2019 7:43 am

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 121
Joined: Thu Jun 21, 2018 4:30 pm

Re: Raspberry Pi 4 Thread - general discussion

Wed Jun 26, 2019 7:44 am

6by9 wrote:
Wed Jun 26, 2019 7:01 am
noggin wrote:
Tue Jun 25, 2019 11:46 pm
HiassofT wrote:
Tue Jun 25, 2019 8:04 pm
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

Return to “General discussion”