00:09 kode54: Another migration.
00:09 kode54: ?
00:09 kode54: Why is there now a migration every few weeks?
00:10 airlied: it's the same one, just either retries or different stages of infrastructure pieces
00:11 kode54: Oh, so this migration has just taken over a month now
00:11 kode54: Sorry it’s causing so much trouble
00:20 benjaminl: yeah... gitlab is an operational nightmare even on my two-user instance. 1+ month for a upgrade of a large instance sounds about right
00:21 benjaminl: my condolences to people working on this
04:24 YuGiOhJCJ: hello, I am using the driver "intel" with the option "DRI" set to "crocus" in Xorg, it's working fine for OpenGL apps like "glxgears" but when I try Vulkan apps like "vkcube" I get an error saying that I should enable DRI3, indeed when I check the logs of Xorg, I see that only DRI2 is enabled, nothing about DRI3, how to set "DRI" to "crocus" and "DRI" to "3" at the same time in my /etc/X11/xorg.conf.d/92-intel.conf file please?
04:27 airlied: don't use driver "intel"
04:27 airlied: you shouldn't need an xorg.conf at all
04:30 YuGiOhJCJ: I need a xorg.conf because I have an old xorg-server and a recent mesa, so xorg-server by default tries to load the deprecated "i965" file from the Amber branch which is not what I want because it is not anymore available on my computer, so I have to specify to use "crocus" in my xorg.conf, it is mandatory in my case
04:31 airlied: does your old X server have dri3 support?
04:31 YuGiOhJCJ: is there an easy way to check that?
04:32 airlied: xdpyinfo should show DRI2 and DRI3
04:32 airlied: but anyways use modesetting instead of intel and it might just work
04:33 YuGiOhJCJ: indeed DRI3 is missing with xdpyinfo, I only have DRI2
04:34 YuGiOhJCJ: it's weird because I am using the exact same xorg-server version on another computer with and AMD graphics card and DRI3 is enabled I can see DRI3 with xdpyinfo and in the Xorg logs: "[ 24.323] (==) AMDGPU(0): DRI3 enabled" is it possible that DRI3 works with AMD but not with intel/crocus?
04:35 airlied: ah yeah probably intel turns off dri3 for some reason
04:35 airlied: the manpage says it should support all of them when you specify the name
04:36 YuGiOhJCJ: yeah but the problem is that I already set "DRI" to "crocus" so I don't think I can set to "crocus" and "3" at the same time
04:37 airlied: no but the manpage does say it should enable 3 if possible
04:37 airlied: try changing it to 3 and use MESA_LOADER_DRIVER_OVERRIDE=crocus
04:37 airlied: inside the session
04:40 YuGiOhJCJ: wait, I only set it to 3, without loading "crocus" and it wotks! glxgears and vkcube are working at the same time
04:40 YuGiOhJCJ: *works
04:41 YuGiOhJCJ: I see the error in the Xorg logs trying to load the file "i965_dri.so" but I guess it tries to load something else after that
04:46 airlied: not sure the intel driver really uses the gl driver anyways, at least for dri3
04:47 YuGiOhJCJ: do you understand this output? https://pastebin.com/tQttYEQ0
04:47 YuGiOhJCJ: "crocus" is not used anymore so I am wondering what is used
04:48 YuGiOhJCJ: but it's working fine, I am happy of the result, I am just wondering what happened exactly
04:49 airlied: YuGiOhJCJ: the X server with intel driver will only use the GL driver for some dri2 stuff, if dri3 is working you probably won't notice any issues
04:56 YuGiOhJCJ: ok, I compared with the old output with intel/crocus: https://pastebin.com/G4TjEWkJ it seems that instead of "DRI driver: crocus" we have "DRI driver: i965", so I am not sure how the Xorg server is able to load the i965 driver because the file is missing, we see the error but yeah it's working like that
04:58 airlied: as I said the X server doesn't matter unless you are using glamor, it's what get loaded on the client side that matters more
05:05 YuGiOhJCJ: what is weird is that if I don't specify "DRI" "3" in my xorg.conf file, then I only have DRI2 enabled and so "vkcube" is not working
05:06 YuGiOhJCJ: in the man of the "intel" driver, it is said that "Default: All levels of DRI are enabled for configurations where it is supported." so I expected that DRI3 would be loaded by default
05:06 YuGiOhJCJ: maybe it's because my Xorg server is old and has an obsolete behavior I don't know
05:31 RAOF: Hm. It seems like it's possible to get _every_ error return (EBUSY, EINVAL, EACCES) for an asynchronous non-modeset atomic commit even with entirely correct usage?
09:15 wv: I'm on imx53, seeming to have some issue with RGB565. I patched kernel so it only advertise RGB565. Also our application is only using RGB565 (cog webkit through WEBKIT_EGL_PIXEL_LAYOUT=RGB565), So I would assume that only 6 5 6 MSB's are used. However, it seems colors are changed at the display output (also 3 LSB's are changing). Display is connected via 24 bits to the LCD port. Is IPU still applying corrections?
09:48 MrCooper: RAOF: EBUSY means there's still a pending commit for any CRTC which has state in the new commit; EACCES means a connector/plane CRTC_ID property has an invalid CRTC ID
09:48 MrCooper: EINVAL should mean some invalid state in the commit, or a bug in the validation code
10:04 MrCooper: can Nvidia & Intel discrete GPUs scan out from system memory?
10:18 MrCooper: benjaminl: this was a migration to a new cluster; upgrades to new GitLab versions normally seem pretty straightforward to us, from my PoV as someone who hasn't been actively involved in it
10:25 sima: MrCooper, they can't even texture from system memory in many cases for reasons on intel iirc, much less scan out
10:26 MrCooper: heh, that's rough
10:28 tnt: So they can only copy to/from system memory and that's it ? Or can they do buffer/vertex data ... ?
10:31 alyssa: tarceri: what driver hits th ntt thing
10:31 alyssa: can't repro withthe shadr test on softpipe
10:31 alyssa: (loop gets unrolled or something)
10:33 alyssa: ok, repro'd by disabling unrolling
10:33 alyssa: thanks
10:37 enunes: emersion: I tried to look at your branch for https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/327 but it seems to have disappeared with the gitlab issues, can you push again?
10:37 emersion: oh right
10:38 emersion: should be fixed now
10:39 enunes: thanks
10:41 sima: tnt, iirc it's no using lossless compression (precompressed formats) and no using atomics or something like that
10:41 sima: *precompressed formats are fine I meant
10:42 tnt: sima: tx
11:08 emersion: ty daniels!
11:09 daniels: np :)
12:29 wv: does the kms driver of ipuv3 applies some color correction by default? It tends to change the pixels surrounding other colors (blue background, 1 white pixel, also pixels around the white one are not exact the blue as intended)
12:37 lynxeye: wv: I'm not aware of any color correction being applied by default. If you want to dig more into this the place to look at is the IPU DP setup (ipu_dp_* functions in the kernel driver)
12:38 wv: lynxeye, but can this be explained by a color correction? We have background color #00005b , so some blueish. Then we put one white pixel #FFFFFF, and pixels around that white pixel (left/right/top/bottom) become #000052
12:39 wv: is that what a color correction does? (I'm not familiar with that)
12:42 pq: wv, where and how do you measure the resulting pixels?
12:43 wv: our display output go to a FPGA, which takes in the values. Giving us the opportunity to read the values directly
12:43 pq: what's is "display output"? HDMI signal?
12:45 pq: wv, could it be that the signal is temporarily YCbCr at some point, perhaps even sub-sampled?
12:45 lynxeye: pq: How do you fill the buffer? CPU writing into a dumb buffer or do you use the GPU?
12:45 wv: display port
12:45 wv: 24bit parallel
12:47 pq: lynxeye's question was for wv I think
12:48 wv: pq, I don't say that cannot be the case, I don't know. I know I only kept RGB565 as DRM_PLANE_FORMAT (by removing all others in the enum). So that would make only RGB565 goes through. I don't know where other color encodings would pop in?
12:48 pq: in the DisplayPort signal
12:49 pq: HDMI and I guess DisplayPort can negotiate a YCbCr format for the signalling. That's completely independent of the framebuffer format.
12:51 wv: pq, can this be disabled?
12:52 pq: wv, does your FPGA grabber not tell you what the format in signal is?
12:53 wv: well, it's just 8 bits per color coming in (rgb), together with the pixelclock. If some encoding/decoding happens, should be earlier
12:54 wv: it's a "fsl,imx-parallel-display"
12:55 pq: I also thought DisplayPort is a serial, multi-lane, packet formatted signalling, not parallel. So I don't think you are actually using DisplayPort.
12:56 pq: I don't think my guess of YUV 4:2:0 was right in that case.
12:57 pq: wv, have you tried manually reading the FB after you wrote the white pixel to see if the unexpected values are already there?
12:57 wv: pq, sorry, it's possible I'm wrong. I'm talking about the imx-parallel-display port, which is basically parallel port
12:57 pq: I know nothing of such, unfortunately
12:58 pq: is it intended to drive an LCD panel without... umm, a panel controller or something?
13:00 pq: I'm just wondering if it already includes some hardware signal tuning for the panel analog parts.
13:00 pq: or maybe contrast enhancement
13:03 wv: pq, how can I take a dump of the fb? I just tried a dd of /dev/fb0, but that gives me a console dump, while on the screen I have my blue test thing
13:04 pq: wv, well, how did you write the white pixel?
13:04 wv: using wpewebkit
13:04 pq: yikes
13:04 pq: ok
13:06 wv: but putting a browser dump image as background in weston, gives the same result
13:06 pq: oh you have an image? then use any image viewing tool to check the pixel values
13:07 pq: are they what you expect them to be?
13:07 pq: e.g. geeqie, gimp, whatever
13:24 lynxeye: wv: My bets would be on the KMS driver being innocent. Probably you get dithering in the GL driver with the RGB565 framebuffer.
13:27 DavidHeidelberg: daniels: for the deqp_fraction of venus-lavapipe. Now it's 15, let's say we need 45 for the pre-merge to fit under 15 minutes.
13:28 daniels: wouldn’t 30 be enough to halve it … ?
13:28 DavidHeidelberg: But now, for nightly job 35 minutess * 15 (let's assume "DEQP_FRACTION: null"),, that's 8 hours. Maybe just FRACTION 10 would be enough to be around 1 hour?
13:28 daniels: and yeah, sure
13:29 DavidHeidelberg: daniels: I can try. But for the full job, I think we cannot do the "full job" :D
13:29 DavidHeidelberg: until we get some super-fast runners
13:29 daniels: heh, or shard it
13:29 DavidHeidelberg: daniels: compromise, 35 to get closer to 15 minutes for pre-merge?
13:30 daniels: sounds good
13:30 DavidHeidelberg: daniels: 4 runners per 2 hours? isn't that bit much for venus?
13:33 DavidHeidelberg: I'll start with fraction 10, timeout: 120m for nightly and fraction 35 for pre-merge
13:33 DavidHeidelberg: and we'll see :)
13:37 daniels: nice
13:46 wv: pq, dump is taken via inspector tool, but everything looks ok there
13:47 wv: lynxeye, that would mean issue is somewhere in adreno?
13:51 daniels: wv: btw, you said earlier that you had RGB565 as the format, but the colour string doesn't seem like it would fit into 565?
13:52 daniels: also, are you doing any scaling at any point?
13:54 pq: wv, dithering is not a bug, it's an intentional feature. GL has controls to enable/disable it, but the app needs to use them.
13:54 lynxeye: wv: IIRC GL has dithering default enabled, but most GPUs really only do dithering with reduced color depth formats like rgb565. If you don't want any dithering in GL you need to disable it via glDisable(GL_DITHER), which would be something wpe needs to set in your case.
13:54 pq: wv, can you take a screenshot instead of a inspector tool dump? Maybe inspector tool renders the whole thing from scratch in a very different way?
13:55 wv: daniels, yes, that's also our concern, that we see also the LSB's moving, while we would not expect that.
13:56 wv: pq, that's what I tryed, but dumping the /dev/fb0 while there's a browser running, still dumps the console in stead of the browser
13:56 wv: lynxeye, I'll have a look, thanks
13:57 pq: wv, no, not /dev/fb, but... you'd need a display server to run the app on, not on bare KMS.
13:57 pq: or, one of the horrible KMS screenshot hacks
13:59 pq: wv, btw. do you expect that when a 6-bit value is converted to 8-bit, it is simply padded with zeros?
14:01 pq: if the meaningful bits are MSB, and LSB get added, then for pixel values it is common to replicate the MSB in the LSB in order to keep the "nominal" value more precise.
14:02 pq: e.g. conversion from u8 in to u16 out would be out = (in << 8) | in, so you get non-zero LSB.
14:03 wv: pq, that's an interesting remark... I was indeed expecting the values to be padded with zero's, but indeed, makes more sense to have some value in
14:03 wv: nevertheless, that would not explain why pixels on top, bottom, left and right would change colors
14:04 pq: true
14:07 wv: lynxeye, is there a way to verify if htis dithering is truely enabled in my case?
14:09 lynxeye: wv: Are you using the opensource GL drivers or closed blob one?
14:09 wv: opensource mesa/freedreno
14:11 lynxeye: wv: You can check if this condition is true (and you may hack out dithering there, to check the theory): https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/freedreno/a2xx/fd2_blend.c?ref_type=heads#L111
14:31 linyaa: what's the best channel to ask questions about CI infra?
14:31 wv: lynxeye, thanks, trying it out
14:45 robclark: linyaa: I guess here or #freedesktop ?
14:52 wv: lynxeye, great, at first sight it seems it solved our issue!
14:53 wv: so dithering seems to have been the issue
14:56 wv: *our issue ;-)
15:14 lynxeye: wv: Note that dithering is quite useful with 16bit rendertargets, as it hides most of the color banding you would usually see with those low depth targets. So ideally you would only disable it in cases where you care about exact color reproduction.
15:18 wv: lynxeye, well, as a matter of fact we do as our fpga needs the exact values for our application.
15:19 wv: but there' still something weird. If we put an image as background in weston-desktop, it's ok now
15:19 wv: if we load the exact same image in webkit, there's still some difference in the pixels themselves, not the ones around at first sight. But something to lookin to later. Have to run for the kids now
15:19 wv: thanks for the help so far!
15:53 hch12907: oh, gitlab.fd.o has ipv6 access now? that's pretty nice!
16:03 DavidHeidelberg: 🥳
16:25 MrCooper: karolherbst: do you know if Nvidia GPUs can scan out from system memory?
16:26 karolherbst: no idea tbh
18:11 mmind00: Hi all, can someone tell me if the patch at https://lore.kernel.org/all/20231023173718.188102-2-jonas@kwiboo.se/ adding some NV-something fourcc types is good to go?
18:11 mmind00: While I can handle the driver changes well, I don't have enough experience in core drm-land and definitly don't want to mess up something that add uapi elements
18:20 zamundaaa[m]: Sigh, looks like the matrix bridge was disconnected again
18:21 zamundaaa[m]: emersion: do you know if the mst path (PATH property without the "mst:connectorid") is guaranteed to be unique on a given KMS node?
18:35 emersion: zamundaaa[m]: pretty sure it's not
18:35 emersion: there could be two identical docks on two different DP ports
18:36 zamundaaa[m]: Is there at least some way to find out which DP port a connector is connected to?
18:37 zamundaaa[m]: I guess I can still make it work without that as well, but it's more messy
19:01 daniels: mmind00: go for it
19:04 mmind00: daniels: hehe ... thanks for the vote of confidence, will do :-)
19:27 bl4ckb0ne: is there some tooling around to visualize the std140 layout?
19:42 gfxstrand: dcbaker: Any thoughts on NAK merging?
19:43 bl4ckb0ne: pahole for spirv would be the best
19:57 gfxstrand: I'm not aware of any
19:59 alyssa: gfxstrand: r-b
19:59 alyssa: :p
20:00 Sachiel: NAK merging what?
20:01 zmike: NAK
20:02 bl4ckb0ne: cant even find a layout visualizer
20:02 bl4ckb0ne:adds it to the everlasting and growing todo list
20:06 ccr: what about ACK? or is it NAK on ACO -> ACK? :P
20:07 kisak: AMD COmpiler Kompiler
20:09 ccr: yo we heard you like compilers so ..
20:09 alyssa: ccr: apple cool kompiler
20:10 alyssa: or agx or asahi
20:10 ccr: \o/
20:10 alyssa: :p
22:02 emersion: zamundaaa[m]: sorry, not sure i get your question… you mean get the parent connector?
22:03 zamundaaa[m]: yes
22:04 emersion: zamundaaa[m]: have you seen my patch sent today on wayland-devel?
22:04 emersion: https://lists.freedesktop.org/archives/wayland-devel/2023-October/043195.html
22:05 zamundaaa[m]: oh, I think I misunderstood that. So the parent connector is one of the always-existing connectors for a given KMS device?
22:06 emersion: yes
22:06 zamundaaa[m]: okay, then I could construct an actually-unique identifier by getting that connectors index or sth
22:07 emersion: yeah…
22:07 emersion: see ville's reply
22:07 zamundaaa[m]: On the other hand, having two identical docks with two identical outputs that have the exact same EDID (or no EDID) connected to two DP ports is an edge case of an edgy edge case. Falling back to the connector name in such a case is probably ok
22:08 zamundaaa[m]: emersion: well, that's annoying. I would've thought that at least for the always-existing connectors the order would be stable
22:10 emersion: me too…
22:10 zamundaaa[m]: But, ignoring those special edge cases, mst minus parent connector should already be good enough for my use case
22:10 zamundaaa[m]: Thanks for your help
22:10 emersion: plz stable PATH prop for every connector…
23:50 anholt: anyone have CTS fixes that have landed that they wish were in mesa ci? now's your chance to slip one in. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25872
23:51 zmike: haha I was gonna ask if you got that one and then I clicked