Faith Ekstrand

I must say... I'm incredibly proud of the Xe kernel driver team at Intel for what they've been able to deliver in the last few years. Incredibly proud.

My final act at Intel was to drop the initial Xe.ko prototype and tell management to put together a team to finish it.

Even though I can claim to have started Xe, what I left them with when I walked away was a pretty bare prototype. About the only really useful things were the UAPI and some of the core design philosophy (which I think they've largely kept). But the actual code? Hopefully they've replaced most of it. 😅 What I left them was pretty much "We can do kernel drivers better. Here's roughly how. Have fun!"

And Matt Brost and rest of the team have pulled it off! They took my half-baked pile of... whatever it was and turned it into a solid and modern kernel driver. Intel is back to being a leader in the DRM subsystem. I'm really proud of them and I hope they're proud of their work. 💜

Feb 5 at 6:46pmWeb
Show threadJulius Schwartzenberg - ЮліусFeb 5

@gfxstrand that's great to see!!

Maybe one day also the PowerVR chips that Intel shipped could get some support again. It seems there's a lot of relevant code out there nowadays! :) :)

Show threadermo | Rune MorlingFeb 6

@gfxstrand Out of an abundance of cultivated naïvité, what do you make of the amdgpu driver?

If it could do with improvements, what would a first good step look like for that to become reality...?

Show threadFaith EkstrandFeb 6

@ermo amdgpu is the oldest modern driver in the tree. That means it's been doing modern things like decoupled synchronization longer than anyone else. Cool! But doing it first doesn't always mean doing it best. We've learned some things since then and not all of amdgpu's APIs have worked out as well as they thought they would at the time.

That's not meant to be critical of anyone. Mistakes get made when you're the first. It's inevitable.

Unfortunately, going back and fixing those is a giant PITA and finding people motivated to do it is hard when most of the AMD developers are focused on the future and new hardware, not fixing past mistakes.

Some of the newer drivers that are a little behind the curve have had the opportunity to learn from those mistakes and have better APIs because of it. That doesn't mean amdgpu is bad. Just that that's the cost of being on the edge.

They're also likely going to be the first to ship userspace fencing for graphics (it's in the works) and I'm sure they'll get that subtly wrong, too, and we'll learn from the experience.

It'll make some of the old mistakes irrelevant as the old hardware starts to fade into memory but I'm sure there will be new mistakes that will haunt us for the next decade. That's sort of the nature of software development.

Show threadDemi Marie ObenourFeb 10

@gfxstrand How would you rate Xe (compared to the other drivers) in terms of security against malicious input? What about Intel’s firmware compared with the others?

For context, I have worked on security-oriented operating systems since 2020 or so, and am still trying to figure out which GPU drivers can withstand what a decently resourced attacker can throw at them.

Show threadDemi Marie ObenourFeb 10

@gfxstrand Right now, the state of the art in the compartmentalized OS world is software rendering, which isn’t fun at all. But when security is a constraint, one doesn’t enable extra attack surface unless one has reason to believe it is safe.

Asking users to judge the risk for themselves is only helpful if they have some information to make an informed decision with. Asking them to only enable it for trusted guests is generally not helpful at all, as the programs that need it the most (games) are generally the least trusted.

I should probably present at XDC2026 about the world I work in.