Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nvidia RTX Spark

nvidia.com

Post reply on HN
Print view View original

431–437 of 437 posts

Re: Nvidia RTX Spark

#431

Post by lmm »

abenga wrote: post #411
lmm wrote: post #342

Earlier quoted context omitted.

What trouble? If you want a GPU that works on Linux, let alone FreeBSD, you buy nVidia, install their drivers and get on with your life (and sure, maybe you can't use Wayland, but why would you want to?). I'm all for open-source in theory, but in practice the AMD drivers cause far more trouble than the nVidia ones ever do.

After I switched from Nvidia to AMD GPUs on my main rig, I can now run Sid without issue and upgrade my Kernel whenever I want to without getting a black screen with a blinking cursor on the next boot.

> Sid

Are you refusing to use the Nvidia binary drivers and/or a setup like DKMS that ensures kernel modules are rebuilt as necessary? While I respect the principle, it's a problem you're creating for yourself.

> upgrade my Kernel whenever I want to without getting a black screen with a blinking cursor on the next boot.

Really? I had very much the opposite experience.

Re: Nvidia RTX Spark

#432

Post by abenga »

lmm wrote: post #431
abenga wrote: post #411

Earlier quoted context omitted.

After I switched from Nvidia to AMD GPUs on my main rig, I can now run Sid without issue and upgrade my Kernel whenever I want to without getting a black screen with a blinking cursor on the next boot.

> Sid Are you refusing to use the Nvidia binary drivers and/or a setup like DKMS that ensures kernel modules are rebuilt as necessary? While I respect the principle, it's a problem you're creating for yourself. > upgrade my Kernel whenever I want to without getting a black screen with a blinking cursor on the next boot. Really? I had very much the opposite experience.

I installed the drivers according https://wiki.debian.org/NvidiaGraphicsDrivers. Yet every time a new kernel is released (note that this is new, new kernels, e.g. at the moment I am using 7.0.10, just one point release off the current tippy tip 7.0.11), whether or not Nvidia drivers would work after boot was a crapshoot. Maybe it's better now, seeing as they are trying to open source some part of the drivers, I guess. It got so troublesome at the time that I just got a 7800XT to replace my old 2070. Never had the issue again.

Re: Nvidia RTX Spark

#433

Post by trash_cat »

numberwan9 wrote: post #405
kennywinker wrote: post #267

Earlier quoted context omitted.

I’ve read all the stuff about how llama.cpp is much faster and better than ollama, and i believe it - but good god llama.cpp isn’t user friendly. You’d think in an era where “code is free” there would be an easier story around running local ai than compiling llama.cpp by hand and then spending hours researching flags - only for it to crash from an oom error every ten prompts or so.

Please take a look at https://llama.app , all you need is 'llama serve'

There is more to it than typing "llama serve".

Re: Nvidia RTX Spark

#435

Post by rldjbpin »

given how dgx spark was more advertised for finetuning ("tinkering") instead of inference, it is quite interesting to see their approach for the laptops to now be more inference-based.

knowing nvidia and their approach to consumer hardware (especially those on notebooks), i'd take a heavy grain of salt on getting a good deal.

also, they've been bad to their ecosystem partners, but now they've been able to boss them around into supporting them so far. i suppose getting anticheat vendors to finally support arm might be enough of a nudge for linux support? one can only dream

Re: Nvidia RTX Spark

#437

Post by tancop »

ChocolateGod wrote: post #427
BatteryMountain wrote: post #394

Earlier quoted context omitted.

Those are specific firmwares for those devices that are either closed-source binary blobs, open-source hackjobs/reverse engineered attempts, or just plain missing firmwares. The fault is not on Linux but rather on Qualcomm not releasing things for that specific SoC. Some SoC's have better support than others. ARM cpu's themselves works perfectly fine on linux. Intel has closed things down: some wifi and webcam firmwa…

> Those are specific firmwares for those devices that are either closed-source binary blobs, open-source hackjobs/reverse engineered attempts, or just plain missing firmwares This isn't fully the reason, Linux is infamous for requiring a specific build for each SoC (and usually each board of said SoC) where as Windows on ARM uses ACPI which Linux doesn't support to the same level. Linux prefers the landfill promoting…

> Linux is infamous for requiring a specific build for each SoC

no, thats just androids problem. desktop linux like ubuntu ships all the device trees from their supported arm variants. its still more work than acpi for kernel maintainers but you dont need device specific builds.

> landfill promoting device tree for each device

whats landfill promoting about this? you dont need to keep the trees updated they only depend on the hardware and follow a stable spec. and even if the vendors dont want to support linux a community user can write their own device tree and send upstream.

Post reply on HN