06:31 yyds: hello, I ask a question, what diffrent between dri-driver(/usr/lib/dri/*) and gallium-pipi(/usr/lib/gallium-pipe/*) driver?
09:37 MTCoster: For VK_EXT_physical_device_drm, does anyone know if the primary node is supposed to be for the GPU or the display? The spec wording is vague but seems to lean towards GPU, but a lot of software seems to use it for display. I know a lot of hardware doesn't differentiate, but still
09:47 dj-death: MTCoster: for display
09:48 dj-death: MTCoster: by default Anv for example uses the render node
09:55 emersion: MTCoster: are you wondering about split render/display?
09:56 MTCoster: In pvr-land, the display is always a separate drm device to the gpu itself so the distinction matters for us
09:56 emersion: i don't think it's a good idea to carry over the mistakes of mesa's renderonly
09:56 emersion: i'd expose one VkPhysicalDevice for the DRM render node
09:57 emersion: with primary of the render device
09:57 emersion: and leave the separate display device alone, it has nothing to do with vulkan
09:58 MTCoster: That was my initial thought, but it comes into play with VK_KHR_display
09:59 MTCoster: And some software seems to assume the primary drm node returned is for the display
09:59 emersion: what is "some software"?
09:59 emersion: VK_KHR_display is unrelated to the physical device
09:59 emersion: VK_EXT_physical_device_drm queries the physical device only, not what VK_KHR_display might use
09:59 MTCoster: The example I have on hand is the one given in !11616, swvkc
09:59 MTCoster: Gotcha, will stick with the render primary
10:00 emersion: returning the display device is causing lots of pain on the GL path
10:01 MTCoster: Is there an equivalent extension for obtaining the display node?
11:06 emersion: no
11:06 emersion: and i don't think there should be
11:07 emersion: it would be very useful to have a way to figure out that a VkPhysicalDevice can be used with a display device
11:07 emersion: but i don't think it should be a "try using it then figure out what display node the driver picked" kind of thing
17:20 dcbaker: kusma: that devenv issue is caused by the `pkgconfig` module being imported but unusued. the easiest work around is to turn on any OpenGL driver (say radeonsi), which will use the module. The fix is already landed for 1.2.1
17:22 kusma: Yeah, I saw from the issue tracker. But thanks for the info!
17:22 dcbaker: cool
18:49 alyssa: jenatali: test-dozen-deqp has been really slow today, any idea what's up?
18:49 jenatali: alyssa: Blame whoever else is using the runners
18:49 alyssa: I don't mean the queued time or infra
18:49 alyssa: I mean it's spending 20+ minutes in deqp itself
18:50 alyssa: if that's normal.. then the job needs to be split in 2
18:50 alyssa: either we need twice as many runners available for it, or the fraction needs to be halved
18:51 alyssa: Pass: 75208, ExpectedFail: 10, Skip: 324619, Duration: 22:56, Remaining: 0
18:51 alyssa: I see that's with DEQP_FRACTION 4... I think that should be DEQP_FRACTION 8, realistically.
18:52 jenatali: It's not normal. 10-ish minutes is normal
18:52 alyssa: Alright.
18:52 jenatali: Execution speed slows down when other workloads are using the runner
18:52 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/46112511 is the job in question fwiw
18:52 alyssa: the runners aren't dedicated?
18:52 jenatali: No
18:52 alyssa: huh.
18:52 jenatali: They're shared among other fdo projects
18:52 alyssa: is that special to the microsoft jobs?
18:52 alyssa: *windows
18:52 alyssa: or I guess special to the software rasterizer jobs?
18:52 jenatali: No, the Linux runners aren't dedicated for Mesa either
18:53 jenatali: Oh sure the hardware runners I guess are, but the build runners aren't
18:53 alyssa: ok..
18:53 alyssa: well I was told if runtimes are high it's because everything's on fire but
18:53 alyssa: I guess I should close gitlab and pretend I didn't see anything and we can all pretend I didn't say anything
18:53 alyssa: squirrel!
18:54 jenatali: I wish we had dedicated runners, but despite the size of my company, it's incredibly hard to get those kinds of resources allocated for a project like our drivers in Mesa
18:54 jenatali: So, we provide keys and then Collabora manages the runners for us
18:54 zmike: the execs know that if the drivers don't work nobody can see the problems
19:14 dcbaker: zmike: I've got a bunch of unexpected passes on the 23.2 branch with zink, you got any ideas or would you like me to just mark them as expected and move on? https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/944410 (zink-radv-vangough-valve)
19:15 zmike: hm I vaguely recall seeing those fixed
19:15 zmike: so probably mark xpass
19:16 dcbaker: Sweet, thanks