
A Nvidia Engineer Wrote a Vulkan Driver That Works on Older Raspberry Pi - reddotX
https://www.phoronix.com/scan.php?page=news_item&px=RPi-VK-Driver
======
pcwalton
A few years back I wrote an N64 emulator graphics module for the Raspberry Pi
because I was unhappy with the poor performance of the existing ones and I
would have _really_ wanted this. Drawcall overhead for Broadcom's official
drivers is extreme: you can't have more than a single-digit number of
drawcalls per frame and still maintain 60 FPS. I ended up having to go to
ubershaders for everything just to maintain 30 FPS. I'm certain the hardware
was capable of much more, but the drivers were holding it back.

~~~
mobilio
This is one of RPi limitation - closed source firmware and drivers. But
hardware is much better...

~~~
dividuum
Only partially true on the Pi4: The complete OpenGL stack is now open source
using Mesa (it was optional on previous models). Video decoding is slowly
moving over from the closed MMAL stack to KMS and V4L2. The boot firmware is
still closed though.

~~~
messe
> The boot firmware is still closed though.

Not much worse than a PC then in that regard.

~~~
mobilio
UPDATE - mine fault. CPU doesn't have AES instructions!

Actually it is.

For example some RPi CPUs have AES acceleration instructions built similar as
AES-NI on x86. But due firmware limit we can't use them.

Probably it's licensing and pricing issue...

~~~
messe
I looked it up. That's not true. The hardware isn't there, and would require
the RPi foundation purchase a license to implement.

See the engineer reply in this thread:

[https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=2078...](https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=207888)

> That is licence for the HW, so you buy it then add the requisite HW to the
> die, so no, it cannot be added later without redeisgning the HW, which would
> cost about $1M Plus the licence....

~~~
messe
Can't edit my own post, but please stop downvoting mobilio. They admitted they
were wrong, and there's no shame in that.

Even if they had been wrong, they shouldn't necessarily have been downvoted,
because it still ended up adding to the discussion.

------
Abishek_Muthian
Excellent effort.

I wonder whether there will compositor support this driver, to take advantage
in the desktop environment. I had made several attempts to get a smoother
desktop experience[1] on RPi 3 -

•LXDE + Openbox on Raspbian + X server

•Xfce4 + VC4 + X server + Arch Linux ARM + USB SSD

•Enlightenment + Wayland + Arch Linux ARM + USB SSD

Although Elightenment on Wayland with OpenGL was the smoothest of them all,
it's not usable(frequent crashes with RPi) and since the frame buffer was
limited to 2048x2048 none of them supported my 2560x1080 monitor.

Xfce4 + VC4 on Arch Linux is more usable, but is still not as stable as
default Raspbian. I didn't see any productivity merits in continuing this
adventure and decided to reclaim the memory from GPU to revert into
headless[Arch+SSD] for a motion eye setup processing 3 720p camera streams
simultaneously with average of ~ 50% CPU on all 4 cores when not watching the
feed live(but motion active).

[1][https://abishekmuthian.com/getting-smoother-desktop-
experien...](https://abishekmuthian.com/getting-smoother-desktop-experience-
on-raspberry-pi/)

~~~
mmm_grayons
I found arch to be quite stable on mine, though I didn't use a desktop most of
the time. When I did, i3 was by far the fastest, so maybe give that a try.

~~~
Abishek_Muthian
I agree reg Arch ARM, may it's just VC4 that's causing the issue in desktop
environment. I'll give i3 a try if I pursue this, but IMHO RPi < Pi4 are best
suited for headless operations.

------
jeroenhd
Very nice, this can speed up some of the old Pis still hanging around quite
significantly if software authors start making use of Vulkan on ARM.

I wonder how Nvidia is looking at this with their terrible anti-open source
mindset. I hooe an engineer of theirs with experience from their company
writing a video driver doesn't get the author any repercussions.

~~~
int_19h
Not just old - this also supports Zero and Zero W, which are in a category of
their own.

------
tosh
repo: [https://github.com/Yours3lf/rpi-vk-
driver](https://github.com/Yours3lf/rpi-vk-driver)

------
ensiferum
Just makes me wonder whether there could be any conflict of interest here and
who owns the copyright. I know some of the big corps assume ownership of
whatever their employees produce even outside working hours. Or Maybe the
project was signed off ?

------
squarefoot
Any chances to see something similar ported to older Mali GPUs such as the
ones contained in lower end Allwinner ARM SOCs? So far it seems only newer
ones are (officially) supported.
[https://developer.arm.com/solutions/graphics-and-
gaming/apis...](https://developer.arm.com/solutions/graphics-and-
gaming/apis/vulkan)

------
dheera
How hard would it be to reverse engineer CUDA and make something like WINE
that translates all CUDA operations into OpenCL or directly into third-party
GPU instructions?

Obviously wouldn't be as fast as on NVIDIA hardware but it would potentially
be much faster than the CPU versions of those pieces of software.

~~~
bootloop
It's easier to replace the CUDA kernels with probably designed OpenCL kernels
instead. Edit: For third party: Thats what the driver does, compiles OpenGL
and OpenCL code into GPU machine code. In case of mesa based on reverse
engineering.

~~~
dheera
> It's easier to replace the CUDA kernels

If it's your software, yes. But not if you're trying to fix an already-written
framework or run other peoples' machine learning models.

------
stelf
Does it mean you’ll be able to speed up the compositor of gui and ff for
example?

~~~
pcwalton
It doesn't look like this supports GLSL, so that would have to be addressed
first. Furthermore, there's no Vulkan backend yet for WebRender.

~~~
simcop2387
Actually it might be, Zink just got OpenGL 3.0 support.

Zink is an OpenGL Implementation on top of Vulkan and that might actually be a
good way to do full OpenGL on these devices.

~~~
tambre
Zink has next to no optimization effort so far and is thus very slow from what
I've read. Maybe in a few years, since they currently seem to be focusing on
compatibility.

~~~
messe
Which is the right way to go about it, especially when Vulkan is still in the
process of being adopted. Make it right; then make it fast.

------
Havoc
Glad to see any green/red team engineers doing any *nix stuff frankly :)

Seems super petty given the wholesomeness but would have preferred if he
invested the energy into RPi4 to be honest though given how accessible it is
now.

~~~
sgt
Perhaps it will come to RPi4 as well?

~~~
Narishma
RPi4 has a different GPU than the older models. Someone else is already
working on an official Vulkan driver for it.

~~~
glglwty
I wonder whether this situation of reverse-enginnering GPU drivers is
sustainable. GPUs on ARM SOCs tend to be quite different from each other and
most vendors have no interest in collaborating with the linux community. On
X86 at least we have Intel and AMD willing to invest in linux drivers.

~~~
d_tr
IMHO it is just unethical to have to reverse engineer your hardware to program
for it.

------
fractal618
I've always disagreed with the grammar rule in this situation. "An Nvidia
engineer" just sounds and flows better than "A Nvidia engineer"

~~~
j4ah4n
I think I learned something new here. I've always thought the rule was "use
`an` if it _is_ a vowel, else use `a`".

If I understand this correctly now, it's "use `an` if it makes a vowel
_sound_, else use `a`".

~~~
maxton
It’s definitely about vowel sounds, because we don’t say “a hour” or “a herb”.

~~~
the_pwner224
deleted; i misread the parent comment

~~~
DavidVoid
"hour" starts with an 'o'-sound, since the 'h' is (mostly) silent, so "an
hour" is correct.

------
dboreham
An?

------
historyremade
for fuck's sake, no one has to follow standards!

------
Ericson2314
Great effort, but [https://github.com/Yours3lf/rpi-vk-
driver/tree/master/extern...](https://github.com/Yours3lf/rpi-vk-
driver/tree/master/external/lib) makes me side

Just use NixOS everyone, and never vendor anything ever again no matter how
many packages you need to fork.

