having open source gpu runtime, from api to metal, would be nice. but as you can see, the real meat of the business (the compiler) will probably never-ever be open sourced for internal political reasons. which is the most interesting component.
it must be said the gpu crowd is very different to the cpu crowd. the cpu crowd trips over themselves to tell everyone about their ISA. the gpu crowd keep it very close to their chest. (the gpu isas are also quite batshit insane but thats another conversation.) you wind up with almost polar opposite experiences in terms of how these two groups interact with the broader industry.
gpu people reeeaally don't want you prying your nose beyond the userspace APIs, in my experience.
EDIT - to add though... that is kind of understandable, because the gpu crowd is under a lot more pressure to support basically everything and everyone. opengl, dxil, spirv, opencl - and the dense matrix of combinations. I often see people hate on Apple for developing their own API (Metal), but honestly? I totally get it. in retrospect they probably did the right thing.
we have an epidemic of gpu programming "specs" and "standards", with no end in sight. i can't help but keep editing this comment with more of my hot takes: ofcourse nvidia owns the GPU programming space. they're the only ones offering anything resembling an actual platform! and they will continue dominating the space, because the rest of the players are too busy playing in their own ballpens.
I think the only way to dislodge nvidia is to ape their silicon. a USSR needs to come along, steal their masks, and just make carbon copies. not a shim, just straight up copy nvidia 100%. like, you run `nvidia-smi` and it reports back "yep this is a real nvidia card". and then sell it for half the price. it would be totally illegal, but when youre a state actor You Can Just Do Things.
Anything with an ARM Mali family GPU, same as you'd find for the question "where are Nvidia drivers used" as being "anywhere an Nvidia GPU is used". There isn't a premade list of certain people/companies who might ever used a certain brand GPU in their products, it's "just about anywhere". That can be anything including phones, tablets, mini PCs, laptops, SBCs, TV boxes, VR headsets, and so on - it's not limited to use in a specific product/manufacturer/type of device only.
If you're looking for something hackable to play with the Mali driver options on yourself, Chromebooks or SBCs (like the one in the article) are usually the easiest bet and where the development is done vs the more fixed-by-manufacturer type devices like the typical phone where you get what they decide to package (which may or may not be the particular open driver you're looking to see used).
Hmm, not really. As mentioned above, anything including phones, tablets, mini PCs, laptops, SBCs, TV boxes, VR headsets, and so on. Chromebooks and TVs would just be 2 examples of these types of devices.
As a solid example, the screenshots from the article are not taken from a Chromebook or TV :).
First of all thank you everybody for reading and commenting!
I want to address some of the comments I got regarding the article:
- xyz vendor is not covered: For this there is a simple answer, I don't have the hardware so I can't make a fair judgement when reporting about it. I don't want to be another reporter of basic benchmark scores & 1080P Youtube playback but actually show off the hardware capabilties with the right software. Hopefully this will be possible with more in the future as this project grows
- This is only one sector of the space why don't you have micro controllers or x86: While I want to cover all aspects of the space I am not an embedded engineer. I started during covid with the goal to replace my X86 homelab server with an ARM one to save power and got deeper into the rabbit hole until I ended up maintaining some boards and doing some Debian/Ubuntu based bring ups in my freetime.
This led to me wanting to have one place to share my findings along the way and document things that might leave one stranded in the world of Yocto/U-Boot/Linux Kernel/Device-Trees/etc. and I created sbcwiki.com, not only for me to share my findings but for others to contribute with simple markdown files to the GitHub repo too.
In this format I go deep down the Mailing lists, news articles and more to summarise what exciting hardware has been published and software has been merged into Linux. Also breaking down rumours and developer conferences about future SoC‘s. Hope you all find it useful!
Can you include more prices? It would give me an idea of the cost even if it is in USD. What i found most annoying about my latest search is that it is hard to find something not named raspberry or Arduino for a reasonable price. I was looking for a simple gigabit board with usb 3 to attach a removable drive to. The only one i found was raspberry pi orange 3B . Nobody else seemed to have gigabit nic with usb 3.
The Raspberry PI also has an intangible value from years of community goodwill. And people trust that the kernel OS support will be around in 10 years.
The NVIDIA solution is impressive... but self-immolated with the consumer price point (markets for government equipment may work.) People usually either have money or time... asking for both in a product is foolish.
The other SoM also have a long-tail market attention problem, as one could spend 2 weeks tracking unstable kernel driver problems. Or just drop in a $35 pi, and solve the task at hand. =3
Rockchip SoCs starting with the RK3399 can do both USB3 and Ethernet.
The only board that I own that does both at the same time is the Pine64 Quartz64 that uses the RK3566. My Pinebook Pro doesn't have an ethernet port, Orange Pi 5 Max has ethernet but doesn't use the builtin controller to provide it.
i see Quartz64 with 4GiB of RAM offered for $60. Sounds pretty reasonable for an SBC of this caliber. I mostly mean that something like the original RPi would be underpowered for USB3.0 and 1GbE, to say nothing of smaller devices like a $15 ESP32.
Delivering double digit IPC improvements (looks like the industry is still competitive).
> The Arm C1 Ultra CPU aims for +25% single-threaded performance and double-digit IPC gains
The new Mali GPU's look not bad too with +20% performance while 9% more power efficient.
And SME2-enabled Armv9.3 cores for on device AI doesn’t sound bad either
It is not clear on which core the successor of Neoverse V3 (the server version of Cortex-X4, which is used in the latest Graviton) will be based.
Arm C1-Ultra is the successor of Cortex-X925. C1-Ultra has great improvements in single-thread performance, but Cortex-X925 had very poor performance per die area, which made it totally unsuitable for server CPUs. Arm has not said anything about the performance per area of C1-Ultra, so I assume that it continues to be poor.
Arm C1-Pro is the successor of Cortex-A725. Arm has made server versions of the Cortex-A7xx, but Amazon did not like them for Gravitons, for being too weak.
Therefore only Arm C1-Premium could have a server derivative that would become the successor of Neoverse V3 for a future Graviton.
For now, the technical manual of C1-Premium is very sparse. Only when the optimization guide for C1-Premium will be published, showing its microarchitecture, we will know whether it is a worthy replacement for Cortex-X4/Neoverse V3, which had the best performance per die area among the previous Arm CPU cores.
Today I'm showcasing my open source (written in Go) Telegram bot that does a few things that are nice to have for group chats:
1. Clean any URL of Tracking Parameters
2. Parse TikTok (Videos / Photos), Instagram (Reels / Posts), Twitter/X (All posts) in a way that you don’t need to leave the Telegram App to view the content. This utilizes either open source tools like FxEmbed to switch the domain or for tiktok photos attaches them as a gallery reply.
We've used this happily for months now and from feedback I know it’s being used in bigger channels too. As I do no logging I cannot say more about its popularity.