00:37 mareko: karolherbst: can you report it as an issue?
09:02 hakzsam: cwabbott: can you rebase https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25436 ? I can take a look at the radv changes again, thanks!
15:09 alyssa: airlied: did a C port of d3d tessellator
15:09 alyssa: gcc compiles it 5x faster than the c++, lolz
15:26 Company: if there's one benefit to C over all the fancy modern languages (and C++), it's that it compiles insanely fast
15:26 emersion: Go and Hare fast as well
15:27 Company: a full GTK compile these days (with a hot disk cache) is 20s on my desktop, and somebody on an M2 did it in 5s
15:28 Company: and we're somewhere between 500k-1M loc
15:28 MrCooper: Company: layout transitions preserve image contents
15:29 Company: MrCooper: but if 2 processes use the same image and one of them does a layout transition, won't that break?
15:30 karolherbst: alyssa: though to be fair, C++ compiles fast as well if you don't include the STL
15:30 MrCooper: Company: shouldn't with Wayland (or DRI3/Present), since there's a clear ownership transfer
15:31 karolherbst: but yeah.. nice :)
15:31 karolherbst: ehh wait
15:31 karolherbst: the first comment to the others, and the second one is for you
15:31 MrCooper: Company: hmm, we were talking about the client reading from the image when it doesn't own it though
15:31 Company: MrCooper: yeah, I was about to point at that
15:32 MrCooper: do compositors really need layout transitions though? Honestly not sure
15:32 Company: MrCooper: which is what zmike meant with "you need to acquire it first"
15:32 Company: in Vulkan terms, everything needs a layout transition
15:32 Company: if that needs layout transitions in the real world: no idea
15:33 MrCooper: my expectation would be that Vulkan WSI transitions to presentable layout before handing off to the presentation engine
15:33 pq: C compiles so fast, because the code author has had to do the expensive compilation in their head first.
15:34 emersion: that's not really true
15:34 alyssa: pq: the C version is shorter & clearer than the C++
15:34 Company: pq: considering how many abstractions C++ has, I don't believe the load in C is much less - what compilers do though is verify correctness, and C++ or Rust do that better
15:34 alyssa: now, this was bad C++
15:34 alyssa: but I've rarely seen good C++.
15:36 Company: is that so different with C?
15:37 daniels: MrCooper: we don't use layout transitions in Mesa but the IHVs were specifically asking for it - mostly NV iirc
15:37 alyssa: Company: C++ provides more degrees of freedom to do bad ;)
15:38 Company: daniels: what is a layout transition, in hardware terms? Is it just copying around memory between different caches?
15:39 Company: daniels: I'm mostly asking because I'm wondering because I want to identify it in bug reports - "oh this looks like use-after-layout-transition" or so
15:40 daniels: Company: one example from Intel is that they can, behind the scenes, allocate extra storage to allow them to use 'compression' within the client, then when the image gets handed over to the server, fully resolve the image so the server could read it as if uncompressed
15:41 daniels: or perhaps if you want to render to one tiling layout, but scan out from a different kind of tiling layout, blit between the two
15:42 Company: so you end up with something that looks either completely garbled, or those images where the stride looks off that look skewed
15:45 pq: wouldn't layout transition happen in-place, though? like the compression example, except an actual layout transition which makes access with old layout produce garbage as well, kind-of destroying the contents (temporarily) from at least someone's perspective?
15:45 pq: until transitioning back to the original layout
16:08 Company: I now wonder if I've seen intel transition linear layouts to tiled ones, because the data only needs to be linear when the memory is readable
16:08 Company: or if that was a case where I screwed up LINEAR and OPTIMAL tiling in vkCreateImage()
16:10 Company: can the driver even do anything to a LINEAR layout? because the vkMemory of that can be mapped at all times
16:10 Company: but then, all the swapchain images will always be OPTIMAL I think?
16:18 dj-death: Company: Anv doesn't transition linear to tiled
16:18 dj-death: Company: we only decompress if need be
16:18 Company: then it was me messing up LINEAR and OPTIMAL
16:19 jenatali: Hey everyone, I'm back after ~3 months. Did I miss anything? :)
16:28 alyssa: jenatali: NIR 2.0 merged!
16:29 jenatali: \o/
16:29 jenatali: I'm going to have to re-learn how to write lowering I guess
16:29 alyssa: jenatali: changelog https://gitlab.freedesktop.org/mesa/mesa/-/issues/9396
16:38 karolherbst: :D
16:38 karolherbst: jenatali: uhm.. we do CL C code instead of nir builder now
16:39 jenatali: Instead of? Or in addition to?
16:39 karolherbst: depends which future me you ask
16:39 karolherbst: or rather future alyssa
16:40 karolherbst: jenatali: but yeah... make sure I haven't regressed anything in the past, though I also didn't tinker too much with clc
16:40 karolherbst: _but_
16:40 karolherbst: if you are bored and want something to look into, we are thinking about using llvms spir-v target
16:40 jenatali: Lol I am decidedly not bored
16:40 karolherbst: :'(
16:41 karolherbst: but but
16:41 jenatali: Last I saw that shelled out to an external llvm-spirv tool, didn't it?
16:41 karolherbst: huh......
16:41 karolherbst: ohhh right
16:41 karolherbst: there was that as well....
16:42 karolherbst: let me see who pinged me on it..
16:43 karolherbst: I don't remember
16:43 karolherbst: but it's apparently using the native backend now
16:43 jenatali: Oh cool
16:43 jenatali: I'll be interested to hear what the difference is
16:43 karolherbst: it allows us to use O2 and O3
16:44 karolherbst: so mostly just smaller binaries
16:44 karolherbst: and I think future development shifts to that anyway
16:44 alyssa: jenatali: write code once in C, run both on the CPU in driver and on the GPU from a lowering pass, 0 bindings, native perf, nothing short of magic
16:44 karolherbst: (and also less packaging pain)
16:45 jenatali: Yeah that'll be nice
16:45 jenatali: Let me know how it goes, I'll be interested to switch CLOn12 to that too assuming it goes well
16:45 karolherbst: I mean.. it will be a flag to clc anyway
16:45 karolherbst: but yeah
16:45 alyssa: :D
16:45 jenatali: Yeah, it just means different packaging
16:45 karolherbst: once I test it you can ack the MR :P
16:46 jenatali: Since we statically link everything, it's one less dependency to pull
16:46 karolherbst: yeah
16:46 alyssa: (application: needing to preprocess a draw. do it on the CPU if direct draw, do it in a 1 shot kernel if indirect draw. only write the logic once.)
16:46 karolherbst: some distros build libclc as part of llvm and libclc requiring the translator annoys some
16:46 jenatali: What LLVM ver does that need?
16:46 karolherbst: 17/18 or so I think
16:47 karolherbst: ohh found it
16:49 karolherbst: jenatali: https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2023-10-27&show_html=true#t-1237
16:49 karolherbst: whatever faith said there
16:51 jenatali: Great
16:57 alyssa: have Faith
17:24 karolherbst: alyssa: fyi, I'm planning to review your nir builder v2 MR :P
17:27 alyssa: karolherbst: thanks!
17:46 alyssa: karolherbst: hopefully geom shaders land before i finish tessellation, ;P
17:46 karolherbst: :D
17:46 karolherbst: I see, no preasure to get it reviewed :P
17:46 alyssa: :P
17:47 alyssa: the current MR is just like 2/n
18:22 alyssa: konstantin: thank youuuuu
18:23 alyssa: karolherbst: common code bits now reviewed. will hold off merge a bit to give you a chance but would be nice to merge this week
18:24 HdkR: First the GS, then the TS, then the RT, all the things~
18:27 airlied: alyssa: id be happy to move to C version, not like the one we have has ever really changed much
18:28 karolherbst: alyssa: yeah, I plan to take a look on Wednesday the latest
18:28 alyssa: airlied: ack. will cc you on the MR if I get around to writing it
18:28 alyssa: karolherbst: :+1:
18:43 jenatali: alyssa: looks like my top priority might actually be getting GLOn12 to 4.3 and then 4.5, hooray
18:46 airlied: jenatali: what is missing for 4.3? buffer storage?
18:47 airlied: or do you have to do compute shaders?
18:49 alyssa: jenatali: >:)
18:50 jenatali: airlied: it's just the texture view extension that's missing. Compute is done
18:50 jenatali: The required format casting was only added to D3D in the last couple years
19:28 dj-death: people here remember what the frcp alu stands for?
19:28 jenatali: Float reciprocal?
19:29 dj-death: ah 1.0f / src0
19:29 dj-death: didn't know about the reciprocal name :)
22:58 Company: is there a way to get dmabuf data (read: multiplane YUV) into a GL texture without having a dmabuf?
22:58 Company: or alternatively, is there a way to get data to memcpy into?
23:01 dj-death: just copy it over to a buffer
23:01 Company: I think I can make that happen in Vulkan - just allocate the right VkFormat and set a YcbcrConversion and then just map the vkMemory and copy into it
23:01 Company: what kind of buffer?
23:02 dj-death: do you want the converted data or the data prior to sampling?
23:02 Company: I have the data
23:02 Company: I want to hand it to GL
23:02 Company: but I have it in regular memory, not as a dmabuf
23:03 Company: basically, I decoded a frame with ffmpeg and now I want to make GL do the colorspace conversion
23:04 dj-death: yeah making a buffer and memcpy into it would work
23:04 dj-death: then get the dmabuf and hand it over to GL
23:04 Company: "making a buffer"?
23:04 dj-death: a VkBuffer
23:05 Company: ah
23:05 Company: but that requires VUlkan
23:05 dj-death: yeah
23:05 Company: I want a GL-only solution
23:05 DemiMarie: Company: No expert here, but I thought most GPUs could not handle YUV. In any case, GL has stagnated so I would not be surprised if there is no GL solution.
23:06 dj-death: Company: yeah not sure
23:07 dj-death: Company: weston probably solved that problem at some point ;)
23:07 Company: somebody asked if we can handle regular buffers on top of dmabufs
23:07 Company: and that got me wondering how easy that is
23:08 dj-death: Company: oh... gbm
23:08 Company: yeah, that works for Weston I guess
23:44 Kayden: cwabbott: thinking of using interval trees for a few more things, would be neat to see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22071 land
23:45 Kayden: ah, for some reason gitlab didn't load the new comments, I see you're busily rebasing things
23:59 robclark: Company: if sw decoded data (linear yuv) just do the R8 + R8G8 trick that everyone's done forever.. no need to harm dmabuf's
23:59 Company: robclark: but then I need to write a shader - with dmabufs I don't need to