Open-Source Raspberry Pi Graphics Drivers Add Double Buffer Mode

[qarium]

Because Apple did it.
The Mac mini only consumes 30W while having similar single-thread performance as a 9900K.
As much as I hate saying that...

remember the M1 apple presentation ?... apple did show linux. (of course in a VM but still free advertisment for linux)
at that time i did see some secret backchannel info go from the apple people to the linux people and back...

i think as soon as the M1 driver in linux is in a good status apple will enter the linux market with the M1 SOC...

no maybe not for consumers but for the server market and also other SOC Embedded System markets..

[anarsoul]

You should also consider that 10 years ago 1080p was a high-end display and most laptops were shipped with 768p.

1366x768@60Hz needs 180 MB/s of memory bandwidth for scanout in worst case (if there's no framebuffer compression), while 1920x1080@60Hz needs 355 MB/s. Also modern desktop environments tend to copy it at least once, so it's up to 180*4 = 720 MB/s and 355 * 4 = 1420 MB/s respectively. It's x4 here because you need to write it out initially, read it back from 1st copy, write it back to 2nd copy, scan it out. Copies are expensive.

[sykobee]

I have a Raspberry PI 4b 4GB.

I thought it was a good idea but graphics performance in 64 bit mode is disappointing.

The GPU in the Pi 4 is not much of an upgrade (given the time span) over the first Pi nearly a decade ago. It's not been the focus of improvements unlike the CPUs. It's 2-3x as fast, you'd be expecting 10-20x faster in that timeframe, very roughly.

But that's one of the tradeoffs to get a very cheap SBC. Cheap means older 28nm process, cheaper older ARM A72 cores, small GPU, small SoC with narrow memory bus.

And even if they have a new SoC ready to go for the Pi 5, it may be getting delayed because fab space is at a massive premium right now. Now hopefully this new SoC if it comes out this year will have A76 cores and at least 4x the GPU cores on a 12nm process, but who knows what the restrictions are for the design.

[kiffmet]

What I find very disappointing about the Pi4 is the state of video playback acceleration. There is still no VAAPI interface, which is simply unacceptable nowadays, especially since the Pi4 by far isn't a new product anymore and VAAPI is the most widely supported de-facto standard. Instead stuff like Chrome, ffmpeg, Kodi, etc. all need to be patched to support the Pi4. This makes running any distro that is not Raspbian rather cumbersome and screws you over once you need packages that are newer or not available in Debian.

When Allwinner and Rockchip manage to provide VAAPI, why doesn't the Pi Foundation?

[Quackdoc]

What I find very disappointing about the Pi4 is the state of video playback acceleration. There is still no VAAPI interface, which is simply unacceptable nowadays, especially since the Pi4 by far isn't a new product anymore and VAAPI is the most widely supported de-facto standard. Instead stuff like Chrome, ffmpeg, Kodi, etc. all need to be patched to support the Pi4. This makes running any distro that is not Raspbian rather cumbersome and screws you over once you need packages that are newer or not available in Debian.

When Allwinner and Rockchip manage to provide VAAPI, why doesn't the Pi Foundation?

it would be up to broadcom to support vaapi, not pi foundation. (though they could sponsor work on it I suppose) but it does support OMX video decode, which means most libav programs should work with it.

I would not call vaapi the defacto standard. maybe on linux itself it is. but that hardly makes it defacto

[Holadavid]

Raspberry Pi is not in a race to bottom for a modern cpu/gpu. They could release a 28nm Pi 5 with an in house designed basic GPU, inefficient and weak yet open and documented as their Pico nano. SBCs main problems are poor support, blobs and usually restricted to old kernels as in the Nvidia Jetson nano. It has to be affordable and supported, not necessarily powerful.

[coder]

Anyway, 2 channels of 64-bit DDR3 1600 MT/s has bandwidth of 1600 * 64 * 2 / 8 = 25600 MB/s (it would be 12800 MB/s via single channel)

While 1 channel of 32-bit DDR4 2400 MT/s has bandwidth of 2400 * 32 / 8 = 9600 MB/s.

According to Wikipedia, R. Pi v4 has LPDDR4-3200, which is where I got ~13 GB/s.

[kiffmet]

Quackdoc ffmpeg, vlc, mpv, firefox, chrome, gstreamer, Kodi, Kdenlive, OBS, etc. do all support VAAPI, so yes, on Linux it is the de-facto standard as in "that's what the most relevant programs/libraries support". Kodi has dropped all Pi specific code because the project doesn't want the additional maintenance burden.
OMX support is poor and often requires out-of-tree patches, the same goes for decoding via V4L2/mmal. Since the patches are often tied to specific versions of these libraries, the situation effectively limits the number of distros, which are able to provide some form of video decoding acceleration at all, and even then it works rather poorly because it's a hackjob.

[coder]

i think as soon as the M1 driver in linux is in a good status apple will enter the linux market with the M1 SOC...

no maybe not for consumers but for the server market and also other SOC Embedded System markets..

I don't agree with this, at all. They might want Linux to work in a VM, for the benefit of those users who need to work in Linux, but Apple doesn't really have much to gain from getting into the pure hardware business.

Furthermore, their chips would be very expensive in embedded markets, and don't scale well enough to be compelling server options.

[coder]

You should also consider that 10 years ago 1080p was a high-end display and most laptops were shipped with 768p.

Heh, in Dec 2004, I got a 15.4" laptop with 1920x1200. I kept that laptop way too long, because of it. I even tried upgrading the CPU, but the result was underwhelming.

Also modern desktop environments tend to copy it at least once,

Perhaps for parts they're updating, but your computations seem to assume full-screen updates on every scanout.