A NVIDIA Engineer In His Spare Time Wrote A Vulkan Driver That Works On Older Raspberry Pi

[Alexmitter]

Haha. True. However so is Wayland and yet even in the recent benchmarks the performance isn't any better than standard Xorg.

Powerful machines eat up the fps difference. When it comes to aarch64 phones and notebooks, a new class of devices highly anticipated in the community, Wayland makes a giant difference. On a powerful machine, you get the other goodies like better input latency, better draw latency, better controlling over the frame drawing so driver side buffering is not needed anymore. FPS is not anything and hopefully no one was expecting his in Xwayland running games to perform drastically better.

All that is really important to see is that Xwayland performs well, and it does. So it does not matter anyways if your desktop runs on Xorg or Wayland. Your stuff just works(expect you are on KDE, but then you have bigger issues then adopting a modern display server). Its not like you will miss anything.

[CochainComplex]

NVidia? Not really apparently (truly hope they will prove us wrong soon though). Developers working for NVidia, are certainly able though

I know ...but it is like with dogs just give them some goodie and they will eventually continue with their good behaviour

[pal666]

It also shows that there are some briliant software engieers at nVidia who are handicapped in what they can do.

he was imagination tech engineer while writing this, he very recently switched to novideo

[pal666]

So Nvidia is able to do open drivers

no, that was imagination tech(and they have open source positions), see my prev comment

[pal666]

However so is Wayland

only in fantasy worlds of people who are unable to learn

[andrei_me]

Rob Clarke making the Etnaviv (Qualcomm Vivante) driver while being employed by TI.

Almost right, some fixes:
Clark, without e
Freedreno ( Qualcomm Adreno)

But yeah, I remember back then, when radeonSI was slower than r600

[s_j_newbury]

Haha. True. However so is Wayland and yet even in the recent benchmarks the performance isn't any better than standard Xorg.

Why can't a certain subset of readers understand the "Wayland" benchmarks Michael does are Xwayland benchmarks since it's still the default unless you specifically opt-in with env vars or compile-time. This used to be useful when Xwayland performance was improving against plain Xorg and little software worked with Wayland natively. Now though, Xwayland has little overhead (except in RAM) and pretty much anything recent has a working Wayland backend, especially GNOME apps.

Michael really needs to start benchmarking native Wayland to put this to rest.

[kpedersen]

Michael really needs to start benchmarking native Wayland to put this to rest.

Well I do want to support X11 software. Wayland was still *meant* to be a faster backend to X11 software too. It was meant to be faster than much of the underlying Xorg machinery.

If he was to do a comparison that you think is fair, it would be between Wayland and a strange mashup of Xorg which has the protocol layer stripped and just the backend rendering directly surely?

Anyway, I don't want to derail this conversation, sorry for the noise

[Raka555]

So....can we get a driver that can do the following?:

1) Run GNOME 3 fast enough to be usable. Even if you don't use it, it's a good benchmark to follow. A lowly Gemini Lake Celeron dual-core can run it just fine. A Pi should be able to as well. It doesn't even have the eye-candy of Vista's Aero (which is almost 14 years old), yet there really aren't any production-ready ARM SoC GPU drivers that can run it decently.**
2) Provide video acceleration across the board using standard libraries, from the UI (see above) to all web video, like YouTube, without specially-optimized software (like weird offline video players) or browser plugins.

**I've read that the RK3399 chips have some kind of driver that is somewhat serviceable, but there are no ARM board makers or system sellers that are recommending that it can be used for GNOME 3 daily driver, and that's pretty telling.

So much of this stuff is just hardware companies throwing out ARM chips with IP-locked-up GPU's that won't create Linux drivers, and then it's up to someone in the Linux community to reverse engineer the hardware. It's a big problem for Linux, but ARM just doesn't really care about it at all. ARM is built around IP - it's how ARM Holdings make their money. ARM is ultimately built for Android, where Google and hardware companies don't have to comply with GPL restrictions, which is toxic about the concept of IP.

I agree with you, but I am not so sure the gnome performance problems on RPI is down to GPU drivers.
My take on it is that gnome is just so bloated that it thrashes the CPU cache on most RPIs.

If you haven't played around with RISC-OS on the RPI, just give it a try to see what can be achieved, and that is without any GPU acceleration.
The GUI's feel extreme fast and responsive.

Edit:
You want to see the "gnome 3 test" for testing GPU drivers.
I want to see the "RPI test" for testing software in general...

[coder]

a driver for hardware without readily available docs.

Really? I though the Pi Foundation got Broadcom to open the specs on VideoCore.