07:53 tzimmermann: arnd, did the fix resolve the linker issues wrt font symbols for you?
07:55 arnd: tzimmermann: yes, everything's fine with that version
07:55 arnd: You can add my Tested-by or Acked-by if you like
07:55 tzimmermann: arnd, thanks. i'll send out the update then
09:05 MrCooper: is a KMS driver supposed to generate a hotplug event when the list of modes it advertises for a connector changes, in particular from no modes to some modes?
09:32 emersion: when does that happen?
09:32 emersion: i'd say yes, hotplug event for any KMS state change
09:52 MrCooper: emersion: https://gitlab.gnome.org/GNOME/mutter/-/issues/4657#note_2699272 , looks like during resume no modes are advertised, and no hotplug event after that
09:53 MrCooper: based on your feedback I'd call that a driver issue
09:53 pq: yes, an event seems like a good idea
10:56 glehmann: ugh, nir_io_semantics is out of bits
10:58 karolherbst: seems like "no_validate" is one that could go :P
10:59 karolherbst: but maybe some could be moved into a per stage union?
11:09 glehmann: that would pretty hard I think
11:09 glehmann: maybe should just allow 64bit intrinsic indicies
11:10 glehmann: would also help with nir_io_xfb
11:20 karolherbst: yeah, not having better ideas myself
11:24 karolherbst: how do we feel about this? (f2f16 (fmul (f2f32 a) (fmul (f2f32 b) (i2f32 c)))) -> (fmul a (fmul b (i2f16 c))
11:26 karolherbst: (inputs are f16)
11:27 glehmann: not valid imo
11:29 glehmann: even just with one multiplication it's debatable, but with two, it's a clear no go precision wise
11:30 karolherbst: mhhhh
11:30 karolherbst: yeah, fair
11:43 karolherbst: mhhh maybe I've missed it, but do we have a pack instruction that packs two f32 values with conversions fo f16 into a 32 bit value?
11:45 pendingchaos: pack_half_2x16_split/pack_half_2x16_rtz_split
11:45 karolherbst: ahh cool
11:45 karolherbst: thanks!
11:45 karolherbst: huh seems like it's already wired up, but I don't see it being used... maybe an opt I'm missing
11:46 karolherbst: (pack_32_2x16 (vec2 (f2f16 a) (f2f16 b))) -> (pack_half_2x16_split a b), right?
11:53 karolherbst: okay.. that seems to do bit
11:57 karolherbst: though not sure if that ending up as rtz would be valid mhh
11:57 karolherbst: we can also do rtne
11:59 glehmann: why are you not using vec2 f2f16?
11:59 karolherbst: because it's not a vector op
11:59 karolherbst: it takes two arbitrary sources on hw and nir_opt_vectorize doesn't like to vectorize into a vec2 here
12:00 glehmann: yes, but backends have copy propagation for that and it's a known problem that nir_opt_vectorize sucks
12:00 glehmann: neither should be solved with a new opcode imo
12:01 glehmann: if anything nir needs less conversion instructions, not more
12:01 karolherbst: how should I vectorize it then? Just add a backend opt for it?
12:03 glehmann: well in an ideal world nir_opt_vectorize would deal with it, but I guess for now you can have a (`vec2`, ('f2f16', 'a@32'), ('f2f16', 'b@32')) -> ('f2f16' ('vec2', a, b)) pattern in your backend opt_algebraic
12:04 glehmann: maybe with an is_used_once on the f2f16 if that's a tradeoff you want to have, maybe not
12:05 karolherbst: yeah.. will play around with it
13:39 stsquad: I'm trying to figure out where the failure is when guest mesa reports "got error from kernel - expect bad rendering 9" - how can I track the details of what DRM_IOCTL_VIRTGPU_EXECBUFFER triggered in the host?
14:53 digetx: stsquad: check kernel log, add msgs to the ioctl error code paths if needed
15:05 stsquad: digetx: yeah U get nothing from dmesg and env VIRGL_LOG_LEVEL=debug MESA_DEBUG=1 LIBGL_DEBUG=verbose on the host side don't give me much to go on
15:06 stsquad: time to break out gdb
15:07 digetx: I mean ioctl error code paths in the kernel driver
15:08 digetx: most likely number of passed BOs is wrong or something like that, which happened in past
16:07 glehmann: nice, somehow I managed to break xfb, but not vk xfb
16:07 glehmann: or maybe vulkan cts just doesn't have coverage
16:08 zmike: vkcts coverage of xfb isn't the greatest