I’m fairly certain blockchain GPUs have very different requirements than those used for ML, especially not LLMs. In particular they don’t need anywhere as much VRAM and generally don’t require floating point math, nor do they need features like tensor cores. Those “blockchain GPUs” likely didn’t turn into ML GPUs.

ML has been around for a long time. People have been using GPUs in ML since AlexNet in 2012, not just after blockchain hype started to die down.

I think what they meant by that is “is this different wrt antitrust compared to Intel and x86?”

Intel both owns the x86 ISA and designs processors for it, though the situation is more favorable in that AMD owns x86-64 and obviously also designs their own processors.

I would say that in comparison to the standards used for top ML conferences, the paper is relatively light on the details. But nonetheless some folks have been able to reimplement portions of their techniques.

ML in general has a reproducibility crisis. Lots of papers are extremely hard to reproduce, even if they’re open source, since the optimization process is partly random (ordering of batches, augmentations, nondeterminism in GPUs etc.), and unfortunately even with seeding, the randomness is not guaranteed to be consistent across platforms.

No, the server is on the github account linked above as well. The repo is here.

Signal however doesn’t federate and does not generally support third-party clients.

I used to do something like this before Signal became a thing. We used to use OTR via the Pidgin OTR plugin to send encrypted messages over Google Hangouts. Funnily enough, I’m pretty sure Pidgin supports Discord, so you could use the exact same setup to achieve what you described.

It was pretty funny to check the official Hangouts web client and see nonsensical text being sent.

This was also one of my concerns with the hype surrounding low cost SLS printers like Micronics, especially if they weren’t super well designed. The powder is incredibly dangerous to inhale so I wouldn’t want a home hobbyist buying that type of machine without realizing how harmful it could be. My understanding is even commercial SLS machines like HP’s MJF and FormLab’s Fuse need substantial ventilation (HEPA filters, full room ventilation, etc.) in order to be operated safely.

Metal is of course even worse. It has all the same respiratory hazards (the fine particles will likely cause all sorts of long-term lung damage) but it also presents a massive fire and explosion risk.

I can’t see these technologies making it into the home hobbyist sphere anytime soon as a result, unfortunately.

My stance on Proton is my stance on GrapheneOS: just because the creator is bad doesn’t mean the software is bad. As long as the software is better compared to the alternatives then I seen no reason to stop using it.

I think the major difference is that for a software package or operating system like GrapheneOS, theoretically people can audit the code and verify that it is secure (of course in practice this is not something that 99% of people will ever do). So to some extent, you technically don’t have to put a ton of trust into the GrapheneOS devs, especially with features like reproducible builds allowing you to verify that the software you’re running is the same software as the repository.

For something like Proton where you’re using a service someone else is running, you sort of have to trust the provider by default. You can’t guarantee that they’re not leaking information about you, since there’s no way for you to tell what their servers are doing with your data. Accordingly, to some extent, if you don’t trust the team behind the service, it isn’t unreasonable to start doubting the service.

But at least regulators can force NVIDIA to open their CUDA library and at least have some translation layers like ZLUDA.

I don’t believe there’s anything stopping AMD from re-implementing the CUDA APIs; In fact, I’m pretty sure this is exactly what HIP is for, even though it’s not 100% automatic. AMD probably can’t link against the CUDA libraries like cuDNN and cuBLAS, but I don’t know that it would be useful to do that anyway since I’m fairly certain those libraries have GPU-specific optimizations. AMD makes their own replacements for them anyway.

IMO, the biggest annoyance with ROCm is that the consumer GPU support is very poor. On CUDA you can use any reasonably modern NVIDIA GPU and it will “just work.” This means if you’re a student, you have a reasonable chance of experimenting with compute libraries or even GPU programming if you have an NVIDIA card, but less so if you have an AMD card.

I work in CV and I have to agree that AMD is kind of OK-ish at best there. The core DL libraries like torch will play nice with ROCm, but you don’t have to look far to find third party libraries explicitly designed around CUDA or NVIDIA hardware in general. Some examples are the super popular OpenMMLab/mmcv framework, tiny-cuda-nn and nerfstudio for NeRFs, and Gaussian splatting. You could probably get these to work on ROCm with HIP but it’s a lot more of a hassle than configuring them on CUDA.

I’ve tried Overture, Creality, and Inland (all black though, not transparent) and Overture printed the best for me (at least for functional parts where I cared about print quality and tolerances). Inland’s PETG+ and High Speed PETG was even better though.

The main benefit I think is massive scalability. For instance, DOE scientists at Argonne National Laboratory are working on training a language model for scientific uses. This isn’t something you can do on even 10s of GPUs for a few hours, like is common for jobs run in university clusters and similar. They’re doing this by scaling up to use a large portion of ALCF Aurora, which is an Exascale supercomputer.

Basically, for certain problems you either need both the ability to run jobs on lots of hardware and the ability to run them for long (but not too long to limit other labs’ work) periods of time. Big clusters like Aurora are helpful for that.

Yeah we used to joke that if you wanted to sell a car with high-resolution LiDAR, the LiDAR sensor would cost as much as the car. I think others in this thread are conflating the price of other forms of LiDAR (usually sparse and low resolution, like that on 3D printers) with that of dense, high resolution LiDAR. However, the cost has definitely still come down.

I agree that perception models aren’t great at this task yet. IMO monodepth never produces reliable 3D point clouds, even though the depth maps and metrics look reasonable. MVS does better but is still prone to errors. I do wonder if any companies are considering depth completion with sparse LiDAR instead. The papers I’ve seen on this topic usually produce much more convincing pointclouds.

I think it’s been about a year? IIRC Intel only started using TSMC for their processors with Meteor Lake, which was released in late 2023.

I believe their discrete GPUs have been manufactured at TSMC for longer than that, though.

I use a lot of AI/DL-based tools in my personal life and hobbies. As a photographer, DL-based denoising means I can get better photos, especially in low light. DL-based deconvolution tools help to sharpen my astrophotos as well. The deep learning based subject tracking on my camera also helps me get more in focus shots of wildlife. As a birder, tools like Merlin BirdID’s audio recognition and image classification methods are helpful when I encounter a bird I don’t yet know how to identify.

I don’t typically use GenAI (LLMs, diffusion models) in my personal life, but Microsoft Copilot does help me write visualization scripts for my research. I can never remember the right methods for visualization libraries in Python, and Copilot/ChatGPT do a pretty good job at that.

There is no “artificial intelligence” so there are no use cases. None of the examples in this thread show any actual intelligence.

There certainly is (narrow) artificial intelligence. The examples in this thread are almost all deep learning models, which fall under ML, which in turn falls under the field of AI. They’re all artificial intelligence approaches, even if they aren’t artificial general intelligence, which more closely aligns with what a layperson thinks of when they say AI.

The problem with your characterization (showing “actual intelligence”) is that it’s super subjective. Historically, being able to play Go and to a lesser extent Chess at a professional level was considered to require intelligence. Now that algorithms can play these games, folks (even those in the field) no longer think they require intelligence and shift the goal posts. The same was said about many CV tasks like classification and segmentation until modern methods became very accurate.

I work in CV and a lot of labs I’ve worked with use consumer cards for workstations. If you don’t need the full 40+GB of VRAM you save a ton of money compared to the datacenter or workstation cards. A 4090 is approximately $1600 compared to $5000+ for an equivalently performing L40 (though with half the VRAM, obviously). The x090 series cards may be overpriced for gaming but they’re actually excellent in terms of bang per buck in comparison to the alternatives for DL tasks.

AI has certainly produced revenue streams. Don’t forget AI is not just generative AI. The computer vision in high end digital cameras is all deep learning based and gets people to buy the latest cameras, for an example.

GPU and overall firmware support is always better on x86 systems, so makes sense that you switched to that for your application. Performance is also usually better if you don’t explicitly need low power. In my use case I use the Orange Pi 5 Plus for running an astrophotography rig, so I needed something that was low power, could run Linux easily, had USB 3, reasonable single core performance, and preferably had the possibility of an upgradable A key WiFi card and a full speed NVMe E key slot for storage (preferably PCIe 3.0x4 or better). Having hardware serial ports was a plus too. x86 boxes would’ve been preferable but a lot of the cheaper stuff are older Intel mini PCs which have pretty poor battery life, and the newer power efficient stuff (N100 based) is more expensive and the cheaper ones I found tended to have onboard soldered WiFi cards unfortunately. Accordingly the Orange Pi 5 Plus ended up being my cheapest option that ticked all my boxes. If only software support was as good as x86!

Interesting to hear about the NPU. I work in CV and I’ve wondered how usable the NPU was. How did you integrate deep learning models with it? I presume there’s some conversion from runtime frameworks like ONNX to the NPU’s toolkit, but I’d love to learn more.

I’m also aware that Collabora has gotten the NPU drivers upstreamed, but I don’t know how NPUs are traditionally interfaced with on Linux.

A lot of the cheap tablet SoC vendors like Rockchip (whose SoCs end up in low cost SBCs) really only do the bare minimum when it comes to proper linux support. There’s usually next to no effort to upstreaming their patches so oftentimes you’re stuck on their vendor kernel. Luckily for the RK3588(S), Collabora has done a considerable amount of work on supporting the SoC and its peripherals upstream. I run my Orange Pi 5 Plus (RK3588) on a mainline kernel and it works for my needs.

This practice is a lot easier to defend for a low cost SoC compared to something as expensive as a Snapdragon Elite though…

One of the big changes in my opinion is the addition of a "Smart Dimension" tool where the system interprets and previews the constraint that you want to apply instead of requiring you to pick the specific constraint ahead of time(almost identical to SOLIDWORKS), and the ability to add constraints such as length while drawing out shapes (like Autodesk Inventor, probably also Fusion but I haven't used that). It makes the sketcher workflow more like other CAD programs and requires a little less manual work with constraints.

Hmm, that actually sounds like a bug. I haven't seen that on my end (once I set the locations of options in my toolbars they stay there, even after restarts). You may want to report that on their issue tracker. Sorry that you're having a rough experience!