Igalia Working Towards Faster 2D Rendering For Older Raspberry Pi Boards

[dragon321]

Maybe they should base their work on the Vulkan driver work mentioned earlier: https://www.phoronix.com/scan.php?pa...=RPi-VK-Driver

Raspberry Pi 1-3 GPU is not really capable of running Vulkan. So any implementation would be limited and not conformant. So probably there will be little interest of that. Especially when RPi 4 GPU is Vulkan capable.

[caligula]

I'm still using a Pi 2 for some light tasks and it holds up pretty well. But sadly it's too underpowered for even the lightest of the desktop environments...

That's odd. I've been using a 1080p desktop since 2007 or so using mid-range GPUs of that time. My old PC from 2001 could easily play Quake 3 @ 1280x1024 (Geforce 2 or 3). AFAIK RPi 1 & 2 can also play Quake 3. On RPi3 the FPS is 80 fps at 1080p: https://www.linuxadictos.com/en/rasp...i-100-fps.html

Basic desktop should be much less demanding than Quake 3. How is it possible that the board can run Quake 3 but not a basic desktop environment?

[hamishmb]

Back when it was new, people were saying the Pi 2 was quite good for basic web browsing, email, etc. I have a Pi 3 that seems to do that fairly well, not that I've tried much. I think it's probably decent.

[Quackdoc]

If that Pi dies, you should consider a Pi Zero W. I also have one and it works wonderfully well for those kinds of things.

im planning on getting one of them for a test bed I plan on buying a pi 2 zero w but both it and it's first generation are sold out on pishop, and im not sure of any other reputable companies in canada selling them at non exorbitant prices

[monkeynut]

im planning on getting one of them for a test bed I plan on buying a pi 2 zero w but both it and it's first generation are sold out on pishop, and im not sure of any other reputable companies in canada selling them at non exorbitant prices

I suppose this is why this work matters so much - keeping existing hardware useful whilst we have a shortage of new hardware. (I know the Pi Zero 2 uses this GPU anyway, though)

Maybe they should base their work on the Vulkan driver work mentioned earlier: https://www.phoronix.com/scan.php?pa...=RPi-VK-Driver

Reminds me of the MiniGL implementation on 3DFX Voodoo that became Glide, A specific, limited version purely for specific needs. You could call the Vulkan implementation on Pi0-3 "MiniVK" and keep it behind a flag for use on specific applications.

[blackshard]

That's odd. I've been using a 1080p desktop since 2007 or so using mid-range GPUs of that time. My old PC from 2001 could easily play Quake 3 @ 1280x1024 (Geforce 2 or 3). AFAIK RPi 1 & 2 can also play Quake 3. On RPi3 the FPS is 80 fps at 1080p: https://www.linuxadictos.com/en/rasp...i-100-fps.html

Basic desktop should be much less demanding than Quake 3. How is it possible that the board can run Quake 3 but not a basic desktop environment?

Mostly because the "basic desktop environment" is unoptimized and quake 3 is well optimized.

Taking back the "progress" comment of first page, I think many of people here maybe tried Windows 95 with sub-100MHz processors and ancient video cards with a 2 or 4 megabytes of memory: the experience was quite decent. Nowadays the same decent desktop experience can't be replicated with 1.5GHz processors, speedy video chips and gigabytes of DDR RAM. Yes, resolution went up (800x600 -> fullhd) and color bits per pixel also (16 bit -> 32 bit), but hardware resources went up much more.

[ssokolow]

If that Pi dies, you should consider a Pi Zero W. I also have one and it works wonderfully well for those kinds of things.

I'm planning to get one at some point for my paranoid approach to developing a SNES→Gameport adapter using one of those $1 STM8 boards.

(To protect the specific-model genune SoundBlaster 16 in my retro-computer from oopses, I intend my development setup to start as Cheap-enough-to-not-mourn-Chinese-SNES-controller → $1 STM8 → most-cheaply-replaceable-eBay'd-USB-Gameport-adapter → $2 Charger Doctor USB Volt/Amp meter → $12 USB Isolator → $13 Powered USB Hub → $12 USB Isolator → Inexpensive Pi Zero W -WiFi+SSH→ Expensive PC)

...possibly plugged into the GFCI+Breaker (AFCI+overcurrent if possible)+Emergency Shutoff Switch extension cord I've been meaning to build for testing new retro acquisitions.

[arQon]

Basic desktop should be much less demanding than Quake 3. How is it possible that the board can run Quake 3 but not a basic desktop environment?

The short, easy answer is "Because DE developers are a lot less skilled than id developers" - which is certainly true, but misses the point and doesn't actually answer the question.

The longer, much less soundbite-y answer is a lot more involved, and TBH I'm not sure I can explain it well enough for normal people to understand without running on for pages, but I'll try...

The root of the problem is residency. Yes, you're correct that 256MB is *far* more VRAM than the initial Q3-capable cards had (IIRC the TNT was 32MB, and that was the second-best card available at launch), and a DE is a far more trivial project. There are basically two reasons why Q3 "works" but a DE might not:

1) For the vast majority of cases, 100% of the textures used in any given frame in Q3 are already resident. If they *aren't*, they have to be uploaded to the card before they can be used (that's "at all", not "texturing from VRAM is faster than texturing from main memory", though that's changed in the years since). That upload is slower than literally *anything* else Tech3 does, by a *lot*. I don't remember the exact numbers any more, obviously, but needing even one upload of a 256x256 wall texture, for example, would bring the framerate from ~80 to ~30. It's just massively more "expensive" than you might think: all the BSP work, animations, preparing and submitting all the draws, etc etc - all of that *combined* takes less time than it does to upload one lousy texture. (To be clear, this isn't a failing in Tech3, it's just "how bus bandwidth works").

If you understand what swap is, this is basically exactly that, with all the problems that come with it. Once your texture set exhausts the VRAM, you not only have to pay to upload texture P, evicting texture A as a side-effect, but then also pay to *re-*upload A at the start of the next frame, evicting P again, and so on. The fact that you're "only" going from RAM to VRAM still doesn't make this any less of a "thrashing" case than it is when it's your SSD being destroyed by swap - you're basically screwed.

2) The driver is broken (or GLAMOR / the X server / etc is). While OGL works for exactly the case I just described (even if only slowly), whatever TF is going on with the Pi does not. I've read the Igalia post, and while it's not really clear *which* piece of the stack is broken, clearly at least one piece of it is. Possibly "just" because of design choices, but either way you end up at the same place: *something* has to manage the memory use properly, and that piece is currently missing.

So, how does a compositor work? Basically, each program just draws into textures rather than "the screen", then the compositor uploads those textures and shoves them into the framebuffer at the right locations and (pseudo-)depth, and everything's great. But, remember how slow those uploads are? If you only need to update e.g. an xterm window, things will be okay even on something as slow as the Pi, but there are some fairly large problems that become apparent very quickly:
* A 1080p display is 8MB of VRAM, which is a lot larger than any Q3 texture.
* You need either enough VRAM for the buffers for *all* your programs, or you need a compositor that isn't braindead.
* Potentially, you're looking at multiple nearly-screensize windows all needing to upload those large textures at the same time, for lots of frames in a row.

Those problems *can* be worked around fairly easily, but it takes time. What makes it worse though is:
* Programs will also have their own icons etc, which will also be occupying a chunk of that limited VRAM.
* Web browsers etc in particular will also have "real" images that they will also be trying to shove into VRAM.
* The Pi's "video card" has additional requirements that sources are in a Special Magic sort of buffer that, basically, is of a fixed size, which means bonus headaches when a window is resized etc.

Again, these are still soluble problems - but the more you thrash the VRAM, the worse your performance gets, until you go from FPS to SPF.
Note that the compositor itself just makes things worse rather than being a key part of the problem, so abandoning that in favor of unbuffered output doesn't really do anything more than buy you a little bit more breathing room. Ultimately, you need to have the final result available to present at a single point in time, regardless of how you get there.

[degasus]

I think what really changed here compared to 20 years ago are the applications. They are optimized to perform well on current systems, not on those GPUs 20 years ago.
The example in the blog post is chrome. It saves the final image of all open tabs in a pre-rendered texture, which shall be GPU accessable. On modern GPUs, this might be still on main memory and not on the GPU. However on old GPUs, it has to be on VRAM. 20 years ago, only the main framebuffer of the DE was keeped in VRAM. And only the part of each window, which was shown, was actually rendered and stored. Compositors were known for increasing the GPU requirements a lot.

But I think there is something which is broken in the system: Why does the DE crash if an application requests too much VRAM? That's a direct outcome of X11 server side rendering. So let's switch to wayland (without xwayland), so only the applications might crash.

[coder]

On the contrary, GPUs on the raspberry pi, especially the first Pi1, are the working horse of the whole platform.
Of course they are now aging, but in 2012 and for some years those GPUs (and the whole compositor/GPU/VPU compound) were quite extraordinary in respect to the competitors, either in terms of computational capacity per watt and features.

This is not accurate. I don't know where you get this BS, but the Pi's GPUs were never competitive.