07:59tacokoneko: hello, when I am trying to cross-compile mesa 26.1, 26.2 or main from 64-bit x86 GNU/Linux to 64-bit ARM GNU/Linux, and I am seeing this error every time, what should I do?
08:00tacokoneko: src/compiler/spirv/meson.build:83:23: ERROR: Tried to mix a host machine library ("vtn") with a build machine target "vtn_bindgen2" This is not possible in a cross build.
08:01tacokoneko: here is more of the log: https://pastebin.com/raw/dk8Rp5vU
08:03tacokoneko: cross file implementation https://pastebin.com/raw/ur7JgKjY and llvm-config implementation https://pastebin.com/raw/KYS6bQYj
09:06melissawen: tzimmermann, I applied a patch to drm-misc-fixes (https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4d4be202165e832d74849b4a68e289a2a377039c) and it caused a merge conflict in drm-misc-next with https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3cc8eee9f3460b5b1366155ef31b3193a381fe30
09:07tzimmermann: melissawen, i'm working on it. give me a bit to test the conflict resolution
09:08melissawen: tzimmermann, ah, sure, thanks
09:24tzimmermann: melissawen, should be good again
12:41melissawen: I have a patch to fix a bad merge conflict resolution that I think I should have applied to drm-misc-next-fixes: https://lore.kernel.org/dri-devel/20260807115712.22423-1-mwen@igalia.com/
12:41melissawen: but now, should it go to drm-misc-next instead?
13:42tzimmermann: melissawen, there are some docs on fixing a broken conflict resolution: https://drm.pages.freedesktop.org/maintainer-tools/committer/conflict-resolution.html#removing-a-wrong-conflict-resolution does this help?
13:49melissawen: tzimmermann, I think it's a bit more complex, since it was a very big merge made by airlied here: https://lists.freedesktop.org/archives/amd-gfx/2026-July/148126.html
13:51melissawen: TBH, I think I'm not capable to solve all merge conflicts that probably happened there, so I just checked previous approach and found out that I should resubmit the commit that "disappeared"
13:53tzimmermann: melissawen, so the issue is not in drm-tip but drm-next. maybe airlied can apply your fix directly onto drm-next
13:55melissawen: tzimmermann, right. BTW the drm-tip conflict I mentioned earlier looks resolved on my side, I ran rebuild-tip and looks good, thanks!
14:01glehmann: Does anyone understand this error? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/108797253
14:01agd5f: airlied, daniels can you help set up a https://gitlab.freedesktop.org/drm/amd/kernel tree and include it in the drm maintainer tools?
14:14karolherbst: glehmann: maybe def is NULL?
14:15karolherbst: nir_def_instr_nonconst could then underflow
14:16glehmann: I don't see how it can be NULL
14:17glehmann: it's just this https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/nir/nir_builder.h#L1162 and x cannot be NULL either
14:18glehmann: and this is a build error, not runtime
14:19karolherbst: mhhh
14:21karolherbst: there is some offsetof stuff going on.. the "nir_def[384307168202282325]" is definitely weird. Maybe just some compiler bug?
14:21glehmann: yes, maybe
14:21karolherbst: the index is 0x555555555555555
14:24glehmann: actually, maybe it works if I change the stride check to > 1 instead of != 0
14:25glehmann: because stride of 1 should be impossible, but the compiler can't know that
14:25glehmann: and then the mul source can be invalid
14:27karolherbst: yeah... I can see how that could lead that
14:35glehmann: No, didn't help
14:36glehmann: idk what to do with this, these warning as error builds are just annoying
14:36karolherbst: it's also ubsan which.. takes other code paths
14:38dliviu: lassebq: drm_gem_dma_dumb_create is likely to use the CMA buffers, so you might want to increase in the kernel config the max value.
14:38karolherbst: but also where is the nir_def[0x555555555555555] coming from 🙃
14:40lassebq: dliviu I tried that but even with cma=128M it was still crashing
14:40dliviu: crashing is different from ENOMEM
14:40lassebq: Well, mb I meant to say indifferent
14:40lassebq: Same enomem
14:45dliviu: the most likely place that returns -ENOMEM is drm_gem_dma_create, you might want to add some drm_dbg() there. I don't know how dma_alloc_xx() plays with USB devices in terms of address space allocation
14:46dliviu: maybe the kernel thinks it can only access the device's memory if it goes through the soft bounce buffers, and you might run out of space there.
14:47dliviu: Best is not to try to allocate a buffer in the driver but to import buffers through PRIME. Then it's the job of the userspace to allocate the buffers and pass them on to you via atomic commits
14:47lassebq: I'm building this as a kernel module though. Do I need to recompile kernel to get dbg messages there?
14:47dliviu: is the drm.ko also a module?
14:48lassebq: Nope
14:48dliviu: then you need to recompile kernel
14:48lassebq: Okay
14:49dliviu: well, you need to recompile the kernel anyway when you change the DRM code, but if it were a module at least you could rmmod/insmod it without reboot
15:01karolherbst: glehmann: would be funny if "nir_def *new_idx = NULL;" would fix it
15:41glehmann: it's written before all reads, so that would be wild
15:45karolherbst: yeah...
15:45karolherbst: I don't have any other ideas, I could see this happening with maybe uninitialized memory somewhere and the compiler getting confused, but...
15:46karolherbst: I have no better ideas
15:57glehmann: using nir_imul_imm instead of nir_imul_imm helps
15:57glehmann: this is so silly
15:58glehmann: eh, instead of nir_imul_imm_nuw ofc
16:03karolherbst: yeah.. that skips the nir_def_is_alu
16:07karolherbst: I'm sure it's something with the container_of and some obscure UB that's practically not UB..
16:07karolherbst: uhhhh
16:08karolherbst: maybe the result of container_of is considered stack memory or something weird and that trips of ubsan here?
16:09karolherbst: or some aliasing thing 🙃
16:11karolherbst: nir_def_instr_nonconst does cast to nir_undef_instr, not sure if that's already UB enough
16:19glehmann: yes, it is UB because of strict aliasing
16:21glehmann: also kind of unnecessary, we can just do pointer manual math to get to the nir_instr
16:23karolherbst: yeah.. I hope that's the source of your problem there at least
16:31glehmann: nope
17:09karolherbst: rough
19:48airlied: agd5f: do we have a lot of links pointing at the current drm/amd project to report issues?
19:49airlied: since we will have to move it aside I think
19:50agd5f: airlied, likely
19:59airlied: agd5f: I suppose we can just rip the bandaid off and see what happens, maybe move the current project one called issues and hope people see it and then fix URLs as we find them
20:01agd5f: airlied, what if we keep drm/amd and add a new drm/amdgpu/kernel for just the git repo?
20:07airlied: yeah that should be discoverable actually
20:28DragoonAethis: agd5f: There's also an option of bulk moving all issues to the new project
20:29DragoonAethis: Old issues get closed and have a note + link with the new location, most places within fd.o GitLab get the issue location fixed up, external links still land in the old repo
20:30DragoonAethis: But the old repo can be then archived with one last issue in the old repo + note in the README where to go next
20:35airlied: DragoonAethis: but we also want to move the project into a subgroup which I think means the links would break
20:35airlied: agd5f: okay the tree is there and integrated into drm-tip
20:36DragoonAethis: airlied: okay, so the drm/amdgpu subgroup sounds good
20:36DragoonAethis: then let's move drm/amd into drm/amdgpu/kernel
20:36DragoonAethis: and all the links get a redirect and everything's neat
20:36airlied: agd5f: you are the owner of the tree
20:36DragoonAethis: And the branches on what used to be drm/amd can be set up for drm-tip et al
20:37airlied: so you probably need to add whomever else is going to be allowed push, and you might want to add branch restrictions on the 3 branches (drm-amdgpu-next, drm-amdgpu-fixes, and drm-amdgpu-next-fixes)
20:37DragoonAethis: ...unless it's too late for another move already, but it'd be nice to do it properly now
20:37airlied: DragoonAethis: we never used drm/amd for development, only issue tracking
20:37DragoonAethis: airlied: yeah, and it'd be better to have it in the same repo as the actual dev branches IMO
20:38agd5f: Is there a strong reason to move the issue tracker? I'm not sure how much tooling will break
20:39DragoonAethis: Links will get redirected into the new repo, your issue automation will work if it references projects by IDs, and *should* keep working while the repo redirect is valid
20:39DragoonAethis: But this depends on which API endpoints the automation is using
20:45DragoonAethis: But then the only reason I have is 1 repo > 2 repos for the same thing, so your call