09:27 columbarius: hey, who is the contact person for xorg at gsoc for general questions?
09:36 emersion: columbarius: Trevor Woerner
12:08 karolherbst: what's the proper way of unbinding the current console these days, so I can unload the main GPU driver?
12:20 Ristovski: hmm, I know of /sys/class/vtconsole/vtcon0/bind (which can be echoed to according to kernel docs), not sure if thats what you want
12:21 javierm: karolherbst: echo 0 > /sys/class/vtconsole/vtcon1/bind I think ?
12:22 javierm: Ristovski: vtcon0 is the dummy console I believe
12:28 Ristovski: javierm: ah
12:29 Ristovski: you're right, `cat /sys/class/vtconsole/vtcon0/name` -> `(S) dummy device`
12:31 javierm: Ristovski: yeah, on my hp x2 chromebook: https://paste.centos.org/view/raw/c6653673
12:32 javierm: karolherbst: ^
12:32 Ristovski: nice, good to know
12:34 eric_engestrom: DavidHeidelberg[m]: not aware of anything with the rpi farm, and looking at the jobs that didn't boot, I don't see any pattern (different devices, on different runners)
12:47 karolherbst: vtcon1 doesn't exist anymore
12:47 karolherbst: or rather.. not on my system
12:50 javierm: karolherbst: what do you have in /proc/fb ?
12:50 karolherbst: fb0 and fbcon
12:50 karolherbst: ehh
12:51 karolherbst: 0 i915drmfb
14:05 daniels: mupuf: navi dispatcher unhappy? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/37546314#L150
14:07 mupuf: Ha, yes. Already rebooted it and restarted the jobs that were failed to please marge
14:08 daniels: ah thanks, unfortunately too late for re-enabling LAVA
14:11 digetx: tzimmermann: I've fixed the missing drm-shmem resv lock that was triggering the Intel CI last week https://lore.kernel.org/dri-devel/20230305221011.1404672-2-dmitry.osipenko@collabora.com/ the dmabuf->attach()->drm_gem_pin() path was missing the lock; in the past versions I had drm_gem_pin() to take the lock, but it was causing unsolvable issue for i915 and we (Christian) decided to let exporters to handle the lock themselves; some more
14:11 digetx: details in the cover letter
14:11 mupuf: Sorry
14:12 digetx: tzimmermann: the Intel CI report is here https://patchwork.freedesktop.org/series/114671/
14:12 tzimmermann: digetx, thanks a lot for the fix
14:15 digetx: tzimmermann: I'll be happy to re-add the resv path to misc-next as soon as you'll approve the v12
16:02 daniels: anholt_, robclark: chezas 5, 7, 10, 11, 13, and 15 are all marked as paused - are they supposed to be held back or should they be working?
16:06 daniels: (I noticed because a630 was backed all the way up, which seemed not unrelated to people running a630-vk-full on them by triggering all manual jobs - maybe just tag a couple of the runners with a630-vk-full and make the job require that tag, so we don't block pre-merge runs when that happens?)
16:18 kisak: dcbaker: if you have a spare moment, can you check what happened to the 23.0 backport of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20688 ? Seems like it was cherry picked and got knocked out of staging https://gitlab.freedesktop.org/mesa/mesa/-/commit/3f71736eb1cc15f89502977498afa38204bedbbf leading to https://gitlab.freedesktop.org/mesa/mesa/-/issues/8439#note_1806342
16:26 dcbaker: kisak: it causes a ton of regressions on virgl iirc
16:27 dcbaker: I Can look more when i get into the office
16:28 kisak: ah, that's a good enough reason for me.
16:37 robclark: daniels: I think there were some that were paused due to being flaky but didn't realize it was that many.. maybe we should give a different tag instead of pausing them so that we could try to run jobs on them?
16:38 daniels: robclark: sure, I could rename them as mesa-freedreno-cheza-naughtystep and we could hit them with a --stress run?
16:38 robclark: yeah, seems like a good idea
16:59 daniels: 1 and 7 don't even have a cpu-uart device, so that's not super promising
17:00 MrCooper: who needs a CPU or UART anyway
17:02 daniels: robclark: 5, 13, and 15, can't get network; 11 might have bricked storage (EC works fine, CPU never emits anything from the UART); 10 just stays in some kind of type-C negotiation death spiral
17:04 daniels: so yeah, atm we only have 7 running chezas ...
17:05 daniels: would it be better to try to move testing to either a630 or 660?
17:06 robclark: it would be great to have some a660 runners.. since both a630 and a618 are a6xx gen1 and we'd like to have some a6xx gen4 coverage in CI
17:06 robclark: but I think we don't have hw for that
17:14 robclark: anyone know what compiler and version is used in debian-arm64 / debian-arm64-release build jobs?
17:14 daniels: ok, lemme chase up a660 enable then
17:15 daniels: robclark: C compiler for the host machine: ccache cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110")
17:15 daniels: the Meson configure output is collapsed by default in job logs, but if you expand it it'll tell you
17:15 daniels: C linker for the host machine: cc ld.gold 2.35.2
17:16 robclark: ahh, I see it now.. gcc version is what I was after
17:18 daniels: but yeah, I think we need to do something about a630 coverage, because right now fdno MRs launch 12 a630 jobs on 7 DUTs :\
17:19 robclark: we in theory have some more boards we could add.. I guess we could try to swap the bad boards?
17:19 robclark: it isn't ideal but last I looked we still weren't the long pole
17:32 daniels: yeah, if you have some spares, then you can swap out any/all of 1, 5, 7, 10, 11, 13, 15 ;)
17:51 digetx: jani: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/20 in case you haven't seen it, had this disabled rerere issue once again today on another machine; I assume it's up to you to review and merge it, thanks
17:59 anholt_: robclark: the new boards have not been going well. fritz works on them periodically, but none have been stable.
18:00 anholt_: daniels: I like the idea of full runs on limited subset of runners.
18:12 daniels: DavidHeidelberg[m]: ^ when you do LAVA priorities as well, could you please also set a618 full run priority to like ... 2
18:16 daniels: anholt_: picked -2 and -4 arbitrarily https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21737
18:18 anholt_: daniels: do we want to do that to lava, as well? Even if you've got priorities, someone clicking some manual runs (me, doing a morning round of ci checking on various MRs) during a lull would hopefully not block merges (later on as the north america day gets going). Right now I stagger my submissions, but tags would let me not do that.
18:21 daniels: anholt_: yeah we definitely do ... I know LAVA upstream completely changed how they do device aliases a while ago and it's not super straightforward atm
18:22 daniels: just aliasing tags on the gitlab-runner side wouldn't work given that we only register one instance per device type, and scale the parallel on the client side according to how many devices are available rn
19:20 daniels: robclark: any idea if a660_zap.mdt is redistributable yet?
19:24 robclark: daniels: I don't see it in upstream l-f so it might not be
19:26 robclark: daniels: maybe lumag might know what it would take? I think linaro has been pushing fw for SoCs that are in 96boards things, but not sure if there is anything w/ a660..
19:46 daniels: ack, thanks
19:48 HdkR: I would love to see day-0 support for snapdragon in both the firmware repo and upstream kernel. :)
19:49 HdkR: If I reiterate it enough, maybe it'll eventually happen.
21:12 robclark: HdkR: there has been day-0 support for the recent SoCs (but more just the base support, not including the blinky things like gpu)
21:14 HdkR: robclark: If someone's not dangling the keys in front of me then my ADHD brain can't pay attention to it. Need the blinky GPU
21:15 robclark: heheh.. it is at least moving in the right direction
21:16 HdkR: We at least got some day-1 patches for SM8550 on the ML. Which is a heck of an improvement
21:23 robclark: does anyone see a problem with adding a python-lxml build dependency? Or alternatively have an idea about how to do xml schema validation without adding a new dependency? https://gitlab.freedesktop.org/robclark/mesa/-/commit/498d53664a5dc9d2ee71943401fc169930d335b7
21:24 robclark: (CI is telling me that I'm missing some step to get python3-lxml into all the needed containers..)
21:28 lumag: daniels, the problem is that the zap.mbn/mdt is signed by the vendor of your board
21:28 lumag: so you can not just copy it from one board to another
21:29 robclark: lumag: I guess daniels is talking about intrinsic or similar board.. which I guess probably use the test-key signed fw
21:30 lumag: daniels, check your inbox please
21:31 lumag: yeah. They can be signed by any key
21:32 lumag: but we do not have an ODM who would license this file for redistribution
21:33 lumag: robclark, if we put the signatures aside, can you write the zap shader?
21:34 robclark: as in, my own implementation.. yeah, I guess in theory.. if tz doesn't check the signature.. maybe an empty file with whatever signing hearer/footer would work?
21:35 robclark: it's really just some sqe code with some embedded cmdstream and shaders
21:38 lumag: robclark, you or any other mesa / freedreno expert :D
21:39 robclark: well, we have an assembler/disassembler for it at least
21:40 robclark: I guess writing our own might be a way to unblock adding CI runners (where, I think daniels concern is that we don't really have a mechanism to _not_ redistribute the fw)
21:42 lumag: well, if we had one, we would have been completely unblocked
21:42 lumag: (one = ZAP written from scratch)
21:45 daniels: robclark: ours is the 888
21:46 daniels: ...
21:46 daniels: is the HDK
21:46 daniels: robclark: we can just fetch it from the LAVA server on every boot rather than having it in the rootfs, but it's kind of lame
22:33 tarceri: mareko: it dependeds at what stage in the linked you are talking about. We must remove what we can before validation because we have seen in the past games use declare more varying than is valid so the shaders only work if we remove the dead ones
22:36 tarceri: We also remove them so the other stages know what is used and not used, and we can do further optimisations if they are not used. Does your optimisation pass work across stages?
23:22 TimurTabi: I'm trying to build Mesa 22.3 on Ubuntu 20, and I'm running into a lot of issues with outdated dependencies. I've worked around most of them, but this one has me stumped, "Message: libdrm 2.4.110 needed because amdgpu has the highest requirement". I'm building on a system that has only Nvidia hardware, so I don't care about amdgpu. How do I tell the build to ignore amdgpu?
23:25 airlied: TimurTabi: set -Dvulkan-drivers and -Dgallium-drivers to not include amd drivers
23:25 TimurTabi: Eh, how exactly do I do that?
23:26 kisak: it's less hassle to just build new enough libdrm
23:27 TimurTabi: Hmmmm that's surprising but okay
23:29 airlied: TimurTabi: -Dgallium-drivers=nouveau -Dvulkan-drivers=
23:29 airlied: if you just want nouveau stuff
23:30 TimurTabi: Ugh, libdrm_nouveau still wants a newer libdrm.
23:31 airlied: then you need it :)
23:32 kisak: fwiw, https://launchpad.net/~kisak/+archive/ubuntu/turtle/+packages?field.series_filter=focal exists with 22.3.6, and https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa-build-deps/+packages?field.series_filter=focal is the build deps for it
23:32 kisak: you can take whatever you want to make your life easier
23:33 TimurTabi: Doh
23:37 TimurTabi: Is there some Ubuntu hack to install everything at once, or do I just need to download and install all the debs?
23:38 kisak: the easy way is just use apt-add-repository like any other PPA
23:39 TimurTabi: right