00:00 Venemo: Lynne: awesome, thank you for helping me through all this
00:01 Lynne: sure, thanks for looking into it
00:01 Venemo: of course
00:38 karolherbst: anybody any actual good idea on why this use-after-free can triger? https://gist.githubusercontent.com/karolherbst/6c49f0ef258983ff46e8c91b48e2f7bb/raw/b0faa94ea32508dcea53c217aa1470c8345d8fbe/gistfile1.txt
00:38 karolherbst: *trigger
00:38 karolherbst: loc info on top of 2f205caea484e3882a209d4262f2f1ce1e0734a8
10:11 kode54: Lucky me, I found a regression in amdgpu going from 6.7 rc4 to rc5
10:55 kode54: false alarm, patch from my kernel package, not rc5
15:32 Company: so, I want to test my dmabuf reading code
15:32 Company: for that, I need some reference images/data blobs/whatever, so I can confirm my implementation is actually correct
15:32 Company: is there a way to get those?
15:35 Company: just so I can make sure I didn't accidentally swap DRM_FORMAT_XRGB2101010 and DRM_FORMAT_RGBX1010102 and things like that
15:38 dj-death: afaik it's completely opaque
15:40 Company: not for the linear variant
15:40 Company: drm_fourcc.h even tries to document it
15:41 Company: I could go by those docs, but I'd like to have some external verification
15:43 Company: I also kinda need that if I want to make sure I write the right code in Vulkan
15:45 dj-death: must have misunderstood your question then
15:45 dj-death: I thought you were asking if the dmabuf carries some metadata but its content
15:46 Company: no
15:46 dj-death: you want to mmap the dmabuf and do memcmp on it?
15:47 pq: Company, vivid? Kernel V4L2 test driver.
15:47 Company: pq: that doesn't have all the formats - and it's V4L2's idea of dmabuf formats, which doesn't cover drm_fourcc.h
15:48 pq: right
15:48 Company: they have their own fourccs (dmabufs rock!)
15:49 pq: Nothing comes to mind. :-/
15:49 pq: IGT theoretically maybe?
15:49 Company: I mean, I can just implement something and then wait for someone to file bugs, but that seems like a suboptimal solution
15:51 pq: That's what I've intended to do with Weston testing and so far never got to it yet.
15:51 Company:has recently been annoyed by dmabuf vs Vulkan vs GL vs GLES all having different descriptions for the same and slightly different formats
15:51 Company: so I'm not centralizing the code in GTK that handles those
15:52 Company: and originally I thought I'm just gonna be a genius and write perfect bugfree code, but then it turned out I might not be able to do that
15:52 Company: so now I'm looking for tests
15:53 gfxstrand: Few of us can...
16:01 dj-death: Company: I just found an interesting kind of related drm modifier issue
16:01 dj-death: one more!!
16:02 Company: I don't even care about modifiers yet
16:02 Company: I only know about LINEAR, INVALID, and everything else
16:02 Company: which goes as DONT_TOUCH
16:04 alyssa: i go to gfxstrand for all my perfect bugfree code needs
16:05 DemiMarie: Can nonlinear modifiers be interconverted via a shader?
16:07 dj-death: DemiMarie: interconverted?
16:08 Company: DemiMarie: modifiers are about memory layout, which may involve allocating in a specific region of GPU memory, or just tiling/aligning memory - it's a free for all
16:08 Company: so some of them could probably be conferted with shaders, but I'd go with DONT_TOUCH unless you're driver code
16:09 emersion: pq: tentative has a helper script for this
16:09 emersion: er
16:09 emersion: Company: ^
16:09 Company: tentative?
16:10 emersion: https://git.sr.ht/~emersion/tentative/tree/master/item/contrib/drm-convert
16:11 Company: it has the 8 formats that I already have working
16:12 emersion: lol
16:15 emersion: might be able to use pixfmtdb for this but will require some work
16:17 sima: Company, to add to your fun you also need to test dma-bufs that need the DMA_BUF_SYNC_START/END ioctls
16:17 sima: and/or implicit fence handling (which the above does for you too)
16:17 mattst88: dcbaker: what happened with mesa-23.2 stable releases?
16:18 sima: on top of the format stuff
16:18 sima: I guess a little debugfs node that you can pass buffer metadata and it gives you a dma-buf fd back would be neat for this ...
16:18 Company: sima: I just use that all the time, so I'm on the safe side there
16:18 sima: for implicit sync igt uses vgem
16:18 emersion: sima: isn't this vgem?
16:19 emersion: or system dma-heap?
16:19 Company: sima: currently I use Vulkan to create my dmabufs
16:19 sima: emersion, only the implicit sync stuff I think
16:19 sima: Company, yeah but that limits you to what that specific driver supports
16:19 Company: no
16:19 sima: unless you aim for lavapipe, which I think supports very little
16:19 Company: I just stuff it in a VkBuffer
16:19 emersion: I think system dma-heap would work
16:19 Company: not even
16:20 sima: Company, well but who generates the test data then to make sure it's not wrong the same way as your code?
16:20 Company: vkAllocateMemory() + vkGetMemoryFdKHR()
16:20 Company: sima: right - that requires something else anyway, because Mesa only knows the common formats - plus most of them aren't writable
16:20 Company: like, NV12
16:21 sima: emersion, on x86 at least vgem gives you wc, so no explicit flushing/invalidating needed
16:22 emersion: oh
16:22 Company: emersion, sima: speaking of lavapipe, we had a discussion recently about a future with software rendering (for cloud-based desktops etc), and supporting dmabufs on llvmpipe was something that seemed important
16:22 sima: and yeah I guess adding some code to vgem to fill a buffer with a pattern for a specific format would be useful
16:22 emersion: Company: should already work
16:22 sima: we do kinda have the drm format lib already ...
16:23 sima: DemiMarie, if you know what the modifier does exactly, you should be able to emulate it with a compute shader
16:23 emersion: right
16:24 Company: emersion: llvmpipe doesn't do dmabufs - at least not with EGL
17:48 FL4SHK[m]: Let's say I've got a GCC backend for my GPU where the GPU specific operations (SIMD) are intrinsics in the GPU. Could a Mesa GPU driver use that GCC backend?
17:59 agd5f: FL4SHK[m], mesa already uses LLVM GPU backends for shader compilation.
18:04 dcbaker: mattst88: I happened to them... Let me see what state the branch is in and try to pull something together today
18:04 mattst88: dcbaker: I don't need it or anything -- I was just curious
18:05 mattst88: 23.3.1 was just released today, so I'm not sure there's much point in 23.2.x stable releases at this point
18:05 dcbaker: Yeah, this was just a me issue
18:05 dcbaker: :(
18:06 FL4SHK[m]: <agd5f> "FL4SHK, mesa already uses LLVM..." <- I'm developing a new GPU and I find GCC easier to write backends for than LLVM.
18:06 FL4SHK[m]: Is it possible to use GCC instead of LLVM?
18:06 mattst88: dcbaker: don't worry about it -- you've had a ton of stuff going on
18:06 agd5f: FL4SHK[m], sure in theory
18:06 FL4SHK[m]: cool
18:06 dcbaker: Yeah, I still shouldn't have just let if fall on the floor though
18:06 FL4SHK[m]: I'll work towards that
18:15 DemiMarie: FL4SHK: Honestly you would be better off writing a native Mesa backend. Mesa is moving away from LLVM because it causes quite a few problems.
18:16 FL4SHK[m]: oh I see
18:16 FL4SHK[m]: that's fine with me
18:17 FL4SHK[m]: Out of curiosity, can you tell me what kind of problems exist?
18:25 DemiMarie: https://www.gfxstrand.net/faith/blog/2022/01/in-defense-of-nir/ from gfxstrand
18:39 FL4SHK[m]: cool
19:43 alyssa: preemptive nak on new LLVM (or GCC or QBE or whatever) gpu backends in mesa
19:44 alyssa: amd's grandfathered in but if it were proposed today it'd be a nak from me tbh
19:44 alyssa: (and amd is moving towards aco anyway)
19:50 airlied: a gcc backend for a gpu would be the most pointless place to start
19:51 airlied: shows someone designing a cpu :-P
20:06 FL4SHK[m]: it really depends on the design of the GPU
20:07 FL4SHK[m]: if GPUs are a large number of scalar cores, then they're a kind of CPU anyway
20:07 FL4SHK[m]: I know GPUs are arranged in SIMT configurations
20:07 FL4SHK[m]: I intended on doing just that
20:51 alyssa: if this is a hobby project only, do what you want & don't let anyone rain on your parade :>
20:51 alyssa: but for in-tree mesa drivers... anything not-NIR in 2023 is a really hard sell for me
20:53 HdkR: What about RISC-V GPU?
20:55 mattst88: IMO, people in this channel spend way too much effort answering questions about speculative/impractical/unrealistic ideas
20:55 kisak: if the hardware is GLES 3.1 era at least, there's a pretty big carrot to bootstrap Vulkan and get it healthy enough to run Zink to bring up both Vulkan and OpenGL at the same time.
21:03 FL4SHK[m]: <alyssa> "but for in-tree mesa drivers..." <- I'm happy to make a NIR driver
21:08 agd5f: I would argue that fixing any deficiencies in LLVM would be a better long term solution as compute and gfx start to converge more, otherwise, you end up writing two compilers which sucks
21:28 DemiMarie: agd5f: The hardware is different and needs a different IR
21:29 mattst88: DemiMarie: seriously? stop.
21:32 airlied: agd5f: haven't people been trying that for 15 years now :)
21:32 airlied: maybe fastisel will solve all my problems
21:33 airlied: I think llvm is fundamentally at odds with being a compiler you'd want to use at runtime esp in gaming scenarios and efforts to change that are very difficult
21:34 airlied: for compute and offline usecases it likely has a lot better advantages in abiltity to optimise
21:34 airlied: but I don't think divergence is solved problem
21:40 agd5f: perhaps, but I think a lot of it is NIH. Rather than fixing someone else's project, I'll just write a new one tailored to my specific use case.
21:47 airlied: I think if I was designing a SIMD type thing I'd go LLVM, for SIMT I think NIR is definitely superior
22:36 DemiMarie: mattst88: will do