20 ms·
A Nvidia Engineer Wrote a Vulkan Driver That Works on Older Raspberry Pi
- tosh 6y agorepo: https://github.com/Yours3lf/rpi-vk-driver https://github.com/Yours3lf/rpi-vk-driver
- stelf 6y agoDoes it mean you’ll be able to speed up the compositor of gui and ff for example?
- pcwalton 6y agoIt 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 6y agoActually 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.
- Narishma 6y agoBut it's only a small subset of Vulkan that this driver implements. I would be surprised if it's enough for an OpenGL implementation.
- tambre 6y agoZink 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 6y agoWhich 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.
- pcwalton 6y agoA 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 6y agoThis is one of RPi limitation - closed source firmware and drivers. But hardware is much better...
- dividuum 6y agoOnly 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 6y ago> The boot firmware is still closed though. Not much worse than a PC then in that regard.
- mobilio 6y agoUPDATE - 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 6y agoI 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=207888 https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=2078... > 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....
- fractal618 6y agoI've always disagreed with the grammar rule in this situation. "An Nvidia engineer" just sounds and flows better than "A Nvidia engineer"
- eganist 6y agoThe ppronunciation is "en-vidia", so yes, "an Nvidia" would be correct. If the company was pronounced ni-vidia (or any other vowel in place of that first `i` vowel, then "a Nvidia" would've been correct.
- iforgotpassword 6y agoJust like it's "a user" not "an".
- FPGAhacker 6y agoor 'an uber' instead of 'a uber.'
- ngcc_hk 6y agoThought it is a Uber as you say yu-ber in English. It sounds different if in German?
- devbat8712 6y agoYou absolutely do not say you-ber in english
- blahbhthrow3748 6y agoI'm pretty sure "an NVidia" is grammatical here.
- MHordecki 6y agoWhat is the grammar rule? I've always assumed that you use "an" whenever a noun starts with a vowel sound, which "Nvidia" does ("n" being pronounced as "en"), thus making "an Nvidia" the grammatically correct one.
- deleted 6y ago[deleted]
- jeroenhd 6y agoVery 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 6y agoNot just old - this also supports Zero and Zero W, which are in a category of their own.
- dheera 6y agoHow 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 6y agoIt'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 6y ago> 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.
- my123 6y agoWhy reverse-engineering something that is very well documented? (and hell, PTX even has GCC and LLVM backends while we are at it) The issue here is manpower, and not obfuscation in any way.
- aspaceman 6y agoIt’s a lot of work. That’s actually it with the CUDA stuff. Nvidia made a massive investment, and is still doing so, so the work got done. OpenCL just doesn’t have the same cash backing it up. Oh also this is basically what AMDs HIP does. The issue is that the project hasn’t been moving very fast.
- namibj 6y agoPrepare for loads of reverse-engineering, as there are binary-only CUDA kernels in applications. This does tend to break when new GPUs come out, but a software update takes care of that. I assume some do that for obfuscation, while others are certainly using it for performance, see e.g. https://github.com/bryancatanzaro/nervana-lib-gpu-performance-preview https://github.com/bryancatanzaro/nervana-lib-gpu-performanc... for some practical-ish examples.
- Abishek_Muthian 6y agoExcellent 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-experience-on-raspberry-pi/ https://abishekmuthian.com/getting-smoother-desktop-experien...
- mmm_grayons 6y agoI 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 6y agoI 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.
- dboreham 6y agoAn?
- Ericson2314 6y agoGreat effort, but https://github.com/Yours3lf/rpi-vk-driver/tree/master/external/lib https://github.com/Yours3lf/rpi-vk-driver/tree/master/extern... makes me side Just use NixOS everyone, and never vendor anything ever again no matter how many packages you need to fork.
- historyremade 6y agofor fuck's sake, no one has to follow standards!
- Havoc 6y agoGlad 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.
- aspaceman 6y agoThe Linux team at Nvidia is actually full of awesome people, used to know some of them. They’re just often hamstrung by business objectives.
- sgt 6y agoPerhaps it will come to RPi4 as well?
- Narishma 6y agoRPi4 has a different GPU than the older models. Someone else is already working on an official Vulkan driver for it.
- glglwty 6y agoI 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 6y agoIMHO it is just unethical to have to reverse engineer your hardware to program for it.
- nl 6y agoNVidia ships heaps of Linux stuff, mostly via their machine learning teams. For example they have their NVidia Jetson devices which all run Linux: https://www.nvidia.com/en-au/autonomous-machines/embedded-systems/ https://www.nvidia.com/en-au/autonomous-machines/embedded-sy...
- ensiferum 6y agoJust 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 6y agoAny 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/vulkan https://developer.arm.com/solutions/graphics-and-gaming/apis...
- deleted 6y ago[deleted]