@gfxstrand@social.treehouse.systems

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 12mo ago

Mesa is working to update our contributor guide. Can you guess why?

Did you guess AI?

Because if you did, you'd be right. I don't want to put anyone on blast here so please don't go digging to find the motivating MR and harass the contributor or anything like that.

But the situation was exactly what you might think. Someone ran ChatGPT on the code and asked it for suggestions on making it more performant. They applied a bunch of the changes against their local branch, tested it, and found that it gave maybe a 0.5-1.0% perf boost in some titles.

That's totally fine. I don't care what tools you use to find a bottleneck. I'll happily take more FPS, no matter who found the issue or how. If some AI assistant helps you find things no one else has found and lets us make drivers faster, great!

But that's not what happened.

What happened next is that they then tried to make it the Mesa project maintainers' job to sort through the shit ChatGPT spit out and decide what's useful and what's not and why the changes helped and whether or not they were correct. The contributor had no no idea and, more importantly, they had no desire to actually learn about the Mesa code-base or the hardware in question. They just wanted to run ChatGPT and send its suggestions towards upstream.

This is not useful. This is not contributing. It's just burning maintainer time sorting through AI hallucinations. We have enough mediocre code to review that comes from actual humans who are actually trying to learn about Mesa and help out. We don't need to add AI shit to the merge request pile. If you don't understand the patch well enough to be able to describe what it does and why it makes things faster, don't submit it.

So now we're making it really clear: If you submit the merge request, you're responsible for the code change as if you typed it yourself. You don't get to claim ignorance and "because the AI said so". It's your responsibility to do due diligence to make sure it's correct and to accurately describe the change in the commit message.

Some things shouldn't have to be explicitly written down but here we are... 😩

755

25

447

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 5mo ago

RE: @collabora@floss.social

In case you missed, it, my blog post about memory optimization in NIR was published today.

floss.social

50

3

33

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 4mo ago

Hey, look! I wrote another compiler.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41841

gitlab.freedesktop.org

38

6

12

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 4mo ago

II complain about #freedesktop GitLab reliability sometimes but it could be worse. We could be on GitHub.

social.treehouse.systems

35

0

7

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 2mo ago

RE: https://floss.social/@collabora/117009529861785253 Little Kraid update, now in blog post form:

floss.social

9

0

5

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 2mo ago

Unoptimized rust is annoyingly slow. I'm not really complaining that much because the optimizer does eat all those layers for lunch, just like it promises to. It's just a little annoying to watch the C code base be so much faster in debug builds.

7

1

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 7mo ago

Boots up DragonAge: The Veilguard on NVK to test something.

Hunh... Since when did that run at 60 FPS?

We're making progress. 😁

41

1

6

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 7mo ago

Sometimes, just for fun, you have to actually use your shit and feel proud of yourself.

Other @collabora@floss.social folks are preparing for a demo at an upcoming trade show. They're going to do an NVK demo at the booth again and this year we decided to demo some games. (Last year was some WebGPU demos running in Chrome.) So I installed Jedi: Fallen Order and fired it up.

At first, it was kind janky. It was playable but you wouldn't want to play like that for hours. Then I realized it was running at 4K. At FHD, it was a buttery smooth 60 FPS. At max settings. On a laptop! Honestly, the fact that I could keep 4K above 20FPS on a laptop GPU was pretty surprising.

So, yeah, I spent a chunk of the afternoon being a Jedi. Got to make sure the demo is good and stable! 😂

42

1

6

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 2mo ago

RE: https://masto.ai/@phoronix/117023122749558085 Seeing this number never ceases to amaze me. When I started in graphics, 1% was the glass ceiling we could never hope to break.

masto.ai

4

0

2

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 6mo ago

Replying to

New blog post out! "Re-thinking framebuffers in PanVK" https://col.la/framebufferspanvk

col.la

18

1

12

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 11mo ago

Another week. Another LLM MR that makes no sense and burns maintainer time. Could we all please just stop with this?

48

0

20

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 7mo ago

Wow! Turns out refactoring the universe broke something. Who'd have thought. 😅

16

0

1

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 3mo ago

Replying to

@karolherbst@chaos.social @thephd@pony.social Yeah, I don't particularly love writing compilers. But here I am, writing my 3rd. I think it's 3. It's 3 I've written (if you don't count the SPIR-V parser). But I've worked on more.

3

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 5mo ago

Replying to

@aras@mastodon.gamedev.place Well, I already know it’s been read and appreciated by at least 2 people!

4

1

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 5mo ago

Replying to

@dotstdy@mastodon.social Yes and no. Yes, that’s what the spec appears to say but it’s deceptive. The problem is that you can’t really reason about aliasing from a positive direction like that. If it’s just variables, sure, that’s fine. But you can have aliasing pointers even without aliasing variables. For example, s.a[0] and s.a[i] may alias and that’s just with one variable. So when we’re trying to reason about this inside the compiler, we have to be super careful. First, we chase the dereference chains back as far as we can. If we can chase both back to variables and those variables don’t alias, then we’re good. If they might alias, then we’re toast. If we can chase both dereferences back to a common ancestor, then we play the game of trying to prove they don’t point to overlapping ranges in the variable. If we can’t chase one or both of them back to a variable and we can’t find a common ancestor then, again, we have to assume the worst. The “you can assume no aliasing” only really helps with the first case. The rest is all up to the compiler to figure out. IMO, the way we specified this stuff in SPIR-V was a mistake. Same goes with having a NonUniform decoration instead of a Uniform hint. They made sense in the context of GLSL but don’t generalize well. We (SPIR-V spec folks) are working on digging our way out of both of those holes but it’s hard now that the wrong precedent has been set.

4

8

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 5mo ago

Replying to

@dotstdy@mastodon.social We do the best we can with what we’re given, just like a C compiler. And just like a C compiler, you can sometimes get better output by using temporaries and avoiding unnecessary pointer accesses.

1

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 5mo ago

Replying to

@dotstdy@mastodon.social Oh, we do look at the decorations and try to apply them. We just flip them first.

1

6

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 5mo ago

Replying to

@dotstdy@mastodon.social Oh, yeah, BDA makes everything tricky. We tried to spec something but when pointers can get materialized out of thin air it can be hard to reason about them. The good news is that unless you’re interleaving access to multiple external pointers (which isn’t common in graphics), we should still be pretty good at sorting it all out.

1

4

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 5mo ago

Replying to

@dotstdy@mastodon.social Oh, that’s just because AMD’s caching situation in bonkers. But also, marking stuff appropriately RO will probably help NVIDIA, too, because it’ll enable their constant caching mode which is a lot faster. (Though it’s less bonkers than AMD’s scalar cache. 😂)

1

2

0

Faith Ekstrand @gfxstrand@social.treehouse.systems

· 5mo ago

Replying to

@aras@mastodon.gamedev.place It would be interesting to see how well that actually works. NIR isn’t really meant to go into GLSL but we do go into SPIR-V for Zink and GLSL via VirGL so the translation is possible. I just don’t know if it would then throw off the driver compiler or not.

1

0