SDIO is still a fairly common interface that wifi and bluetooth adapters are connected with in embedded systems. Much lower idle power and protocol complexity than either USB or PCIe. You just don't find those wireless chipsets in an SD card form factor anymore. (and even if you did, SD card adapters don't generally support SDIO)
The problem is that this feature is generally restricted to enterprise customers because VDI systems are such a profitable market. NVIDIA and AMD both only offer this on enterprise cards, and Intel has been very wishy-washy on support in their cards.
If you're looking for a thing to google, look up SR-IOV support on (consumer) GPUs.
Also if you're wondering who the customers of these things tend to be, it's generally the CAD market, law firms, etc. If no one's laptop contains sensitive data and can only stream the desktop of a remote system, the loss or theft of an employee's computer isn't nearly the same kind of a security worry.
The trouble is that the RAM chip on the Pi is a high density module that's going to have come under pressure from the datacenter buildouts.
An 8 GiB DIMM for a desktop or server is using 8x 1 GiB chips or 16x 512 MiB chips (9/18 for ECC). An 8 GiB Pi uses a single 8 GiB chip. That's the same density as you would use for 128 GiB or larger sticks.
Almost everything we hate about ARM based systems is the result of everyone in the SoC ecosystem, not just ARM. It's just unfortunate for them from an optics perspective that they've been basically the only CPU core on the block so they get the brunt of the hate.
I place far, far more blame on companies like Qualcomm, Broadcom, Imagination Technologies (PowerVR), etc.
Go look at any of the non-microcontroller RISC-V based SoCs. It's not any better on any metric. Upstream software support is little to non-existent. Basically every RISC-V board needs a vendor kernel and they all have device tree and u-boot hell.
The SoC providers that make powerful chips are in the market of selling more chips - bad external support is a feature for them. Means that when they stop supporting the product you have to come buy a new chip. And if everyone does that, there's no better company to switch to because they all treat you the same.
About the only SoC vendor I have any respect for is Texas Instruments because they actually upstream a bunch of their code. Honestly I think this is because most of their parts are aimed industrial products and have support cycles >10 years.
I intentionally didn't say Rockchip because while they're in a bunch of hobby boards they don't really help with open source hardware work. They just take the position of "we won't stop you, but we're not going to help you".
Gen 4.0 x16 is 32 GB/s in each direction, but the way this is implemented is not the way you'd go about this if you wanted high performance.
Edit: Their benchmarks are also run using ZRAM, which compresses pages before writing to swap. Not sure what the performance overhead of that is, but it's probably quite a bit.
First of all, it's a userspace program hooking the nbd driver, which is known for being slow. It also uses a bounce buffer in userspace before transferring to the GPU. So when the kernel needs to swap a page, it has to first copy it into a userspace facing buffer. The userspace program that has to wake back up and issue the cuda operation to copy the page into device memory.
nbd also doesn't really do a good job of supporting high queue depth or merging adjacent accesses. So if the kernel is issuing a bunch of 4K page swaps without any coalescing, you're going to end up with at least million kernel/userspace context switches per second just to handle 4 GB/s (4 GB / 4K page), let alone 64 GB/s. And that's just the NBD portion, forget the mess that is the NVIDIA driver. PCIe can move a lot of data, but in order to get anything even resembling the full bandwidth, you have to have use DMA engines with long page lists. Having to set up a transfer for every 4K page over PCIe will not reach full saturation of the bus.
Swapping to NVMe is a very optimized path -> the swapper can submit lists of pages directly to the NVMe driver and the controller can DMA them directly out of RAM, no copies or context switches CPU side at all.
This could probably be improved by migrating to the ublk driver as it might let you avoid the userspace bounce buffer. It'd also be able to have multiple write queues to at least set up CUDA copies in parallel.
Memory on an expansion card isn't gated on PCIe 5, it's gated on CXL support. CXL and PCIe use the same electrical/physical layer but the protocol is very different.
The problem with putting (system) RAM on a PCIe card is that PCIe is not a cache-coherent interconnect. If you have a cache line that resides on your GPU sitting inside your processor's cache a remote modification to that memory by either the GPU, another CPU core or some other PCIe device with NOT invalidate the CPU cache line. You also have the fun situation that if it's modified on both ends simultaneously the resulting state will be non-deterministic.
Device drivers have to be very careful about synchronization when accessing memory-like areas on PCIe. CXL adds a cache coherency protocol among other things, so that invalidations and snoops can be exchanged over the interconnect.
KiCad schematic and board files are all text based with a fairly strict grammar, so you would be able to feed it directly into an LLM. Not that that means the LLM could actually make sense of it. Never tried though XD
> AI-users thus become less effective engineers over time, as their technical skills atrophy
Based on my experience, I think this will prove more true than not in the long run, unfortunately.
Professionally, I see people largely falling into two camps: those that augment their reasoning with AI, and those that replace their reasoning with AI. I’m not too worried about the former, it’s the latter for whom I’m worried.
My mom is a (US public school) high school teacher, and she vents to me about the number of students who just take “Google AI overview” as an absolute source of truth. Maybe it’s just the new “you can’t cite Wikipedia”, but she feels that since the pandemic, there’s a notable decline in the critical thinking skills of children coming through her classes.
We have a whole generation (or two) of kids that have grown up being told what to like, hate, believe, etc. by influencers and anonymous people on the internet. They’d already outsourced their reasoning before LLMs were a thing. Most of them don’t appear to be ready to constructively engage with a system that is designed to make them believe they are getting what they want with dubious quality.
A few things come to mind, but I wasn't even alive then so what do I know XD.
On one hand, it seems rather strange, because back in the early days of C (and later C++) there were far more CPU architectures in play. Every big Unix hardware vendor had their own CPU architecture, whereas today we only have about six. (In my mind: x86, arm, mips, risc-v, ppc, and s390x)
But it might be that in the early days of C/C++, development involved connecting to large shared Unix environments where the machine you developed on what always the machine (or at least the same type of machine) the program would run on, and also that those vendors weren't exactly incentivized to make developing for competitor's architectures easy.
As someone who has also spent two decades wrangling C/C++ codebases, I wholeheartedly agree with every statement here.
I have an even stronger sentiment regarding cross compilation though - In any build system, I think the distinction between “cross” and “non-cross” compilation is an anti-pattern.
Always design build systems assuming cross compilation. It hurts nothing if it just so happens that your host and target platform/architecture end up being the same, and saves you everything down the line if you need to also build binaries for something else.
As someone who works on systems at this level, believe me, it’s a learnable skill. And at least an intellectually valuable one I think too. Even if you never really need the knowledge for the things you do, there’s a nice feeling that comes from seeing something done at a high level and understanding how that makes its way down into the system and why those design choices were made.
If I were more money motivated I’d probably be building CRUD apps too. I just like weird puzzles XD.
Yeah, the 18 months it took me to lose that first 100 pounds was about the most miserable I've ever been in my entire life. Constantly hungry, constantly thinking about food, exercising 3 hours a day, having to sit out of social events because more than half of them involve going to restaurants, etc.
It really opened my eyes to just how food centric society is.
When I was on Ozempic in the US (Bay Area), it was a dial-a-dose Ozempic branded pen. Came with 4-6 single use needles you’d screw onto the end before use, and discard into a sharps bin after.
Yeah I might just have to go get it out of plan. Kaiser covers Ozempic, but none of the Tirzepatide based medications. (Edit: looks like that might have changed)
I am a big guy (6’4, 330 lbs), but I was amazed that Ozempic just seemed to do nothing. I was having the gastric side effects, but I could still eat 3000 calories a day if I cheated without feeling anything.
I’ve always been more of a savory kind of person myself. I’d take biscuits and gravy or a steak over sweets any day!
But I feel you on sugar. Took me a long time to cut sugar cravings. A decade ago I cut regular soda out of my diet, which a few years later led to me cutting out pretty much anything sweetened. Realistically it wasn’t the sweetness for me, it was the “mouthfeel” or doing something with your mouth. Just straight sparkling water satisfied the entire craving for me.
The hardest thing for me to give up / heavily cut back on was fried things. Maybe that’s the result of my parents using french fries as the reward food when I was a kid…
I’m always kind of envious of the people who were able to lose weight on GLP-1 drugs. I lost a bunch of weight a few years ago, and still need to lose a lot more (430 lb -> 330, goal 240), but I fell out of the good habits for, well, no good reasons…
Decided to try Ozempic and was on it for about 6 months. Didn’t do a single thing for my appetite unfortunately, even on the max dose.
Sample size of one here, but if you’ve got mental health struggles that feed into your eating patterns, GLP-1s might not help with your weight problems.
To add to what you said, it’s also nice to be able to keep it within one API that’s platform agnostic when possible.
Sure we’ve had the ability to keep the pipeline on GPU for awhile, but it usually required platform specific API bindings to convert to a platform specific descriptor (handles on windows, IOSurface on macOS, dmabuf on Linux), which you then had to pull into a platform specific decoder/encoder API (DXGI, WMF, AVFoundation, VAAPI, etc.), and then all of that again but in reverse to get the surface back into your 3D API.
This whole thing just makes life easier for everyone.
Comparing JACK and PulseAudio is like comparing apples and oranges. And honestly, JACK by itself is unsuitable as an audio server for general desktop usage.
JACK doesn’t support device hotplug (ya know, connecting and disconnecting a headset, something most of us do) and it also doesn’t support multiple applications generating audio without the user having to configure how audio is mixed.
JACK is designed for low latency in environments like Digital Audio Workstations (DAW) where you know 1) what audio hardware is present at all times, and 2) what applications are going to generate audio.
Many people who use/used JACK ran a PulseAudio bridge on top of it for every application that wasn’t the one or two applications that needed ultra low latency audio.
PulseAudio had some major warts, but JACK wasn’t some panacea that did everything better.