01:26 tarceri: zink radv ci looks down
07:25 mripard: sima, jani: so, should I do the drm-misc-next PR?
08:30 mareko: we could do mediump = float16/int16 at AST level and call it a day
08:30 jani: mripard: I'm planning on doing drm-intel-next pull req today
08:32 javierm: sima, tzimmermann: any thoughts about https://lists.freedesktop.org/archives/dri-devel/2023-November/431355.html ?
08:33 mripard: jani: and so the plan is still to send both drm-misc-next and drm-intel-next to drm-next, and backport drm-next once both have been merged?
08:34 tzimmermann: javierm, i have only briefly followed the discussion. IMHO the DT is the authoritative source
08:34 tzimmermann: what ard says about tracking framebuffer memory is exactly what we do in our aperture code
08:35 tzimmermann: as you mentioned
08:37 javierm: tzimmermann: agreed on both items. I agree that the patch is a workaround but IMO is the least bad option because a) is a stopgap to fix the issue and b) it's simple enough that can be cherry-picked for stable
08:37 jani: mripard: if I understood sima correctly, yes
08:39 javierm: tzimmermann: the question I had if you can think of another way to handle this due ard saying that isn't a great approach
08:39 javierm: tzimmermann: another option that I thought could be to make sysfb DT aware and check if there's a simple-frambuffer node present, but that sounds even a worse approach to me...
08:44 kode54: wow
08:44 kode54: was it redhat that asked for vp9 and av1 to be added to the patent encumbered codecs list?
08:46 javierm: emersion: it's OK to land https://lists.freedesktop.org/archives/dri-devel/2023-October/427587.html? Jonas reviewed the mutter MR https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3337
08:46 kode54: oh, it was Microsoft who implemented that
08:46 kode54: why is Microsoft putting codec switches into Mesa?
08:54 javierm: tzimmermann: thanks for answering in that thread
08:59 tzimmermann: np
09:02 kode54: I see, there's a hot discussion on the subject in !26320
09:03 kode54: * mesa!26320
10:27 sima: javierm, I feel like the entire sysfb complexity has reached levels that are firmly above my head :-/
10:28 sima: but yeah using the aperture helpers to make sure we only have one sysfb instance feels a bit icky
10:28 sima: what you might want to do (but that could blow up in entirely different ways) is the resource reservation framework, with a mandatory resource
10:28 javierm: sima: yeah... same. The sysfb design has reached its limits
10:28 sima: but that might prevent the real drivers from loading properly
10:28 sima: so probably not the right thing either
10:29 sima: at least we tried using that somewhat in i915 for making sure we only use the stolen memory range when the bios hasn't butchered the setup somehow
10:29 javierm: sima: long term I think that the aperture infra should be part of the device model and hooked into the request_mem_region() helpers
10:29 sima: and it was endless pains
10:29 sima: javierm, well request_mem_region kinda is aperture helpers
10:29 javierm: e.g: request_mem_region_exclusive() or someting
10:29 sima: except see above, request_mem is also utter levels of pain
10:29 sima: yeah that's what I was thinking of
10:29 sima: we tried that for i915 stolen
10:29 javierm: sima: yeah but doesn't have the "remove conflicting devices" part
10:30 javierm: it just -EBUSY
10:30 sima: for entertainment dig into git history :-)
10:30 sima: javierm, well that too, so that part would need to be added
10:30 javierm: sima: ah, I see
10:31 sima: javierm, so yeah, my "I'm absolutely in way over my head" gut feeling is that a) yes this hack is very, very icky but also b) everything else is so much worse
10:31 javierm: sima: right. Do you agree then with tzimmermann and my opinion on this, to merge this workaround and then figure out how to better handle this long term?
10:31 sima: I think we're very firmly in "least terrible" design space here :-(
10:31 javierm: sima: yeah... agree
10:32 sima: javierm, yeah feel free to add an a-b: me onto that, and maybe try to capture some of that "yes this is terrible" understand as much as we can still grasp it ...
10:35 javierm: sima: sure
10:36 javierm: sima: while I've your attention :) Are you OK with merging https://patchwork.kernel.org/project/dri-devel/list/?series=802258 ?
10:37 javierm: sima: that's the buffer damage series we discussed before but using a slightly different approach suggested by tzimmermann
10:37 javierm: basically to set the plane->ignore_damage_clips = true in the .atomic_check for drivers that need it
10:38 javierm: I've ack from Thomas and Zack @ VMWare, but didn't want to push before asking you. Since you suggested the previous approach
10:41 sima: javierm, patch 4 doesn't really explain when you have the buffer damage case
10:41 sima: or is a bit unclear
10:42 sima: so maybe add a sentence that we need to ignore damage and fall back to full damage when the buffer, i.e. &drm_plane_state.fb has changed, and that as long as when that buffer stays the same, buffer damage tracking drivers can still benefit from the damaged regions
10:42 sima: currently it reads a bit as if you need to unconditionally set this flag
10:43 sima: you kinda have that in the last paragraph, but I'd just add the very specific "this is the state structs members you need to look at" explainer in the previous paragraph
10:44 sima: oh for the todo entry maybe reference the &drm_plane_state.ignore_damage_clips entry
10:44 sima: and maybe also add a link to the overall docs from the kerneldoc for that in patch 1
10:44 sima: with these doc bikesheds: a-b: me, looks like a clean approach from a code pov
10:44 sima: and defo less work :-)
10:45 sima: easier to backport too since smaller, and all that good stuff
10:45 javierm: sima: sure. I'll make those fixups and post a v4 likely tomorrow. Thanks for your feedback!
17:14 enunes: emersion: so even with the accelerated pixman backend for wlroots I can't use a vulkan only driver because it still relies on gbm to import buffers from clients, even if I hack it a bit to use the dumb buffer allocator to avoid gbm for compositor allocation
17:14 enunes: I don't suppose there will be any other quick hack to avoid that one?
17:15 emersion: enunes: hm it shouldn't do that?
17:15 emersion: which wlr version is this?
17:16 emersion: actually it never used GBM to import client buffers AFAIK
17:16 emersion: it uses GBM to allocate GPU buffers, but if you're running with Pixman it shouldn't pick GBM?
17:17 enunes: it does going through the types/wlr_linux_dmabuf_v1.c path, this is the patched version 0.16.0 originally for the raspberry pi case
17:17 emersion: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/504b9491f05d3227d45ea6bcc9c347e1a6bf9586/types/wlr_linux_dmabuf_v1.c#L203
17:18 emersion: and before that it was using wlr_renderer to do this
17:18 emersion: (aka GL)
17:19 emersion: so yeah they probably patched that in the rpi version?
17:19 enunes: I see, so I guess it is patched code indeed
17:20 emersion: to make ti work with upstream wlr you need to (1) implement begin_data_ptr_access() in linux-dmabuf wlr_buffers
17:21 emersion: and (2) force wlroots' hand to create linux-dmabuf even with the Pixman renderer
17:21 emersion: i think that should be enough
17:21 emersion: (brb)
17:21 enunes: this is exactly what is implemented with gbm here, I guess I can try to implement it with just libdrm
17:22 emersion: yeah
17:22 emersion: plain libdrm, mmap, DMA-BUF sync IOCTLs
17:22 emersion: make sure to only avdertise LINEAR and nothing else
17:22 emersion: advertise*
17:22 enunes: cool, thanks for the help!
17:23 emersion: please ping me again as needed :)
17:31 sima: jani, I guess drm-intel-next pr tomorrow?
19:09 jani: sima: https://lore.kernel.org/all/87v89sl2ao.fsf@intel.com/
19:09 sima: aye
19:10 jani: sima: writing the changelog always takes me longer than I think... and I wonder if anyone ever reads them :/
19:10 jani: further than the highlights
19:14 sima: I do read them when doing the pull ...
19:22 sima: imre, 191dc43935d1ece82bc6c96 thx for making that fail on compile when I get it wrong :-P
19:32 imre: yep, that conflicts in dm_helpers_construct_old_payload(), I resolved that based on the email I sent. but in general it should've been merged via drm-misc-next
19:39 sima: yeah I intentionally got it wrong just to see how gcc gets unhappy :-)