The problem isn't how bright should 1023 be. The problem is how bright should diffuse white be (aka graphics white or SDR white)? None of HDR10, HDR10+, or DoblyVision ever attemped to address that question. Which is a pretty important question to answer if you want to use HDR in a desktop / multi-window environment.
None of HDR10, HDR10+, or DolbyVision ever answered the question of how to adapt for varying ambient brightness levels, either, which is again a very important question to answer for portable devices like phones, tablets, and laptops.
Bit depth is precision. HDR or SDR are the range. They are orthogonal concepts.
But at a high level you're basically asking "why doesn't scRGB exist" and, well, it does :) https://en.wikipedia.org/wiki/ScRGB (also called extendedSRGB)
While it may prevent sleep, one of the frustrations I have on an old skylake desktop with a bunch of 1080ti GPUs is that when set to power saving modes, the GPUs sit at 1x2.0 pcie lanes and low wattage. That slows down loading quite a bit.
So it will use more power, but nothing close to when the GPU is being used.
Is VRAM not directly accessible by the system then? Since it's mapped directly into the CPU's address space, I had assumed that there's a simple DMA controller managing said access and I would then also naively assume that said controller is separate (or at least on a separate power plane) from the actual GPU.
they are talking about the scenario of having a discreet GPU in addition to the GPU on the CPU. So there's 2 GPUs, and the nvidia one has its own VRAM (typically of the GDDR variety even) that isn't shared with system RAM (hence the purpose of this project). So that also means 2 memory controllers.
Doesn't it come with Nvidia's blend of Ubuntu with a custom kernel? Do other distros work as well as "DGX OS" or are nvidia's kernel changes pretty important to have?
I've not noticed much in it that is NVIDIA specific.
But I would say that as an Ubuntu and Debian user for decades I have no incentive to use anything else on it and I'm just pleased to have a Linux on Aarch64 machine that is well supported for a change.
afaict, they have their own package repo mirrors and a few dedicated packages for nvidia stuff
tbh, I was rather unimpressed with the out-of-box experience for an "ai" computer, you couldn't even run a model locally with the common tools people use (no llama-cpp, ollama, vllm, etc). No huggingface CLI eiher, like come on!
I need to update that because I have a nice vllm setup on there now with 4 models running, but should be able to get anyone else going without having to muddle about as I did.
This plus the price different had me buy an AMD Strix Halo board last week. It seems the work with vLLM and training models could make the Spark worth the price difference, but before today's news I had the same thought about support and did not want to lock myself into a cool paperweight, especially with 128gb of RAM on the line. AMD is x86 and I can repurpose that or run Linux forever.
Well, MediaTek actually said they made most of the SoC in fact. But the actual CPU cores themselves are all but certainly off-the-shelf Cortex parts, since MediaTek doesn't have a custom core design at all afaik.
For Apple it worked because they waited until they had a really, really good ARM ISA CPU (combined with arguably sandbagging their x86 offering for a few years prior but I digress).
Qualcomm is also working on a really good ARM ISA CPU with their acquisition of NuVia and subsequent Oryon architecture.
Meanwhile this is just using off-the-shelf ARM CPUs in a MediaTek SoC with blackwell bolted to the side of it. ARM's CPUs so far have been subpar for laptop-class chips. Hence why neither Apple nor Qualcomm are using them.
> Meanwhile this is just using off-the-shelf ARM CPUs in a MediaTek SoC with blackwell bolted to the side of it
MediaTek is involved in the SoC but both the CPU & GPU from Nvidia are bolted on to it. I.e. it's not a standard MediaTek CPU with an Nvidia GPU added.
MediaTek's press release pretty clearly indicates the CPU came from MediaTek, and so far Nvidia doesn't have any custom CPU core they've called "Grace". Seeing as the DGX Spark has what seems to be the same core chip, it'd be really surprising if the RTX Spark swapped out the CPU cores without any fanfare announcing that
> tbh, I always read this as Intel doing some sales magic here.
Possibly, but Apple choosing a new, thicker chassis the same generation that they introduce their more power efficient replacement is certainly a thing. Even if Intel failed to achieve the TDP they told Apple, Apple also seems to no longer believe the thinness they were doing was viable for that TDP anyway.
Intel's product offering certainly wasn't as compelling towards the end there, but it also looked almost uniquely bad in Apple's chassis vs everyone else's
The Intel chips of that time were fine but it was a problem from both sides. Apple refused to "compromise" their hardware design and Intel failed to deliver on their promises regarding power/heat budgets and kept telling Apple execs that they were just one cycle away from fixing all of the problems.
Ultimately, Apple won that fight when they decided to stop letting Intel control their hardware roadmap and it's been a great change for the entire industry. Intel is finally seeing some changes in their own products, largely in response to Apple dropping them. Now Nvidia is getting into the game which means more competition which is also good.
> that will let me iterate at the speed of JS or Python with performance of C or Rust.
Didn't Go already do that?
> I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement
Yes, and it will still only be useful in the same niche that C is because the entire philosophy of Zig is to essentially be like C. You're never going to interate at JS/Python speeds with Zig because you'll always be wrangling with memory lifecycles, object lifecycles, etc...
> no. GC pauses turn any serious systems work into hell.
did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter
> this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui
Sure, but if you're philosophically okay with hidden allocations and control flow, why not just choose a language that doesn't compromise itself for those ideals in the first place?
that was me comparing, please kindly read usernames next time :)
> why not just choose a language that doesn't compromise itself for those ideals in the first place?
I might want to wrap a timing-sensitive machinery into some nice UI. Rust has Tauri for that, sure, but now we are bringing npm and have zero chances of having GPU-accelerated UI without a crap-ton of fuckery which would be easier in Zig. another path for resolving that same issue is Compose Desktop + Project Panama, but then you are dealing with data marshalling, FFI boundary, and manual resource management in an environment that does not expect this.
so, here is a genius idea: why not have everything in one language? C++ already does that, much like C, but Zig does that so much better, and incremental compilation time is one of the more practical and immediate developer UX benefits it provides. Rust? good luck having shared mutable state there.
> The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad
It's unlikely to be just a devex issue. The fact of the matter is that a memory unsafe language is an extremely tough sell today, and companies that have a security team at all have likely already made or are planning on making policies like https://chromium.googlesource.com/chromium/src/+/master/docs...
There's a reason "rewrite it in Rust" was a meme long before LLM coding tools or this Bun drama. With AI accelerated fuzzing techniques and similar, memory safety is rapidly going to become a basic requirement of anything run in a production environment.
None of HDR10, HDR10+, or DolbyVision ever answered the question of how to adapt for varying ambient brightness levels, either, which is again a very important question to answer for portable devices like phones, tablets, and laptops.
reply