01:20 karolherbst: airlied: any
01:20 karolherbst: airlied: do you have LLVM assertions enabled?
01:20 karolherbst: because it's an assert inside LLVM
01:20 karolherbst: might as well be an LLVM bug
01:22 airlied: karolherbst: and it didn't happen with llvm17?
01:23 karolherbst: correct
01:23 karolherbst: I'm on LLVM 55172b7005a6f972272f6d79f2b0d15063bc1b1c btw
01:23 airlied: I did get a crash on lgamma test that was more out there
01:23 karolherbst: but anyway, looks like some LLVM pass doing weird things
01:23 airlied: LLVM ERROR: Instruction Combining did not reach a fixpoint after 1 iterations
01:23 karolherbst: airlied: https://gist.githubusercontent.com/karolherbst/5b0d9dd18746717a56f28c88c94c1aa3/raw/b86a58af2df3047901c3e939857f28297652c98a/gistfile1.txt
01:23 airlied: don't think that's a friday thing to tackle
01:24 airlied: okay this build should have debug and asserts
01:24 tleydxdy: so, if I initialize a buffer in vulkan and read the content without initializing it. would I potentially read content leftover from other processes?
01:25 airlied: karolherbst: got LLVM_ENABLE_EXPENSIVE_CHECKS on?
01:25 karolherbst: good question
01:25 karolherbst: nope, it's off
01:57 alyssa: gfxstrand: AGX has imad
01:57 alyssa: but it also allows a left-shift on the addend, so I have a special imadshl_agx for it
02:00 Sachiel: intel had imad too
02:00 Sachiel: but raja didn't like it
02:11 dcbaker: Sachiel: I see what you did there
02:43 jenatali: tleydxdy: on Windows at least, no
03:23 tleydxdy: what about on linux? I'm pretty sure with e.g. X sometimes I would see an application display some leftover from other application when it first start for example.
03:24 tleydxdy: so I'm tending towards that vram content are not being cleaned up by linux
03:24 tleydxdy: but I want to confirm this...
03:25 airlied: yes on Linux in some cases
03:28 tleydxdy: what prompted my train of thought is this, my first reaction was "so what if local mem is leaky, vram is already leaky" https://blog.trailofbits.com/2024/01/16/leftoverlocals-listening-to-llm-responses-through-leaked-gpu-local-memory/
03:29 tleydxdy: then I wonder if application can guard against vram leak. I'm pretty sure they can't cus kernel can swap out their buffer without application knowing
03:31 tleydxdy: what's the situation on system memory then, do kernel (or is there a kconfig) that let kernel zero out pages before giving it to userspace?
03:31 airlied: yeah system memory is zeroed
03:32 tleydxdy: hmm is that the default?
03:33 airlied: yes
03:33 tleydxdy: cool
03:34 tleydxdy: ig maybe a patch to zero out vram would be interesting?
03:35 tleydxdy: do kernel at least zero the vram when it migrates a bo?
03:44 airlied: I think there are some bits around for amdgpu
03:44 airlied: it's not really one place to do it, it's a per-driver thing
04:02 tleydxdy: maybe a ttm callback to clear bo?
05:00 gfxstrand: alyssa: NV also has funny shift things on adds
05:00 gfxstrand: What's with that?
08:31 dolphin: airlied: sent drm-intel-next-fixes (yeah, was looking to do it yesterday but ran out of time)
08:58 MrCooper: tleydxdy airlied: see https://patchwork.freedesktop.org/series/127807/ ; once that lands, making amdgpu finally always clear BOs should be essentially a flip of a switch away
08:59 MrCooper: tleydxdy: note that user-space drivers may re-use BOs from a local cache instead of allocating from the kernel, in which case it's the user-space driver's responsibility (at least it shouldn't leak anything from other processes though)
14:17 tleydxdy: MrCooper: very cool
15:19 jani: daniels: istr asking this before, but don't recall the answer... is it possible to set up git pre-receive hooks on gitlab based repos? I'm thinking /git/drm/drm-intel.git/hooks/pre-receive and dim "--push-option fdo.pushedWithDim=this-was-pushed-with-dim-and-not-manually"
15:19 jani: demarchi: ^
15:32 daniels: jani: oh, that's a really good point
16:27 demarchi: daniels: afair it's possible for self hosted
16:27 demarchi: ops, that should be to jani ^
16:37 daniels: yeah, https://docs.gitlab.com/ee/administration/server_hooks.html would do it
17:28 gfxstrand: Are messages to mesa-dev getting through? Or are the archives just slow?
17:29 daniels: gfxstrand: what are you expecting to see that isn't there?
17:29 daniels: the last I see both in my inbox and in the archives is https://lists.freedesktop.org/archives/mesa-dev/2024-January/226100.html
17:29 daniels: ah I see, you sent a message but it was moderated since the address wasn't a list member
17:29 daniels: released it now
17:30 gfxstrand: Ugh... I must have my old e-mail address in the list
17:30 gfxstrand: I can fix that
17:30 daniels: np, it's allowlisted now
17:33 gfxstrand: perils of silently switching e-mail addresses. I hit a different one today with my old @collabora e-mail.
17:34 mattst88:checks mesa-dev and sees email about mesa not building with... python 2.6?!
17:34 gfxstrand: https://lists.freedesktop.org/archives/mesa-dev/2024-January/226101.html
17:44 alyssa:refreshes phoronix
17:50 kisak: mattst88: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9498 ?
17:51 Calandracas: just want to confirm: rusticl doesn't support online compilation of clcpp?
17:54 Calandracas: Its not a problem, I can still run the sources through clang and llvm-spirv, just a minor convinience while developing
18:04 mattst88: kisak: I was looking at https://lists.freedesktop.org/archives/mesa-dev/2024-January/226102.html -- looks like a different issue
22:46 apinheiro: gfxstrand, I just checked and skimmed your email. Really interesting (thanks btw), and we would really answer it. But having said so ... any reasonable reply would need to wait until Monday, as is midnight now, and I prefer to have a fresh mind before answering. That also include Iago is really good at fully disconnecting on weekends.