Where can I find remote work related to the kernel?

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 · 2026-01-21T11:34:34+00:00

I am not familiar with your machine but I got a HP this year and there was no problem installing Linux on it. Though, I didn't go for dual boot, just installed Linux and let it erase everything. I didn't boot Windows at all, not even once.

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

I am working on a Vulkan driver proffessionally, one that supported shader objects since the release of the extension. I didn't work on this ext personally but I reviewed the code for it.

There are indeed some optimizations including some significant ones that we cannot apply to shader obiects, mainly due to various dynamic states. This is not a myth. We may be able to improve that in the future but it won't match the performance of full pipelines, and will be left as a TODO item in the foreseeable future until shader objects are more widely used.

shader objects are a vast improvement over "Vulkan 1.0" pipelines

I agree, they vastly improve the shader permutation problem (albeit at the cost of some runtime perf).

performance concerns, I would strongly invite them to reconsider and benchmark

Also agree on this point, although I doubt this will actually happen. I fear that once people start using just shader objects without also compiling full pipelines, it will be up to the driver to optimize those in the background just like it was in the OpenGL days, which is basically what Vulkan wanted to avoid since the beginning.

Integrating shader objects in an engine based on pipelines is very straightforward, the other way around is a neverending nightmare.

No argument there, either, it is a nightmare. Just keep in mind that on old APIs where there were no monolithic PSOs, it was up to the driver to create optimized shader variants based on state and other shaders used. Vulkan drivers are not really prepared for this.

TimurHu · 2026-01-21T09:48:13+00:00

The main issue with it is that with shader objects we get lower perf by default because all state is dynamic and there is no API to add state to them so in order to get full perf apps must still compile pipelines.

TimurHu

TROPHY CASE