00:59 kode54: I only just noticed the argument on the drm mailing list regarding the drm scheduler
00:59 kode54: yikes
01:08 psykose: which one
01:17 alyssa: psykose: https://lists.freedesktop.org/archives/dri-devel/2023-July/413834.html
01:18 psykose: thanks
01:21 psykose: spicy thread
04:04 Venemo: mareko: I'm sorry that you dislike clang-format. personally I don't mind the style, any style is fine with me as long as I don't have to deal with it manually. I agree with alyssa 's writup on the gitlab about this topic
04:06 Venemo: honestly I feel better since we use it because I don't have any stylistic comments on my MRs anymore and that helps me sleep bettet
04:06 Venemo: better*
05:05 Lynne: how does radv treat command buffers, specifically pools, as?
05:06 Lynne: are command buffers independent from pools, so pools are nothing more than a malloc?
05:08 airlied: Lynne: radv just uses some generic mesa infrastructure that all the drivers share
05:08 airlied: but I think it recycles them within a pool
05:08 airlied: so you won't get mallocs
05:09 airlied: but it doesn't preallocate any
05:11 Lynne: so there shouldn't be any issues specifically with radv if two command buffers which share the same pool are accessed from different threads?
05:14 airlied: nope
05:17 Lynne: ah, well, for a brief moment I thought fixing that may have fixed the av1/hevc flickering issues on rdna3
06:36 Lynne: airlied: where does skeggs' kernel branch expect the gsp firmware to be at?
06:38 Lynne: as far as I can see, it tries to load gsp/gsp535.54.03, but how would it know which variant to load?
06:47 Lynne: found it, it still requests a booter load microcode, which I don't think exists/is needed?
06:52 airlied: Lynne: it's needed
06:52 airlied: you have to extract it from the open-gpu-kernel-module
06:53 Lynne: yeah, I found it
06:53 airlied: https://github.com/NVIDIA/open-gpu-kernel-modules nouveau/extract-firmware-nouveau.py
06:53 Lynne: it's in hex form, surely it's available in .bin somewhere, right?
06:54 airlied: it's not available in any from beyond whatever nvidia give it to us in
06:55 Lynne: it's actually embedded into their open kernel modules
06:55 airlied: yes so the script pulls it out
06:55 airlied: into .bin files
06:57 airlied: what card you testing it on? ampere or ada?
07:02 Lynne: ada
07:06 Lynne: got a bit further, I get a crash when loading the firmware (just a kernel one)
07:07 Lynne: may be because I'm using a different version's gsp firmware rather than strictly 5355403
07:10 Lynne: I can't know, 535.54.03 doesn't actually provide gsp for ada, but their beta drivers do
07:28 pq: emersion, I'm not sure what other purpose VGEM might have if not allocating sysram exportable to dmabuf.
07:29 emersion: pq, i don't see any way to allocate DMA-BUFs in vgem though…
07:29 emersion: i would've asked ajax how this works in xserver, but they're no here
07:29 airlied: Lynne: don't think we have any userspace for ada, I thought karolherbst got ada going with gsp today
07:30 Lynne: userspace?
07:30 pq: emersion, odd - in Weston we were looking forward to use VGEM in order to test direct scanout with VKMS, and that would need dmabuf. I recall Leandro having even a MR open perhaps.
07:32 pq: or maybe it wasn't a MR yet...
07:32 emersion: i see https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/513
07:32 emersion: that one uses dumb buffers with vgem, but that doesn't work
07:32 emersion: hm, or maybe that works with the primary node, not the render node?
07:32 pq: How does it not work? The test suite is green?
07:33 pq: see also https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/537
07:33 emersion: the test is not ran AFAIK
07:33 pq: ah
07:33 emersion: or is it not?
07:33 emersion: i don't see WESTON_TEST_SUITE_ALLOC_DEVICE set anywhere, and it's required for the test
07:33 pq: alloc device is indeed the primary node, not render node
07:34 MrCooper: I do suspect dumb BOs only work with card nodes
07:34 pq: see !537
07:34 emersion: d'uh, export WESTON_TEST_SUITE_ALLOC_DEVICE=$(basename /sys/devices/platform/vgem/drm/card*)
07:34 pq: yes, dumb bo alloc is only allowed on primary nodes AFAIK
07:34 emersion: okay, nevermind then
07:34 emersion: any reason why vkms is not used to allocate?
07:35 pq: err, because.... it's a KMS device and clients might not be able to... so VGEM device is used to bend the rules?
07:35 emersion: but dumb BOs are not for clients…
07:36 pq: but clients need dmabuf, and that's currently the only way
07:36 pq: maybe VGEM needs to grow a driver-specific bo alloc API then?
07:37 Lynne: airlied: ah, as in nvk, I can backport a patch if it hasn't been merged by then
07:37 pq: but how would se use it? Via GBM?
07:37 pq: *we
07:37 emersion: yeah
07:38 emersion: a lot of work for no clear benefit
07:38 emersion: OTOH, you could probably just use weston-simple-dmabuf-gbm for tests
07:38 pq: in weston !513 logs I see: 10/50 drm-composite-bypass OK 1.38s 1 subtests passed
07:39 emersion: well, not exactly that exe ofc, but code close to it
07:39 pq: Does GBM on VGEM work?
07:39 emersion: i would be surprised if it did
07:39 emersion: yeah, the test works
07:39 pq: yeah, so it needs work - what do you mean would be a lot of work for no clear benefit?
07:40 emersion: i mean that dumb BOs and using the primary node "works" for testing
07:40 pq: yes?
07:40 airlied: Lynne: yeah nvk, though I think nvc0 fixes just got into an MR
07:40 emersion: so, why bother
07:40 pq: that's my line :-)
07:40 pq: I thought you were against using such a hack
07:41 emersion: it doesn't work for wlroots, because wlroots insists on using render nodes for… rendering
07:41 emersion: hm, actually, maybe GBM works with vgem primary nodes, now that i think about it
07:41 emersion: via kmsro…
07:41 pq: it might become a problem in weston too, if it didn't already, I haven't really followed all the renderer rearchitecting
07:42 pq: I'd assume that Weston opens VKMS primary for renderer and gets kmsro, but that might be changing.
07:43 Lynne: airlied: "sec2(gsp):booter-load: boot failed: -5"
07:43 emersion: hm my head hurts now
07:44 emersion: kmsro always gives me a good headache
07:44 pq: emersion, if you want to make GBM + VGEM render node work for alloc and dmabuf export, it sounds like a good idea to me if it doesn't work already.
07:45 pq: cc daniels
07:45 emersion: yeah, that one doesn't work for sure
07:45 emersion: but i don't know if it makes sense
07:45 pq: why no sense?
07:45 emersion: it feels weird to have mesa code for something which can't render
07:45 pq: it would make VGEM look a lot more like a normal driver, to support Mesa sw
07:45 emersion: we'd probably need… vgem_dri.so
07:46 emersion: which would only support allocs
07:46 pq: I guess so
07:46 emersion: and… defer rendering to llvmpipe?
07:46 pq: yes
07:46 airlied: Lynne: you have nouveau.config=NvGspRm=1
07:46 emersion: that'd be great for wlroots, because it would fit perfectly our abstractions
07:47 airlied: ?
07:47 pq: emersion, I think it would be architecturally a good idea indeed.
07:48 pq: then again, I know practically nothing of Mesa insides
07:48 pq: but from outside it makes sense
07:53 Lynne: airlied: yup, though it's not needed on ada, the notes said it's enabled there by default
07:55 Lynne: what happens is actually "gsp: fwsec-frts: 0x00be", which is a check for whether the device ack'd the firmware, from what I can tell
07:55 Lynne: so it's getting loaded
08:41 emersion: daniels: btw, do you want me to do anything special wrt. that tearing mesa MR?
08:42 karolherbst: Lynne: as in mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24226
08:46 llyyr: doing any kind of search on the mesa issue tracker results in an error 500
09:02 Lynne: karolherbst: yup, which gsp binary did you use?
09:03 karolherbst: 535.54.3
09:03 karolherbst: it uses the ampere one
09:03 karolherbst: ada is surprisingly identical to ampere
09:03 Lynne: gsp_ga10x.bin?
09:03 karolherbst: yeah
09:05 Lynne: didn't work for me
09:07 Lynne: maybe the kernel branch ought to track the beta drivers? they're already experimental enough, wouldn't make a difference :)
09:09 karolherbst: in what sense didn't it work for you?
09:21 Lynne: errors out with "gsp: fwsec-frts: 0x00be"
09:23 Lynne: tried other booter versions too, and 2 gsp binary versions, it pretty much always happens
09:51 lynxeye: zmike: Sorry, seems I broke pipeline creation by directly pushing the etnaviv fixup. Maybe you can trigger the etnaviv CI again?
11:12 hussam: hello.
11:12 hussam: I have a problem with intel graphics 620 on an 8th gen intel laptop
11:12 hussam: I think it is due to modesetting
11:13 hussam: if I suspend on Xorg, resuming from suspend shows an old frame
11:16 dolphin: hussam: have you tried with wayland compositors?
11:16 hussam: sometimes even on switching TV
11:16 hussam: VT
11:16 hussam: yes, it doesn't happen under Wayland.
11:17 hussam: but I have other issues with wayland like applications showing up twice or as unknown in gnome shell dashboard. so I was hoping to see if I can fix the xorg issue.
11:18 dolphin: Right, there are instructions for filing bugs at the channel topic for #intel-gfx, but if it's only on Xorg it's going to a backlog as Xorg bugs are not prioritized much unless it was previously working and it's a clear regression
11:19 dolphin: But if you have such issues with gnome-shell, please do file those in the bug tracker, they should get attention.
11:19 dolphin: (in wayland mode, that is)
11:20 hussam: I don't know if this is a regression. I used nvidia on a desktop for over two decades and 3dfx before that. Very different than intel.
11:20 hussam: No such issue under wayland.
11:21 dolphin: right, regression would mean that something worked on the exact same hardware and userspace, but with older kernel
11:22 dolphin: and is then broken by update to newer kernel
11:52 penguin42: karolherbst: I guess now I've got profiling support in, I can go back and look at my original performance question a bit more :-)
12:42 mareko: zmike: can you please review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22436 ?
12:48 zmike: lynxeye: 👍
12:48 zmike: mareko: I have a tab open for it but this week's been hectic
12:50 zmike: will try and get it before today's call block
15:35 zmike: austriancoder lynxeye: it seems one of the jobs are fixed, but the other 3 are not https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/939477
16:09 austriancoder: zmike: gc7000 fails as there is an UnexpectedPass now 👍🏼
16:10 zmike: 💪💪💪
16:10 austriancoder: zmike: and gc2000 has only 5 fails ..
16:10 austriancoder: so.. not that bad
16:11 austriancoder: zmike: and the _asan job needs more tuning so it can be ignored
16:24 lynxeye: austriancoder: Are you going to investigate the remaining gc2000 fails? If not I can take another look, but not sure if I get around to it today.
16:26 zmike: I don't think there's that much of a rush
16:33 austriancoder: lynxeye: not sure.. was a long day already
17:15 cwabbott: dj-death: I totally forgot about !23374, I guess you mostly reviewed it but there was one comment left
17:16 cwabbott: I've rebased it now that the dependent stuff has landed
17:19 dj-death: cwabbott: cool, I'll rebase the anv stuff
17:25 cwabbott: dj-death: fyi, you'll probably have to rework the anv patch to combine the dynamic and pipeline feedback loop flags due to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23374/diffs?commit_id=e226eebfb964ee895443ebaa998b6485e8d16273#994589f18ec2d4dde5c2b22b3d9441a238147a78_1799_1821
17:36 dj-death: cwabbott: not sure why, I seem to remember it
17:36 dj-death: cwabbott: will see