06:55 tzimmermann: danvet: about that topic branch: after 'dim apply-pull', 'dim push-branch' is the way to push the patches into the public repo?
08:34 danvet: tzimmermann, yup
08:35 tzimmermann: danvet, ok already pushed
08:49 MrCooper: I'm going to remove the image repositories on https://gitlab.freedesktop.org/mesa/mesa/container_registry which are no longer used on master or the 20.0 branch: lava_arm{64,hf}, {buster,stretch,testing}-slim, x86_test
09:31 austriancoder: daniels: I think you are the right person to ask: does this simple example for khr_partial_update looks sane? https://hastebin.com/ozesuwihax.cpp
09:44 daniels: austriancoder: i assume you'd never get an age >= -1 though?
09:44 daniels: er, >
09:44 daniels: i mean, broadly speaking that does look correct, but you do need to make sure you have a valid age first
09:46 austriancoder: daniels: the age is always 0
09:48 shadeslayer: anholt: Is there a way we can quantify 'interesting workload' so that we can expand this? https://gitlab.freedesktop.org/shadeslayer/traces-db/-/commit/5ae0766404a50c269bb27127590b229ff50d93e8
09:49 daniels: austriancoder: right, 0 means that the buffer is new and uninitialised, so you can't use a partial update on it, it needs to be full
10:01 dschuermann: @intel: can/do you optimize iadd(x, b2i(cond)) to add_carryin(x, 0, cond) in the backend?
10:02 dschuermann: asking because it has some implications on how you'd want bcsel optimized by NIR to get that pattern more often
12:12 austriancoder: daniels: not sure what full stands for in this context.. but I think something like this: https://hastebin.com/unelukukik.bash
12:13 daniels: 'full' update means a non-partial update
12:13 daniels: if the buffer age is 0, the buffer contents are completely unknown, so you must paint the entire buffer
12:13 daniels: but if the buffer age is >0, you can reason about the existing content of the buffer and only update changed regions
12:24 austriancoder: ah.. full update
14:19 danvet: pq, just realized that link_status doesn't give you the nice property with CONNECTOR=%id and PROPERTY=%id
14:19 danvet: but could be easily fixed
14:22 pq: danvet, you mean, no-one wrote the code to put that into the hotplug event? Did the fine-grained hotplug events land already?
14:22 pq: or that link_status is somehow unsuitable for fine-grained hotplug events?
14:23 emersion: it's suitable, but not done
14:23 emersion: fine-grained hotplug events didn't land :(
14:24 danvet: pq, yup, for hdcp
14:24 danvet: but link_status preceeded it, so it's not wired up
14:24 danvet: emersion, I've looked at the code, seems to be ther?
14:24 emersion: oh?
14:25 danvet: drm_sysfs_connector_status_event
14:25 emersion: it's there for hdcp
14:25 danvet: it's just, you only get it for hdcp :-P
14:25 pq: did someone write the userspace?
14:25 danvet: so type userspace, we'll add it
14:25 emersion: not for link-status right?
14:25 danvet: yeah not for link status
14:25 danvet: or for connection status
14:25 emersion:can definitely type user-space
14:25 danvet: emersion, connection status is a pile more typing
14:26 danvet: since the locking is more tricky
14:26 danvet: but link-status should be easy
14:26 emersion: okay
14:26 emersion: problem is
14:26 emersion: it's hard to trigger a link-status failure
14:26 danvet: pull cable?
14:26 pq: ahhaha, I forgot the hdcp fine-grained event userspace is already in Weston. :-p
14:26 emersion: i don't have the chamelium to test anymore
14:27 emersion: pq: does weston also handle these events for non-hdcp?
14:27 emersion: in other words, is the fine-grained event handling generic and not tied to hdcp?
14:28 danvet: hm cable pull wont work, we'll auto-retrain once it's back in
14:28 danvet: you'd need to exchange it by a shitty one
14:28 emersion: danvet: wouldn't that just disconnect?
14:28 emersion: yeah
14:28 pq: emersion, the new property value look-up is generic, but the value is only used if it is the HDCP thing.
14:28 emersion: ok
14:28 pq: weston does not do link_status at all
14:28 emersion: ah :(
14:28 danvet: emersion, essentially replace the call to drm_sysfs_hotplug_event with drm_sysfs_connector_status_event
14:28 danvet: in the kernel
14:28 danvet: and it's wired up
14:29 emersion: let's see
14:31 danvet: the trouble is that given how much hotplug uevent we have sprinkled around everywhere
14:31 danvet: it's always only ever going to be an optimization
14:32 danvet: so if you don't have the CONNECTOR=%id you still need to process everything that every had the non-specific events
14:33 emersion: yeah, but that's fine
14:41 emersion: bleh, compiled the i915 change on my non-intel machine
15:19 danvet: pinchartl, you're making sure that the tegra bridge support is following the new style?
15:19 danvet: aka can I ignore that thread :-)
15:20 danvet: tomba, [PATCH 01/59] drm: Add devm_drm_dev_alloc macro <- feel like taking a look?
15:20 danvet: or was that jyri
15:24 pinchartl: danvet: Sam and I are keeping an eye on it, but I only see patches I'm CC'ed on
15:25 danvet: pinchartl, add a regex MAINTAINERS entry for drm_bridge?
15:25 danvet: to also catch the driver-side interfacing
15:26 pinchartl: I'm barely coping with the e-mails I'm CC'ed on :-)
15:26 danvet: I've done that recently to catch dma_buf stuff tree-wide, just in case :-)
15:26 danvet: pinchartl, ok that's harder problem
15:55 tomba: danvet: yes, I can take a look next week. I guess you missed my ping earlier. I wasn't able to apply your series, and asked what is the series based on?
16:06 danvet: uh gone
16:30 karolherbst: anybody affected by the problem I try to solve here? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/123
16:30 karolherbst: or anybody else seeing those CTS tests fail?
16:31 karolherbst: just wondering if this is really just a issue affecting nouveau or other drivers as well
16:32 imirkin: it definitely _could_ affect other drivers, but perhaps nouveau is the one that gets caught
16:56 MrCooper: dcbaker: no time to file an issue right now, but piglit b535e2e34ba244f2b4b7e43f16ce624804650167 "framework: Actually deserialize the test environment" broke at least the gpu & cl profiles here: https://paste.debian.net/1140973/
17:04 dcbaker: MrCooper: I'll fix it
17:35 dcbaker: MrCooper: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/263
18:00 sravn: danvet: Let DRM_FBDEV_EMULATION depend on FB sounds OK IMO. But one has to click [y] or [y] to FB before one is offered the choice to enable the emulation.
18:01 sravn: But this is less magic than when you have to select one small non-obvious thing far away like for example backlight, before you can see a DRM driver
18:53 danvet: sravn, the trouble is that it's not even there
20:26 Putti: Hi, mesa loader tries to use renderD128 node but I would like to use renderD129, how do I do that? I tried export DRM_PRIME=1 without no luck.
21:07 soreau: Putti: I think it's DRI_PRIME
21:09 Putti: soreau, thanks, I should really get some sleep...
21:43 imirkin: does anyone remember who was doing stuff in the kernel with big endian and formats? they landed some patches, i wanted to look over them, but don't remember the precise name
21:43 imirkin: either gerd or geert, and probably a last name
21:45 imirkin: aha, looks like Gerd Hoffman
22:39 karolherbst: ehh.. is it normal that the cursor is "laggy" under wayland? Or is that just the compositor being stupid doing sw rendering of the cursor?
22:39 karolherbst:enabled too much kernel debugging stuff, no everything is slow
22:41 anarsoul: karolherbst: which compositor?
22:41 karolherbst: kwin
23:43 anholt_: jekstrand: so, any thoughts on what we could do that's like nir_search for codegen purposes?
23:59 jekstrand: anholt_: Unclear.
23:59 jekstrand: anholt_: For one, thing, I think it's a whole lot more sane if you can do it in SSA without source modifiers.