Check out our Monthly Survey Page to see what our users are running.
Latest Comments by pleasereadthemanual
SDL 3 will prefer Wayland Over X11, if certain protocols are available
28 March 2024 at 1:07 pm UTC Likes: 5

Sounds reasonable. Hope the protocol extensions get implemented sometime soon.

Just out of curiosity, I was counting the merge requests for protocol extensions in wayland-protocols today...

There are currently 86 open merge requests (MRs) in wayland-protocols. 4 protocol extensions were merged in the past 7 days, including the long-time linux-drm-syncobj-v1 protocol for explicit sync. 155 MRs have been merged in total (not all are protocols, but most are), and 51 have been closed (either in favor of new protocols or rejected outright).

Of the 86 open MRs, 43 of them were created in the past year. The remaining 43 are more than 1 year old. 14 MRs are between 1-2 years old. 9 MRs are between 2-3 years old. 12 MRs are between 3-4 years old. 8 MRs are between 4-5 years old, including the enormous Color Management protocol (#14), which is actually even older than that because this one predates the gitlab instance.

Did someone mention portals? Certainly not me.

FWIW, Explicit Sync and Color Management are the ones I really care about, and Explicit Sync is finally merged.

Nova, a Rust-based Linux driver for NVIDIA GPUs announced
27 March 2024 at 10:46 pm UTC Likes: 1

Quoting: Eike
Quoting: pleasereadthemanualYou see, it's actually really simple.

(...writes a manual...)


Quoting: Eike
Quoting: pleasereadthemanualI get the distinct feeling I'm missing something...

(Serious) question: Mesa?
Probably!

Nova, a Rust-based Linux driver for NVIDIA GPUs announced
27 March 2024 at 12:28 am UTC Likes: 9

I see there is some confusion about the Nova/Nouveau + NVK + Zink/Nouveau NVIDIA driver situation.

You see, it's actually really simple.

Graphics drivers always come in pairs, you see: there's a kernel driver, and then there's a userspace driver that sits on top of the kernel driver. First, we had the Nouveau kernel driver, which was a reverse-engineered open source driver alternative to the proprietary NVIDIA driver (it does not have a name). The proprietary NVIDIA driver, to keep things simple, is both the kernel and userspace driver in one. So, by itself, the Nouveau kernel driver is not useful, which is why it needs a userspace driver. To keep things simple, it was also called "Nouveau". It handled OpenGL calls.

Many years later, NVIDIA open sourced the kernel driver of their proprietary stack, often referred to as "open kernel modules". So now they have two drivers too!

Now we have NVK, which is a userspace driver just for Vulkan. Then Zink was written (which afaik was also being used for AMD) for the OpenGL calls, but what it really does is convert the OpenGL calls to Vulkan calls, which ends up being both faster than writing a new OpenGL driver and actually faster in performance because Vulkan is apparently the panacea to almost every problem on Linux.

So you can have a few stacks:

Nouveau (kernel) + Nouveau (userspace)
Nouveau (kernel) + NVK + Zink
Nova + NVK + Zink
NVIDIA (proprietary kernel) + NVIDIA (proprietary userspace)
NVIDIA (open modules) + NVIDIA (proprietary userspace)

The open modules are also "out of tree", which means they will never be mainlined like Nouveau, so they are no easier to install than the proprietary modules, and offer the same performance.

However, be careful! You can't combine the open modules from NVIDIA with Nouveau userspace or NVK + Zink. The open kernel modules only work with the proprietary driver.

I wonder if you could combine Nouveau (kernel) with NVK and Nouveau (userspace). Food for thought!

Then there's the GSP firmware for the GPUs. This is what will allow NVK to support HDMI 2.1+, because that code is inside the firmware. I think. I don't know anymore.

I get the distinct feeling I'm missing something...

Oh, and I almost certainly got the stuff about Zink wrong. I think that had something to do with converting the OpenGL code on the Nouveau userspace driver to Vulkan or something..?

SDL 3 has a first preview release out with HDR and Vulkan for the 2D rendering API
26 March 2024 at 8:45 am UTC

Quoting: Marlockthey could delay SDL3... but that only helps if Wayland devs clearly signal they'll solve their end of the issue soon with high priority... which seems a bit unlikely, though Valve does have plenty of people working for them on both things, iirc
This was brought up in the pull request, but it doesn't seem like something SDL is interested in doing. Either because they just don't believe they can get this protocol and implementations sorted out in time for the next release (ideally, that might take 6 months?), or because they don't want to delay it at all. That might change as SDL3 gets closer to release.

There are definitely Valve employees like Joshua Ashton who engage in Wayland Protocol discussion. Joshua Ashton has also done a few implementations for Wayland protocols such as in Mesa. I'm sure there's more I don't know about. For this particular protocol, at least Xaver Hugl (KDE), Joshua Ashton (Valve), Simon Ser (wlroots, gamescope) and Derek Foreman (Collabora) have been working on it. No idea how close it is to completion, and it seems to depend on another protocol that isn't finished.

Oh, and even flibitijibibo is commenting on the SDL pull request.

SDL 3 has a first preview release out with HDR and Vulkan for the 2D rendering API
25 March 2024 at 11:04 pm UTC

Quoting: hell0
Quoting: pleasereadthemanual
QuoteIf we do this, we are basically accepting these issues are unfixable for the next ten years (SDL4).

[...]

Shipping a broken default is the wrong thing to do. Unfortunately, that protocol is unlikely to be finished before SDL3's release (3+ months away).

Two bad options. There's suggestions of flipping the default later on in the lifecycle of SDL3 once this protocol is implemented, and that seems like what's going to happen. I'm not sure what the downsides of this are.

I'm not interested enough to go and read the whole debate. But is there really a 10 year life cycle for SDL? Or something preventing them from releasing SLD4 a year from now?
There is no evidence supporting this one way or the other that I can find, aside from Conan-Kudo's argument. He is the only one that mentioned it, and no one else responded about it. I couldn't find any information about how long SDL versions are supported for.

I can only assume it's based on the time between SDL1 and SDL2, and now SDL2 and SDL3.

SDL 3 has a first preview release out with HDR and Vulkan for the 2D rendering API
25 March 2024 at 1:17 pm UTC Likes: 5

Interesting to see two Valve employees, Joshua Ashton and Sam Lantinga, as contributors and even creator/maintainer of SDL. I wonder how many more there are.

Taking a look at the CREDITS.md file:

QuoteMike Sartain for incorporating SDL into Team Fortress 2 and cheering me on at Valve.
Pierre-Loup Griffais for his deep knowledge of OpenGL drivers.

And just as an interesting point-of-fact:

QuoteEverybody at Loki Software, Inc. for their great contributions!

That Wayland vs X11 issue is quite contentious. We've got everyone from Conan-Kudo, Xaver Hugl from KDE, to Mattias Klumpp weighing in on it. One thing that strikes me is how long it would take for Wayland support to be implemented if the missing protocol isn't merged in time for SDL3's release:

QuoteIf we do this, we are basically accepting these issues are unfixable for the next ten years (SDL4).

What's more, every major desktop is now Wayland-first, and GNOME is soon to be Wayland-only, maybe next year. The XWayland X server is still around, so there's still support for the features SDL needs...but it also has problems.

Shipping a broken default is the wrong thing to do. Unfortunately, that protocol is unlikely to be finished before SDL3's release (3+ months away).

Two bad options. There's suggestions of flipping the default later on in the lifecycle of SDL3 once this protocol is implemented, and that seems like what's going to happen. I'm not sure what the downsides of this are.

Explicit Sync Wayland Protocol Merged, Wayland Protocols 1.34 released
23 March 2024 at 1:32 pm UTC

Quoting: CalebQ42Good to see this is finally being fixed(ish). This is one of the main reasons I switched to AMD nearly a year ago as the issue ultimately comes down to NVIDIA deciding they want to do something a different way then everyone else and letting their users have a bad time. From the research I've done, there are some benefits to explicit sync over implicit sync, but since every other driver already has implicit sync no one was in too much of a rush to add it.
It seems like almost everybody is in favor of explicit sync: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317#note_1358617

There's a link to this article included: https://lwn.net/Articles/814587/

QuoteExplicit synchronization is the future of graphics and media. At
least, that seems to be the consensus among all the graphics people
I've talked to. I had a chat with one of the lead Android graphics
engineers recently who told me that doing explicit sync from the start
was one of the best engineering decisions Android ever made. It's
also the direction being taken by more modern APIs such as Vulkan.
I can't claim to have researched the topic in detail beyond what was necessary for me to understand the significance of this protocol for my flickering issue on Wayland, but this doesn't actually seem like a controversial issue: everybody wants explicit sync.

Glad to see this issue is finally going away, though.

GitLab takes down Nintendo Switch emulator suyu due to the DMCA
22 March 2024 at 6:32 am UTC Likes: 1

Quoting: LoftyHow is it different from emulating lets say a 20yr old PS2 game ? perhaps fundamentally it is not that far apart, but the developer is not losing money on sales for a start, the hardware is well and truly out of action and there is no effective DRM to bypass or machine to crack. Maybe that's just semantics.
Strictly speaking, the two are not mutually exclusive. The common rhetoric is that users should buy the Switch, hack it so it can dump game archives for cartridges they insert, and then for the user to purchase the game and dump it. Nintendo doesn't lose out on any sales this way.

What is the proportion of people doing that? That's a completely different story.

Some PS1 discs were protected by Libcrypt in 1998. Circumventing that today would still fall afoul of Section 1201 of the DMCA, no two ways about it.

GitLab takes down Nintendo Switch emulator suyu due to the DMCA
22 March 2024 at 1:02 am UTC Likes: 2

Quoting: LoftyAnd furthermore emulation was nowhere near the level that is it now with big name youtubers showing off day one releases running flawlessly on competing hardware (steam deck) from a platform (switch) that is currently on sale.
Technically that was the objective of bleem! with emulating current-gen Playstation games on the competing Sega Saturn; the quality may not have been great, but if they could have made it great, they would have. I don't think whether the emulator performs well or not really has much of an impact on the ethics.

Take second-hand products, for example. Is the only reason selling products you own second-hand is legal because they might be of worse quality than a new product? I don't think this has anything to do with it ethically.

Quoting: LoftyTrue, but slightly exaggerated. Those early emulators at the time weren't exactly performant & bug free across a wide catalogue of games and the systems used to emulate ( PC ) were not doing so with ease at 4k.

and valve showing yuzu in their promotional steam deck thumbnail

With regards to the 7 years of PPSSPP that a fair old time along but i take your point, but even so the emulation quality of today with such a large global community of developers is WAY bigger than it was back then.
I don't really have a horse in this race because I've used emulation exactly once, to play an hour of the original Mario game, over a decade ago. And...maybe a few Pokemon ROM hacks way back when?

From what I've heard, Switch emulators offer a much better experience than the Switch console. Higher resolutions and frame rates, for example. If somebody has bought the game, shouldn't they be able to play it wherever they want? Wine isn't emulation, but the same principle applies: should Linux users not morally be able to play Windows games they bought on Steam?

Emulators allow people to play games they haven't bought, but the fact is, you can play games you haven't bought on a hacked Switch itself anyway. If Yuzu and Ryujinx went away for good, people who don't pay for games will still be able to play those game ROMs on the Switch and get the same experience as a paying customer.

At least they have to buy an older Switch now, I guess, but companies usually lose money on every console they sell, so that's not really a benefit...

The difference is, emulators seem to offer a better experience than a Switch. Isn't it...anti-competitive not to allow that?

That being said, if Valve taking a harsh stance against emulation convinces Nintendo to bring their games to Steam, that can only be a good thing.

I don't really have a horse in this race, but that's how I see it.

Quoting: LoftyId argue Retro gaming is becoming more popular than current year gaming. Because most AAA games are garbage.
On this, I can agree. Though I still really like Rainbow Six: Siege for the social aspect.

GitLab takes down Nintendo Switch emulator suyu due to the DMCA
22 March 2024 at 12:35 am UTC Likes: 5

Quoting: LoftyNot that i ever want to side with a giant mega corporation but i can kind of understand the Nintendo perspective on switch emulation, i mean people are emulating games that are practically day one release on emulators, sometimes games that have been leaked. Emulation is meant for game preservation and nostalgia (edit* not exclusively) It's not very nostalgic emulating a current gen game on non supported hardware and it's not a game that needs preserving whilst its still on immediate sale.
Many emulators have emulated current generation games for other hardware.

Dolphin emulated Gamecube only 2 years after it was first released, in 2003.

PCSX2 started in 2002, only 2 years after the Playstation 2 was released. PCSXR was started 4 years after the first playstation released, and the emulator would eventually be used by Sony themselves in their classic console.

Connectix was released 5 years after the first Playstation was released.

PPSSPP started 7 years after the PSP was released while it was still being sold, which is the same amount of time between when the Switch was first released and now.

Bleem! emulated Sony games for the Sega Saturn in the same generation.

Unsurprisingly, Citra was started 3 years after the release of the 3DS.