Piero Bosio Social Web Site Personale

But it's not really ideal.

In an ideal world, I'd be able to tweak the compiler bits, add the API translation, and then flip the feature on across the entire Mesa stack. Boom! 64-bit vertex attributes for everyone!

And I could do this. I could do it today. It'd take me an hour or so to type up. The problem is that not everyone uses the common state tracking code and so I can't actually ensure they get the translation. I can provide it but I'd have to hide it behind an enable bit, which only gets set by drivers that use all the necessary common pieces and want the features.

This came up this last week as I was hooking up 64-bit vertex attributes for NVK and looking at how it's handled in RADV today.

This is a feature that should be trivial to implement entirely in common code. On the compiler side, you bitcast double to uvec2 and dvec2 to uvec4. For dvec3 and dvec4, you split them into a uvec4 and a uvec2 or another uvec4, respectively. NIR already has all the code to do this.

Then, on the API side, we could just translate between the Vulkan descriptions of vertex attributes to one that's similarly split. So we'd replace VK_FORMAT_R64_UINT with VK_FORMAT_R32G32_UINT, etc. In the 384 and 512-bit cases, we'd provide two vertex attributes, with the correct respective formats and the top half offset by 16B. This is easy to do in Vulkan because dvec3/4 attributes are already required to consume 2 locations so we don't even have to renumber them.

A bit more on this...

One of the problems I keep running into when trying to do common Vulkan stuff in Mesa is that all the common code is optional. About the only thing that isn't optional is the dispatch layer that handles Get*ProcAddress(). This means that, while I can implement something in the common layer, if a driver isn't using that component for some reason, they don't get the benefit.

The second issue is a layering problem. While the dispatch tables allow common code to call back into the driver, the common code is first and foremost a client of the driver, not the other way around. This means that I can't just add a bit of code and then start flipping on features like you can in gallium. Even if I do add it to common code, all the feature bits and all the format bits are all handled by the drivers.

Also, there's no truly common compiler code so if something requires both API side stuff and compiler stuff, there's no way to do the compiler stuff in common and mandate it. And even if we did, since all the API-side stuff is optional, there's a chance a driver will get the compiler half but not the API half.

The urge to write a gallium-like layer for Vulkan intensifies...

OH: "It makes sense when you remember this GPU was designed to render Angry Birds"

Help! Spirv-opt ate my mediump!

I just enabled ASTC on Tegra with, effectively, one line of code and got it right on the first try.

Do you have any idea how amazing this is?

You know. ASTC. The one format that has a non-power-of-two block size. The only format group NVIDIA supports where the block size isn't square.

First try. Every single Vulkan CTS test for ASTC passes.

On Intel, getting ASTC working was utter hell. We had so many image layout bugs. Block sizes of 4 were assumed all over everywhere. There were x/y mixups that only mattered for non-square blocks. The whole cooncept of a non-power-of-two didn't exist. Our block compressed format handling was also just plumb wrong.

Then Lina and I wrote ISL and put a lot of time and thought into how we do layout calculations to avoid a lot of the anti-patterns in the old code. Everything has units. Everything is an isl_extent4d and those have helpers so you aren't banging on them manually. We carefully ensured that the calculation flow only went one direction and we never multiplied and then divided it back out later. ISL fixed so many bugs.

With NVK, I wrote NIL which was based on our learnings from ISL. After Daniel helped me port NIL to Rust, I took it a step further and encoded the units in Rust types instead of just suffixes on variable names. This means you have to go out of your way to ever screw up a unit conversion.

The result is ASTC in one line of code.

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

Train seat assignment is a register allocation problem. In this essay I will...

Do you have any idea how embarrassing it is when someone from a multi-billion dollar company is like, "We're being on open-source to do this."

You realize it's just like this one guy, right? A guy who's not even really getting paid for it. And you have billions.

Like, maybe you could fund some of that work? Just a thought...

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... 😩