01:52 swung0x48: I guess I need to acquire permission before I can fork Mesa into my own namespace and work on that?
01:54 Sachiel: swung0x48: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/new?description_template=User%20verification
01:55 swung0x48: yeah i've already done that: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/2533
01:59 Sachiel: now just wait for someone with access to grant it to you
05:37 mareko: do you think hosting the kernel drm-next tree on Gitlab with pre-merge testing by Gitlab CI would be a good idea?
05:52 airlied: mareko: well the tree is hosted there, just a matter of working out how to get pre-merge MRs open for incoming stuff
06:28 mripard: mareko: airlied: I gave it a try earlier that year (or was it last year?) for drm-misc here https://gitlab.freedesktop.org/mripard/kernel-other/-/blob/drm-misc-templates/.gitlab-ci.yml?ref_type=heads
06:28 mripard: the feedback was mostly that I should be using the freedesktop and gitlab-ci templates more, but I haven't been able to wrap my head around them since.
07:36 daniels: drm/msm already has that
08:00 mripard: daniels: msm uses drivers/gpu/drm/ci/gitlab-ci.yml?
08:34 daniels: mripard: yeah, has done for a little while now - it's still not pre-merge blocking, but it is there
09:41 ella-0: Hi, I'm looking through the util/list iterators and currently the unsafe variant of the iterator keeps track of the next element which means the next element in the list can not be removed. Would anyone be opposed to change to this making it more similar to the glsl/list in allowing the next element to be removed?
11:00 mlankhorst: mripard: sorry for the delay, but I'm looking into the dma-buf cgroups process charging interaction, and I thought you maybe had some insights in those?
11:44 mripard: mlankhorst: sure, go ahead
11:49 mlankhorst: I think the model in android is that there is a central allocator, and then you want the buffers to be charged to the clients that allocate?
11:51 mripard: yep
11:51 mripard: it's not just in Android, we have the same thing for any compositor, and I would suspect for pipewire ?
12:03 daniels: mripard: clients still allocate their own buffers in both wayland and x11
12:09 mripard: daniels: really? I thought (at least with X11) you could have the DDX allocate a buffer for a client? Or is it only for the server's internal needs, and it would only contain the composition outpuT?
12:11 daniels: mripard: DRI2 allocated on behalf of clients, but DRI3 shifts the allocation back to the client
12:14 pq: mripard, Wayland compositors allocate only for their own needs: framebuffers, and if they want their own copy of window contents (e.g. if the client buffer is not reasonably GPU-accessible).
12:15 pq: very much no central allocator process here
12:16 mripard: daniels: pq: ack, thanks :)
12:20 mripard: mlankhorst: then, yes, my understanding is that in Android SurfaceFlinger uses a HAL (gralloc) to allocate client buffers
12:20 mripard: but my understanding was wrong with wayland, so take it with a grain of salt :)
12:21 mripard: afaik, TJ was working on an API to transfer the charge to another process at some point to address this
12:21 mripard: and airlied was working on something similar recently I think?
12:21 mlankhorst: Yeah
12:24 pq: mripard, a funny scenario: a client allocates a dmabuf, send it to the Wayland compositor, client fully unref's the dmabuf, compositor keeps the dmabuf alive; who gets the blame of hogging memory? :-)
12:24 mripard: I'm pretty sure I'd have left to do goat cheese by the time we get to that corner case :)
12:25 pq: Enjoy!
12:29 pq: actually, Linux must already have an answer to that, because one can do the exact same thing with a memfd.
12:30 mripard: I wonder if you can track it through the fds, and/or double-charge
12:33 mlankhorst: pq: Either way, once compositor is done it drops the reference, so nothing bad should happen?
12:33 mlankhorst: Just wait until the next pageflip..
12:35 pq: mlankhorst, normally, yes.
12:36 pq: but the accounting should be accurate regardless - the compositor might have a bug and not release it always.
12:36 pq: killing or limiting the client would be useless in that case
12:37 mlankhorst: Then the problem is a bug in the compositor causing a denial of service
12:37 pq: yes
12:37 pq: so the memory should be charger to the compositor
12:37 mlankhorst: That would open another bug in this case..
12:38 pq: OTOH, if we have a malicous client that purposefully gives the compositor memory to hold, it should be charged to the client.
12:39 pq: If it's double-charged, then killing either process alone won't release that memory. But maybe that's not the intention either?
12:41 pq: When the allocating process closes its last handle to a piece of memory, then the memory cannot be charged to the process anymore - it has released it and cannot do anything more. Do you transfer the charge to another process that still has a handle? Or not?
12:42 pq: If not, there will be the funny situation that memory is taken, but no-one owns it. Maybe that's not a problem though?
12:43 pq: I dunno :-D
12:45 Ermine: does the same problem apply to wl_shm buffers?
12:45 pq: Need to step back and ask what the goal of accounting is.
12:46 pq: Ermine, it can, yes. And I assume the cgroup memory accounting does something about it.
12:47 pq: I just don't know what.
12:54 mlankhorst: The original cgroup stays alive
12:55 mlankhorst: Process that allocates it, keeps charged to it
12:55 pq: ok
12:56 pq: What happens when the process exits, and another process in another cgroup keeps the allocation alive?
12:56 Ermine: Same can be done to dmabufs anyway?
12:58 pq: I suppose the "everyone allocates for themselves" is not a problem, but the Android central allocator is?
12:58 mlankhorst: The allocation keeps the cgroup alive
12:59 sima: pq, for android's binder there was patches to transfer the charge away from the central allocator
12:59 sima: so if android wants to use this, they need to resurrect those
14:21 robclark: hmm, so recent mesa, deqp is crashing.. istr there were some changes related to x11 thread safety.. any hints:
14:21 robclark: https://www.irccloud.com/pastebin/Tk2edpzA/
14:21 robclark: (and also, how was this not a problem in CI?)
14:22 zmike: CI doesn't run on x11
14:22 zmike: it uses surfaceless
14:23 zmike: and I'd assume that should be fixed by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37006 if it ever becomes mergeable
14:25 robclark: hmm, I am using a surfaceless deqp build as well.. so hmm, how do we end up there?
14:26 robclark: hmm, ok.. EGL_PLATFORM=surfaceless helps
14:26 alyssa: i think that env vars been needed since always
14:27 robclark: hmm
14:27 robclark: pretty sure I didn't have to use that before..
14:27 robclark: maybe I changed something in my setup
15:31 zmike: mareko: ping https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36634
16:50 glehmann: are there any helpers for post dominance?
16:53 glehmann: for nir, I mean