03:35 veryclosed: I remember graphitemaster saying how monkeys will eat each other , first of all i am not even considered a monkey with all the offshore science, they studied my bones and their shapes always looked a bit different than for others, and the blood group is also likely a- which is more of an alien genotype, but i have different theory about that, third of all those were male obnoxious stalker abuse bullies, yet horrible at
03:35 veryclosed: any performance who cause they whole tourism island to bleed empty, and really they are much hated as of now, by anyone. And such blokes will get physical treatment anyway. They were harassing all my friends and businesses. Khmers do not like that their high end tourism magnet islands stay out of business. So first thing they will look at is to get abusers out of there, who distract tourists, i am just clapping hands for
03:35 veryclosed: it, totally mind ill people i faced there doing just that. Khmer military there might be quite strong, accounted that when a large conflict happens they will ally with vietnam and thailand and myanmar even and lao and such. They did already aimed guns out anyhow to major nasty folks disturbing tourism.
03:49 kode54: I remember one channel I was once in banned the entire city of Toulouse from their forum because of one ban evader
03:50 kode54: just, up and grabbed all the IP ranges for the city wide ISP and added them all to a huge ban block
03:51 airlied: we used to ban all of estonia
03:53 Dark-Show_Pi4: zmike: Commit 2978b85789cb1d5847c88c17dc6ce8fdaa1e8cfd has broken zink support on the Pi4 with "ZINK: vkCreateDevice failed (VK_ERROR_FEATURE_NOT_PRESENT)" removing the lines added with that commit re-enables support.
04:15 youresuicidal: I generally remind you, how all your trash got banned from freenode, hahaaa, all your birth bully abortion leftovers, literally all. I would not say those words, you still halt the worlds computing cause your skills and behaviour is not something considered high end class.
04:35 hch12907: I think the spamming has gotten worse lately
04:50 kode54: you can probably ban that whole /64
07:42 MrCooper: soreau: both drmModeAddFB calls use the same handle, so both FBs reference the same underlying BO
07:45 soreau: MrCooper: yea I saw how kmscube did it when I was writing this https://gitlab.freedesktop.org/mesa/kmscube/-/merge_requests/47
07:46 MrCooper: to be clear, they need to reference BOs for page flipping to have any effect
07:46 MrCooper: *different BOs
07:57 soreau: MrCooper: thanks for the clarification
08:17 pq: FB is a wrapper with some metadata and points to a BO, which points to the piece of memory containing the pixels.
08:27 linkmauve: Are BO and GEM handle synonymous? I recently wrote a DRM client which didn’t use gbm at all and didn’t encounter the BO terminology anywhere.
08:35 pq: linkmauve, depends on the context
08:35 tzimmermann: javierm, jfalempe, do you have comments on https://lore.kernel.org/dri-devel/20230920142535.19321-1-tzimmermann@suse.de/T/#t ? i've updated the format helpers with an extra argument that stores the internal buffer; including preallocation. this might improve performance slightly, but most of all it allows to avoid kmalloc during in drm_panic. with the right setup, it will also be possible to blit glyphs directly into the
08:35 tzimmermann: scanout buffer. only a minimal amount of tmp memory will be required for drm_panic
08:36 pq: linkmauve, here we are talking about a GBM app, so a BO is a gbm_bo, and a detail unmentioned is that you get a GEM handle out of the BO to create a DRM FB.
08:36 lynxeye: linkmauve: A GEM handle is the userspace reference to a GEM object, which is what is usually called a buffer object or BO for short in kernel context
08:39 linkmauve: Ok, thanks. :)
08:41 pq: linkmauve, btw. were you aware of the caveats: https://gitlab.freedesktop.org/mesa/drm/-/blob/main/xf86drm.h?ref_type=heads#L816-833 ?
08:44 jfalempe: tzimmermann, I'm still protyping the changes to make drm_panic draw line per line.
08:44 linkmauve: I have read that text, but I’m still not sure about the lifetimes of either object. The fd will be usable until I close() it, but is the handle’s lifetime tied to the fd’s in my process?
08:45 pq: no, the handle needs to be closed explicitly
08:46 jfalempe: tzimmermann, I'm also considering doing in-place conversion, as I need a buffer to write xrgb8888 data, and if the destination format is 32bits or less, it would be better to convert in place.
08:46 linkmauve: drmCloseBufferHandle() under it?
08:46 tzimmermann: jfalempe, ok. glyph-by-glyph might easier
08:47 pq: linkmauve, yes. But drmCloseBufferHandle() simply closes the handle without any reference counting.
08:48 jfalempe: tzimmermann, Also I planned to call directly line functions like drm_fb_xrgb8888_to_rgb565() because I don't have framebuffer or clip objects in drm_panic.
08:48 linkmauve: My current usecase is I get a fd from V4L2’s EXPBUF, get a GEM handle for it, to import into a DRM framebuffer, so only a single process is involved for now.
08:48 tzimmermann: jfalempe, right. you can use existing format helpers for conversion. drm_fb_blit() copies a framebuffer into a scanout buffer. and it convert the format if necessary.
08:49 linkmauve: Eventually I will let the user of my decoding library decide whether it imports the fd in DRM, or in EGL, or in mmap().
08:49 linkmauve: So if I don’t import it into a DRM framebuffer, that is if I don’t drmPrimeFDToHandle(), there is no handle created and thus nothing to close either?
08:50 tzimmermann: jfalempe, the glyph is a bitmap IIRC. if you set the input framebuffer to DRM_FORMAT_R1 and point the src data to the glyph buffer, it should be possible to draw the glyph directly into the output
08:50 linkmauve: Except if EGL did that for me behind the scenes, but then I don’t have to care either because EGL does its stuff.
08:50 pq: linkmauve, even so, if you happen to import the same buffer again, and you already have a GEM handle for it, you will get the *same* handle. If you then close the handle once, it's gone for the both fds.
08:50 tzimmermann: the format conversion is implicit. if the output buffer is already in _R1, no conversion would happen
08:50 jfalempe: tzimmermann, yes that's how fbdev work, it consider the glyph as a 1bit image.
08:51 pq: linkmauve, yes, no need close if you didn't get a handle in the first place.
08:51 tzimmermann: and for the format conversion, you'd only need a few bytes of temporary memory. with the new patchset you can preallocate that easily.
08:52 pq: linkmauve, the problem is, if you call FDToHandle, and EGL internally does FDToHandle, then both you and EGL have the same handle. If one of you closes the handle, also the other loses the handle.
08:52 tzimmermann: the format-helper tests in tests/ have some examples on how to make a 'fake' framebuffer to use with the format-conversion API
08:52 linkmauve: pq, how do I make sure two fds are for a different file description btw?
08:52 pq: ...on the same fd, or a different fd pointing to the same kernel BO
08:52 tzimmermann: (the current api could be better, i guess)
08:52 pq: linkmauve, you don't, really.
08:53 pq: that's why you should use GBM for all fd-to-handle purposes, so it does the reference counting right.
08:56 pq: linkmauve, I don't think it matters whether the file description (nor file descriptor) are the same or not. What matters is which kernel BO they point to.
08:56 linkmauve: Would you recommend that even if I only import the buffers to a framebuffer? In order to avoid maybe reusing the same buffer from V4L2?
08:56 pq: linkmauve, you said you were writing a library that might sometimes import to EGL instead.
08:57 linkmauve: Ideally I don’t know what the user is doing.
08:57 pq: linkmauve, do you also expose the dmabuf fd or some other handle to your library users?
08:57 linkmauve: Currently I only give the dmabuf fd yes, alongside the required metadata to import it.
08:58 linkmauve: Size, format, modifier, offsets, strides.
08:58 pq: linkmauve, so, your users could be calling FDToHandle without you knowing.
08:58 jfalempe: tzimmermann, ok, I'm looking into that, (and I will review your patches too).
08:59 linkmauve: Yes.
08:59 tzimmermann: thanks
08:59 pq: linkmauve, if your lib, or the user, then closes the GEM handle, both will lose it.
08:59 linkmauve: Speaking of which, I don’t even know when it’s ok to reuse the buffer for the next V4L2 request.
09:00 pq: linkmauve, the only remedy is that everyone must be using GBM for getting a GEM handle from a dmabuf fd.
09:00 linkmauve: My library should never actually deal with GEM handles, the user should.
09:00 pq: GBM is the one that reference counts then properly, and it also works if you import to EGL, since EGL internally uses it too.
09:00 linkmauve: Right.
09:01 pq: ok
09:02 linkmauve: Hopefully my library will limit itself to handing out buffers from V4L2, and that’s it, but I think I still need to know what the user does with them in order to reuse them or not.
09:02 pq: btw. in general buffer re-use is recommended, because freeing and allocating is heavier. Ideally you do all the imports and handle conversions once, and then in steady state just switch between what you have.
09:03 linkmauve: Perhaps I need to have an API function which the user calls to release the buffer, or something.
09:03 linkmauve: Yup, I could see that while tracing, REQBUFS takes some millisecond or so.
09:03 pq: yes, you will need some kind of sync mechanism
09:06 pq: if you also support resize, you might want to have buffers individually created and destroyed as needed, rather than a whole "swap chain" at a time.
09:07 linkmauve: I’m currently focusing on image formats (I have static opaque lossy webp implemented already, yay!), but those include videos nowadays.
09:30 mlankhorst: Lyude: should i expect a whole lot of nouveau commits in drm-misc-next?
10:03 jani: where's a no-nonsense guide to deploying documentation from a fdo gitlab repo to pages?
11:09 pq: jani, what's nonsense? https://gitlab.freedesktop.org/wayland/weston/-/blob/main/.gitlab-ci.yml?ref_type=heads#L556-581 ?
11:12 jani: pq: but I guess you first need to have a container registry or something something?
11:13 jani: pq: those lines have stuff like "- .fdo.suffixed-image@debian"
11:14 Venemo: why do we even bother with Mesa 23.2 at this point? why not just go straight to 23.3
11:15 pq: jani, yes, if you want to. Or you don't, and run some generic container that where you create a public/ dir any way you want.
11:15 ishitatsuyuki: Venemo: context for 23.2 vs 23.3?
11:15 pq: jani, every project has a container registry. Weston uses ci-templates to create and re-use custom containers.
11:15 Venemo: ishitatsuyuki: well, Mesa 23.2 hasn't had a final release yet and the branch point for 23.3 is very close now, isn't it?
11:16 ishitatsuyuki: ok, I see
11:16 Venemo: maybe I am missing some context on what happened with 23.2?
11:17 jani: pq: I'm just looking for a basic guide with simple steps to get this done, from scratch, on a new project. zero experience in gitlab workflows, some experience in github workflows
11:17 pq: There are the gitlab docs, but I suppose those are not what you want.
11:18 jani: pq: maybe I just need to set aside more time to peruse them. seem a bit exhausting :p
11:19 jani: pq: after that, the weston yml will probably be helpful, thanks
11:19 pq: jani, is the hypothetical project already having CI running in any way?
11:19 jani: pq: nope, nothing at all
11:20 pq: ok, I think that should be the first step then. Look at pages as a second step.
11:20 pq: as in, decide where and how you want to get your containers from
11:22 jani: pq: okay, thanks
11:22 pq: jani, https://docs.gitlab.com/ee/ci/quick_start/ - maybe is some kind of default container, since I don't see it configured...
11:25 pq: jani, then, https://docs.gitlab.com/ee/user/project/pages/
11:37 koike: Hi sima o/, a few drm/ci patches were sent to the list with A-b's, I would like to check with you about the workflow, who should pick those patches up
11:59 Venemo: dj-death: can you please finish your review on this one? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24752
12:04 dj-death: Venemo: will do, maybe not today though
12:05 Venemo: dj-death: thanks, can I assign it to you?
12:09 dj-death: Venemo: sure
12:09 Venemo: done, thx
12:44 sima: koike, kinda on vacations, but check with drm-misc maintainers if a backmerge is needed and then push to drm-misc-next
12:49 koike: sima: ok, thanks!
12:58 mlankhorst: just wait a bit btw
13:01 mlankhorst: I would like to confirm that some patches belong to drm-misc-next, otherwise I need to rebase it, backmerge would mess it up
15:24 soreau: the runner said I don't have enough privs to run jobs for MRs so it spams my inbox with fail messages :P
15:34 soreau: what is the producedure to gain enough privileges to run jobs for MRs on gitlab.fd.o?
16:21 soreau: zmike: To run wlroots compositors with drm backend, you have to make sure drm backend is enabled in wlroots first
16:21 zmike: pls post in ticket
16:21 zmike: thx
16:22 soreau: ok, updated comment
16:26 cmarcelo: To know what margebot is up to I've been using a search on MR with filter: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?assignee_username=marge-bot&scope=all&sort=updated_desc&state=opened&utf8=%E2%9C%93 is there a better way to do that (i.e. does margebot itself have a log or status somewhere)?
16:27 DavidHeidelberg: cmarcelo: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20347
16:29 DavidHeidelberg: but needs to be rebased, it's loooong time ago
16:35 cmarcelo: DavidHeidelberg: thanks, I'll take a look at that.
18:22 mlankhorst: Lyude: ping?
18:30 Lyude: mlankhorst: I can make one if you want, I had pushed it there after asking airlied
18:51 anholt: anyone up for acking some piglit test coverage for my refactor long ago? https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/813
18:53 mlankhorst: Lyude: Ok that's fine, I just wanted to know all the nouveau commits in drm-misc-next were intentional before making a new pull request. :)
18:53 Lyude: yeah it's intentional! :)
18:55 sima: Lyude, so time for a MAINTAINERS update to add drm-misc as nouveau repo?
18:56 sima: maybe also add the new volunteers there if that's not yet done
18:56 sima: can also just add as reviewers
19:24 mareko: karolherbst: can rusticl use PIPE_CONTEXT_COMPUTE_ONLY?
19:24 karolherbst: last time I tried it was broken in radeonsi
19:25 mareko: it works on CDNA
19:25 airlied: but it should definitely use it
19:25 karolherbst: but I kinda want to rather have screen flags also for other things
19:25 pepp: karolherbst: I tried a while ago and it worked fine
19:25 karolherbst: mareko: I think something was broken with the compute blitter, but I can check again
19:26 mareko: karolherbst: pipe_context::blit isn't supported by compute-only contexts
19:26 karolherbst: yeah.. it wasn't through the blit method
19:26 mareko: regardless of the method
19:26 karolherbst: just accelerated resource/image copy things using compute instead of 3D
19:27 mareko: compute-only contexts can only use util_compute_blit at the moment
19:28 mareko: which implements a subset of pipe_context::blit
19:28 karolherbst: right... but CL doesn't have API blits anyway
19:28 karolherbst: all I know is that some GPU accelerated shader based resource copy path wasn't working correctly
19:28 karolherbst: but that was like last year probably
19:29 karolherbst: I'll check with the CTS and report back
19:29 mareko: if si_compute_copy_image returns false, we should look into it
19:30 karolherbst: any specific reason you are asking, or just being curious here?
19:32 mareko: karolherbst: yes, it's a long story, you can also set PIPE_CONTEXT_COMPUTE_ONLY if PIPE_CAP_GRAPHICS returns 0, otherwise CDNA will refuse to create a context
19:32 karolherbst: ahhh
19:33 karolherbst: right.. CDNA was entirely without 3D support
19:33 karolherbst: yeah, makes sense
19:34 karolherbst: okay, if I don't run into any bugs, I'll just set PIPE_CONTEXT_COMPUTE_ONLY, otherwise I'll check for PIPE_CAP_GRAPHICS
19:40 dcbaker: zmike: I have an unexpcted pass from zink-lvp: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49441458. Should I just mark that as expected pass and move on?
19:43 mareko: karolherbst: clear_texture won't work with a compute-only context, you can use util_clear_texture_sw in the meantime
19:43 karolherbst: ahh, yeah, that might explain it
19:44 karolherbst: atm I fall back to `u_default_clear_texture`
19:44 mareko: that might also work
19:44 karolherbst: if that's the case, radeonsi can just not set the clear_texture cb and rusticl will fall back to u_default_clear_texture
19:44 karolherbst: I can try that later
19:45 mareko: radeonsi uses u_default_clear_texture, which should fallback to sw because clear_render_target is NULL
19:45 karolherbst: okay
19:46 mareko: oh, it's not
19:46 mareko: yeah it will crash most likely
19:52 karolherbst: my GPU hard reset :')
19:52 karolherbst: or rather.. it doens't do anything
19:55 karolherbst: mareko: yeah.. removing si_clear_render_target indeed helps
19:55 karolherbst: but seeing some errors in dmesg "amdgpu: failed to get a new IB (-512)" and "amdgpu: failed to clear page tables on GEM object close (-512)"
19:56 mareko: karolherbst: that's probably a result of the hang/reset
19:56 karolherbst: even after a reboot?
19:56 mareko: I see
19:57 mareko: we shouldn't see those results after reboot
19:57 karolherbst: but I did a warm reset, so maybe some leftover state on the hardware
19:58 zmike: dcbaker: yes
19:58 dcbaker: zmike: 👍️
20:04 karolherbst: mareko: besides that the CTS is clean
20:04 karolherbst: only saw those messages right at the beginning
20:04 mareko: ok good
20:05 karolherbst: ehh wait... I think I removed my commit setting COMPUTE_ONLY
20:06 karolherbst: okay.. another run then
20:06 karolherbst: yeah.. nevermind, it's still broken
20:07 karolherbst: I'll dig into it later and see what's actually causing this
20:20 mareko: karolherbst: most likely you need to set the environment variable AMD_DEBUG=nodcc
20:22 karolherbst: mhh, doesn't help
20:22 mareko: karolherbst: what's the failing test doing?
20:23 karolherbst: I didn't pinpoint which test(s) are causing it yet
20:32 karolherbst: mareko: something with shared memory it seems
20:34 karolherbst: looks like a null pointer access
20:34 karolherbst: maybe shared memory doesn't get bound or something?
20:35 mareko: karolherbst: shared memory isn't bindable
20:35 karolherbst: pepp: it's the `api/test_api execute_kernel_local_sizes` causing issues
20:37 karolherbst: ehh wait.. it's not even using shared memory
20:37 karolherbst: just running a shader
20:37 karolherbst: let me try to figure out what exactly messes it up
20:38 karolherbst: mhhh... RUSTICL_DEBUG=sync fixes it...
20:38 karolherbst: maybe something with fences or so messing up
20:39 karolherbst: I'll try to figure out more tomorrow
21:00 mareko: karolherbst: can you also please check whether this fixes it? https://pastebin.pl/view/raw/7396a189
21:02 karolherbst: yep, that helps with that single test
21:12 karolherbst: mareko: with that patch I don't see any regressions and it seems to work: https://gitlab.freedesktop.org/-/snippets/7690
21:12 karolherbst: I still have AMD_DEBUG=nodcc set though
21:12 karolherbst: trying a new run without it
21:13 karolherbst: but that also seems to work, or at least it's not as broken as without that patch so far
21:29 karolherbst: yep, looks fine without nodcc as well
22:58 orowith2os[m]: Does anybody know if using a DRM master node gives a compositor anything special than just privileged ioctls?
22:58 orowith2os[m]: I asked karolherbst about it elsewhere but nothing solid
22:59 orowith2os[m]: I'm mainly interested in if a compositor running on a master node has higher priority for GPU work
22:59 orowith2os[m]: And if other clients on render nodes get put at a higher priority when e.g. gaming or using direct scanout
22:59 anholt: nope, it's just the ioctls.
23:21 anholt: argh. no gdb and no apt in the ci rootfs
23:29 orowith2os[m]: anholt: ouch, would like to maybe sort something like that out at some point
23:30 orowith2os[m]: Iirc ChromeOS has GPU hints for when things happen, if we can drag that over into desktop Linux it would be amazing
23:30 orowith2os[m]: (and Mutter would be able to make decent use of it)
23:30 anholt: hooking up queue priorities: great. associating literally any new behavior with DRM control nodes: bad.
23:31 orowith2os[m]: Anything to hint the GPU when it needs to clock up and when it can go into low power mode
23:32 orowith2os[m]: (e.g.: low clocks normally, slightly higher to accommodate overview animations, back down when not doing anything)
23:33 orowith2os[m]: Right now I believe the flow is you do something -> GPU sees you do something -> GPU clocks up
23:33 orowith2os[m]: This would be you hint that you're about to do something -> the GPU clocks up -> you do something
23:34 anholt: a common way to fix this on phones is to hook input after an idle delay to preemptively clocking up gpu.
23:34 orowith2os[m]: If that's making any sense
23:34 anholt: which doesn't require any app smarts
23:34 orowith2os[m]: Hm
23:34 anholt: and is entirely within the kernel
23:34 orowith2os[m]: Yeah, I believe that's what ChromeOS does
23:34 orowith2os[m]: But I don't believe it's ever been upstreamed
23:35 orowith2os[m]: So many believes, eugh
23:35 anholt: also, if your kernel driver doesn't quickly clock up on submit after an idle period, that's also a driver bug.
23:35 orowith2os[m]: But a general hinting mechanism would probably be better
23:35 anholt: but this is my opinion
23:39 zamundaaa[m]: Dallas Strouse (she/her) 🧑‍🏫: there is https://lists.freedesktop.org/archives/dri-devel/2023-August/419773.html
23:41 zamundaaa[m]: But yeah it would be good to have something that can be done before any rendering commands were submitted, to work around things like PSR. Afaik the kernel does some guesses based on input events, but that's imo a really bad hack and not super useful
23:41 orowith2os[m]: Yay! Glad to see Kwin is taking some interest too :)
23:42 zamundaaa[m]: Guess for PSR specifically, a compositor could just commit a pageflip with an old buffer. But that feels like a hack too, just in userspace instead of the kernel
23:44 orowith2os[m]: Mutter's use case is to work around it taking too long to get to GPU work; it stays on the CPU for so long that frames get sent late, which is why triple buffering patches exist
23:45 orowith2os[m]: Getting to hint the GPU when it's about to do something means it can reject the triple buffering patches entirely
23:45 orowith2os[m]: The problem itself should be fixed too, but the workaround/solution has more use cases, so
23:46 orowith2os[m]: Just to be sure, I'd like to rope in jadahl to confirm I have everything correct
23:46 orowith2os[m]: I am fairly new to all of this