09:47 mripard: lumag: did you end up having the time to look into the msm legacy_cursor removal regressions?
09:48 mripard: we have a bad bug on vc4 that is caused by it, and I was ping'd about it again
12:59 lumag: mripard: no...
13:00 lumag: mripard: is it about dropping legacy_cursor interface and only using planes for it?
13:06 mripard: lumag: yes
13:10 lumag: mripard: do you have a pointer to VC4 issue?
13:18 lumag: mripard: I'm asking, because I remember an AI/TODO on me to drop legacy cursor from the MDP5 driver, but I don't have anything else related in my memory.
13:23 mripard: lumag: https://lore.kernel.org/all/20230127-rpi-cursor-corruption-v2-1-1f97bd00df01@cerno.tech/
13:24 mripard: and the debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035878
13:26 mripard: lumag: but tl; dr: if you move the cursor along the edges of the display, you get a corrupted frame that looks pretty much random
14:44 phryk: Heya, I'm (slowly) getting into low level graphics programming on *nix and am considering adding inline docs to some things so people doing the same in the future hopefully have to struggle less than me. Is there an inline documentation tool already used for freedesktop projects (ideally already used in the CI pipeline)?
14:48 pq: phryk, every project is unique. Mesa seems to have a docs folder: https://docs.mesa3d.org/sourcetree.html
14:50 pq: I'm not sure if GBM has any doc build.
14:50 phryk: pq: for docs to be available through LSP they will have to be written inline tho, or am i misunderstanding something?
14:51 pq: No, there are just several kinds of docs. Some projects integrate inline docs with other docs.
14:52 pq: Targeting LSP is a good detail.
14:52 pq: ..to mention.
14:53 pq: and which exact API you want to document
14:53 phryk: right, from other languages i'm used to, inline docs for stuff you can access from LSP and docs directory for "full" documentation including things like architectural overviews.
14:53 pinchartl: in my experience, when you start with no documentation at all, high-level documentation that explains the architecture and overall operation is more important than detailed API documentation. the latter is what LSP usually needs, and that can come in a second step if your time is limited
14:53 phryk: well, first off GBM becaus that's the thing i have to figure out currently. after that probably libdrm because the lack of good up-to-date docs there was a major source of frustration for me.^^
14:54 phryk: pinchartl: yeah, but i'm only slowly getting to know it. i simply do not have the knowledge to write the higher-level overviews – but i can work things out function by function.
14:56 FLHerne: Mesa uses hawkmoth for inline docs now unless I missed a further change, per https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24507
14:56 pq: phryk, for libdrm KMS API, you would mainly look at kernel docs: https://docs.kernel.org/gpu/drm-kms.html
14:56 FLHerne: no, I'm being daft, ignore me
14:57 pinchartl: phryk: you'll need to understand the overall architecture to use it properly, so you'll get there :-)
14:57 phryk: pinchartl: yeah, *after* i worked myself through the actual functions. if this was a project i'd written from scratch, i'd definitely start with the high-level overview because specific APIs are more likely to change. :)
14:58 pq: ...mainly look at kernel docs to understand how stuff works, in order to write the API docs
15:28 phryk: the mesa repo seems to contain references to doxygen and hawkmoth (and sphinx). docs/codingstyle.rst only references doxygen, but it's rst, which implies sphinx which seems to imply hawkmoth… so would i write inline docs as rst or doxygen notation?
15:38 zmike: can I get an ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36413 to finally end the nightmare
15:39 zmike: and mattst88 I guess maybe this is you? https://gitlab.freedesktop.org/mesa/waffle/-/issues/120
15:45 zmike: jenatali: any plans to address deprecation warnings?
15:53 jenatali: zmike: eventually, sure
15:54 jenatali: Is there an urgent need for it?
15:54 zmike: well I'm hoping I can delete the pipe surface interfaces in finite time
15:54 zmike: and everyone who drags their feet on this makes that impossible
15:55 zmike: as it is we have a number of effectively unmaintained drivers that I guess I'll have to refactor since somehow we are not able to eject them from the tree
15:55 jenatali: zmike: make it a local function and call it directly within the driver? I.e. really copy and paste the macro code instead of having the preprocessor do it?
15:56 jenatali: That's what I'd do in the short term anyway
15:56 zmike: I'm talking about util_framebuffer_init
15:56 zmike: which is not a macro
15:57 jenatali: Oh right, I was thinking it was. My point still stands though, give the lagging drivers a copy of that with a specialized function call
15:57 zmike: that's not really how things work though
15:57 zmike: the point is to remove pipe_surface as an object
15:57 zmike: so there is no way to give drivers a copy since they would then have to continue using that interface
15:58 jenatali: Yeah ok I see what you're getting at
15:58 jenatali: I'll try to get to it this week
15:58 zmike: you could go the nouveau route and: copy the function into your driver, make the driver surface functions public, and then call them directly
15:58 zmike: but that kinda misses the point if you are not a dead driver
15:58 zmike: thx
15:59 jenatali: I mean that's more or less how our driver would have to work though I think?
16:00 jenatali: I dunno, need to take a closer look
16:00 zmike: I was able to extend an existing cache I had for image view objects for this case, but that might be non-trivial if you don't already have something like that in place
16:02 jenatali: Yeah I don't
16:02 zmike: yeah okay so maybe you need to go the nouveau route for now
16:02 jenatali: Each surface allocated a unique descriptor
16:09 jenatali: Maybe I'll see if I can unify with nouveau and do a u_surface instead of pipe_surface
16:32 mattst88: zmike: emil velikov has been the closest thing to a maintainer we have for waffle
16:34 mattst88: zmike: https://gitlab.freedesktop.org/mesa/waffle/-/commit/a16983fea590491727c8119256c7b938fe1f9d10 and https://bugs.gentoo.org/901365 might be of use to you though
16:35 zmike: mattst88: yes, I know what has caused it
16:35 zmike: and the solution for now seems to be 1) install waffle using cmake 2) reinstall using meson
16:35 zmike: which is stupid
16:42 mattst88: looks like apitrace started using pkgconfig for waffle in Apr '25 with 40ce75de6b7d2935e4f94941d821bfb7ddf4c308
16:43 mattst88: which is in v13.0
16:43 mattst88: is this not good enough for some reason?
16:43 zmike: hm
16:43 zmike: maybe I've just been doing it since before then and didn't realize it was resolved there?
17:31 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36296
17:31 zmike: not sure how I could split this differently to be more reviewable
18:23 dcbaker: dwfreed: ^
18:25 Sachiel: matrix spam? I'm seeing nothing
18:30 dcbaker: yeah, matrix spammer that are apparently unregistered, but I see them across a bunch of different channels
18:31 HdkR: +M is nice.
19:06 majosa: Hi, chat. I would like ask if anyone knows about problems with fragment interpolation being lower precission on AMD drivers (RADV for example) compared other implementation like Nvidia or Llvmpipe ones. Thanks for your attention
20:22 anholt: daniels: I'm working on getting a common closed shader-db set up, with permissions matching gfx-ci/tracie/traces-db-private, and I was thinking of making a group for gfx-ci/private-access to make the membership common between the two. But I suspect I need to be an owner of gfx-ci in order to make a subgroup.
20:23 anholt: (I was going to put the group under mesa/, but that means that all mesa members get access. Which I think would be good for the project, but it's not what we decided when we did traces-db-private)
20:25 gfxstrand: Is there a good/easy way in kernel space to go from a client pointer to the BO and offset that it maps to?
20:32 airlied: somewhere in the vma manager probably
20:32 airlied: drm_vma_offset_lookup_locked
20:34 gfxstrand: But that's in offset space, not the client's address space
20:37 airlied: you should be able to work it back from address space
20:38 airlied: DRM_FILE_PAGE_OFFSET_START?
20:38 airlied:is pre caffiene, so I might be missing a step here
20:40 airlied: oh yeah that is just the fd, you'd have to probably lookup the vma offset in mm
20:40 gfxstrand: Yeah
20:40 gfxstrand: I don't think I want to descend into that madness
20:44 airlied: gfxstrand: I think find_vma would do it
20:45 airlied: then just check it's a gem va, and grab the private data
20:58 gfxstrand: I think I'm just going to give up on my crazy arm cache flushing plan. :cry:
21:03 HdkR: What's wrong with arm cache flushing?
21:04 HdkR: Aside from the mess of 32-bit, but that can be ignored :P
21:07 sima: yeah find_vma + upcast should do this trick, and the upcast should be generic if you look at the vma_ops->open/close hooks
21:08 gfxstrand: HdkR: Sadly, 32-bit can't be ignored. :'(
21:09 HdkR: Wha
21:09 zmike: can't it tho
21:09 gfxstrand: "What's wrong with XYZ? Except the part that makes it hard"
21:09 gfxstrand: That's some real math professor "the details are left to the reader" energy right there. :P
21:10 sima: I thought even on 32bit arm cpu it's fairly reasonable on v7
21:10 gfxstrand: No
21:10 sima: at least we vendored a bunch in drm_cache.c
21:10 gfxstrand: It's reasonable on ARMv8 but only for 64-bit userspace
21:10 HdkR: cache clear instructions aren't available in userspace in 32-bit arm.
21:10 sima: oh yeah that part is funny
21:10 HdkR: So you need to do cache clears in kernelspace, which is spicy.
21:11 sima: why spicy? I mean aside from the entire part that it's a syscall
21:11 gfxstrand: sima: You say "we vendeored a bunch in drm_cache.c" but then that's only for x86 and a bit of ppc
21:12 sima: hm right, that patch never landed
21:12 HdkR: buffer_storage coherency ensuring visibility on 32-bit is definitely where you don't want a syscall :D
21:12 sima: it did float around
21:13 sima: might only be vendored in msm perhaps, robclark should know
21:13 gfxstrand: I've got patches for panthor: https://gitlab.freedesktop.org/gfxstrand/linux/-/commits/panthor/cached-maps
21:13 gfxstrand: Writing the panfrost patch shouldn't be hard. And I'll do roughly the same thing in nouveau.
21:13 gfxstrand: It's just a giant PITA
21:14 sima: yeah robclark defo had patches for drm_cache.c once
21:15 gfxstrand: And it's very unclear what (if any) safety requirements there should be. Presumably Arm made cache ops privileged for a reason so I shouldn't just add a Linux cache flush syscall. (Not that I'd want to spend a year of my life arguing with core MM about it.)
21:15 sima: oh userspace cache flushing just makes all the nasty attacks easier, from rowhammer to all the spectre stuff
21:15 HdkR: But also arm64 can do it from userspace, so..huh?
21:15 gfxstrand: I mean, it makes sense that Arm doesn't give you a proper invalidate from userspace
21:16 sima: I don't think there's anything more, we've exposed fine-grained flushing for bo since forever
21:16 gfxstrand: On AArch64, it does a flush+invalidate when run from EL0
21:17 gfxstrand: Which is fine
21:17 sima: well, that's the same fun for gpu invalidates we have with xe
21:17 HdkR: ah, the pure invalidate without flush? yea...
21:17 gfxstrand: Pure invalidate without flush is definitely unsafe
21:17 gfxstrand: x86 clflush is always flush+invalidate
21:17 sima: either the pte caching bits enforce the flush (or snoop) or you need to flush it all before you hand the memory to userspace
21:17 gfxstrand: But Arm has separate invalidate and flush
21:18 HdkR: Windows even blocks some of these on arm64 in addition to what Linux allows.
21:18 sima: after that the pure invalidate is just a very funny write
21:19 sima: so yeah if you want to expose the raw invalidate you need to flush your bo on alloc (or at least once before the first pure invalidate)
21:27 pinchartl: zamundaaa[m]: I was thinking of rejecting commits with global alpha + alpha channel. I'm worried it would break compositors though :/
21:27 pinchartl: (sorry, didn't see your reply as the matrix bridge quoted a matrix user name)
21:44 gfxstrand: I don't want to expose pure invalidate. But I'm also not sure if I accidentally did. I'm fine with flush and flush+inval (which is what I get from userspace on AArch64)
21:56 HdkR: All the operations that matter are what. Fence (all, store, load), flush, flush+invalidate?
21:57 HdkR: and flush+invalidate with optional instruction barrier?
21:57 HdkR: If I'm remembering x86 and ARM mappings.
21:59 HdkR: and then for device to CPU coherency for non-coherent systems, you'd want in the kernel space an invalidate after job completion?
22:01 HdkR: Coherency domains suck :D
22:18 zamundaaa[m]: pinchartl: any compositor that does more than the bare minimum with KMS needs to be able to handle that
22:20 zamundaaa[m]: And fall back to the primary-plane-only configuration