04:08 soreau: why does radeontop make my compositor frame events perfectly on time whereas without, they are latent by some margin? ref: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/2087
06:23 airlied: hey fossilise/shader-db experts, is there anything written to compare the compile speed between two runs?
06:39 soreau: it seems like /sys/class/drm/card1/device/power_dpm_force_performance_level should be set to "high" for workstations by default
06:41 soreau: doing this acheives the same frame timing perfection as running radeontop
08:05 glehmann: karolherbst: workgroup size does no matter for load_subgroup_size for VK/GL
08:06 glehmann: they are seperate concepts, and if you use a too small subgroup size you will get partially empty subgroups.
08:08 glehmann: so back to your example, if the hardware/driver subgroup size is 32 and the workgroup only has 16 invocations, you get a subgroup size of 32
08:34 MoeIcenowy: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/101245813 oh Mesa CI fails sanity check
08:37 MrCooper: looks like an infra issue which should be raised on #freedesktop
08:50 pq: emersion, daniels, last time (several years ago) I looked at evdi, all it did was to route stuff back to userspace, so it really had no device to attach to, USB or otherwise, regardless of what the (proprietary) userspace on the other end did.
09:03 emersion: pq, userspace could surface back the USB device details and create one KMS device per USB device
09:03 emersion: but that's a bad architecture anyways, shrug
09:06 tzimmermann: emersion, pq, i work on some improvements to the kernel's damage handling. if DRM detects a modeset, if frees the damage clips from user space. but for mere page flips, it keeps them. do you know if that is an intentional design?
09:06 MoeIcenowy: well at least evdi isn't something mainlined?
09:06 emersion: i have no idea
09:07 tzimmermann: emersion, which question are you answering to?
09:08 emersion: yours ;P
09:08 tzimmermann: oh, ok. do you know if any user space re-uses any such damage clips in later commits?
09:21 emersion: oh, you mean the damage clips blob?
09:22 emersion: i think all userspace i know of keeps it strictly per-commit
09:22 emersion: it would be weird to persist it across commits, damage changes all the time
09:30 pq: yeah, what emersion said.
09:30 javierm: tzimmermann, emersion: if this is cleaned up and the damage clips are not carried over between page flips, can the ignore_damage_clips then be dropped ?
09:31 javierm: I mean the struct drm_plane_state.ignore_damage_clips
09:31 tzimmermann: emersion, right. that makes sense. the kernel's logic is very inconsistent. it clears the blob in the middle of the atomic check. then different pipeline elements see different state
09:32 tzimmermann: javierm, i'd rather make it the single flag for damage iterators
09:32 pq: tzimmermann, what do you mean by "frees the damage clips from user space" exactly? Does it implicitly destroy the blob and free its id?
09:33 tzimmermann: pq, exactly this
09:33 emersion: i wonder what happens when switching VTs from a FB_DAMAGE_CLIPS-aware DRM master to one which doesn't support FB_DAMAGE_CLIPS
09:33 emersion: is the new master unable to update any region outside of the clip?
09:34 pq: I see, that freeing probably needs to the kept then, surely some userspace already depends on it.
09:34 emersion: pq, if the free'ing is delayed a bit, until next commit, probably it's fine?
09:34 tzimmermann: emersion. that would be a full modeset; hence no damage clips
09:34 pq: emersion, yeah
09:34 emersion: tzimmermann: VT switch doesn't imply full modeset
09:34 pq: Are blob IDs re-used?
09:34 zamundaaa[m]: Doesn't damage clips automatically reset to zero, like in fence fd?
09:35 tzimmermann: specifically at https://elixir.bootlin.com/linux/v7.0.10/source/drivers/gpu/drm/drm_damage_helper.c#L81 if there's an implicit modeset, the kernel clears the blob
09:35 emersion: zamundaaa[m]: it would've been nice, with the wrinckle that ffmpeg kmsgrab wouldn't be able to read it
09:35 emersion: but it's a hack anyways
09:36 tzimmermann: now my question is: does user space require or want this? or rather not?
09:36 emersion: zamundaaa[m]: a bit too late for that anyways
09:36 pq: What if the kernel implicitly frees a blob ID, and then userspace later frees the same ID? Could that ID refer to something else by then? Are blobs ref-counted btw?
09:36 emersion: tzimmermann: does git blame say anything interesting?
09:38 zamundaaa[m]: emersion: making kmsgrab less useful sounds like a bonus to me :D
09:38 emersion: aha
09:39 emersion: tzimmermann: maybe it's a workaround for the VT switch or sth
09:39 tzimmermann: emersion, is says exactly nothing: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v7.1-rc6&id=d9778b40260950a01a00852be43ca6c5c2d97f69
09:40 emersion: well, i think there's no point in taking damage into account for modeset
09:40 emersion: and it's safer to ignore/reject damage, so that a modeset always starts from a blank state
09:41 emersion: but maybe the way the kernel implements this is not the right way, that i don't know
09:41 tzimmermann: emersion. exactly, we ignore damage in full modesets. but in some cases, user space supplied a page flip, but the driver upgrades to a full commit. in those cases, the kernel frees the damage blob
09:42 emersion: what do you mean by "full commit"?
09:42 emersion: do you mean modeset?
09:42 tzimmermann: emersion, a full modeset
09:42 emersion: kernel should never upgrade a regular commit to a modeset
09:42 emersion: if ALLOW_MODESET is not set, the kernel is not allowed to perform a modeset
09:43 tzimmermann: emersion, by regular commit, you mean page flip?
09:43 emersion: i mean an atomic commit without ALLOW_MODESET
09:43 emersion: which would be page-flip in legacy uAPI parlance
09:44 emersion: well, it's perfectly possible that there's a quirk of the legacy uAPI that i'm not aware of
09:45 tzimmermann: emersion, ALLOW_MODESET is still respected
09:47 emersion: pq, yes it's ref'counted, and user-space holds a ref iirc
09:49 javierm: tzimmermann: what I meant is that if you make the core to also do drm_property_blob_put() on page flips, then things like https://elixir.bootlin.com/linux/v7.0.10/source/drivers/gpu/drm/virtio/virtgpu_plane.c#L113 won't be needed
09:50 javierm: AFAIU that's a workaround to the fact that damage clips are carried over during page flips
09:51 tzimmermann: javierm, it's more complicated than that
09:52 javierm: tzimmermann: ah, I see. You still need if the buffer attached to the plane is changed between commits...
09:53 tzimmermann: the damage blob is for mere page flips. we cannot _put() them.
09:53 tzimmermann: the code in virtio is for flushing the framebuffer data (i think), while damage clips is for planes.
09:54 tzimmermann: i have a series that keeps damage blobs unconditionally across all state changes. instead it maintains ignore_damage_clips to control DRM's usage of the damage clipping
09:55 javierm: tzimmermann: and what will the semantics of ignore_damage_clips be? To always ignore it or ?
09:55 tzimmermann: a would assume from the comments here that user space always updates damage clips as required.
09:58 tzimmermann: javier, by default damage clips are enabled if present. if there's a special case that requires full-screen updates, drivers/helpers set the flag during atomic_check. later damage handling during atomic_commit would then ignore damage clips and go for the full update
09:58 tzimmermann: javierm ^
09:59 tzimmermann: that cleanly separates the user-supplied property from the kernel's interpretation
09:59 javierm: tzimmermann: got it
10:00 emersion: tzimmermann: so it would be nicer to set that flag there instead of dropping the blob?
10:00 tzimmermann: yes. from the discussion here, it seems that user-space is ok with this
10:00 tzimmermann: emersion ^
10:00 emersion: yes, seems so
10:01 javierm: that also sounds more consistent with what drivers do when they want the damage clips to be ignored so it makes sense to me as well
10:03 tzimmermann: you might want to look over this series, although it's still buggy in edge cases: https://lore.kernel.org/dri-devel/20260530185716.65688-1-tzimmermann@suse.de/T/#mb57af259fbcf28aae46e6f560962c74956df97b7
10:03 javierm: originally I was thinking the opposite, to set it to drop the blog and set to NULL everywhere but instead using the existing ignore_damage_clips makes more sense
10:03 javierm: and is more explicit indeed
10:03 javierm: tzimmermann: sure, I'll take a look
10:04 tzimmermann: thanks, javierm
10:06 tzimmermann: javierm, when i looking into damage-handling code, i found various conditions and tests that affect damage handling. the easiest resolution appears to consolidate this aroudn that flag. although i know that this wasn't the initial intention of the flag
10:07 javierm: tzimmermann: yeah, as mentioned I originally thought that could be dropped and instead use the lack of the blob as the condition
10:07 javierm: but given that there's a flag already, makes sense to use it and make the condition more explicit
10:34 javierm: tzimmermann: I reviewed your series. It's a nice cleanup, I just had two small comments
10:36 javierm: tzimmermann: now going back to virtio-gpu (and vmwgfx), I wonder if the 'new_state->fb != old_state->fb' condition shouldn't be part of drm_atomic_helper_check_plane_damage() as well
10:38 javierm: since there's no support for buffer damage currently, I believe that check could be part of the core and be dropped from these drivers
10:49 tzimmermann: javierm, why? if we swithc the fb, damage clips tell us what has changed. that's the main purpose.
10:50 tzimmermann: we cannot move this into check_plane_damage
10:51 tzimmermann: IIRC gnome uses 2 fbs to flip between them. simple mouse cursor movements would become really slow
10:53 karolherbst: glehmann: okay, at least in OpenCL is implementation defined, and the CL CTS test I was looking at was relying on specific behavior, so in the end I fixed the CTS and all is good. Was just curious how it's defined generally.
10:56 javierm: tzimmermann: right, I forgot about the whole per-buffer uploads vs per-plane or per-CRTC uploads distinction
10:56 javierm: tzimmermann: these virtual drivers are the odd ones so it makes sense for the check to be in the drivers
10:56 javierm: that's actually why I preferred to ask here instead of the mailing list since I wasn't sure about it
11:27 tzimmermann: javierm. yeah, makes sense to split the patch. will do that for the rev
11:29 tzimmermann: 'the next rev'
11:32 javierm: tzimmermann: thanks, and yeah if you split would be easier for stable to cherry-pick
12:41 wens: looking to do some more GEM DMA helper related cleanup, and this bit of code looks very weird #
12:41 wens: 242
12:41 wens: 243
12:41 wens: 244
12:41 wens: https://elixir.bootlin.com/linux/v7.0.10/source/drivers/gpu/drm/imx/dcss/dcss-plane.c#L241
12:46 wens: I imagine pitches should already be the correct value and does not need to be divided?
13:19 wens: and also it uses the dma address from gem dma object of plane 0 as the base for calculating the address of plane 1
13:19 wens: seems a bit iffy, even though I suppose most applications just use the same dma buffer for all planes, just one plane after the other
14:10 jnoorman: NIR (and related places like `spirv_to_nir`) often uses patterns like `nir_instr1(nir_instr2(...), nir_instr3(...))` to build instructions. Since the evaluation order of arguments is unspecified in C, this introduces nondeterminism in the compiler. I'm currently hitting this issue because my x86 drm-shim doesn't always produce the same output as my aarch64 native build. I imagine this could be en issue for tests as well (e.g., any test
14:10 jnoorman: using something like `check_nir_string`). So I was wondering how people feel about this: would it be a useful goal for Mesa to have a deterministic compiler?
14:19 karolherbst: jnoorman: given that most of those are generated, we might be able to enforce ordering globally for a lot of things
14:20 karolherbst: could wrap it with a macro, or something
14:20 karolherbst: though that might suck in different ways
14:24 karolherbst: do we have a simple way to determine if a nir_intrinsic uses a variable? mhh
14:24 karolherbst: well image variable to be specific
14:24 karolherbst: ohh I have a better idea, nvm
14:26 jnoorman: karolherbst:
14:27 jnoorman: you mean creating macros for all builders to enforce ordering? I tried to think of a way to do that but couldn't immediately think of one.
14:29 karolherbst: yeah.. just take the expressions as arguments and evaluate them in order in the macro and then call into a builder C function
14:29 karolherbst: but that turns all those into macros..
14:41 glehmann: ideally C would just have a defined execution order for this, it's just silly
14:44 karolherbst: you'd think there is a compiler option for that, but no :)
14:46 pq: what's one more compiler in Mesa, use it to compile that code with determinism...
14:51 jnoorman: glehmann: I agree, but I have found no way to force this somehow.
19:57 airlied: karolherbst: do you have llama.cpp fossils?
19:57 karolherbst: never created some, but you can run individual things easily
19:58 karolherbst: but yeah need to create fossils yourself
22:25 airlied: loop unroll 972 blocks to 13467 blocks might explain the slowdown
22:30 karolherbst: oof
22:31 karolherbst: maybe don't want to unroll that aggressively :)
23:02 airlied: the loop is marked as unroll in the spir-v though