02:45 tarceri: Trying to run a degp test on zink on lvp and getting the message "ZINK: failed to choose pdev" anyone have any tips?
02:46 zmike: LIBGL_ALWAYS_SOFTWARE=1 ?
02:47 tarceri: That seemed to do something thanks!
02:47 tarceri: Although the test passed and its crashing in CI grrr
02:48 tarceri: although maybe I need to add validation or something
02:48 zmike: I was gonna say you should check the CI log
02:49 zmike: then you can see if it's a validation issue
02:49 zmike: if not then it's probably a caselist
02:49 tarceri: yeah it a validation error
08:42 glehmann: does anything ensure that the second operand of shuffle(_xor, _down, _up)/rotate is 32bit?
08:42 glehmann: looking at the spirv spec, it just says an unsigned integer, but no specific width
08:44 glehmann: and vtn doesn't do any type conversion either, but all NIR lowering assumes 32bit
09:01 karolherbst: glehmann: I suspect the languages do
09:01 karolherbst: it's always 32 bit in OpenCL C e.g.
09:01 karolherbst: wouldn't surprise me if it's the same in glsl
09:02 tzimmermann: javierm, i have a dumb question: why do we remove the platform FB from sysfb_disable() ? https://elixir.bootlin.com/linux/v6.7/source/drivers/firmware/sysfb.c#L66
09:04 glehmann: karolherbst: yeah but that's irrelevant for us as someone could emit their own spirv where it's not 32bit
09:04 karolherbst: I guess they could
09:04 karolherbst: probably should slab some u2u32 on the second arg then inside vtn
09:05 tzimmermann: javierm, we only call sysfb_disable from https://elixir.bootlin.com/linux/v6.7/source/drivers/video/aperture.c#L357 and https://elixir.bootlin.com/linux/v6.7/source/drivers/video/aperture.c#L296 . ammediately afterwards, we move of the registered firmware devices and remove them
09:05 tzimmermann: javierm, can we reduce sysf_disable() to a simple "disabled = true" ?
09:07 javierm: tzimmermann: maybe it's a left over from the time when we haven't moved that unregister logic to the aperture helper ?
09:07 tzimmermann: i think so.
09:07 tzimmermann: it must be from when sysfb_disable() was still called from within fbdev
09:07 tzimmermann: can we clean it up?
09:08 javierm: tzimmermann: yeah, if everything is handled by aperture now I agree that simply disabled = true should be enough (since that's protected by the disable_lock)
09:08 tzimmermann: damnit, i know!
09:08 tzimmermann: there's this gap between registering the device and probing the driver
09:08 javierm: tzimmermann: ah, right
09:09 tzimmermann: apologies for bothering :/
09:09 javierm: tzimmermann: no worries, it's confusing :) I remember we added that to fix a bug but didn't know if still applied after the refactor made for aperture
09:12 tzimmermann: javierm, i do have a few patches for sysfb. i'll post them in a bit
09:13 javierm: tzimmermann: great
09:14 javierm: tzimmermann: maybe include one to the comment to clarify why the remove is needed ?
09:14 javierm: now it only says "It also unregisters a device if this was already registered by sysfb_init()"
09:14 tzimmermann: they also improve resource handling for screen_info. at some point, sysfb will then be able to register apertures by itself without driver
09:14 javierm: tzimmermann: that's cool
09:14 tzimmermann: but it's not there yet
09:14 tzimmermann: anyway, you'll see
09:15 javierm: tzimmermann: Ok, thanks
09:19 javierm: tzimmermann: speaking of sysfb, I think you mentioned that wanted to post a patch to move sysfb_init() to device_initcall() ?
09:19 mripard: sima: I'm not entirely sure how to handle the Broadcast RGB stuff (and the larger HDMI rework). There's been some feedback that we should just merge the thing as it is because it's an improvement already, and some that we should document it even further. What's your opinion there?
09:19 tzimmermann: javierm, i did
09:20 tzimmermann: i can add it to the patchset
09:20 javierm: tzimmermann: great, thanks
10:46 mripard: jani: ok, you convinced me. We need an eBPF panel
10:46 jani: mripard: :D
10:48 jani: mripard: I think it boils down to what the goal really is. you think it's overcomplicated already, and I think it's going to be incredibly more complicated to do all the stuff that's mentioned in the cover letter :o
10:49 mripard: I think expecting the DSI controller driver to handle two panels in the overcomplicated part
10:49 mripard: everybody will get it wrong, you won't test the same code path than the "production" one, etc.
10:50 mripard: so I think we should just have a proper driver panel for it
10:50 mripard: but you're probably right that that driver would be quite complicated
10:52 jani: and, in the end, a lot of the DSI panels are really fussy about configuration and the exact order and timing of things... I'm not convinced a simulated panel is going to get us very far
10:54 jani: and yet I get where the series comes from. DSI is hard, even with the panels, and changes without real panels are going to bitrot fairly easily
10:54 javierm: mripard, jani: did you see Marek's talk about testing DPI and LVDS using a UVC bridge? https://www.youtube.com/watch?v=ncnM8K6A1l4
10:55 javierm: he mentions DSI as something that he wants to explore in the future
10:57 mripard: javierm: I think jani's point is that while it would allow to test some setup of the DSI controller, there's so many variations that we would still get a lot wrong
10:57 mripard: I guess it's a matter of whether we want to test to catch most regressions, or to prove correctness
10:59 javierm: right. And I guess it also boils down on whether one wants to test regressions for the controller but not the panels (because as he said, for that the only option is to test with the real panel)
11:10 jani: boils down to what the goal here is, really
11:10 javierm: jani: yeah
11:12 jani: seems to me marek's goal is completely different
11:14 jani: and for what he's doing, DSI is probably going to be an order of magnitude more difficult than DPI or LVDS, but let's not tell him so maybe something good comes out of it ;)
11:15 javierm: :D
11:42 MrCooper: kusma: no cookie for you from Marge :)
11:42 kusma: Yeah, I'm ashamed!
15:47 tomeu: DavidHeidelberg: any ideas on what I'm doing wrong here? https://gitlab.freedesktop.org/tomeu/linux/-/jobs/53859771#L56
15:49 tomeu: Helen Koike: or maybe you?
15:53 tomeu: oh, nm, found it
15:53 tomeu: I still had drivers/gpu/drm/ci/gitlab-ci.yml in the repo config :)
18:00 DavidHeidelberg: tomeu: you combining mine gfx-ci/linux commit for CI with drm-ci CI :D
18:01 DavidHeidelberg: the .gitlab-ci folder is unexpected in the Linux kernel tree managed by drm-ci (in drivers/gpu/drm/ci) since it just copy everything from the mesa tar INCLUDING the .gitlab-ci there
18:01 DavidHeidelberg: optimal solution would be to omit copying .gitlab-ci, since it has no added value anyway, but dropping my CI commit is the right thing to do 78b99a84ad1d4863eba012a7af7744a56fad4e7c
18:04 DavidHeidelberg: I should read all the messages you wrote.
19:50 HdkR: nir_constant_expressions.py creates a typedef that conflicts with natively declared float16_t on some platforms. What would be the viable workaround?
20:07 HdkR: arm_neon.h in particular declares it, so it conflicts pretty heavily
20:12 HdkR: src/util/half_float.h also declares a type for cpp which conflicts with the definition a bit. That has 16-bit storage where the nir_constant_expressions is just a typedef for 32-bit float.
20:34 HdkR: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10452 Created an issue about it for people to debate how to solve it.
20:53 jenatali: Oof
23:28 karolherbst: kinda a shame that the C standard didn't cleaned up the float types as well, but apparently float/double were well defined contrary to the int types 🙃
23:29 karolherbst: mhh actually
23:29 karolherbst: HdkR: C++23 be like: https://en.cppreference.com/w/cpp/types/floating-point
23:30 karolherbst: though no idea if the C folks want to do something similar