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.
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.
> 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....
It's an export law issue. Raspberry Pi is an educational product that should be exportable all around the world. They can't let crypto regulation laws upend that goal.
Wasn't one of the issues with earlier Pi versions that the driver just serialized high-level GLES-like commands to a front-end processor that ran a huge closed firmware blob? All GPUs have built-in command processors but this was closer to a full driver running as a firmware blob on an auxiliary CPU.
Do you mean hardware module? Have you got any blogs or docs about this?
Came across the same thing doing a baremetal kernel (fun!) and this never crossed my mind!
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).
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.
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.
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.
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 ?
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.
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.
Prepare 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-performanc... for some practical-ish examples.
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.
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.
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.
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.
There is a Canadian joke that is related to this very thing:
Where did the Québécois get that H sound for Ottawa?
They took it out of here.
When speaking with a French Canadian accent, Ottawa sounds like Hottawa, and Here sounds like Ear. There is a similar more adult-oriented joke about the word Happiness. It is utterly baffling to Anglophones, especially since whatever rule they are following doesn't apply to the word Ontario, which pretty much sounds the same as in English.
If you've never heard Quebec French, imagine Celine Dion telling the joke and you'll get it.
The Happiness joke is based both on the missing H and the different emphasis on syllables, so you are probably right or at least close. The subtraction of H in words like Here and Happiness seems like a different rule than its addition on hard vs soft initial-O words, though.
"An Nvidia engineer" would actually be grammatically correct here, since the pronunciation of "Nvidia" starts with a vowel sound and not a consonant one. It's the pronunciation of the word that matters for a/an, not the spelling.
In case anybody was wondering, the official pronunciation of the word "Nvidia" is apparently "en-VID-eeyah" [1].
I didn't know that, I always got told it depends on the first letter (and it didn't make sense for me for some words).. (Obviously not a native speaker)
Wait, what? So the rule isn't that the pronunciation starts with a vowel sound? Instead it's a more murky thing about how easy it rolls off the tongue?
University starts with the 'y' sound, hence "a university." On the other hand, "an unimpressive fact" uses "an" because "unimpressive" starts with the 'u' (vowel) sound.
That’s why the pronunciation of “an history” is such a contentious issue in British political linguistics to this day. Crucially, as has been observed correctly, the rule is that one should use the appropriate indefinite article. That in turn depends on whether one pronounces, as pirates, or has a silent ‘h’, revealing one’s origins even once the guise of Received Pronunciation had been defensively adopted.
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.
This is actually a deeper issue about the confusion between the language itself (english phonology requires what you're describing) and the written form. No english speaker in the world, unexposed to the written form of "Nvidia" would ever say "A Nvidia."
That entirely depends on how you pronounce "nvidia" in your head. I can imagine someone who has never heard the name spoken out loud think of it as "ni-vidia" (I have done worse) and "a Nividia" is easier than "an Nividia"
That's just weird over-correction. "A historic day" is correct but for some reason people heard "An historic day" and the idea spread that it was a special exception.
Kind of like how you see lots of people on Reddit saying "water isn't wet, it just makes other things wet". They heard someone else say it and it sounds smart so they repeat it, without spending 10 seconds to look it up in a dictionary.
To me it may be a tell for the writers at one point pronouncing it as "'istoric", similar to those who say human as "'uman", and then as you said likely fanning out as an over-correction, possibly because that dialect was associated with prestige.
Titles with character length limitations do create tension that pulls sentence construction toward concise information density over strict readability, but avoiding unintended implicit statements in titles is a concern of mine.
This usage is acceptable because if you simply delete the word nvidia, we lose valuable context which tells us why we should pay attention to this post over any other engineer’s post with analogous drivers for this use case: the pedigree of the engineer suggests that the driver will be performant and of a similar quality as those other drivers produced by the engineer’s company.
