01:23 mareko: I think ChatGPT would be a decent CEO
03:03 jenatali: No comment
03:20 HdkR: :D
04:45 robclark: jenatali: so MS/openai is trying to break into the CEO-as-a-service market? :-P
05:14 mattst88:buys chatgpt.ceo domain
12:49 Hazematman: Hey all, based on the discussion yesterday on DMABUFs I created this MR to change the default path for `PIPE_CAP_DMABUF` in gallium to call `drmGetCap`. That way drivers that want to support importing DMABUFs without drm can simply override the default behavior in their driver. I would appreciate some feedback on the change :)
12:49 Hazematman: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21654
13:09 Lynne: err, why in unholy tarnation is vkGetMemoryHostPointerPropertiesEXT on AMD returning VK_MEMORY_PROPERTY_PROTECTED_BIT, which specifically forbids host-visible memory?
13:10 zmike: define "AMD"
13:10 Lynne: radv, of course
13:10 zmike: bnieuwenhuizen hakzsam ^
13:12 hakzsam: Lynne: can you fill a bug report?
13:14 bnieuwenhuizen: Lynne: what do you mean VK_MEMORY_PROPERTY_PROTECTED_BIT? It only returns memory types, no?
13:15 bnieuwenhuizen: and I don't think we have a type returning VK_MEMORY_PROPERTY_PROTECTED_BIT so I'm confused
13:15 Lynne: yeah, me too, it's only returning 0x20 in memoryTypeBits
13:16 bnieuwenhuizen: right, which memory type is that on your system?
13:16 bnieuwenhuizen: (should be memory type 5?)
13:16 Lynne: ah... I mistook VkMemoryPropertyFlagBits for memoryTypeBits
14:23 gawin: wanna merge this hasvk patch https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21444 someone has something against?
15:46 karolherbst: any quick review on this llvmpipe patch? Or does somebody wants to trade review? I kind of want to land it https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21604/diffs?commit_id=b5566bb33da40b0318ff15bb230eaf8bd47e2c3d
15:47 karolherbst: and for our current EVoC student I'd need this MR looked at from llvmpipe folks as well: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20378/diffs?commit_id=fd73b7eaf241485e0e238900ca2a463c251a9f65
15:53 zmike: probably tag airlied/sroland/brianp
19:16 eric_engestrom: `weston --xwayland` prints `xserver listening on display :1`, but is there a way to programmatically get that from outside of weston?
19:16 eric_engestrom: (for scripting)
19:20 emersion: setup a pipe before starting the compositor, write DISPLAY to that pipe with a script auto-started by the compositor
19:20 emersion: would be the most reliable way
19:22 alyssa: pendingchaos: I see you're on board for cmarcelo's plan to delete all non-scoped_barriers :D
19:23 alyssa: once all the infrastructure needed has landed I guess we should make a checklist of drivers to convert
19:24 alyssa: admittedly these cross-tree reworks can be... slow to proliferate
19:25 pendingchaos: deleting all non-scoped_barriers sounds like a good idea
19:25 pendingchaos: but honestly, removing ACO's implementation of memory_barrier_buffer is more because it's an ugly hack that doesn't behave exactly like the scoped equivalent
19:26 alyssa: nv50, zink, r600/sfn, v3d
19:26 alyssa: ok I guess there are only 4 drivers that need to be converted to scoped barriers
19:26 alyssa: I was expecting scarier
19:27 alyssa: admitedly r600 and nv50 both kinda scare me :p
19:30 alyssa: zmike: can I interest you in deleting zink code
19:31 zmike:grimaces
19:31 zmike: my license for utilizing the patented Delete The Code methodology ran out at the start of the year
19:31 zmike: I haven
19:31 zmike: t renewed
19:33 eric_engestrom: emersion: thanks, that's a good idea
19:33 eric_engestrom:looking up how to setup a start script in weston
19:34 daniels: eric_engestrom: man weston.ini, search for 'autolaunch'
19:34 eric_engestrom: thanks
19:34 jenatali: alyssa: I think we have some code to delete if they go away entirely
19:36 alyssa: zmike: :R
19:36 alyssa: wiring up nir_intrinsic_scoped_barrier in zink should be Easy* since it's supposed to just be SPIR-V
19:36 alyssa: *terms and conditions may apply
19:37 alyssa: jenatali: yeah I didn't get around to deleting the dxil code but !21634 lands you can delete all your memory_barrier* and control_barrier code
19:37 zmike: I imagine you could figure it out then if it's easy :P
19:37 alyssa: zmike: man i've got 3 compilers to worry about and none of em are zink's :p
19:37 jenatali: Sweet
19:37 alyssa: dxil already handles scoped_barrier so there's nothing to do but delete
19:37 alyssa: hence why it wasn't on my driver list of shame
19:38 alyssa: zmike: Oooh ooh I know, I don't have any Vulkan drivers to test Zink with
19:39 airlied: i wonder does virgl need some work
19:39 zmike: lavapipe
19:39 alyssa: That's my excuse and I'm sticking with it 😎
19:39 alyssa: Oh drat
19:39 alyssa: foiled
19:39 airlied: not sure what tgsi barriers are
19:39 zmike: mega foiled
19:39 alyssa: airlied: I think virgl is ok
19:40 alyssa: at least, virgl shouldn't be any more broken by this than it already is
19:40 alyssa: venus otoh..
19:41 alyssa: er wait venus doesn't use tgsi does it?
19:41 cmarcelo: alyssa: airlied: tgsi has the idea of memory barrier atomic counter, which we currently don't have in scoped barrier. at one point we thought about havign a nir_var_atomic_counter and for all but TGSI users lower it down into ssbo, but not sure if it is worth it.
19:41 alyssa: TGSI is on its last breath so I don't care
19:41 alyssa: any new TGSI backends are auto-NAK from me
19:41 alyssa: if gfxstrand doesn't beat me to it ;p
19:42 zmike: I still need to implement ttv to optimize zink for nine
19:42 alyssa: auto NAK
19:42 zmike: it's happening
19:42 alyssa: er
19:42 alyssa:auto naks
19:43 alyssa: If you really want to cut out ttn for zink9 then teach nine to produce NIR directly instead
19:45 cmarcelo: alyssa: I thought TGSI was a key part of virgl, is it moving to use sth else?
19:46 alyssa: cmarcelo: erm
19:46 alyssa: I guess I should leave that to a virgl person
19:46 airlied: it cant move
19:46 airlied: its in the protocol
19:47 alyssa: right, i think the question then is "is it currently broken?" because if not I think we're ok
19:48 alyssa: ooh
19:48 cmarcelo: alyssa: it shouldn't be broken now, because drivers are asking for the non-scoped version
19:48 alyssa: OK, I see how this works
19:48 alyssa: cmarcelo: Still ok :-)
19:49 alyssa: Er wait
19:49 alyssa: misread
19:49 alyssa: hum right yes ok I see the problem now :|
19:50 alyssa: Would it be acceptable to translate memory_barrier_buffer to "memoryBarrierBuffer(); memoryBufferAtomic();"?
19:50 alyssa: If so, then we can just have ntt set the extra TGSI_MEMBAR_ATOMIC_BUFFER flag for buffer barriers
19:50 alyssa: and everything works out conservatively
19:50 cmarcelo: I had a local patch to let drivers ask for "do scoped but still feed me the atomic_counter intrinsic", that could also be sufficient
19:51 cmarcelo: as long as TGSI drivers explicit ask for it (may need a PIPECAP)
19:51 alyssa: worst case I guess we could do that
19:51 alyssa: but the above solution is a local patch to tgsi-to-nir
19:51 alyssa: and won't change perf on hardware that lowers atomics to SSBOs
19:51 alyssa: i.e. everyone?
19:52 alyssa: This is my preference anyway
19:54 cmarcelo: need to see what users of TGSI prefer. I think it is fine either have a atomic_counter intrinsic for their sake (would now be properly documented as such) or even the nir_var_atomic_counter (although it seems more noisy).
19:56 alyssa: Other than virgl/svga, I don't think any of the TGSI users care
19:56 alyssa: virgl/svga just passes the buck up to the host
19:56 alyssa: and on top of SSBO hw there's no perf difference
19:57 alyssa: actually, it's r600/sfn that I'm worried about
19:57 alyssa: since it seems to have "real" atomic counters (uniquely)
19:57 alyssa: and it's a NIR backend
19:58 alyssa: though I suspect it's fine to eat an extra "wait_ack" instruction in the rare case where memoryBarrierAtomic() is used but memoryBarrierBuffer() is not
21:00 mareko: lavapipe flake: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/37357938
21:00 marex: jannau: hey, I dug this out New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
21:00 marex: jannau: is that similar to what you have on the m1 ?
21:01 marex: Product: ICY BOX IB-366StU3+B
21:01 daniels: mareko: please put it in an MR
22:30 jannau: marex: asmedia seems to reuse product ids for different products. probably a different chip since it supports only 5 gbps instead of 10 gpbs but worth a try
22:54 marex: jannau: I'll see what I can do, unless someone really wants to start debugging it