bazzite VS ZLUDA

Oh neat! Thanks for the information.

> running Steam on Bazzite (https://bazzite.gg) inside Proxmox.

Does this mean you can pass the gyro controls onto Steam Link or GeForce Now or some such? I have no interest in retro games, but it would be awesome to use gyro aiming for shooters...

https://github.com/ublue-os/bazzite/blob/main/Containerfile#... has, in addition to fan and power controls, automatic updates on desktop, supergfxctl, system76-scheduler, and an fsync kernel:

  rpm-ostree install rocm-hip \

I went looking for KDE, but was disappointed. From the FAQ on https://projectbluefin.io/:

> What if I want something like KDE or another window manager?

> Bluefin is an opinionated GNOME experience. However Universal Blue provides a maintained set of base images for anyone to be able to make a custom image. We hope Bluefin acts as an inspiration for others to build their own communities around user experiences. For example check out Bazzite if you want a great KDE gaming experience, similar to SteamOS.

The Bazzite link 404s, but there is info at https://universal-blue.org/blog/2023/11/08/bazzite-20/ and https://github.com/ublue-os/bazzite. Seems mostly focused on SteamDeck.

It's a cool list of patches.

I love these projects that bundle a bunch of cool things together with a base thing. Bazzite is a SteamOS project that similarly bundles all kinds of crazy things, and was a very popular recent submission, for another example. https://news.ycombinator.com/item?id=38828040 https://github.com/ublue-os/bazzite

The maintenance style here looks difficult. They seem to somehow take chunks of new chromium releases and make commits with those dropped in changes, and fix random stuff for a while. Looks very arduous. It makes me appreciate a somewhat opposed style, the Debian's Quilt model, where you have take the upstream and keep reapplying a set of patches to upstream. Maintaining is then just re-hacking any patches that break, and authoring new patches, whenever reapplying breaks. Seems like it'd be much easier to maintain, long run.

I was also hoping for something like the Quilt model because it seemed like it would be a good way to learn some shit about Chromium! Having the patches on hand would point to some key parts of the code-base, I feel! Im not sure how I'd learn what went into this fork, other than meticulously going through history. The readme also doesn't link to where it sources it's many patches from (which is another thing Bazzite did an excellent job of!).

Kind of interesting seeing a spreading focus on using more/modern x86-64 extensions spreading. Ubuntu is dabbling with what they are calling x86-64-v3, Red Hat too. https://www.phoronix.com/news/RedHat-RHEL10-x86-64-v3-Explor...

https://opencontainers.org/

Here is Containerfile from the repo: https://github.com/ublue-os/bazzite/blob/main/Containerfile

Hadn't heard of Bazzite.

> Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers, living room home theater PCs, and numerous other handheld PCs.

https://github.com/ublue-os/bazzite/

Worth visiting the readme even if not interested. There's a huge list of included stuff, and a lot of it seems really cool.and helpful (for gamers or streamers mostly).

check out bazzite, it's basically steamos but fedora based instead of arch based, has the same immutable root layout for stability and smooth upgrades and as long as youre not using nvidia graphics you can use gaming mode with the bazzite-deck image

It now supports AMD GPUs since 3 weeks ago, check the latest commit at the repo:

https://github.com/vosen/ZLUDA

The article also mentions exactly this fact.

Looks like nvidia is trying to keep the lynchpin of their entire business model from crumbling underneath them. ZLUDA lets you run unmodified CUDA applications with near-native performance on AMD GPUs.

https://github.com/vosen/ZLUDA

With Triton looking to eclipse CUDA entirely, im not sure this prohibition does anything more than placate casual shareholders.

>Dark API functions are reverse-engineered and implemented by ZLUDA on a case-by-case basis once we observe an application making use of it.

https://github.com/vosen/ZLUDA/blob/master/ARCHITECTURE.md

> I know AMD have their competition, but their GPU software division keeps tripping over itself.

They are actively stepping on every rake there is. Eg they just stopped supporting the drop-in-cuda project everyone is waiting for, due to there being "no business-case for CUDA on AMD GPUs" [0].

[0] https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq

https://github.com/vosen/ZLUDA

They still funded it and it was created.

From the same repo, I found this excellent, well-written architecture document: https://github.com/vosen/ZLUDA/blob/master/ARCHITECTURE.md

I love the direct, "no bullshit" style of writing.

Some gems:

> Anyone familiar with C++ will instantly understand that compiling it is a complicated affair.

> Additionally CUDA allows, to a large degree, mixing CPU code and GPU code. What does all this complexity mean for ZLUDA? Absolutely nothing

> Since an application can dynamically link to either Driver API or Runtime API, it would seem that ZLUDA needs to provide both. In reality very few applications dynamically link to Runtime API. For the vast majority of applications it's sufficient to provide Driver API for dynamic (runtime) linking.

CUDA is huge and nvidia spent a ton in a lot of "dead end" use cases optimizing it. There have been experiments with CUDA translation layers with decent performance[1]. There are two things that most projects hit:

1. The CUDA API is huge; I'm sure Intel/AMD will focus on what they need to implement pytorch and ignore every other use case ensuring that CUDA always has the leg up in any new frontier

2. Nvidia actually cares about developer experience. The most prominent example is Geohotz with tinygrad - where AMD examples didn't even work or had glaring compiler bugs. You will find nvidia engineer in github issues for CUDA projects. Intel/AMD hasn't made that level of investment and thats important because GPUs tend to be more fickle than CPUs.

[1] https://github.com/vosen/ZLUDA

> I don't think you understand just how insanely difficult it is to break into that market.

You're right, I have no clue nor have I ever tried myself.

> Even with apple money or something like that, it's a losing prospect because in the time it'll take you to get up and off the ground (which is FOREVER) your competition will crush you.

This I find hard to believe, do you have a source or reference for that claim? Companies with that amount of cash are hardly going to be crushed by competition be it direct or indirect. Anyway, I'm talking more about the Intels and AMDs of this world.

We have very lacklustre efforts from players I won't name with their Zluda library (https://github.com/vosen/ZLUDA) which I got REALLY excited about, until I read the README.txt. Four contributors, last commit early 2021.

Why, oh why, is it this bad?