00:35zzoon_off_1th_May[m]: airlied: can i update https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21806 and merge?
00:41airlied: oh that had fallen off my list, yes would be good to rebase and merge
00:44alyssa: FWIW-- The X.Org Foundation has migrated from Twitter to the Fediverse. You can follow at https://floss.social/@XOrgFoundation
00:45alyssa: I'd like to focus the account mostly on boosting x/wayland/mesa/drm/etc developers' updates.
00:46alyssa: So if you post about something cool you're working on, feel free to ping me or Lyude for a signal boost :)
00:46alyssa: For ~~zmike~~ bloggers, I'd like to look into plumbing planet.fd.o in as well
00:47alyssa: Goal is a high signal:noise, one stop shop for interesting freedesktop.org related stuff :)
00:47alyssa: (I think GStreamer and PulseAudio updates would probably also be in scope but should probably clarify that, the x.org/fd.o relationship is Nuanced)
00:47alyssa: Cheers and thanks ^^
01:59zzoon_off_1th_May[m]: airlied: ok I'll do it then.
03:16kode54: neay
03:17kode54: neat
03:17kode54: looks like Xe won't be getting HuC loading for DG2
03:17kode54: at least any time soon
03:17kode54: good thing nobody needs the media codecs
03:22kode54: oh gee
03:22kode54: the official driver for the current Xe video devices is actually i915
03:22airlied: kode54: not all codecs need huc
03:22kode54: oh
03:22kode54: just hevc?
03:23kode54: I can live with just av1
03:23airlied: non-sliced hevc, slice hevc with vaapi shouldn't
03:23kode54: oh, neat
03:23kode54: i shouldn't be hassling people
03:25kode54: I need to test the upstream modded intel-media-driver, even though it's a "do not merge" state still
04:27graphitemaster: Is there a way to build mesa to set the default loader driver
04:28graphitemaster: It always defaults to using swrast_dri.so and I'd really like to avoid that
10:27luca_ceresoli: Hello, is this the appropriate channel for a question with modetest?
10:27luca_ceresoli: I have a device with two DRM cards, same driver, both working
10:27luca_ceresoli: But modetest only ever shows info about the first one, regardless of the -D parameter
10:27luca_ceresoli: Is this expected/known?
10:34emersion: luca_ceresoli: do you see these two cards in /dev/dri/?
10:37luca_ceresoli: emersion: yes, indeed I have 3 cards: card1 is teh GPU, I don't care about that, card0 and card2 are the two ones involved here (imx-lcdif module)
10:38emersion: dunno then
10:38emersion: does drm_info show more?
10:39luca_ceresoli: emersion: let me build that and let you know
10:54luca_ceresoli: emersion: things get even more weird with the drm_info output (looks like a nice tool BTW!)
10:54emersion: more weird?
10:54luca_ceresoli: emersion: According to /sys/class/drm/, I have: card0 is HDMI, card1 is etnaviv (I don't care), card2 is LVDS
10:55emersion: each card can have multiple connectors
10:55luca_ceresoli: emersion: according to drm_info: "Failed to retrieve information from /dev/dri/card0", card1 is HDMI, card2 is LVDS
10:56luca_ceresoli: emersion: cards 0 and 1 appear swapped :-?
10:57emersion: … fun
10:57emersion: i have no idea how this can happen
10:57luca_ceresoli: emersion: both cards have one connector each, as expected
11:07luca_ceresoli: emersion: ah, no, wait! The info I got about /sys/class/drm/ was from a previous boot; now they show etnaviv on card0, so no swap at all
11:07emersion: ah, cool
11:08luca_ceresoli: and so I'm back to the original question: how can I have card1=HDMI and card2=LVDS; modetest always handles cadr0 (HDMI), despite any -D flag
11:47pq: luca_ceresoli, I think that's just modetest. I have two cards too, and I cannot get it to look at the other one.
11:48emersion: fwiw, the libdrm tools aren't really actively developed anymore
12:07luca_ceresoli: pq, emersion: thanks, I think there's not much more to say about this :(
12:44kode54: okay, so I guess the Xe driver isn't really for all Xe and newer gpus, only really for the unreleased meteor lake and up
12:44kode54: and i915 is only for integrated gpus and dedicated is an afterthought
12:45kode54: guess I should have gotten an rdna2 card instead
12:51pq: Has anyone suggested yet that pointer input drivers should directly move DRM cursor planes to avoid the roundtrip to userspace just to move the cursor? :-p
12:52pq: That would make a wacky input device: absolute position pointer, that also supports a set_position command.
12:57lumag: jani, and probably airlied, dv_ & others. I'd like to find a way to land https://patchwork.freedesktop.org/series/114473/. The series was in review for about a month, having just partial review & no response after several pings. We have several pending series for drm/msm, which depend on the core changes from the series. What would be your recommendations? In the worst case I can split the code moving patches and thus separate core changes and i915
12:57lumag: changes. Then we can land dsc helper through the drm-misc and let i915 patches linger for some more time.
13:01dolphin: airlied, danvet: Sent drm-intel-next-fixes PR, sorry for delay
13:02dolphin: Dropped one patch (that was more of -next material), please check CI when merging.
13:28lumag: dolphin, probably you can also help with the question above
13:31dolphin: lumag: that would be a question for jani and rodrigovivi I think, being related to display
13:31lumag: dolphin, ack, thanks
13:40rodrigovivi: lumag: maybe a split and resend only patches 1-8 now you could get them merged quickly and do the 9-12 in a follow-up?
13:40rodrigovivi: then patch 7 still needs a review from someone that understand those numbers
13:40lumag: rodrigovivi, that's the problem.
13:41lumag: Would a review form Qualcomm help for #7?
13:42lumag: rodrigovivi, I mean then 1-8 can be merged through drm-intel
13:43rodrigovivi: reviews can come from anyone! but now I believe it would be good if you could add in the commit message some explanation of what those numbers are... where they come from? why just Qualcomm could review it?
13:50lumag: rodrigovivi, anybody can, but I can try asking abhinav__, if somebody with the DSC knowledge can do this check
13:50lumag: s/check/review
13:51lumag: rodrigovivi, just to check: would you like for me to resend the patches 1-8?
13:57rodrigovivi: lumag: yeap, I believe it is better to resend it... and while doing it add a bit more explanation in patch 7 on what those values are and where they come from
13:58lumag: ok
14:59jasuarez: Hi. I'm investigating an assertion we get on v3d driver when running nir_lower_clip_fs
14:59jasuarez: which basically asserts because the clip distance slot is not compact
15:00jasuarez: but I see that panfrost for instance seems to be also calling that lowering, and the test in question is not in the failing list
15:00jasuarez: spec@glsl-1.30@execution@clipping@fs-clip-distance-interpolated
15:01jasuarez: so wondering, if panfrost is actually going through the lowering, and if so, why in that case the slot is compact? is it running a previous lowering to make it compact?
15:01jasuarez: asking because that lowering was writing thinking that in opengl fragment shaders couldn't read gl_ClipDistance, which is wrong
15:31emersion: here's the RFC for a new color pipeline KMS uAPI: https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/T/#u
15:36lumag: rodrigovivi, done, https://patchwork.freedesktop.org/series/114473/
15:43lumag: rodrigovivi, but for the patch 6 we'd still need a review from Intel.
16:30rodrigovivi: jani: who is the best one on our side to help lumag with reviews on patch 6 and 7?
16:31rodrigovivi: maybe mdnavare could give help with the review on patch 6? :$ :)
16:47jenatali: jasuarez: Have you looked at PIPE_CAP_NIR_COMPACT_ARRAYS?
16:47jasuarez: no
16:48jasuarez: I don't see it setting in panfrost
21:42Lyude: emersion: thanks for the pointers btw :), I think I figured out where I was messing my math up (having nvidia hw start lines from 1 line into the sync pulse is confusing, heh)
21:44emersion: nice!
23:00karolherbst: gfxstrand: "Initializer for CrossWorkgroup variable 5 not yet supported in Mesa." :')
23:04karolherbst: seems like I have to support subgroup stuff as well
23:04karolherbst: oh well..
23:16jenatali: karolherbst: Those initializers are going to be fun...
23:16jenatali: And subgroups was on my radar too now that we hooked it up for VK
23:20karolherbst: yeah...
23:20karolherbst: but apparently chip-spv needs it :(
23:20karolherbst: it also needs SPV_INTEL_FP_FAST_MATH_MODE, but ehh.. those are just hints
23:20karolherbst: ohh 64bit int atomics are also required
23:20jenatali: Ooh, that'll be fun
23:20karolherbst: yeah
23:21karolherbst: but I'm still wondering what I'll need to just make blender happy :D
23:30anholt_: DavidHeidelberg[m], robclark: any idea why https://gitlab.freedesktop.org/anholt/mesa/-/jobs/41201228 would not be doing the post-boot msm firmware probe like the GL job manages to?
23:40robclark: anholt_: missing something for however the signed zap fw is handled, I guess?
23:43anholt_: robclark: signed zap is pulled down same as for the a660_gl jobs
23:44robclark: so, from kernel side, each time you open the drm device, if it hasn't managed to find it's fw bits yet (ie. because you didn't have fw in initrd, or whatever reason) it will try again..
23:46robclark: so last attempt at loading fw I see is:
23:46robclark: https://www.irccloud.com/pastebin/mI1H8s8L/
23:46anholt_: and it should be getting opened at https://gitlab.freedesktop.org/anholt/mesa/-/jobs/41201228#L1092 just like at, well, not sure why it loads right then in https://gitlab.freedesktop.org/anholt/mesa/-/jobs/41201098#L1016
23:47robclark: so the thing I don't see in the vk job is:
23:47robclark: https://www.irccloud.com/pastebin/etUcoHMg/
23:48anholt_: yes, that's the thing I'm asking about.
23:48anholt_: there's not an obvious trigger there in the GL job for it happening right then.
23:48robclark: anholt_: you can hack in a `cat /dev/dri/renderD128 > /dev/null` after the job fails? That should be enough to trigger it to try loading fw
23:48anholt_: but then even if it doesn't happen right then I expect it to happen at open time
23:56anholt_: robclark: https://gitlab.freedesktop.org/anholt/mesa/-/jobs/41202312#L1034 that doesn't seem to help. (which makes sense, since opening the device to run deqp didn't help)
23:59robclark: hmm, that time I do see it picking up the sqe fw at least