07:31 sima: tzimmermann, mlankhorst might want to backmerge drm-next into misc trees because we're still stuck on -rc1 of the previous release
07:31 sima: which isn't great since it lacks months of bugfixes ...
07:31 sima: imo best to avoid -rc1/2 in -next trees as much as possible
07:33 tzimmermann: sima, indeed. i'm taking over drm-misc-next today. give me a bit to forward to -rc7
07:33 sima: tzimmermann, just backmerge drm-next so it has all the drm stuff
07:33 sima: since that's not yet in the middle of the merge window
07:33 sima: if I didn't screw up checking that
07:33 sima: drm-misc-next-fixes probably needs the same
07:33 tzimmermann: that's what i intend to do
07:33 sima: ah drm-next is only at -rc6
07:34 tzimmermann: sima, -rc6 is also ok
07:35 tzimmermann: still better than an -rc1
07:35 airlied: I'm just pushing out -rc1 rebases for drm-fixes/drm-next now
07:36 sima: tzimmermann, might need to backmerge the pr tag if airlied pushed already, otherwise we're back on an -rc1 and all that fun
07:37 tzimmermann: ha! still catched the -rc6
07:53 airlied: rodrigovivi, jani : topic for CI could do with a rebase to avoid the e1000e conflicting
08:25 tzimmermann: sima, backmerge done
08:25 sima: thx
09:39 DavidHeidelberg: gfxstrand: do u plan to rebase https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15931 ?
09:44 DavidHeidelberg: spoiler, the code you use got a bit reworked :'(
15:03 robclark: eric_engestrom, mupuf: btw now that a7xx gallium has landed, do the a750 runners have any capacity for some native gl CI? (I guess an x1e dev box would be even better... deqp-runner likes having 12 cores ;-))
15:04 mupuf: robclark: as a manual job, it would be fine
15:04 eric_engestrom: robclark: we have some jobs already, but for merge-pipeline testing we're currently blocked by the number of devices we have
15:04 mupuf: We'll get more soon
15:05 eric_engestrom: mupuf: has there been some movement on that front? I wasn't in that loop
15:05 eric_engestrom: on getting more devices, I mean
15:05 mupuf: eric_engestrom: oh, yes, there was :)
15:06 mupuf: IIRC, 6 more are coming
15:06 mupuf: robclark: I have a 740 I need to plug too
15:07 eric_engestrom: nice!
15:36 robclark: mupuf: I guess even just manual would be nice.. (or nightly?).. I can run deqp manually locally for something that is similar to 740
15:37 mupuf: robclark: all manual jobs run nightly :)
15:37 robclark: ahh, ok
15:37 mupuf: Any estimate on the runtime?
15:38 robclark: on my x1e laptop it is very quick.. I want to say <5min for all of deqp-gles3 for ex
15:38 robclark: but I guess what you have has fewer cores
15:40 robclark: mupuf: not sure how much the boards you are using cost.. but this might be a good option for CI capacity: https://www.cnx-software.com/2024/05/22/snapdragon-dev-kit-for-windows-features-qualcomm-snapdragon-x-elite-arm-soc-for-ai-pc-application-development/
15:41 mupuf: We have HDK8650, they cost about $1.5k each IIRC
15:41 mupuf: Is the elite x using the a750? I thought it was a8xx
15:41 robclark: ok, so $899 is cheaper
15:42 robclark: x1-85 is most closely related to a740, afaiu
15:48 mupuf: I see
18:31 meltq: dianders: should we transition functions like mipi_dsi_set_drvdata and mipi_dsi_attach to multi wrappers too? from what i can tell they seem to be somewhat different from the rest? not really sure
20:02 dianders: meltq: I don't think so. The real idea is for functions that are used during panel initialization since it typically is just a whole pile of commands one after another and you want to stop after the first failure.
21:09 gfxstrand: DavidHeidelberg: Yeah, I probably can at some point.
21:09 gfxstrand: I'd honestly forgotten about that. (-:
21:59 DemiMarie: How much of Mesa is able to build on Windows?
22:10 gfxstrand: The core, enought to run lavapipe and LLVMpipe, RADV, the Microsoft drivers.
22:10 gfxstrand: The rest probably doesn't
22:51 DemiMarie: I see.
22:52 DemiMarie: Why RADV and not the other hardware drivers?
22:52 DemiMarie: How much work would be needed to change this, assuming that only clang (and not MSVC) needs to be supported?
22:52 DemiMarie: The context is that I want to specifically port the native context code to Windows someday, but native contexts use many different hardware backends.
22:57 airlied: radv is only ported because someone wanted to use it as an offline compiler not as a online driver
22:58 robclark: DemiMarie: I think the main thing is the hw drivers need some sort of kmd to talk to and they don't know how to talk to windows kmd
22:59 airlied: yeah write a bunch of virtio kmds then worry about userspace :-)
23:00 DemiMarie: airlied robclark: a virtio KMD already exists :-)
23:00 airlied: that supports native contexts?
23:00 DemiMarie: I thought the kernel didn't care
23:00 DemiMarie: I knew about blob objects, but those are needed for Venus (thus Vulkan) anyway
23:02 robclark: if you have a virtio KMD that supports blob resources and ctx types (ie. what venus needs) then you could probably make the vdrm helper know how to talk to that.. some of vk core runtime expects to be able to do things like syncobj ioctls directly (but I'm probably going to need to solve that part anyways, for a different reason)
23:05 DemiMarie: what’s the different resion?
23:05 DemiMarie: Fuchsia?
23:08 robclark: no, the thing I presented about at last xdc, isolating apps from drm driver
23:09 robclark: although I suppose fuchsia maybe needs a similar thing, idk