00:07zmike: yea they failed earlier
00:09DavidHeidelberg[m]: debian-build-testing is sometimes slower since I added LTO build; I guess it's time to split it?
00:11DavidHeidelberg[m]: or just building LTO version could be enough (since chance it'll miss any non-LTO problem is close to 0)
00:36DavidHeidelberg[m]: second thing, voting about naming in CI: x86-64 vs x86_64 vs amd64; How can we do it?
00:38heat: obviously, x64
00:38heat: :P
00:39DavidHeidelberg[m]: heat: well, it's used that way for Windows, but in Linux world it's probably least common usage
00:39heat: totally, just a joke
00:39heat: ia-32e would also be hilarious
00:40DavidHeidelberg[m]: but still better to have x64 for 64-bit AMD than x86 we use now
00:47Lynne: offtopic, but did kernel 6.2 change some default settings? systemd-journald's saying it can't connect to any process' stdout
00:53jenatali: David Heidelberg: IMO x86_64 seems the most consistent throughout the Linux world
01:05HdkR: Make sure to call AArch64 Arm64 as well. That rename is always fun :)
01:13DavidHeidelberg[m]: vote here please > https://gitlab.freedesktop.org/mesa/mesa/-/issues/8049 <
01:14DavidHeidelberg[m]: I'm for almost every choice, if there will be choice which will stick for few years and not make people confused :)
01:34DavidHeidelberg[m]: mupuf: busybox doesn't handle zstd. Any idea what to do with that? We distribute the mesa build in zstd for some time and I want to enable it too for *valve* jobs, but cannot decompress.
01:46airlied: jekstrand: okay I left a patch in the MR that fixes the template entries, if you are okay with that I'll squash it
02:52Lynne: airlied: src/vulkan/util/vk_format.c:370, VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 isn't strictly compatible with VK_FORMAT_R16_UNORM
02:52Lynne: the bottom bits are described as undefined by the spec
02:52Lynne: so it should be VK_FORMAT_R10X6_UNORM_PACK16
03:12jenatali: That name is an abomination
03:22airlied: Lynne: for all our internal handling I think it's fine
03:23airlied: but I'll dig in and see
03:24airlied: since I don't see any hw support for R10X6 anywhere
03:24airlied: but maybe I should map R10X6 to R16 in drivers then
03:28airlied: Lynne: fixed it to map to that for now, will have to fix up radv
03:44Lynne: I think it would be fine to leave it as R16, assuming you're not aware of any hardware mesa supports that happens to put junk in the LSBs
03:45Lynne: I have zero clue why they defined padding in the LSBs for video formats
03:46Lynne: from a hardware perspective, having data in the LSBs is benefitial, especially in the case where it's used for reference frames
03:46Lynne: as h264 was designed such that 10bit decoding needs 16-bit intermediates if your ref+current frame data is in the LSBs
03:46Lynne: rather than 32bits, halving throughput
04:03airlied: Lynne: i dont think the hw actually cares about the vk format at that level
04:04airlied: at least the decode hw doesnt have a lot of format opts
04:04airlied: it has some 8/10 bit bits
04:09Lynne: maybe it's because the 2-plane p010/p012/y210/y212/etc are LSB padded
04:09Lynne: so they continued that for the 3-plane formats
04:10Lynne: (which is the one I'm wondering about, the 2-plane LSB padding has been ossified since time immemorial by microsoft)
04:10airlied: yeah the hw doesn't even have 3 plane options from what I can see
04:16Lynne: nvidia's does, I think, for 444, reading our vdpau/nvdec, I'm seeing 3-plane yuv444 rather than 2-plane
04:17Lynne: though it could be the driver doing it for some odd reason, like 2-plane 444 not being very popular
04:20airlied: yeah I noticed that in their decoder as well
04:20airlied: they pretty much demanded the 444 extension to even run at one point
04:20airlied: I think I'm pointlessly carrying code for that in radv actually
04:42airlied: Lynne: I've refined that commit to convert to R10X6 and convert that to R16_UNORM
04:49Lynne: yeah, looks fine
04:51airlied: I wonder what V_00A004_GFX10_FORMAT_MM_10_IN_16_UNORM is in the hw
04:51airlied: sounds like it might be related
04:51airlied: but it's gfx10+
04:55Lynne: sounds tiling-related?
04:55airlied: agd5f, mareko : what does MM in those?
05:07mupuf: DavidHeidelberg[m]: You mean for tar? It's weird since it is extracted by the mesa test container
05:07mupuf: Do you have a failed job I can look at?
05:10mupuf: Never mind, I saw your mail
07:47airlied: anholt: is there any cts 1.3.4.0 uprev in progress?
09:17ManDay: Could someone refresh my mind why Mesa will only provide OpenGL with X11? (and if that premise is wrongly phrased: Why does virtual/opengl depend on mesa[X] on Gentoo?)
09:17ManDay: I apologize for repeating this questions over the course of years (?) - I actually wrote down the answer to it but lost it in a data crash.
09:24psykose: it doesn't depend on x11, you can get libGL libEGL libGLES .. without x, no?
09:24psykose: glx and vdpau require it, but not opengl
09:28ManDay: yes, i think it has something to do with GLX being the only (full) OpenGL header, was that it?
09:29psykose: ah, maybe i'm mistaken
09:29ManDay: Like I said, I'm not very sure I phrased that question correctly - the only thing that's sure is that OpenGl depends on Mesa w/ X support (on Gentoo)!
09:32psykose: i build with -Dplatforms=wayland and no x deps and i didn't get a libGL so maybe it's true :p
09:33ManDay: I'm not sure -Dplatforms=wayland is enough to not depend on X11 headers
09:33MrCooper: that's because libGL includes GLX APIs
09:33ManDay: I also build for pure wayland and I have no libGl (only libglapi, whatever that one is)
09:33MrCooper: libOpenGL doesn't require X
09:34MrCooper: it sounds like a Gentoo packaging issue
09:34ManDay: MrCooper: Yes, I think it's a bit of a confusing set of terms with "OpenGL" not necessarily being libGL etc.
09:35psykose: hmm, where does libOpenGL come from
09:35MrCooper: GLVND
09:35psykose: ah
09:35psykose: ok makes sense
09:35psykose: thanks
09:35MrCooper: no worries
09:37MrCooper: there is of course the practical issue that the vast majority of apps using OpenGL still use libGL & GLX
09:38ManDay: MrCooper: Sorry if that's too much of a Gentoo specific but what would you say is the best possible terminology then? Blender, for example, they say they need "OpenGL" (as opposed to GLES) and the Gentoo ebuild depends on "virtual/opengl", but that in turn depends on Mesa with X support.
09:38ManDay: MrCooper: As opposed to? Using libGlVnd?
09:38MrCooper: it depends whether blender uses libGL (likely) or libOpenGL
09:38MrCooper: both provide the OpenGL API
09:39ManDay: So, speculation: The correction could look something like "OpenGl" -> "libGlVnd" instead of "Mesa[x]"?
09:39MrCooper: libglvnd is an implementation detail, it's either libGL or libOpenGL
09:39ManDay: MrCooper: blender uses glVnd, so that would mean libOpenGL, meaning it would do without mesa[X]?
09:40MrCooper: blender doesn't use glvnd directly
09:40ManDay: ...i'm actually not sure I'm understanding the situation entirely
09:40MrCooper: blender uses either libGL or libOpenGL
09:41MrCooper: the Debian blender package uses libGL FWIW
09:42ManDay: Which version is that? From the related blender bugs I think they must have moved to libOpenGl for pure wayland support like they ought to, since 3.4.1?
09:43MrCooper: the Fedora package uses libOpenGL though
09:43MrCooper: makes sense, it's 3.3 vs 3.4
09:45ManDay: all right, my grasp of this is still a bit foggy but I think I got the gist - taking it to #gentoo
09:45ManDay: thank you very much!
09:45MrCooper: so blender 3.4 uses libOpenGL for the OpenGL API, plus libEGL on Wayland, and possibly libGLX on X
09:46MrCooper: no worries
09:47enunes: eric_engestrom: hi, did you have some chance to look into the egl tests timeout?
09:48enunes: one thing I found so far is that if we run only the wayland ones (or worse, change the order and run the wayland tests before the x11 ones), the long list of timeouts is gone...
09:49enunes: trying to find some sense in that
10:13hakzsam: is the branchpoint tomorrow?
10:18javierm: mripard: can I push https://patchwork.kernel.org/project/dri-devel/patch/20221219084023.1402282-1-u.kleine-koenig@pengutronix.de/ to drm-misc-next ?
10:18javierm: mripard: Uwe asked me to take care of some of his DRM patches that have been already reviewed
10:35gawin: hakzsam: yeah
10:36gawin: > 19:29 dcbaker: wednesday
10:36gawin: (from yesterday's log)
10:39hakzsam: thanks
11:09mripard: javierm: yep, thanks
11:10javierm: mripard: cool, thanks
12:17daniels: enunes: can you please clean up the Lima runner? -ENOSPC trying to unpack containers
12:20DavidHeidelberg[m]: enunes: ^ this time it isn't my fault (since yesterday I didn't run any new big pipeline) :D
12:21enunes: daniels: I'll take a look - it happened yesterday and it was because new jobs were taking significantly more space
12:21DavidHeidelberg[m]: mupuf: for runners in FDO farms it doesn't such a big impact, but it means we don't have to store the file twice (artifacts + s3)
12:23mupuf: DavidHeidelberg[m]: I'm all for it, I'm just confused by the code. Let me comment there
12:25DavidHeidelberg[m]: mupuf: np, that part was created around 3am; so if there is confusion, it make sense :D
12:25enunes: daniels: DavidHeidelberg[m]: should be good now, it was the runner this time not LAVA, docker-free-space did not act for some reason
12:30daniels: enunes: aha, thanks
12:32daniels: enunes: appreciate the quick fix :)
12:33psykose: DavidHeidelberg[m]: where can you not decompress zstd (i.e. which platform doesn't have the zstd util installable separately while having busybox)
12:41DemiMarie: Does the Xe driver map the GuC submission queues into userspace, or does the kernel ensure that only valid commands reach the GuC?
12:41daniels: tanty: is there something weird going on with the igalia-rpi network? if you look closely at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34440806 it takes 14 minutes to go from the artifacts having finished downloading to the board booting, which should only be rsync and nothing else
12:42daniels: same thing for every other job in that pipeline
12:45DavidHeidelberg[m]: psykose: it just about the container setup, it can be imported as standalone zstd or busybox patches with zstd support
12:46karolherbst: ls
12:46daniels: enunes: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34443210 also has a flood of failures to create high-version GL contexts - I wonder if that suggests that a bunch of tests should be moved from xfail to skip?
12:46psykose: DavidHeidelberg[m]: you mean, you have a container i.e. dockerfile and one of the build steps is tar xf artifact.zst ?
12:46psykose: sure, i would just install zstd for that :)
12:47psykose: last i checked busybox there was some abandoned zstd patch a year or so ago, not sure if anyone made any progress
12:47psykose: (it is also much easier to install zstd than do weird patching of anything)
13:52mupuf: DavidHeidelberg[m]: sorry for the delay, I got it there :)
13:53DavidHeidelberg[m]: mupuf: oh cool, I was wondering about the extraction :)
13:54DavidHeidelberg[m]: anyway, zstd is on top of tar, so then we have to do tar -xf on the runner
13:57daniels: jenatali: any idea where the weird PowerShell XML spam has come from? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34449284#L386
13:58jenatali: Nope
13:58daniels:shrugs
14:07jenatali: daniels: Might've been the switch to PowerShell core?
14:07jenatali: Dunno, my eyes just skip past it to the stuff that matters
14:11daniels: haha
14:17mairacanal: danvet: hi! about the debugfs clean-up, I'm trying to work on removing the late register helper by adding support for debugfs files on crtc, connectors, and encoders. I just have a doubt if you meant adding the files to the device minor folder or the kms component folder. Have you had any thoughts about it?
14:32enunes: daniels: about the failures to create high GL version, I guess we could try to identify which ones need it and add to skip, just last time I checked it was not just in the lima job so I started wondering if we could have a shared solution
14:44mareko: airlied: MM=multimedia
15:19eric_engestrom: enunes: no, I haven't looked into it more beyond just "run these tests on my local wayland rpi" where nothing timed out; I think I would need to unroll everything the CI does (env mostly, but also which service runs in which job) and repeat it locally to see where it starts behaving weird
15:20danvet: mairacanal, not really, I also don't have a good idea about names
15:20eric_engestrom: enunes: your mention that it times out when "running the x11 tests before the wayland ones" -> sounds like we're running both in the same job? in that case maybe we're not cleaning up correctly between the two?
15:21danvet: i.e. whether it should be drm_connector_add_debgufs_file
15:21danvet: or drm_debugfs_add_connector_file
15:21danvet: roll a dice if you can't decide :-)
15:21danvet: mairacanal, I think the bigger question is whether we can sneak in more typesafety
15:21danvet: so that drivers get a struct drm_connector * pointer instead of void * that they need to cast in their show() callback
15:21danvet: but that's more bikeshed ...
15:30mairacanal: danvet, I see. So, I guess a similar structure from the current debugfs for the crtc, connector and encoder would be fine, right?
15:31danvet: yeah
15:31danvet: unfortunately C is not very good at type generic stuff
15:31danvet: you could strictly speaking store the right type in seq_file->private
15:32danvet: and force cast every function pointer to (show)(seq_file *, void*, void*) from (show)(seq_file*, drm_device*, void*)
15:32danvet: but that violates the C standard in a big way
15:32danvet: despite that it should work on everything gcc supports :-)
15:34danvet: mairacanal, if you feel creative you might be able to instantiate the different variants with cpp, but that tends to end up rather ugly
15:34enunes: eric_engestrom: yes we are running both in the same job. lima also hits the same timeouts if I run the tests as in vc4 -- but if I invert the tasks to run wayland egl and then x11 egl, it goes well on both platforms
15:34danvet: so I'd just copypaste, since it's really not much code
15:35mairacanal: danvet, yeah, I'm creating a couple of macros to avoid copying and pasting a lot
15:35mairacanal: thanks for the answer!
15:36enunes: eric_engestrom: so I guess it's some shared mesa bug or weston or cts bug (?)
15:38enunes: last I checked our VK-GL-CTS version even uses wl_shell rather than xdg_shell , which is something to look into next
15:40eric_engestrom: yeah that's been fixed in the cts, it finally uses xdg_shell now (although I have no idea which release has that)
15:41enunes: I had the same version as CI built locally so unless it's been bumped in the past week or so, mesa CI is still using wl_shell
15:41eric_engestrom: can you check to make sure that x isn't still running (or has pipes/sockets left around or things like that)?
15:42eric_engestrom: it really feels like missing cleanup after X & before weston
15:42enunes: CI doesn't kill X so I think it's expected it will still be running, things should work anyway I think
15:44enunes: unfortunately I can't reproduce it locally either but maybe I can check if bumping VK-GL-CTS to a version supporting xdg_shell has any effect
15:44eric_engestrom: sure, worth a shot
15:45eric_engestrom: (although obviously you should expect tons of other failures related to new/changed tests)
15:46daniels: tanty: slow rsync is now the least of rpi's problems; it seems dockerd might be dead https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34455401
15:57eric_engestrom: daniels: one of the two runners was having IO issues apparently, rebooted now
15:57eric_engestrom: *rebooting now
16:00daniels: thanks!
16:10eric_engestrom: (it's not coming back up, I'm working with someone physically in the office to see what's going on; our CI will be operating at half capacity until that's resolved)
16:21eric_engestrom: our CI should be fully back up now
16:33daniels: mupuf: you might want to either prune results.csv or pre-compress it before uploading; it's 103MB per job which hurts a bit, but more importantly, the artifacts somehow took 7 minutes to upload from when the CTS run actually finished
16:33daniels: that pushes pipeline completion from build+14min (roughly where stoney is atm) to build+21min
16:41jekstrand: danvet, airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16987
16:42jekstrand: An ack from one of you would be nice.
16:42jenatali: jekstrand: I'd love an ack from you on !16200, I think it's good to go unless you've got objections
16:43jekstrand: We're not currently carrying dma-buf.h but we've got bits of it duplicated in the Vulkan WSI code now thanks to the new sync_file import/export ioctls.
16:43jekstrand: jenatali: Sure. Give me a few minutes.
17:06anholt: airlied: not that I know of
17:32anholt: bnieuwenhuizen: any ideas about the d/s fails in radv-stoney-aco-fails?
17:33jekstrand: jenatali: there you go
17:34jenatali: jekstrand: TYVM
17:34bnieuwenhuizen: anholt: wow, that is a lot of failures
17:34bnieuwenhuizen: no I haven't looked at them
17:35mupuf: daniels: da heck, it wasn't like this before :o
17:35mupuf: sure thing, will compress it! This is ridiculous
17:35anholt: some could be stale, because of test list changes plus fractional run
17:35anholt: but apparently at least some d/s fail is being caught by android cts now.
17:36bnieuwenhuizen: anholt: if it is in ChromeOS that is likely by the recent 22.2.0 uprev, which might've hit the "100% dynamic rendering" stuff Jason added to the fail list?
17:38anholt: sounds likely. but I'm also confused how previous android cts vulkan testing didn't catch the existing fails
17:39tango_: oh updated mesa and got rusticl
17:39tango_: no devices though 8-D
17:39tango_: which hw is supposed to be supported by it?
17:42eric_engestrom: tango_: it's not ready yet so by default it exposes nothing; there's an env var to enable it
17:43eric_engestrom: https://docs.mesa3d.org/envvars#rusticl-environment-variables
17:56tango_: eric_engestrom: interesting, thanks. I assume radeonsi: driver missing means that it was built without support for it? or is it supposed t not work on amdgpu-controlled devices?
17:59MrCooper: not yet, there's a pending MR for that
18:17siddh: <danvet> "but that violates the C standard..." <- Though I don't know the specifics of implementation, this sounds like a choice based on types.
18:17siddh: Since C11 (and kernel is now on C11), there is a compile time _Generic macro which is like a switch case for non-variable types, allowing for us a kind of overloading. Only the correct argument is evaluated.
18:17siddh: There is apparently also a GCC and clang extension __auto_type, analogous to auto in c++ but not exactly the same (only can be used for single variables, so ideally in a macro).
18:31wv: Hello, I have this setup where only the upper part of my screen, connected to a imx53 is visible. To maximize the performance, I was thinking if I could reduce the rendering area to only the visible part, keeping hardware acceleration at place. Is there a way I can achieve this?
18:32wv: flow is linux 5.15 -> drm -> wayland -> cog -> wpewebkit
18:32wv: exact same setup on an imx6 too. but imx6 is using etnaviv where imx53 is using freedreno implementation
21:29danvet: siddh, pointer types are not all equally (at least the standard allows that)
21:30danvet: so in theory you have a different function call contract if you pass a void* or a different type
21:30danvet: in practice, it's all the same
21:30danvet: so in theory you can't cast function pointers from the specific to the generic on
21:30danvet: is at least my understanding of the entire mess
21:31danvet: and I don't think we can use auto in a struct, where we'd need it :-)
21:31danvet: you'd need generics for this
21:37siddh: <danvet> "you'd need generics for this" <- Oh okay, thanks for explaining!
21:53siddh: danvet: I was also looking at doing some of the things mentioned in DRM TODO list to start out and also go for EVoC. I couldn't really get what the "Backlight Refactoring" TODO is trying to say. Can you tell me about that? Also, it seems the TODO list isn't fully updated? For example, the TODO with heading "Convert drivers to use simple modeset suspend/resume" seems to be already done, as I can only find 21 matches for
21:53siddh: drm_atomic_helper_resume/suspend in drm folder.
22:16danvet: siddh, for backlight refactoring talk to sravn
22:17danvet: but also I think it's now fairly well advanced, not sure what's left to do
22:17danvet: but sravn should know
22:17danvet: siddh, some of these have been ongoing for a while
22:18danvet: it might be that there's no open coded modeset suspend/resume left (at least for atomic drivers, for legacy onces these helpers don't work)
22:18danvet: siddh, if you want maybe check driver's suspend/resume function for how they suspend/resume modeset state
22:18danvet: well check first whether it's an atomic driver
22:18danvet: and if all are converted, then just submit a patch to delete this todo
22:19danvet: if you find some, maybe submit a patch which list these drivers which are left, so that your audit work did not go to waste (ideally mentioning the relevant suspend/resume function that needs work for each)
22:48DavidHeidelberg[m]: Can I create LTO label in Mesa project? (would be used for issues with LTO involved and most likely not occurring on regular builds)
22:54DavidHeidelberg[m]: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20626 + anyone who wants more robust wget please Ab,Rb :)
22:56daniels: DavidHeidelberg[m]: thanks so much!
22:57DavidHeidelberg[m]: well, I got the wget options served on silver plate from you, so it's thank to you :D
22:57APic: 8===D
22:57APic: ww