Heck, they still support the original Pis and A+; I just installed the latest version of Raspberry Pi OS on my A+ with 128 MB of RAM, and while it is slow, it works just the same.
It helps that the pi zero hasn't been superseded yet, and probably won't be for a long time. (They've surprised me, heck, everybody, before though)
The problem with the $ PiZero w/o WiFi or the $10 PiZero w/WiFi is you don't seem to be able to buy them in quantity. They are simply not 'available' to use in any sort of 'product', it seems.
It's important to note that competitive x86 SBC do exist, and have the typical, full, x86 support. Of course, the downside is that the price is higher (around twice as much for a full system). A downside of ARM SBCs is that they pretty much all have an expiry date. Due to their closed nature, when the community pulls the plug, they're gone (SW-wise). x86 boards last virtually forever. While they're somewhat compatibl…
Which x86 boards would you recommend?
If you're looking for something in the Raspberry Pis price range, the Rock Pi X is only $20 more than the equivalent 4GB Pi4
It has 32GB eMMC onboard too so unlike the Pi4 there's no need to deal with external USB storage or flaky SD cards
I think you are missing broadcom on that list. But for real, why is Broadcom so bad?
Broadcom is notorious for hiding everything behind very restrictive NDAs. You want a CPU from them? Don't bother contacting them unless you plan buying six figures, is the common sentiment on HN. On the other hand, there aren't many competitors that are better in terms of accessibility. Sigh. Implementing embedded devices with any sorts of "smarts" beyond some Atmel uC from scratch is a pain - one has to go with read…
Are there any group buys that could be set up? Surely there are at least 43 people in the world who want to buy that part but don't want to buy the full MOQ
I think you are missing broadcom on that list. But for real, why is Broadcom so bad?
Broadcom is notorious for hiding everything behind very restrictive NDAs. You want a CPU from them? Don't bother contacting them unless you plan buying six figures, is the common sentiment on HN. On the other hand, there aren't many competitors that are better in terms of accessibility. Sigh. Implementing embedded devices with any sorts of "smarts" beyond some Atmel uC from scratch is a pain - one has to go with read…
It's almost like companies value their employee's time and don't want them dealing with non-profitable sales to hobbyists or buying small quantities to poke around and copy IP.
Quake3 runs about 40% faster on this Vulkan driver vs the OpenGL driver. Not sure if that's particularly impressive for Vulkan or not but it does seem more performant than previous options on the Pi 4.
OpenGL is single threaded with a single state machine (ok there are some atomic supports via extensions). Vulkan allows you to manage the stream so you can multi-thread. This allows you to update more that 1 state at a time, for example in OpenGL loading textures and mesh data at the same time can't happen easily. In vulkan you can tune this yourself. (this is a very simplistic example). I usually say that Vulkan is…
OpenGL supports multi-threading via creation of multiple contexts, sharing resources (textures, shaders etc) between them.
Vertex array objects are not which can be a bit of a pain.
Is there an "open" SBC by your definition? Intel has ME/AMT, and requires an opaque, PK-signed-and-only-intel-and-NSA-have-the-key blob. AMD is the same with PSP. I'm not up to date, there might be a RISC-V core available today that is blob free, but in 2012 when RasPi was introduced I wasn't aware of anything blobless.
Freescale's i.MX SoCs are full open. No blobs at all. Check them out. They are sweet. Boards exist.
That's definitely better.
But why do you trust that the silicon doesn't have any backdoors more than you trust the blob? We know for a fact that Intel puts one into the silicon, and that it takes significant reverse engineering to turn most of it off (it's not clear if all of it can be turned off at all) see e.g. https://hackaday.com/2020/06/16/disable-intels-backdoor-on-m...
Answer from another noob: AFAIK it is not about being better, but lower level. Being closer to how GPUs work underneath gives developers more flexibility for optimizing.
Often it has been that Vulkan is closer to how GPUs work simply due to GPU manufacturers having to change their GPUs to work well with Vulkan. To for example add a co-processor to the GPU so that it can do job scheduling in a more Vulkanish way. Vulkan was after all a spec from one GPU manufacturer (AMD), there are a handfull others with their own archs developed with their own assumptions.
Mantle was the single GPU manufacturer API, Vulkan was based on Mantle, but its creation had input from all the major vendors including Nvidia.
Broadcom is notorious for hiding everything behind very restrictive NDAs. You want a CPU from them? Don't bother contacting them unless you plan buying six figures, is the common sentiment on HN. On the other hand, there aren't many competitors that are better in terms of accessibility. Sigh. Implementing embedded devices with any sorts of "smarts" beyond some Atmel uC from scratch is a pain - one has to go with read…
Are there any group buys that could be set up? Surely there are at least 43 people in the world who want to buy that part but don't want to buy the full MOQ
I'd be glad if the big shops (Mouser, Digikey, Conrad) could set up some pool solution... everything one can do as a private person opens up a hellhole of liabilities: international shipping (and tracking), return rights, warranties, import/export tariffs, import/export arms control (GPS receivers come to my mind), CE/RoHS compliance, international taxes (VAT, sales taxes, the US with their mind-boggling state/county/city additional taxes), supply chain integrity (people don't want their "pool buy" for 20 bucks turn out a counterfeit, and it's hard enough for big companies to secure that one).