01:40mareko: so I guess nobody wants to review the glthread MR
01:41Plagman_: maybe tarceri_ can help?
01:41Plagman_: seems valuable
01:42tarceri_: mareko, Plagman_: will take a look
01:43tarceri_: I did skim over it when it was first submitted but forgot to go back for a proper review
08:24mripard: danvet: done
08:30danvet: mripard, thx
09:15hakzsam: MrCooper: no objections if I merge my CI fossilize work then?
09:15hakzsam: (would need someone to Rb though)
09:17hakzsam: especially because it enables building the VK test image by default
10:06leitao: How do I know if a CRTC has multi planes? When trying to get a framebuffer from a crtc, how do I know if I should use drmModeGetFB2 or drmModeGetFB in runtime?
10:20emersion: do you mean, you want to know whether a CRTC has a multi-planaer FB attached to its primary plane?
10:20emersion: you should always use drmModeGetFB2, and fallback to drmModeGetFB if unsupported by the kernel
10:21emersion: leitao: ^
11:19daniels: ^ correct
11:19daniels: even though he's left
12:43hakzsam: MrCooper: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1814337 hmm
13:35arora: Hey airlied jekstrand, I am interested in "vulkan gpu preference tool" project on GSoC, how should I go about contributing to it?
14:08leitao: emersion: thanks for the answer. it seems both drmModeGetFB and drmModeGetFB2 are returning -EINVAL.
14:09leitao: I thought that drmModeGetFB was returning -EINVAL because it CRTC had multi planar, but maybe not.
14:09emersion: leitao: at's your use-case?
14:10emersion: can you make sure you're providing a FB ID to drmModeGetFB, not a CRTC ID?
14:10leitao: emersion: I would like to find the FB of my device. I get the connector, encoder, crtc and when I get drmModeGetEncoder(fd, crtc->buffer_id) I receive a -EINVAL
14:11emersion: what's the value of crtc->buffer_id?
14:11emersion: oh wait
14:11emersion: drmModeGetEncoder doesn't take a buffer ID
14:11imirkin_:assumed that was a typo
14:12emersion:thinks so, but prefers to make sure :)
14:13leitao: hmmm, maybe that is the mistake. Let me doouble check
14:16emersion: you can use https://github.com/ascent12/drm_info to dump the whole DRM state
14:16emersion: from there you can check CRTC IDs and so on
14:17emersion: (btw, drm_info uses drmModeGetFB)
14:20leitao: Let me check
14:40leitao: emersion: this is what I have: https://pastebin.com/63z8nbcb
14:42emersion: leitao: you can see that the FB for "Plane 0" (primary) is returning EINVAL
14:42emersion: probably because it's multi-planar
14:43emersion: (see https://github.com/ascent12/drm_info/pull/50 for drmModeGetFB2 support in drm_info)
14:43gitbot: ascent12 issue (Pull request) 50 in drm_info "Add support for drmModeAddFB2" [Open]
14:43emersion: however it works for the cursor plane ("Plane 2")
14:53mauz555: hi - please some indicate me if the following "dri" package is related to Direct Rendering Infrastructure ? what deb pkg ? https://chromium.googlesource.com/chromium/src/+/master/build/config/linux/dri/BUILD.gn
15:01jcristau: mauz555: https://packages.debian.org/search?arch=amd64&mode=exactfilename&searchon=contents&keywords=dri.pc
15:05mauz555: jcristau: ty
15:26leitao: emersion: how do I make sure it is multi-planar?
15:26leitao: I've applied PR 50 and didn't see any diference, in fact.
15:27emersion: no FB info in "Plane 0"?
15:28leitao: emersion: https://pastebin.com/aHfEv6NT
15:29leitao: it seems to be the same output
15:29emersion: are you sure your kernel supports GETFB2?
15:30leitao: seems so, kernel version 5.2.10
15:30leitao: for plane 8, I see DRM_FORMAT_MOD_LINEAR
15:31leitao: is DRM_FORMAT_MOD_LINEAR the same as single planar?
15:32emersion: 5.2.10 doesn't support GETFB2 i think
15:32emersion: DRM_FORMAT_MOD_LINEAR is in the IN_FORMATS list, it's not the buffer format
15:33emersion: it's just a format compatible with plane 8
15:33emersion: well, a modifier
20:04ajax: so mesa-demos/**/manywin is trying to set up context sharing between two different display connections
20:05ajax: meaning as far as xserver is aware they're different clients
20:06ajax: why on earth did glx ever decide to allow that
20:06ajax: the code has literally never checked that the share context is on the same display as the one you're currently referencing
20:06imirkin_: rm -rf and no one will be the wiser?
20:06ajax: oh but i can't
20:07ajax: because it's only broken on intel and someone filed a bug
20:07imirkin_: presumably i965 only?
20:07ajax: nope! iris too!
20:07imirkin_: given that it's all shared logic
20:07ajax: but works on llvmpipe and radeonsi and i imagine on nvidia
20:08imirkin_: if you like, i can test on nouveau. but that'd just be salt on the wound :)
20:09ajax: so i think the bug ends up being that the fd you get back from DRI3Open is scoped to the client, meaning the display connection, so any time you store a gem handle in a shared object you're storing whatever that value was in that connection's namespace
20:09imirkin_: nouveau and radeonsi have various fun buffer sharing logic to make buffers unique per screen
20:09imirkin_: er, unique globally, not per screen, which is the natural thing
20:09imirkin_: perhaps iris doesn't?
20:10ajax: maybe if you have a share context you should pull your context's display setup results from it, rather than opening a new one.
20:10ajax: though i'm getting some heebies and/or jeebies about that and xlib thread safety
20:11imirkin_: oh right. we ensure that there's a single screen per process
20:12imirkin_: whereas iris does no such thing
20:12imirkin_: (or if it does, it's a lot less obvious)
20:12imirkin_: i dunno if your situation is that there are multiple iris_screen*'s, but if it is, this would help
20:12imirkin_: (it sounds like it might be, which is why i mention it)
20:18ajax: hm, might be indeed
20:21imirkin_: traditionally this was a problem for vdpau + gl
20:21imirkin_: but i could imagine multiple glx things also doing the trick
20:26airlied: multisample depth buffers are very under explained
20:27imirkin_: esp resolving them
20:28airlied: well that bit I care less about
20:28airlied: but how interactions work like early depth testing etc
20:28imirkin_: what's the issue?
20:29airlied: oh it could be I'm missing some plumbing here somewhere
20:29imirkin_: i think they're just removed from gl_SampleMaskIn
20:29imirkin_: (and if that's == 0, you skip the frag)
20:29airlied: but for early depth testing do you have to pick a sample
20:29airlied: can you even do early depth tests
20:29imirkin_: with sample shading or msaa?
20:30airlied: msaa no sample shading
20:30imirkin_: sample shading = one invoc per fragment. you can forget it was msaa in the first place (sorta)
20:30imirkin_: msaa = compute a gl_SampleMaskIn and gl_SampleMask. use the latter to write the output.
20:31airlied: yes but if the depth buffer is multisample, you have to deal with the outside fragment shader stuff like depth testing
20:31imirkin_: (there's a happy in-between where you do e.g. 2x shading on a 4xmsaa thing. that way lies sadness)
20:31imirkin_: depth testing affects the gl_SampleMaskIn if it's early (iirc)
20:32imirkin_: and is applied on top of gl_SampleMask if it's late
20:32airlied:wonders did I get this right when I did the softpipe hacks
20:32imirkin_: there's a control actually which controls this
20:32imirkin_: for whether it's before or after gl_SampleMaskIn. hold on
20:33imirkin_: so i guess without that, gl_SampleMaskIn is actually pre-depth no matter what
20:33imirkin_: but if post-depth it's == 0, you just skip that frag invocation
20:35airlied: so do I early depth test each sample of depth buffer per coverage?
20:37imirkin_: (i'm like 90% sure)
20:37airlied: yeah seems like the right thing, just need to rip up a chunk of llvmpipe to do it, guess that's for today
20:37airlied: that + alpha to coverage should get me most of the way there
20:37imirkin_: fwiw i think swr has a correct impl of all this stuff
20:37imirkin_: and their code is fairly readable
20:38imirkin_: esp if you sorta know how it should work in the first place
20:43airlied: imirkin_: I'm not entierly sure but their backend seems to always exceute in sample_shading mode
20:44imirkin_: iirc they have multipel backends
20:44airlied: well the mulitsample one
20:44imirkin_: but you could be right
20:44airlied: it seems to exceute fragment shaders for every sample
20:44djgl: Hi, is this the right place to ask questions about the Linux kernel internal drm API?
20:44imirkin_: BackendSampleRate -- that probably does
20:44imirkin_: aka "sample rate"
20:45imirkin_: airlied: look for SWR_BACKEND_MSAA_PIXEL_RATE
20:45karolherbst: djgl: yeah, or the dri-devel mailing list
20:45djgl: karolherbst: ok, thanks
20:45karolherbst: djgl: although most of the dicussion here are mostly around mesa
20:45imirkin_: airlied: yeah, looks like they just don't have that one :)
20:46imirkin_: oooo well
20:46airlied: imirkin_: yeah MSAA_PIXEL_RATE just isn't handled
20:46airlied: though I suppose everything outside the pixel shader executions are the same
20:46imirkin_: i *suspect* it's just not upstreamed
20:47imirkin_: but dunno
20:47imirkin_: could be that no one's crazy enough to want that for swr's targets
20:47airlied: yeah you might be right there
20:47imirkin_: since msaa is basically the worst of all worlds
20:47airlied: you'd think lower cpu execution would be a win :-P
20:48airlied: though really doing MSAA on cpu is going to loserville anyways
20:48imirkin_: i think their target applications have a lot more polygons than pixels
20:49airlied:doesn't think he'll go > 4 samples on llvmpipe :-P
20:50imirkin_: should do like 64, show up all the other drivers and cause gl_SampleMask* to actually have to be arrays
20:50mattst88: I think the horses in Civ6 are like 22 pixels and thousands of polygons
20:51imirkin_: mattst88: so clearly Civ6 is a target for swr :)
20:52imirkin_: i guess they didn't hear about gl_TessLevel*?
20:52djgl: The documentation for the prepare handler in struct drm_panel_funcs says that it is typically called before video data is transmitted. Does this imply anything about the state of the MIPI DSI signals when prepare is called (for a MIPI DSI panel)? If not, I'll have to prepare my panel in the bootloader.
20:58Lyude: ok, mst regressions fixed :)
20:58Lyude: turns out i didn't look closely enough at the code that got written for checking pbn limitations because it was mostly wrong :s
21:24seanpaul: Lyude: i don't see your patch, has it hit the list/
21:25Lyude: seanpaul: actually I needed to write a few more, need to fix one small race condition with available_pbn and connector hotplugging
21:25Lyude: (basically the connector needs to be shown as disconnected until we have it's PBN queried, otherwise available_pbn will randomly be 0 and cause mayhem)
21:25seanpaul: oh sounds like fun
21:26Lyude: actually it is! now that locking is sensible in MST this has been extremely easy :)
21:27seanpaul: whoa positive sentiment surrounding MST!
21:27seanpaul: i think we've reached a new milestone
21:27seanpaul: nice work :-)
21:28Lyude: hehe, thanks!
21:28seanpaul:goes back to being part of the problem and piling more on top of MST
21:29Lyude: jfyi too, although radeon.ko's ancient mst code existing will get in the way of this, I realized another pretty nice TODO item would be to entirely get rid of the payload table that we maintain with the allocation helpers and instead just base everything off the atomic mst state
21:29Lyude: if anyone wants to clean up more mst junk
21:29Lyude: i realized that in an atomic world there is, basically no point to having a second payload table like that
21:30seanpaul: mm, yeah that would probably simplify things
21:30Lyude:also still needs to start submitting all her patches for finishing up sideband message tracing, and adding some more selftests, todo todo todo todo....
21:30seanpaul: maybe add to todo.rst?
21:31seanpaul:channeling his inner danvet
21:31imirkin_: todo: write todo
21:31Lyude: yeah, I think I'll do that at some point today if I get the time
21:31Lyude: imirkin_: hehe, basically
21:31Lyude: (note that this is always a thing I try to keep up to date, when I remember it exists https://trello.com/b/Ei3QZ0Cx/work-public )
21:34seanpaul: Lyude: thanks for the pointer, just subbed
21:51airlied: lols todo comment spam as a service
21:51airlied: got an email about my TODO comments in some fork of a kernel on github
21:53Lyude: seanpaul: btw, just finished up (and found nouveau bugs in the process, but these seem to be entirely unrelated to the mst issues) and will be sending the patches onto the list in a few minutes. Would you be willing to help review?