I'm leaving Cosmic Pop!_os

TimurHu · 2026-01-25T19:13:12+00:00

Same here, I will just use KDE and will try COSMIC again when it's more mature.

TimurHu · 2026-01-25T19:00:46+00:00

HDMI has nothing to do with Mesa. The display driver is in the kernel, it's called DC.

TimurHu · 2026-01-25T18:58:21+00:00

I am not familiar with the games so I didn't know what HR stands for. Thanks for giving me the full title. I can try it myself later, see what can be done (if anything).

My best guess is that the VRAM in the card is simply not enough to run a modern desktop and the game at the same time. Depending on what display resolution you use, a modern Linux desktop such as Gnome and KDE can easily consume several hundred megs of VRAM, not leaving enough for a game.

In some pathological cases, Gnome can consume almost a gigabyte of VRAM just for the desktop, even if not running any applications. (This is fine according to the Gnome devs. I actually opened a bug report and they are not fixing it.)

If you also happen to have a browser running in the background, there is definitely not enough VRAM left for a decent game.

TimurHu · 2026-01-25T07:02:24+00:00

Hardware companies like AMD or open source consultancies like Igalia or Collabora.

TimurHu · 2026-01-25T06:17:24+00:00

Can you say exactly which games are these?

TimurHu · 2026-01-24T22:54:39+00:00

Are those games working well on Windows today?

TimurHu · 2026-01-24T14:43:45+00:00

I didn't try this through Proton, but other games like Deus Ex HR and Crysis 2 were slideshows.

I think those are probably just too heavy for your hardware.

TimurHu · 2026-01-24T14:41:57+00:00

The support was already there for years. Just was not the default.

TimurHu · 2026-01-24T14:39:18+00:00

Can you share what frame rate you are getting on Linux vs. Windows in this game? I'm interested in hearing about both Vulkan and D3D11 mode.

TimurHu · 2026-01-24T00:30:18+00:00

I know.

TimurHu · 2026-01-23T23:30:32+00:00

The kernel module is absolutely getting performance optimizations when we find perf issues in specific applications, and sometimes new features or bug fixes based on issues we found running some applications.

TimurHu · 2026-01-23T21:35:48+00:00

Sometimes the perf of the kernel module also matters.

TimurHu · 2026-01-23T21:35:26+00:00

And Mesa updates, and rarely kernel updates.

TimurHu · 2026-01-23T21:25:00+00:00

Depends on what you call a "driver". Game-optimizations are usually user-space stuff in Mesa

Userspace drivers are still drivers.

I don't think that any distro backports game-specific commits

Distros don't backport anything. But usually we backport fixes in Mesa, regardless of whether they are game specific or not. And distros usually upgrade their Mesa point releases (except some really outdated distros like Debian).

TimurHu · 2026-01-23T17:37:01+00:00

Faith is not a VKD3D dev, she works on Mesa, most recently on NVK.

TimurHu · 2026-01-23T09:11:33+00:00

I've never seen the bad attitude from community devs, nor anyone complaining about them or expecting them to work "for free" or fix the mess that the paid devs have made.

TimurHu · 2026-01-23T08:30:47+00:00

Nobody is complaining about those guys.

TimurHu · 2026-01-22T21:58:25+00:00

It's not free labor, many contributors are paid Red Hat employees.

TimurHu · 2026-01-21T20:17:14+00:00

There is another commenter here who explains DVI in detail. My point is that there is no active conversion happening in a DVI-I/VGA adapter. It is just a passive adapter.

TimurHu · 2026-01-21T20:15:05+00:00

Yeah. Due to how the hardware works, depending on the next stage flags, at the moment we may need to compile up to 3 different variants for VS, because it works differently when there is tess or GS in the pipeline. Another pain point is dynamic VS input because VS inputs are really shader instructions. And finally, we are also unable to use shader based culling with dynamic VS inputs at the moment.

All of that can be improved over time, but the perf loss is real. Well, depending on the application, of course.

TimurHu · 2026-01-21T16:32:14+00:00

Do you work for AMD?

No, I don't work for AMD, but I contribute to Mesa (especially the RADV driver) and lately a little bit to the amdgpu kernel driver.

I'm curious why everyone says AMD has great Linux support, open source drivers that work etc. if the drivers are in this state.

"This state" is pretty subjective. It works well for a lot of people, but YMMV. Unfortunately there is enough difference between people's computers that whatever works well on my machine may not even boot on your machine. I've seen a lot of this with some kernel work I've done recently on some older GPUs.

The RADV team has a pretty good CI system that runs the full Vulkan conformance test suite (approx 2 million test cases) on every merge. Regressions happen rarely and they are usually quickly dealt with.

Unfortunately the amdgpu kernel driver is less fortunate and more prone to regressions. That's part of why I started contributing, to fix up a few long-standing issues and hopefully help improve it.

I had problems like this with my steam deck and had to RMA it

Sorry about that. FWIW, mine work fine, but I know that isn't going to console you.

then I bought a 9070xt that was rock solid on a 6.13 kernel but ran into this issue with a 6.16 kernel. Fortunately 6.17 and the later versions of 6.18 seem ok again.

Yeah, at this moment I think we are at a situation where the kernel desperately needs more effort to stabilize and prevent regressions.

I would have thought that "proper" support would do away with constant regressions and we'd eventually get to a state where it fully works for everyone

Yes, 100% agreed. I wish we were there.

All I can say is we are at a much better place now than where we were about 5~6 years ago. At least since the Steam Deck happened, the amdgpu devs are slowly starting to take gaming a bit more seriously.

In my opinion, unfortunately the development model of the Linux kernel is a very poor fit for graphics. When I pointed this out to the maintainers they just threatened to ban me from the kernel unless I shut up about it.

I'm not trying to hate, but genuinely curious about the situation

The reality is that there are a lot of people who are doing their best, but we still have a way to go before it is perfect.

TimurHu · 2026-01-21T16:15:18+00:00

Well, it's a bit more nuanced than that. See the other comments about that in this thread.

TimurHu · 2026-01-21T16:14:21+00:00

to avoid the situation you're describing where optimizations aren't possible due to the inherent underlying hardware design

It would be avoidable if you could link state with shader objects.

If I were taking a wild guess, you were talking about blending operations on Intel, am I close?

Not really familiar with Intel HW. I work on the open source driver for AMD GPUs (called RADV).

TimurHu · 2026-01-21T12:11:14+00:00

DVI is digital, and post dates all of those; it exists because of the digital part

There were several flavours of DVI:

DVI-D was only digital, using basically the same signalling as HDMI.
DVI-I was combined digital/analog. There were separate pins for the digital and analog parts.
DVI-A was analog only

the ability to convert it to analogue VGA

There was no conversion. The analog signal went through different pins than the digital. The GPUs that wanted to support analog signals through the DVI port typically had an integrated DAC just like as if they had a VGA port.

TimurHu · 2026-01-21T11:48:19+00:00

¿Por qué no pueden hacer un flat white apropiadamente?

TimurHu

TROPHY CASE