10:29 daniels: hmmmm, it seems like marge is no longer reliably detecting when pipelines fail, and is instead just waiting for the timeout in a lot of cases
11:38 zmike: on that topic, is it just me or are the stoney jobs even slower than usual lately
12:13 daniels: zmike: yeah they're far far slower, which I guess is caused by upgrading to CTS 13.5.0 now running way more stuff
12:14 zmike: ah
12:16 daniels: need to push that denominator higher
15:05 pinchartl: stupid question: does KMS support interlaced modes with the two fields stored in separate buffers, or does it assume interlaced buffers unconditionally ?
15:07 daniels: pinchartl: afaik it's assuming full-frame input and alternate-field output
15:08 pinchartl: I would also expect alternate field output, as that's kind of what interlaced means :-) I was wondering about the input side
15:21 daniels: right, input is always full-frame ttbomk
15:21 daniels: I've seen some horrible downstream patches to mark FBs as top/bottom field but never upstream afaik
15:24 pinchartl: daniels: I think I'm looking at those horrible downstream patches right now
15:35 daniels: I'm so sorry
15:40 vsyrjala: we have DRM_MODE_FB_INTERLACED, but what it does was never specified. i have a felling it was all my fault
15:41 vsyrjala: but can't remember 100% anymore
15:42 vsyrjala: o_O sti actually uses it for something
15:45 vsyrjala: ah right, i think the plan i had for it was to go along with some setplane flags to achieve bob deinterlacing
15:45 daniels: vsyrjala: 'which field is this fb?' 'one of them!'
15:47 javierm: vsyrjala: I believe that's how sti uses it? AFAIU they use to indicate that needs to enable some HW deinterlacing during an atomic update
15:47 LuckyKnight: Hi all. Where would I determine which GPU-ID I would need to add to https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/panfrost/lib/pan_props.c#L70 ?
15:47 LuckyKnight: It's a Mali G52 Bifrost-"r28p0-01eac0"
15:48 LuckyKnight: but Mesa 23 is only loading softpipe at present
15:49 vsyrjala: javierm: sort of. but not quite what you'd actually want for eg. video deinterlacing when the frame rate doesn't match the vrefresh
15:49 vsyrjala: also wouldn't work for 3:2 pulldown/etc,
15:50 daniels: LuckyKnight: where are you getting 'r28p0-01eac0' from? it sounds like you're using Arm's mali_kbase.ko in the kernel, which Panfrost doesn't support - the upstream kernel has panfrost.ko instead
15:52 javierm: vsyrjala: I've to admit that is not clear to me what's the line between DRM and v4l2 mem2mem for these cases
15:52 javierm: vsyrjala: i.e: should the deinterlacing be implemented as a v4l2 mem2mem and just let the DRM/KMS driver scanout progressive frames?
15:52 vsyrjala: whichever is more efficient i guess
15:53 javierm: vsyrjala: by sharing dma-buf the performance would be about the same I guess? So is more about a design decision it seems to me
15:56 vsyrjala: i think you should be able to implement kms bob deinterlacing without any special kms knobs. just need to make separate fbs for each field, and present them at the appropriate times. and the driver needs real subpixel y offset support to make it not terrible
15:57 vsyrjala: javierm: mem2mem implies extrra memory traffic, so less efficient. though it could of course implement much better deinterlacing algorithms
15:58 javierm: vsyrjala: right
16:05 mripard: javierm: it shouldn't really be relevant, but it's also a matter of usage. If you don't expect the system to ever use the deinterlaced buffer, then kms makes sense. If you do, then v4l2 mem2mem is better
16:07 javierm: mripard: that's true too
16:40 Lynne: am getting pretty bad GPU crashes on radv when using gl_GlobalInvocationID.z to index imagesamplers which are single-plane reps of multiplane formats
17:04 LuckyKnight: daniels: r28p0-01eac0 is indeed from arm's mali. I tried using mesa libEGL/libGLES instead and dri/* drivers. Doesn't sound like it will work then
17:12 hazl: hello! i came in to report on elden ring/dark souls 3 acting strangely on Linux and I want to share a couple of findings. It's likely not dxvk or vkd3d, because it affects both elden ring (dx12) and dark souls 3 (dx11). running the flag to use gpl for shaders doesn't really change anything about performance in ds3, but locking the gpu to 1600mhz drops the usage from 90+% to 30% or so
17:13 hazl: I noticed a lot of people talking about around 50fps on ds3 on the protondb page for it and that it specifically doesn't happen on Windows on the same specs, which means I've entered the uncomfortable territory of "too complicated for me to suss out"
17:13 daniels: LuckyKnight: yeah, if you run Panfrost Mesa you need upstream kernel as well
17:14 LuckyKnight: Kernel is 5.4.96
17:18 robclark: so.. is there some bug or something subtle I don't understand w/ meson compiler.get_supported_arguments() vs cross compiling? It seems to be claiming the compiler doesn't support some arg which it clearly doesn't
17:18 robclark: err, does
18:47 lumag: airlied, danvet: we have a question regarding merging of the PSR patchset: https://lore.kernel.org/dri-devel/b3d3a70a-6f6b-e7ff-cf0c-cb0093212a3b@linaro.org/
18:48 lumag: First three patches are generic and should probably be merged via the drm or drm-misc repos.
18:48 lumag: How should we proceed with the patchset?
18:48 lumag: narmstrong, suggested sending direct pull request with first three patches.
18:54 airlied: tzimmermann, mripard, mlankhorst: also might have ideas
18:55 airlied: jani: also does this a lot
19:01 danvet: lumag, imo just merge them all through msm tree and make sure a pr with that stuff goes out timely
19:01 danvet: a-b: me for that
19:02 lumag: danvet, ack
19:02 danvet: imo topic trees should only be used when actually necessary
19:02 danvet: splitting a series across trees for the sake of splitting is just busy work
19:06 airlied: but yeah send an msm pull a lot earlier
19:06 airlied: since its normally rc6
19:16 robclark: I think even if everything isn't ready, we could send an early PR with just the PSR stuff
19:50 airlied: just fyi I turned mesa issues to members only for now
19:50 airlied: in case anyone is wondering
19:54 zf: what was the motivation for that? is there a spam problem?
19:55 anholt_: massively, yes.
19:55 ccr: :/
19:56 zf: ah, unfortunate
19:56 zf: are there restrictions on who can become a member?
19:56 zf: (also, I don't suppose there's any way to make it readable by non-members?)
20:10 airlied: "for now"
20:12 zf: fair enough :D
20:12 zf: although my question about membership still stands; I don't know what it implies exactly
20:14 airlied: I think someone just has to add you to the mesa project as a reporter
20:16 zf: works for me. my username is zfigura, if someone here has a moment for that :D
21:59 zf: thanks!
22:02 swick[m]: are patches on dri-devel supposed to be applied on top of drm-next?
22:03 emersion: depends on the patch
22:03 emersion: drm-misc-next is the catch-all if there's no better place
22:04 vsyrjala: for pushing stuff. but if the question was "against what tree was this developed?" then drm-tip should generally be the answer
22:04 javierm: swick[m]: if unsure you can base on drm-tip
22:05 javierm: what vsyrjala said
22:05 kisak: airlied: oh, looks like mesa's gitlab issue tracker is not publically viewable as well.
22:06 swick[m]: thanks, that was all helpful information :)
22:06 airlied: kisak: yeah it'll be back
22:06 emersion: oh, misunderstood the question
22:07 emersion: if you're lucky the submitter uses base tree information, but generally that's not the case
22:07 emersion: (https://git-scm.com/docs/git-format-patch#_base_tree_information)
22:08 airlied:sees if the spammers have moved on