Yeah, you can certainly get it to reproduce some pieces (or fragments) of work exactly but definitely not everything. Even a frontier LLM’s weights are far too small to fully memorize most of their training data.

Most “50 MP” cameras are actually quad Bayer sensors (effectively worse resolution) and are usually binned 2x to approx 12 MP.

The lens on your phone likely isn’t sharp enough to capture 50 MP of detail on a small sensor anyway, so the megapixel number ends up being more of a gimmick than anything.

I agree with your thoughts. I hate what Bambu has done to the industry in terms of starting a patents arms race and encouraging other companies to reject open source, but I do love how they’ve pushed innovation and have made 3D printing easier for people just looking for a tool.

I hope the DIY printers like Voron, Ratrig, VzBot, and E3NG can continue the spirit of the RepRap movement.

I work in an area adjacent to autonomous vehicles, and the primary reason has to do with data availability and stability of terrain. In the woods you’re naturally going to have worse coverage of typical behaviors just because the set of observations is much wider (“anomalies” are more common). The terrain being less maintained also makes planning and perception much more critical. So in some sense, cities are ideal.

Some companies are specifically targeting offs road AVs, but as you can guess the primary use cases are going to be military.

Some apps only require ‘basic’ play integrity verification, but now check to see if they’re installed via the Play Store. They refuse to run if they’re installed via an alternative source.

This has been a problem for GrapheneOS, since some apps filter themselves out of the Play Store search if you don’t pass strong play integrity, despite the fact that they don’t require it. Luckily Graphene now had a bypass for this.

OBS can use NVENC, though IIRC it needs to be built with support enabled, which may not be the case for all distros’ package managers.

Yep, since this is using Gaussian Splatting you’ll need multiple camera views and an initial point cloud. You get both for free from video via COLMAP.

Yeah, in typical Google fashion they used to have two deep learning teams: Google Brain and DeepMind. Google Brain was Google’s in-house team, responsible for inventing the transformer. DeepMind focused more on RL agents than Google Brain, hence discoveries like AlphaZero and AlphaFold.

The general framework for evolutionary methods/genetic algorithms is indeed old but it’s extremely broad. What matters is how you actually mutate the algorithm being run given feedback. In this case, they’re using the same framework as genetic algorithms (iteratively building up solutions by repeatedly modifying an existing attempt after receiving feedback) but they use an LLM for two things:

1. Overall better sampling (the LLM has better heuristics for figuring out what to fix compared to handwritten techniques), meaning higher efficiency at finding a working solution.

2. “Open set” mutations: you don’t need to pre-define what changes can be made to the solution. The LLM can generate arbitrary mutations instead. In particular, AlphaEvolve can modify entire codebases as mutations, whereas prior work only modified single functions.

The “Related Work” (section 5) section of their whitepaper is probably what you’re looking for, see here.

40 series to 30 series was pretty tangible IMO (4090 gets something like 30-50% more perf in most tasks than 3090 Ti with the same TDP), in part thanks to the much higher L2 cache plus newer process node.

50 series was very poor though, probably because it’s the same process node.

Is mechanical shutter necessary for max bit depth on your camera? It isn’t on mine (Sony), but bit depth reduces to 12 bit if you max out the framerate. You might still be able to get full 14 bit RAWs if you drop the framerate.

You can do this on Linux using gphoto2, ffmpeg, and v4l2loopback. You probably won’t get full resolution but the quality will still be good enough for video conferencing. See here for a guide.

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.

Sony v Connectix is the actual case that set the precedent for emulation, not Bleem. The Bleem case decided whether or not the use of screenshots of copyrighted games to advertise their emulator was legal. I believe it just deferred to the Connectix case for the legality of the emulator.

Afaik the StarFive SOCs used in SBCs are a lot slower than current ARM offerings. Part of that might be because software support is worse, so maybe compilers and related tooling aren’t yet optimized for them?

Hopefully development on these continues to improve though. The biggest nail in the coffin for Pi alternatives has been software support.

Not sure what’s going on but if the printer was flashed with Klipper, it won’t show anything on the screen until it is connected to a computer running klipper’s host software.