Latest Comments by Marlock
NVIDIA 520.56.06 driver adds easier NVIDIA NGX updates for Wine / Proton
12 Oct 2022 at 11:20 pm UTC
12 Oct 2022 at 11:20 pm UTC
Kisak is one of Valve's linux devs, working on upstream Mesa.
Having an LTS distro is *partially* uncaracterized by adding Kisak Mesa PPA... it does bring in a newer than officially curated component to the OS, but only that one and not the whole mass of core components that the LTS freezes when released. This limits the amount of issues derived from updating packages to a minimum, and makes it much easier to guess if the PPA is or isn't involved.
If that's the only PPA you need, you know graphics issues that arise my stem from it and that removing it and reversing Mesa to the default Ubuntu version is a useful test to fix graphics issues.
This does open the door to "PPA Hell" where a user adds many PPAs and a few of them provide an overlapping selection of packages with conflicting version requirements in that overlap. Reliable PPA sources are careful to avoid putting too much stuff in a single PPA to prevent such overlaps, but there are some examples otherwise.
However most often than not a PPA breaks the system just because it pushed a buggy new version of a package (Oibaf, I'm looking at you!) and this happens to rolling-release distros too.
Also keep in mind that for gaming on Ubuntu LTS, Mesa is the only PPA that Valve themselves recommend going for a newer than default version, and then only if you want to enjoy the latest features they contributed upstream.
It's not a hard requirement anymore, not like when Valve first started getting their hands dirty with the linux graphics stack. Most of their essential contribuitions are already contributed upstream to Mesa and Kernel devs AND pulled downstream into Ubuntu LTS too.
If you think this is too much, it's ok... that's why I like the fact that we have so many good distros! But IMHO it doesn't really make our lives difficult on non-rolling distros if we need a couple things that aren't there by default.
ps: I'm a casual gamer using Linux Mint without any PPA and Steam and Proton work just fine here. I haven't even moved from Linux Mint 20.x to 21, so my distro is based off Ubuntu 20.04, not 22.04, and that's still enough to get things going just fine here.
I also experimentally enabled Kisak PPA on one of my machines and left it there, with Mint's auto-update feature enabled, and the PPA updates are auto-applied without issue (it's been ~1 year since the experiment started).
I don't recommend Oibaf, it's been the source of several threads on the "Steam on Linux" discussion forum on Steam. Kisak on the other hand has almost never (... ... ... maybe actually never?!!) been pinpointed as the source of an issue there.
Oibaf does make it clear that his PPA is on the more experimental side, and Kisak does make it clear his is more on the safe side, so all is as it should.
Having an LTS distro is *partially* uncaracterized by adding Kisak Mesa PPA... it does bring in a newer than officially curated component to the OS, but only that one and not the whole mass of core components that the LTS freezes when released. This limits the amount of issues derived from updating packages to a minimum, and makes it much easier to guess if the PPA is or isn't involved.
If that's the only PPA you need, you know graphics issues that arise my stem from it and that removing it and reversing Mesa to the default Ubuntu version is a useful test to fix graphics issues.
This does open the door to "PPA Hell" where a user adds many PPAs and a few of them provide an overlapping selection of packages with conflicting version requirements in that overlap. Reliable PPA sources are careful to avoid putting too much stuff in a single PPA to prevent such overlaps, but there are some examples otherwise.
However most often than not a PPA breaks the system just because it pushed a buggy new version of a package (Oibaf, I'm looking at you!) and this happens to rolling-release distros too.
Also keep in mind that for gaming on Ubuntu LTS, Mesa is the only PPA that Valve themselves recommend going for a newer than default version, and then only if you want to enjoy the latest features they contributed upstream.
It's not a hard requirement anymore, not like when Valve first started getting their hands dirty with the linux graphics stack. Most of their essential contribuitions are already contributed upstream to Mesa and Kernel devs AND pulled downstream into Ubuntu LTS too.
If you think this is too much, it's ok... that's why I like the fact that we have so many good distros! But IMHO it doesn't really make our lives difficult on non-rolling distros if we need a couple things that aren't there by default.
ps: I'm a casual gamer using Linux Mint without any PPA and Steam and Proton work just fine here. I haven't even moved from Linux Mint 20.x to 21, so my distro is based off Ubuntu 20.04, not 22.04, and that's still enough to get things going just fine here.
I also experimentally enabled Kisak PPA on one of my machines and left it there, with Mint's auto-update feature enabled, and the PPA updates are auto-applied without issue (it's been ~1 year since the experiment started).
I don't recommend Oibaf, it's been the source of several threads on the "Steam on Linux" discussion forum on Steam. Kisak on the other hand has almost never (... ... ... maybe actually never?!!) been pinpointed as the source of an issue there.
Oibaf does make it clear that his PPA is on the more experimental side, and Kisak does make it clear his is more on the safe side, so all is as it should.
Steam Mobile App gets a huge revamp out now for everyone
12 Oct 2022 at 8:59 pm UTC Likes: 2
12 Oct 2022 at 8:59 pm UTC Likes: 2
The current Steam Mobile app did have chat, despite the separate app existing and being more feature-complete... I use only the Steam Mobile messaging because the chat app has issues on my phone.
Will this update remove the simple chat message features entirely ir is it still there in its minimal form?
Will this update remove the simple chat message features entirely ir is it still there in its minimal form?
NVIDIA 520.56.06 driver adds easier NVIDIA NGX updates for Wine / Proton
12 Oct 2022 at 8:30 pm UTC
12 Oct 2022 at 8:30 pm UTC
Fedora has COPR (same idea as a PPA) but also doesn't even need it most of the time because it has more up-to-date packages than Ubuntu.
It even has special channels for the user to choose to be more up-to-date than the base setup, called updates-testing and rawhide.
Most non-rolling distros have something of the sort, I just picked Ubuntu as an example exactly because it's a particularly big AND particularly slow-to-update distro.
If you're on a distro that's so small that it doesn't have any packaging options like this, it would be comparable to rolling-release distros that don't have the man-power to keep packages updated in a timely manner. The issue then is distro dev team size / distro popularity, not being rolling or not.
Not to mention there are some rolling-release distros that are more conservative like non-rolling ones on purpose like Slackware.
Agreed that most rolling distros tend to elect keeping core packages closer to upstream than Ubuntu, but popular/big non-rolling end up solving that issue too and only tiny ones are left behind in the end... and then only tiny ones that don't piggy-back directly on bigger distro repos, because Mint does have a tiny dev team yet its usage of Ubuntu-related stuff solves this issue for them.
It even has special channels for the user to choose to be more up-to-date than the base setup, called updates-testing and rawhide.
Most non-rolling distros have something of the sort, I just picked Ubuntu as an example exactly because it's a particularly big AND particularly slow-to-update distro.
If you're on a distro that's so small that it doesn't have any packaging options like this, it would be comparable to rolling-release distros that don't have the man-power to keep packages updated in a timely manner. The issue then is distro dev team size / distro popularity, not being rolling or not.
Not to mention there are some rolling-release distros that are more conservative like non-rolling ones on purpose like Slackware.
Agreed that most rolling distros tend to elect keeping core packages closer to upstream than Ubuntu, but popular/big non-rolling end up solving that issue too and only tiny ones are left behind in the end... and then only tiny ones that don't piggy-back directly on bigger distro repos, because Mint does have a tiny dev team yet its usage of Ubuntu-related stuff solves this issue for them.
NVIDIA 520.56.06 driver adds easier NVIDIA NGX updates for Wine / Proton
12 Oct 2022 at 5:18 pm UTC Likes: 3
12 Oct 2022 at 5:18 pm UTC Likes: 3
More on the post topic, I'm really glad Nvidia caved for opensourcing parts of their driver (however long it it might take to happen) and started paying its technical debt of linux features that should work but don't because of their proprietary spaghetti-code driver
AMD and Intel obviously helped this happen because of their choice to support opensource driver stacks, but in a way I feel Valve also needs to be deeply thanked for this, as AMD alone hasn't picked up the pace (and probably wouldn't) until our linux gaming development patron came around and comissioned everyone to work on everything:
The Linux Kernel and Mesa themselves
RADV
ACO
DXVK
VKD3D
Zync
GameScope
Steam Deck using an AMD APU
...
I'll be waiting with past and current AMD (and maybe soon Intel) GPUs and APUs while they get up-to-speed
AMD and Intel obviously helped this happen because of their choice to support opensource driver stacks, but in a way I feel Valve also needs to be deeply thanked for this, as AMD alone hasn't picked up the pace (and probably wouldn't) until our linux gaming development patron came around and comissioned everyone to work on everything:
The Linux Kernel and Mesa themselves
RADV
ACO
DXVK
VKD3D
Zync
GameScope
Steam Deck using an AMD APU
...
I'll be waiting with past and current AMD (and maybe soon Intel) GPUs and APUs while they get up-to-speed
NVIDIA 520.56.06 driver adds easier NVIDIA NGX updates for Wine / Proton
12 Oct 2022 at 5:03 pm UTC
If we were talking about some cryptic app that only exists in AUR I would be agreeing, but we're talking about Mesa here.
How's adding Kisak's (Stable) Mesa PPA in any way difficult on Ubuntu and derivates?
On Linux Mint (even though it's the anthitesys of rolling release, because it's always based on Ubuntu LTS with a bonus ~6 month delay) we have a GUI for adding PPAs (and even 3rd-party Debian repos) called "Software Sources". It's not out-of-the-box, but it's at least a go-here-paste-this-click-ok do-once-and-forget procedure, so not that hard at all, right?
As for kernels, Linux Mint has a GUI for kernel version management offering whatever is available on kernel.ubuntu.org HWE stack for the Ubuntu LTS version it's based on, and kernel updates also follow through the Update Manager. 3 clicks will move you over the newest branch available then normal updates will keep it at the last revision.
On Ubuntu itself this is AFAIK a bit less friendly, but there is UKUU (3rd-party app) to cover the GUI-based kernel management gap and this even supports vanilla kernel.org releases, branch auto-upgrades, etc. There are other similar-purpose apps too, and they work across Ubuntu derivates as well.
12 Oct 2022 at 5:03 pm UTC
Quoting: slaapliedjeAMD requires kernel updates and using out of band (meaning not the standard repository) mesa libraries (unless you're running a rolling release, neither of these are easy)This is a widespread notion but I honestly don't get it...
If we were talking about some cryptic app that only exists in AUR I would be agreeing, but we're talking about Mesa here.
How's adding Kisak's (Stable) Mesa PPA in any way difficult on Ubuntu and derivates?
On Linux Mint (even though it's the anthitesys of rolling release, because it's always based on Ubuntu LTS with a bonus ~6 month delay) we have a GUI for adding PPAs (and even 3rd-party Debian repos) called "Software Sources". It's not out-of-the-box, but it's at least a go-here-paste-this-click-ok do-once-and-forget procedure, so not that hard at all, right?
As for kernels, Linux Mint has a GUI for kernel version management offering whatever is available on kernel.ubuntu.org HWE stack for the Ubuntu LTS version it's based on, and kernel updates also follow through the Update Manager. 3 clicks will move you over the newest branch available then normal updates will keep it at the last revision.
On Ubuntu itself this is AFAIK a bit less friendly, but there is UKUU (3rd-party app) to cover the GUI-based kernel management gap and this even supports vanilla kernel.org releases, branch auto-upgrades, etc. There are other similar-purpose apps too, and they work across Ubuntu derivates as well.
KDE devs talk Steam Deck and their work for it at Akademy 2022, over a million shipped
4 Oct 2022 at 12:26 am UTC Likes: 4
4 Oct 2022 at 12:26 am UTC Likes: 4
also this is like the first console from a new brand, not a 5th-gen console from a major traditional brand, and a very experime tal proposal at that, with what gamers could perceive as significant risks to the platform's success (linux instead of windows, PC games over a handheld formfactor, etc)
PS5 backorders have been cleared already wereas Deck backorders haven't so the overall sales figures for the Deck are not yet done
etc, etc
is there any Linux projects financed by Valve page somewhere? it's really starting to get difficult to get the big picture in one go
very much happy Valve chose to pour money into several developer hubs for linux instead of doing just one big thing at a time... a lot more stuff going strong faster, exciting times
PS5 backorders have been cleared already wereas Deck backorders haven't so the overall sales figures for the Deck are not yet done
etc, etc
is there any Linux projects financed by Valve page somewhere? it's really starting to get difficult to get the big picture in one go
very much happy Valve chose to pour money into several developer hubs for linux instead of doing just one big thing at a time... a lot more stuff going strong faster, exciting times
Google gives up on Stadia, will offer refunds on games and hardware
1 Oct 2022 at 5:29 pm UTC Likes: 1
Google killed Stadia by not going into it whole-heartedly from the start, which immediately made everyone assume they'd eventually kill it. 50% typical Google Graveyard, 50% self-fulfilling profecy.
1 Oct 2022 at 5:29 pm UTC Likes: 1
Quoting: elmapulMultiplayer on the PS4 and PS5 only works if you pay a monthly/yearly subscription to PSN, so Google's pricing is actually not far away from Sony's... but a console may keep running locally if the network goes down, can be hacked into keeping function after officially EOL (eg: I bought a Nintendo Wii after EOL and had a lot of fun transfering games from official media to an SD Card)Quoting: Purple Library Guyreally? i dont think it was that confusing.Quoting: elmapulAll I know is what I read here, and back when it was significant news Liam regularly noted both (a) that the actual deal did not require subscription, and (b) that figuring this out from anything Google were saying was nigh impossible. He opined repeatedly both that the service itself worked pretty well and was, all concerns about the fundamental nature of streaming game services aside, a decent offer, and that in his opinion Google were doing a perfectly pathetic job of selling it. Not just the bad messaging on subscription, but terrible ads and all kinds of stuff. I'm prepared to take his word.Quoting: Purple Library GuyPeople didn't actually have to pay a monthly fee for Stadia; it's just Google's terrible marketing made it look like they did.google or a bunch of influencers who lied?
instead of paying 400 dollars upfront for an ps4, and 400 dollars again for an ps4 pro, you pay just for the game, and a montly subscription if you want to play in 4k.
with 10 dollars per month, it would take 40 months to reach the price of an ps4, 3 years and 4 mounths is almost the entire generation.
and while you do that you get exclusive discounts and some games as part of the deal.
dont seems like a bad deal for me, unless they rise the price or shutdown the service and you lose your games without a refund, that is the part that google should make more clear.
google didnt fail to comunicate that as fair as i remember, but a lot of youtubers miss interpret and repeated what they understood.
Google killed Stadia by not going into it whole-heartedly from the start, which immediately made everyone assume they'd eventually kill it. 50% typical Google Graveyard, 50% self-fulfilling profecy.
Google gives up on Stadia, will offer refunds on games and hardware
1 Oct 2022 at 5:15 pm UTC
SAM - Steam Achievement Manager
https://www.gamingonlinux.com/2020/05/steam-achivement-manager-samrewritten-has-a-new-release
Technically cheating, but also technically not since you did earn them somewhere :happy:
1 Oct 2022 at 5:15 pm UTC
Quoting: trumanmothI have successfully transferred save data (at least for Octopath Traveler) by exporting from Google Takeout, downloading to my Steam Deck and renaming the save files to match the local file names. Achievements are lost, but at least 60hrs of progress isn’t.You can edit steam achievements with this tool:
SAM - Steam Achievement Manager
https://www.gamingonlinux.com/2020/05/steam-achivement-manager-samrewritten-has-a-new-release
Technically cheating, but also technically not since you did earn them somewhere :happy:
NVIDIA Linux driver 515.76 is out, as is Mesa 22.2 for AMD / Intel
21 Sep 2022 at 11:34 pm UTC Likes: 2
21 Sep 2022 at 11:34 pm UTC Likes: 2
It's not that simple... Nvidia was king of the hill until recently because their paid developers do good work on their proprietary linux drivers, and AMD just couldn't afford so much in-house work on theirs (remember AMD as a whole has hanged by a thread after 2 consecutive cpus and some gpus performed worse or eat more power than their Intel CPU and Nvidia GPU competition).
Then AMD had a hardware comeback with Ryzen and their newer gpu gens, which gave them a little more room to breath in the financial aspect... and meanwhile they opensourced their linux gpu drivers (which took years of hard effort and a new driver, with severe growing pains to get it up to speed)...
...and then 3rd-parties (mainly Valve) got interested in AMD GPUs (because they're now quite capable for their price and power consumption) and their drivers (because they are opensource)...
...and then everything changed!
AMD still has not as much money to put into linux driver development as Nvidia, but any other interested party can put their hands on the driver and help (not just pay AMD some commissioned work, actually look at the code from a fresh perspective and help!)
If you said 5 years ago that from a practical perspective a proprietary driver can be just as good as an opensource driver or better, you'd be mostly right. Now not so much... openess paid off, and AMD has successfully leveraged the rest of the world to make their driver get better faster than their own money could achieve, gaining the upper hand in multiple (un)expected ways and winning the preference of several customers due to those.
Nvidia's move towards an official linux opensource gpu driver (beyond their ARM boards and beyond the quixotesque 3rd-party noveau mesa driver efforts) is IMHO a belated admission that they took the wrong turn over these years and that they know they are at risk of falling behind.
They could just throw even more money at the problem and maybe keep up... but opensourcing just brings more bang for buck than that and keeping their old strategy unchanged would cost them a lot.
Also from a user perspective, there practical negative consequences to dealing with a proprietary driver. Eg: you can't just grab a new kernel and expect their driver to work. The linux kernel APIs for user apps are rock solid stable, but the internal ABI calls between kernel pieces can change pretty quickly. If a driver is part of the mainlined kernel codebase, anyone proposing changes to these internal calls needs to take care of the other parts of the codebase that use it. If the driver is outside that codebase, the driver devs need to do the work themselves... and an old driver needs to be carefully replaced (before rebooting to the new kernel or else it might just crash at boot trying to use the old ABI over a new kernel).
There are also integration issues with linux features but AFAIK that's more due to Nvidia being stubborn and/or not being convincing enough about why doing things their way would be better (hint: their new drivers are meeting linux halfway after being stuck like a mule for ages and earning "the finger")
Then AMD had a hardware comeback with Ryzen and their newer gpu gens, which gave them a little more room to breath in the financial aspect... and meanwhile they opensourced their linux gpu drivers (which took years of hard effort and a new driver, with severe growing pains to get it up to speed)...
...and then 3rd-parties (mainly Valve) got interested in AMD GPUs (because they're now quite capable for their price and power consumption) and their drivers (because they are opensource)...
...and then everything changed!
AMD still has not as much money to put into linux driver development as Nvidia, but any other interested party can put their hands on the driver and help (not just pay AMD some commissioned work, actually look at the code from a fresh perspective and help!)
If you said 5 years ago that from a practical perspective a proprietary driver can be just as good as an opensource driver or better, you'd be mostly right. Now not so much... openess paid off, and AMD has successfully leveraged the rest of the world to make their driver get better faster than their own money could achieve, gaining the upper hand in multiple (un)expected ways and winning the preference of several customers due to those.
Nvidia's move towards an official linux opensource gpu driver (beyond their ARM boards and beyond the quixotesque 3rd-party noveau mesa driver efforts) is IMHO a belated admission that they took the wrong turn over these years and that they know they are at risk of falling behind.
They could just throw even more money at the problem and maybe keep up... but opensourcing just brings more bang for buck than that and keeping their old strategy unchanged would cost them a lot.
Also from a user perspective, there practical negative consequences to dealing with a proprietary driver. Eg: you can't just grab a new kernel and expect their driver to work. The linux kernel APIs for user apps are rock solid stable, but the internal ABI calls between kernel pieces can change pretty quickly. If a driver is part of the mainlined kernel codebase, anyone proposing changes to these internal calls needs to take care of the other parts of the codebase that use it. If the driver is outside that codebase, the driver devs need to do the work themselves... and an old driver needs to be carefully replaced (before rebooting to the new kernel or else it might just crash at boot trying to use the old ABI over a new kernel).
There are also integration issues with linux features but AFAIK that's more due to Nvidia being stubborn and/or not being convincing enough about why doing things their way would be better (hint: their new drivers are meeting linux halfway after being stuck like a mule for ages and earning "the finger")
Intel's Linux Vulkan Driver readying up a 60%+ speed boost "in draw throughput"
21 Sep 2022 at 9:48 am UTC
21 Sep 2022 at 9:48 am UTC
cyberpunk 2077 doubled FPS on an Intel GPU... from 2 to 4 FPS maybe? :grin:
I expect this is due to Cyberpunk 2077 being an exceptionally draw-heavy game so it's affected more than others. Games are very diverse in this regard, each relying more or less or not at all on certain GPU features.
The original post by Mike Blumenkrantz in his blog "Super Good Code" is very accessible and hilarious (as usual), so totally worth reading!
He explains that the performance gain is due to fixing a performance regression he inadvertedly introduced during previous work on the intel driver. It was undetected until he started using a vulkan performance profiling tool to analyse the drivers and find optimization opportunities...
His fingers are probably fine now, but i fear for his ego... he was feeling like a king after finding the recent RADV optimization :grin:
I expect this is due to Cyberpunk 2077 being an exceptionally draw-heavy game so it's affected more than others. Games are very diverse in this regard, each relying more or less or not at all on certain GPU features.
The original post by Mike Blumenkrantz in his blog "Super Good Code" is very accessible and hilarious (as usual), so totally worth reading!
He explains that the performance gain is due to fixing a performance regression he inadvertedly introduced during previous work on the intel driver. It was undetected until he started using a vulkan performance profiling tool to analyse the drivers and find optimization opportunities...
His fingers are probably fine now, but i fear for his ego... he was feeling like a king after finding the recent RADV optimization :grin:
- Planetary Annihilation: TITANS gets revived as the devs ask for Linux help and feedback
- AMD announced the Ryzen 9 9950X3D2 Dual Edition processor
- STALKER 2: Cost of Hope expansion announced for Summer 2026
- RTS game PERIMETER: Legate Edition gets Linux ARM64 binaries and Steam Workshop support
- Hytale update 4 is another absolute whopper with over 500 new blocks
- > See more over 30 days here
- Away all of next week
- Liam Dawe - What Multiplayer Shooters are yall playing?
- Liam Dawe - The Great Android lockdown of 2026.
- Strigi - Proton/Wine Games Locking Up
- Caldathras - What have you been playing recently?
- Strigi - See more posts
How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck