jetlag diversions - llvmpipe 512-wide vector support

I was travelling last week, and got back to Mike rebasing the zink-video branch and using LLM powerups to fix the final bits of it. We had been locked in a death stare for a few years, and he flinched first. But it got me thinking about another stalled branch I started working on ages ago.

Adding support for avx512 to llvmpipe. The basics have been there, but running LP_NATIVE_VECTOR_WIDTH=512 piglit exploded in a bunch of fragment shading paths, mostly blending and depth handling. This should work even without actual avx512, we just make LLVM generate worse code. I'd gotten it most of the way and then fell over some 1d texture and RGB32 type failures and let it slide when more urgent work came up.

Well this week I had tiredness, and inspired by Mike I decided to dust off my old branch and let Opencode + GPT Terra Pro 5.6 have a go at closing the final gaps. It started finding a bunch of problem, and I chewed through a lot of my monthly quota, and it was generating a lot of good work, but costing a lot of tokens and taking a long time. It closed the gap on a bunch of the 512 wide work over a day or two.

I then decided to switch to Astra, and it was so much better/quicker/cheaper for this job. It started to find other problems in llvmpipe that I hadn't seen, it found some bugs in the 128-wide handling for 1D framebuffer fetch while looking at the code for 512-wide framebuffer fetch. It identified the current test gap and wrote a test filling it. It found a 128/256 difference on a misc piglit fog test and it identified the conversion path that was failing. I had it review the patch series I wrote and Terra had fixed, and it found a bunch of cleanups and cases where the 4/8/16 lane code be made common.

I fixed a niche bug in geometry shader indirect loads (without the LLM) and an egl fd = -1 problem valgrind popped up.

All the niche fixes are pushed, and the 512-wide support is in an MR, it's still all my code, I've just cleaned it up a lot.

I also don't have any avx512 hardware, so I can't answer is it faster until I either rent some AWS time or find a machine in RH, but if anyone else wants to test gears at least it should be possible now. 

 

Comments

Post a Comment

Popular posts from this blog

fedora 43: bad mesa update oopsie

F43 picked up the two patches I created to fix a bunch of deadlocks on laptops reported in my previous blog posting. Turns out Vulkan layers have a subtle thing I missed, and I removed a line from the device select layer that would only matter if you have another layer, which happens under steam. The fedora update process caught this, but it still got published which was a mistake, need to probably give changes like this more karma thresholds. I've released a new update https://bodhi.fedoraproject.org/updates/FEDORA-2025-2f4ba7cd17  that hopefully fixes this. I'll keep an eye on the karma. 
Read more

a tale of vulkan/nouveau/nvk/zink/mutter + deadlocks

 I had a bug appear in my email recently which led me down a rabbit hole, and I'm going to share it for future people wondering why we can't have nice things. Bug: 1. Get an intel/nvidia (newer than Turing) laptop. 2. Log in to GNOME on Fedora 42/43  3. Hotplug a HDMI port that is connected to the NVIDIA GPU. 4. Desktop stops working. My initial reproduction got me a hung mutter process with a nice backtrace which pointed at the Vulkan Mesa device selection layer, trying to talk to the wayland compositor to ask it what the default device is. The problem was the process was the wayland compositor, and how was this ever supposed to work. The Vulkan device selection was called because zink called EnumeratePhysicalDevices, and zink was being loaded because we recently switched to it as the OpenGL driver for newer NVIDIA GPUs. I looked into zink and the device select layer code, and low and behold someone has hacked around this badly already, and probably wrongly and I've no ide...
Read more

sketchy vulkan benchmarks: lavapipe vs swiftshader

 Mike, the zink dev, mentioned that swiftshader seemed slow at some stuff and I realised I've never expended much effort in checking swiftshader vs llvmpipe in benchmarks. The thing is CPU rendering is pretty much going to top out on memory bandwidth pretty quickly but I decided to do some rough napkin benchmarks using the vulkan samples from Sascha Willems. I'd also thought that due to having a few devs and the fact that it was used instead of mesa by google for lots of things that llvmpipe would be slower since it hasn't really gotten dedicated development resources. I picked a random smattering of Vulkan samples and ran them on my Ryzen  workstation without doing anything else, in their default window size. The first number is lavapipe fps the second swiftshader. gears: 336 309 instancing: 3 3 ssao: 19 9 deferredmultisampling:  11 4 computeparticles: 9 8 computeshader: 73 57 computeshader sharpen: 54 34 I guess the swift is just good marketing name, now I'm not sure ...
Read more