02:12 ecm: hello
02:13 ecm: shouldn't the 23.1.4 mesa version fix GLXBadFBConfig errors ?
02:13 ecm: they still persist after updating to it for me
02:15 ecm: i can't do MESA_GL_VERSION_OVERRIDE=4.4 to fix it as my gpu is at 3.3 only
08:42 tzimmermann: mripard, thanks for taking care of last week's drm-misc-next PR
08:44 tzimmermann: sima, airlied, hi. if you have a minute, please merge last week's PR for drm-misc-next. see tags/drm-misc-next-2023-07-21
08:45 sima: oops, will do
08:47 sima: rodrigovivi, dolphin no intel pulls while I'm at it, correct? just want to make sure I'm not missing anything
08:52 dolphin: sima: tursulin should be preparing one, however it looks like no rebase to -rc has happened?
08:56 mripard: tzimmermann: you're welcome, do you want me to do this week too?
08:56 tzimmermann: i'll take care of it, thank you
08:57 mripard: ack :)
08:59 sima: dolphin, drm-next is at -rc2
08:59 sima: or maybe I screwed up something
08:59 sima: nah I didn't fail to push
09:00 sima: dolphin, but maybe wait a bit until I pushed out the latest drm-misc-next merge
09:07 dolphin: sima: uh, but kernel.org is at -rc3
09:07 dolphin: also, I was referring to -fixes :)
09:07 sima: dolphin, yeah but we don't do backmerge every -rc
09:08 sima: dolphin, oh I was talking about -next
09:08 sima: I'll roll -fixes forward
09:08 dolphin: ok, well that clarifies things a bit
09:27 tursulin: sima: you should have drm-intel-fixes pr arrive shortly, thanks!
09:27 sima: tursulin, drm-fixes at -rc3 now
11:14 cwabbott: gfxstrand: you may want to take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24318
11:16 cwabbott: through a series of unfortunate events `shader_info::clip_distance_array_size` is broken with glslang output when xfb is used, it's 1 when gl_ClipDistance isn't declared
11:17 cwabbott: the only option we can see is to make every driver use the helper in the MR or add something to try to detect when ClipDistance is never written and make sure the array size is 0
11:35 sima: tzimmermann, mripard's drm-misc-next pr is pushed out
12:43 alyssa: karolherbst: what are the rules around variable_shared_mem?
12:44 alyssa: I'd like to insert shared mem stuff in the compiler for internal use
12:44 alyssa: in GL/VK that's safe -- I can look at the existing shared_size, compare it to the maximum, and if there's room add my stuff on top (and if not bail, it's for an optimization)
12:45 alyssa: in CL, I don't know if that can possibly be safe unless there are statically no shared mem accesses at all
12:45 alyssa: or maybe that can be relaxed to no indirect shared mem access, and we can teach nir_gather_info to max shared size with the direct offsets+1
12:59 mripard: sima: thanks :)
13:05 karolherbst: alyssa: variable_shared_mem is shared mem added on top of all in shader declared one on launch_grid time
13:05 karolherbst: e.g. if the shared memory required by the launch is bigger than what the declared shared_mem of the nir_shader requires
13:05 rodrigovivi: sima: welcome back, and no pr from my side yet... coming soon
13:06 karolherbst: *shared_size
13:06 sima: rodrigovivi, just pushed out another merge to drm-next
13:06 sima: airlied, ^^ did some -next pr handling, should be all caught up as of now
13:06 karolherbst: alyssa: so if you add shared memory blocks of known sizes at compile time, simply make sure that shared_size gets updated properly
13:06 sima: agd5f, robclark, dolphin, tursulin, jani, anyone else who needs to do some backmerging or whatever ^^
13:18 alyssa: karolherbst: the problem is that there is a hw limit to shared mem and we need to be sure not to exceed it by adding our own blocks
13:19 karolherbst: alyssa: might have to limit the max size exposed through APIs then or something?
13:19 karolherbst: variable shared mem can't really help with that anyway, because it still has to all fit within hardware limits
13:20 karolherbst: it's more like a thing that if you have 1k of shared mem, the application might allocate 512b statically, and 512b dynamically at launch time
13:20 karolherbst: but it still has to fit within hardware limits
13:20 alyssa: right..
13:24 DavidHeidelberg[m]: anyone annoyed by KDL verbosity at the end of the job can give ack on: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24348 ?
13:42 haasn: is there anything special an application needs to do to support VRR? my understanding was that I can just present frames whenever they're ready and they will become visible as soon as possible?
13:43 emersion: yes
13:45 haasn: how quickly can the display/implementation respond to framerate changes? say I have a display with 1 Hz minimum framerate, can an unpredictable input event (e.g. moving cursor) instantly end the 1000ms vblank period?
13:46 emersion: right now, yes… it kind of depends on compositor policy
13:46 haasn: hmm okay; so at a low level, the duration of a frame does not need to be known in advance?
13:46 emersion: the compositor can choose to go to highest refresh rate, or to lock the cursor refresh rate to the app's
13:47 haasn: e.g. say I get frames at unpredictable times from a network source, I can just present them whenever they happen to arrive over the network and it should all work fine without any special handling or thinking?
13:47 haasn: even if I don't know anything about how long each frame will last
13:47 haasn: right, I'm assuming a best case scenario in which VRR is active and the app is in fullscreen and the only thing driving the display
13:47 emersion: yeah, as long as you submit a frame before the max refresh period (min refresh rate), then it'll make it
13:48 haasn: hmm
13:48 emersion: if you miss the max refresh period, it's just like fixed refresh rates again: the compositor will wait for the next vblank to display the frame
13:49 haasn: if the minimum refresh rate is 30 Hz and I'm trying to present a 24 Hz stream, it will introduce input latency corresponding to the difference between 30 Hz and 48 Hz?
13:49 haasn: (assuming display/GPU does LFC)
13:51 emersion: hm, would need to draw a diagram to figure this out
13:51 emersion: but yeah, you'd sometimes miss frames, sometimes not, and the presentation time of your frames would be a bit unpredictable
13:52 haasn: e.g. at t=0ms I submit the first frame, then at t=33.3ms max vblank is reached so the display re-submits this frame
13:53 haasn: actually, wouldn't it then depend on what the display's _maximum_ refresh rate is?
13:53 haasn: say my display has an exceptionally good max refresh rate of 240 Hz
13:54 haasn: if at t=35ms (2ms after max vblank caused the previous frame to get-resubmitted) I suddenly try to present a new frame, shouldn't it respond to the new frame within 4ms?
13:54 haasn: (because of max being 240 Hz)
13:55 haasn: in that case it seems like what would happen is that the framerate would appear to 'alternate' between 30 Hz and 240 Hz
13:56 haasn: because the new frame would always interrupt the previous vblank period right after it started but then max out the next vblank period
13:56 zamundaaa[m]: Not necessarily. LFC is a thing, and amdgpu implements it
13:57 zamundaaa[m]: So you'd actually get 48Hz, if you're presenting at a somewhat predictable rate
14:00 haasn: then I must be misunderstanding how LFC works
14:01 haasn: seems to me like the obvious implementation of LFC would be to just re-submit the previous frame shortly before max vblank is reached, no?
14:01 haasn: without making any assumptions about how long to present it for
14:01 haasn: probably time to do some experiments
14:01 zamundaaa[m]: That wouldn't be LFC
14:01 haasn: ..and add a better timing core to plplay / libplacebo
14:02 zamundaaa[m]: LFC multiplies the refresh rate by an integer if you drop below the minimum refresh rate, so that you stay in the VRR window
14:03 haasn: but I don't understand how this can work if it doesn't know the duration of a frame
14:03 haasn: unless it adds 1 frame of latency to do the calculation
14:03 zamundaaa[m]: No, it more or less just guesses
14:03 haasn: ugh
14:05 zamundaaa[m]: yeah. FYI we could maybe improve on this in the future, as LFC might get implemented in compositors instead of the kernel
14:06 zamundaaa[m]: With a Wayland protocol to tell the compositor that you have a predictable refresh rate, it could be done in a nicer way (at least for video players)
14:10 javierm: tzimmermann: thanks for your suggestion. I already was testing that but it was good to have confirmation that it was what I missed
14:10 javierm: tzimmermann: so silly, I was sure that was testing one thing and was not testing at all
14:11 tzimmermann: javierm, i saw you already have a patch. never mind then
14:11 javierm: tzimmermann: yes, but it was great to have a validation from you that I understood correctly :)
14:12 javierm: tzimmermann: I looked at drivers/gpu/drm/tiny/cirrus.c as a reference btw
14:17 rodrigovivi: airlied: sima: interesting discussion on xe patch made me think if we shouldn't get entirely rid of the drm->date https://lore.kernel.org/all/xh23li7qzshcuheqlaue2pbwtfzdm7uygowpkovtgc52r6y2tp@apdgbzgegvpy/ thoughts?
14:17 rodrigovivi: demarchi: ^
14:19 sima: rodrigovivi, yeah the drm driver date is a bit lolz
14:19 sima: it made sense when drm was out-of-tree developed, but that stopped being a thing for almost 2 decades now
14:20 sima: rodrigovivi, we might need some patches to make sure drm core and userspace can cope with no date, but sounds good otherwise to abandon this
14:20 sima: and update kerneldoc and all that ofc
14:21 javierm: tzimmermann: I saw that you sent a PR for drm-misc-next, would there be another one once this fix lands or would be a -fixes ?
14:22 sima: -rc6 is usually the cut-off, so there should be plenty more
14:22 javierm: sima: Ok, cool
14:23 sima: drm-next cutoff of "you need a seriously good excuse for pr with code that landed after that"
14:23 rodrigovivi: sima: true... there might be some uapi around the date... need to take a careful look
14:23 sima: so anything that landed in drm-misc-next up to -rc6 should still make it
14:23 javierm: sima: nice, thanks for the info
14:23 sima: rodrigovivi, yeah some quick grepping shows that all the drivers I checked set it to some nonsense
14:24 sima: rodrigovivi, a full audit to see where it's used and then aggressively replace it with NULL or outright retire might be good
14:24 sima: drm core could just return a date that appeases existing userspace enough to not break things
14:24 sima: and we'd ditch drm_driver.date outright from the code
14:25 rodrigovivi: yeap, this seems the way to go
14:27 sima: rodrigovivi, at least libdrm seems to be able to cope wiht a zero date_len even
14:27 sima: and all the code I've found only printfs it :-)
14:27 sima: but yeah would need to check the usual ddx, -modeset, mesa, libva
14:27 sima: it's a bit of digging
14:28 sima: rodrigovivi, if the digging indicates we could just set date_len = 0, then patch to drm_ioctl.c to do that first
14:28 sima: plus a todo to delete all the date entries a few releases later maybe
14:47 tzimmermann: javierm, that fix goes into -misc-next
14:48 javierm: tzimmermann: Ok
15:10 karolherbst: airlied: mind upstreaming this patch to llvm? I couldn't figure out how to submit patches through phabricator.... https://github.com/karolherbst/llvm-project/commit/184c97f254dc9d21891c4a64d504940fcf5f3c5f
15:11 karolherbst: never mind.. it was this tiny button nobody finds
15:13 rodrigovivi: sima: cool! I will take a look on those
15:15 psykose: i don't think they're doing more 16.x branch releases so it would have to go to master only, and there they probably won't take it
15:18 karolherbst: yeah..... annoying
15:19 karolherbst: can only suggest distributions to take it
17:31 Kayden: zmike: by the way, I was seeing a ton of zink failures with anv on your branch for moving VB strides
17:31 zmike: 🤔
17:32 DavidHeidelberg[m]: eric_engestrom: i'm suspecting that Sergi sent the KDL to background with some purpose, I would wait jntil he gets back from vacation tk ask about it
17:33 Kayden: zmike: https://mesa-ci.01.org/dev_kwg/builds/2601/group/63a9f0ea7bb98050796b649e85481845 has a partial list but unfortunately it seems it failed to copy the individual test output dEQP-GLES2.functional.buffer.write.random.0 for example just has bad results, no asserts or anything
17:33 eric_engestrom: DavidHeidelberg[m]: ack; reassigned reviewing to him
17:34 eric_engestrom: (also, I have a feeling the reason was that it made sense in an earlier revision)
17:34 DavidHeidelberg[m]: Could be. He'll say his intentions :D
17:36 zmike: Kayden: they all pass for me ?
17:36 zmike: on icl too
17:36 Kayden: zmike: all good then, it's possible something just hosed here
17:39 zmike: 😬
18:58 zmike: since when is mesa main using clang-format?
18:58 psykose: i think it was some parts since a few months ago?
18:58 zmike: I thought it was just for specific drivers
18:59 psykose: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23275
18:59 zmike: toxic
18:59 psykose: your 3-space indents have been vanquished!
21:26 haasn: emersion: the flipside of cursor being redrawn at max fps means that touching your mouse will introduce frame stutters during video playback :^)
21:26 haasn: as I discovered through debugging
21:26 haasn: because in my case it pushes the monitor to 175 Hz which is not a clean multiple of most source framerates (24 Hz, 60 Hz)
21:26 haasn: probably an implementation could be smart enough to measure the vsync timings of the "primary" application and only redraw at clean multiples.. :shrug:
21:26 haasn: this is all voodoo territory
21:27 haasn: even having a terminal printing log messages in the *background* while watching a video fullscreened in mpv is enough to destroy the fragility of VRR on wayland (kde plasma)
21:28 haasn: so in conclusion, to get working VRR you must killall -9 all other processes, unplug your mouse, run mpv with --really-quiet, or indeed, just uninstall the compositor and watch in DRM
21:28 haasn: year of the linux desktop 2023 celebration party when
21:28 psykose: in 2024
21:30 emersion: this is a difficult problem to solve
21:31 emersion: even if the compositor had all of the information
21:33 Nefsen402: I must have bad eyes then. I don't notice any stutter when my monitors shoot up to 160hz after moving the mouse even with video playback with adaptive sync definitely working. I'd prefer to get a smooth cursor in these scenarios. Although maybe something could be done for notifications demons and such to prevent the sync rate of the monitor going out of whack
21:34 Nefsen402: it might be caused by the monitor. Many monitors have problems with them changing sync rates ubruptly and causing brightness changes
21:43 zamundaaa[m]: haasn: now you know why vrr is only enabled with fullscreen by default
21:45 robclark: sima, airlied: re: drm/ci, so one upshot of moving everything into drm/ci instead of having all most of the yml+scripts in a different git tree is that I can't actually run CI without landing drm/ci (ie. the previous trick of configuring gitlab repo to use a URL to find gitlab-ci.yml doesn' t work). Which kinda makes me favor having the drm/ci patch on a branch that I can merge into msm-next (and any other drivers can do as
21:45 robclark: well if they wish) for v6.6. Otherwise my CI setup is broken for the v6.6 cycle :-/
21:47 Nefsen402: zamundaaa[m]: This isn't true. wlroots wayland compositors have VRR enabled in all situations. But this is a policy of the compositor, it's possible to implement what you have but it's definitely not a hard and fast rule
21:47 sima: robclark, drm-tip integration tree? git merge doesn't really care much if a commit exists twice ...
21:47 sima: or I'm kinda lost on context
21:48 robclark: could be in drm next and I'll backmerge.. the issue is that the drm/ci commit actually needs to be in the branch that I want to run CI on
21:48 sima: robclark, also I thought that for upstream the initial drm/ci should be a separate branch anyway, with separate pr to linus or something like that
21:48 robclark: so however you accomplish that is ok
21:48 sima: robclark, yeah the transition is a bit wonky
21:49 sima: robclark, can't you just keep using the gitlab.yaml url setup trick until it's landed in enough branches, and then switch over for your driver's ci?
21:49 sima: getting the foot into this door has taken forever, so what's another few weeks
21:49 robclark: I should have written down the various gitlab repo settings I had to change
21:49 sima: maybe :-)
21:49 robclark: I guess I can figure it out again
21:49 robclark: but pita
21:49 sima: maybe #freedesktop can dig out a log?
21:50 robclark: oh, and also I have to go back to v5 or so of the drm/ci patch
21:50 sima: but yeah I think this issue is just another one to have it as a separate branch
21:50 robclark: before everything was pulled in-tree
21:50 sima: unless airlied wants to go real frisky :-)
21:50 sima: hm
21:50 sima: annoying
21:51 robclark: yeah
21:51 zamundaaa[m]: Nefsen402: I'm talking about KWin specifically, because haasn is using it for these tests. Obviously, other compositors can have different defaults
21:51 sima: robclark, temporarily stuffing your branches into drm-tip + that branch (should be there anyway once we do the drm.git topic branch) to pave over the wobbly times?
21:51 sima: and doing ci on drm-tip during those times I mean
21:52 sima: or hand-roll the same I guess
21:52 sima: or wait until airlied shows up, since I'm kinda falling asleep here ...
21:52 robclark: I guess we could just manually cherry-pick the drm/ci patch as last patch on the branch to run CI.. and then just tag HEAD~1 for MR
21:53 robclark: no worries, don't have to solve it tonight.. just wanted to point out that the workaround for drm/ci out of tree stops working with the in-tree version ;-)
21:53 sima: yeah hand-rolling for now is probably best
21:53 sima: I guess more important is to make sure this doesn't stick around for too long as an annoyance
21:54 robclark: so I either keep testing the old version for a few more years, or we just decide to go ahead and land it and fix as we go ;-)
21:54 robclark: yeah
21:54 sima: yeah I'd say help collect acks on the current patch asap from everyone
21:54 sima: and then airlied can stuff it into a drm.git topic branch
21:54 sima: or me
21:54 sima: airlied, dim help create-branch
21:55 sima: dim create-branch drm/topic/ci v6.5-rc3
21:56 sima: probably, didn't test it without --dry-run
21:56 robclark: amdgpu, i915, mediatek, meson, and rockchip are the other ones (beyond msm) that have CI setup so maybe we can get acks from some of those drivers, I guess
21:56 sima: robclark, yeah that'd be great
21:56 sima: robclark, also acks from any other stakeholders
21:56 sima: anyone else who cares
21:57 sima: anyone who feels like this is cool
21:57 sima: the more the merrier :-)
21:57 sima: I can pile on too ofc
22:27 dottedmag:wonders how macOS and Windows handle VRR
22:28 dottedmag: The easy cop-out is enable it when there is a fullscreen application with direct scanout, and lock overlay updates to the refresh rate of main plane, of course.
23:49 jenatali: That's pretty much what Windows does, yeah