Post B5gG1JXvZt7aDoGw6a by azonenberg@ioc.exchange
(DIR) More posts by azonenberg@ioc.exchange
(DIR) Post #B5gCezGdzepp5wqkyW by azonenberg@ioc.exchange
0 likes, 0 repeats
Is anybody using llvmpipe on Arch Linux with Vulkan? Have you tested recently?I'm seeing all kinds of horrible segfaults of trivially simple shaders in ngscopeclient + llvmpipe with Arch on both my own infrastructure and GitHub Actions.When I put a nvidia card on my Arch VM and use their Vulkan driver instead, everything works fine.
(DIR) Post #B5gERl1BrPJp2sROPA by datenwolf@chaos.social
0 likes, 0 repeats
@azonenberg did you try a cross check using an AMD card, also using Mesa but radeondri instead off llvmpipe, to see if it's a problem with Mesa as a whole and not just localized within llvmpipe?
(DIR) Post #B5gEZUhGQWaSk4oFzE by azonenberg@ioc.exchange
0 likes, 0 repeats
@datenwolf I do not have any AMD cards in the VM server at the moment only nvidia.So my options are currently llvmpipe or a GTX 1630.Down the road when I shuffle some stuff around and put a 100G NIC in the box, I am considering trying to squeeze an AMD in to enable testing on a larger cross section of platforms
(DIR) Post #B5gEd14sUZ0Y2RXC3k by azonenberg@ioc.exchange
0 likes, 0 repeats
@datenwolf there is no x or wayland server running so i dont think there is any mesa? or is mesa involved in the vulkan stack still even when nothing is being drawn?
(DIR) Post #B5gFStyO9UIn3uEw4m by datenwolf@chaos.social
0 likes, 0 repeats
@azonenberg Vulkan is display system agnostic. Creating a Vulkan instance is completely independent from displays.The Nvidia proprietary driver has a couple of quirks in that regard, specifically if it sees a X11 or a Wayland display it will only enumerate devices that are driving screens; so all of my programs using Vulkan go through two instance creation steps, with the first one having all the environment variables that point toward X11 or Wayland removed, then one with those vars.
(DIR) Post #B5gFWKx0J2ktbIEKzQ by azonenberg@ioc.exchange
0 likes, 0 repeats
@datenwolf well i dont even have a display server *installed*, this is a headless VM, so it shouldn't be confused by that
(DIR) Post #B5gFdvOZCk4KesjzCi by datenwolf@chaos.social
0 likes, 0 repeats
@azonenberg Vulkan doesn't need a display server. You can create Vulkan instances and open physical and logical devices just fine, without a display server, or any other kind of graphics environment running.Vulkan is also a compute API, and it has been designed for fully headless operation.
(DIR) Post #B5gFjFzW3Zhlz2Z9c0 by azonenberg@ioc.exchange
0 likes, 0 repeats
@datenwolf yeah i'm fully aware, i was wondering specifically about your comment above WRT mesa, and I wasn't sure if mesa was involved in the portions of the stack that were headless or if it only handled drawing stuff to the screen. i havent actually got that deep in its internals
(DIR) Post #B5gFsPoUuIO33LmNIO by datenwolf@chaos.social
0 likes, 0 repeats
@azonenberg What's the output of `vulkaninfo` on the machine in question?
(DIR) Post #B5gFsPzqE7SdcX5Qye by azonenberg@ioc.exchange
0 likes, 0 repeats
@datenwolf The crash I was getting was segfaults deep inside LLVM-generated code with no symbols, and a thread named "llvmpipe".I don't have a full vulkaninfo dump from the VM at that snapshot handy but here's a subset of the info https://dashboard.ngscopeclient.org/tests/920
(DIR) Post #B5gG1JXvZt7aDoGw6a by azonenberg@ioc.exchange
0 likes, 0 repeats
@datenwolf I was able to initialize vulkan and run a couple of shaders without any problems; 13 of my 17 unit tests crashed with weird pointer or memory corruption looking faults in code that seemed to be llvmpipe's JIT binaries from my SPIR-V.When I put an nvidia card in the same VM, it runs without issue
(DIR) Post #B5gGJFDUPjVI0RGJdI by datenwolf@chaos.social
0 likes, 0 repeats
@azonenberg so much I gathered.What I'm wondering is, if the JITed shaders crash, because they're derefing a pointer to something that's supposed to be managed by Mesa, or if the generated code or the JIT itself is buggy.llvmpipe is a Mesa driver after all, and my first hunch at eliminating that variable is by trying a different driver. If weird things still happen with a different driver, than is something broken in Mesa core. Otherwise it's isolated to llvmpipe driver internals.
(DIR) Post #B5gGPAgEC3YZfqWwsa by azonenberg@ioc.exchange
0 likes, 0 repeats
@datenwolf well i dont have easy access to anything else mesa supported on this vm (or any arch instance i have access to) and nvidia doesnt use mesa.
(DIR) Post #B5gGe45Izv2xYuMVc0 by datenwolf@chaos.social
0 likes, 0 repeats
@azonenberg Hmm… I wonder how difficult it would be to replicate your test harness on one of my machines. I have a pretty broad collection of Nvidia and AMD cards available for testing (although most of the Nvidia cards live in lab systems, but I could pull them in a pinch).
(DIR) Post #B5gGux2KSHm6cs1Ppg by azonenberg@ioc.exchange
0 likes, 0 repeats
@datenwolf well it works fine on nvidia. I daily-drive it on a rtx 2080 Ti , RTX 3070, and Quadro RTX 3000 mobile on Debian 13.And I have CI VMs with GTX 1630s on Debian 12 and 13, Win11, Arch, and Ubuntu 24.04. They all work fine running unit tests headless, although I don't have desktops installed so I can't test the actual application on them.The Ubuntu 26.04 VM has llvmpipe and the same tests work fine. It seems to be only the intersection of arch and llvmpipe that breaks
(DIR) Post #B5gIZMQzXuy2vvOGEi by datenwolf@chaos.social
0 likes, 0 repeats
@azonenberg Interesting. It wouldn't be the first time Mesa catching the fallout of the libc and/or the libstdc++ doing something questionable that breaks LLVM, possibly related to threads.Back in 2021 I stumbled over something that broke Mesa's OpenGL texture handling, but eventually turned out to be glibc pthread implementation apparently being unaware that dlopen is a thing and thereby breaking LLVMs static initialization phase.