11:21melissawen: Hi, long time without applying a patch, so question: I have a fix to a commit that is in both drm-next and drm-misc-next, should I apply it to drm-misc-next-fixes?
11:25javierm: melissawen: AFAIK you should ask to the drm maintainers to cherry-pick it
11:43melissawen: javierm, so apply to drm-misc-next and ask them to cherry-pick from it, right?
11:47mripard: melissawen: I'm not quite sure I got what you were asking, do you mean that you have a fix that was already applied to drm-misc-next, and you want it into drm-misc-(next-)fixes too, or is there a broken commit in drm-misc-next and you need to apply the fix for it?
11:47mripard: I think javierm understood the former, but you might mean the latter?
11:58javierm: ah, I think you understood correctly mripard on a second read
12:01vsyrjala: mripard: are you going to push the get_state stuff at some point? i'd like to add a warn there to scare people when doing it wrong
12:03mripard: vsyrjala: there's a few acks missing (tegra, armada, kmb, mediatek and msm iirc)
12:03mripard: but yeah, if I haven't heard anything by next week I'm going to merge it
12:20melissawen: mripard, the latter, there is a broken commit in v3d that I can see in both drm-next and drm-misc-next, and now I have a fix for this broken commit
12:21melissawen: I would like to know where should I apply the fix for the broken commit
12:21mripard: then yeah, you need to apply it to drm-misc-next-fixes
12:21melissawen: mripard, got it
12:21melissawen: thanks!
14:45robclark: karolherbst8: does cl_gl_sharing _really_ expect to be able to export resources not allocated with PIPE_BIND_SHARED?!
15:16daniels: such a great extension
15:33jenatali: I'd love input from someone with GL expertise on whose bug this is or possible workarounds: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14006#note_3116197
15:48zmike: seems like it would affect any mesa driver
15:48zmike: so probably mesa issue? I don't know the multi-context semantics of display lists
15:50jenatali: I tried zink but hit asserts + crashes in this app :)
15:50jenatali: Softpipe worked, I don't think I've got llvm hooked up in my build to try llvmpipe but I suspect that'd work too
15:51zmike: 🤔
15:51zmike: what's the assert?
15:52jenatali: framebuffer.zsbuf.texture->bind & PIPE_BIND_DEPTH_STENCIL
15:52jenatali: In st_update_framebuffer_state
15:52jenatali: Probably a kopper bug
15:53zmike: LIBGL_KOPPER_DISABLE=1 ?
15:53jenatali: Trying
15:53jenatali: Same
15:54zmike: wat
15:54jenatali: https://enterprise.flashforge.com/pages/flashprint :P
15:55jenatali: If I ignore the asserts eventually I hit a crash in app code, I didn't try to debug that yet
15:56zmike: I'll give it a shot at some point
16:04jenatali: zmike: Suggestions for who to talk to for next steps? I'd be super hesitant to do something heavy-handed like put a flush in glEndList
16:10zmike: unsure? it's weird that zink asserts on that
16:10zmike: I'd like to see if at least one non-sw driver can do it before getting extreme
16:10jenatali: So you want me to debug zink?
16:10zmike: uhhhh I mean I can do it at some point but I'm a little busy atm
16:11zmike: getting spec verification about multi-context use of display lists like this would also be useful
16:11jenatali: One of our execs sent this bug my way because his son wants to use his 3D printer with his new arm laptop :P
16:11zmike: uh oh
16:11jenatali: So I'm motivated to fix it quickly :)
16:11zmike: right...
16:11zmike: well if the app runs on linux I can try and debug a bit later today
16:13zmike: otherwise maybe see if you can apitrace capture
16:13jenatali: I've got one
16:14zmike: if you can get it to me somehow
16:16jenatali: Gimme a minute I'm tracking down this bind assert
16:16zmike: oh I had meant the apitrace for debugging that
16:16zmike: if you want to do it that's fine
17:18jenatali: zmike: Can I experimentally make zink not use resizable BAR?
17:21zmike: you can just hack it in zink_screen.c
17:21zmike: if you ctrl+f resizable_bar I think
17:24jenatali: Looks like that just affects how failures are handled from the DEVICE_LOCAL_VISIBLE heap type, but zink will still try to use it
17:25jenatali: I tried hacking it out of zink_heap_from_domain_flags but that just started giving me asserts
17:25zmike: oh you mean not use it at all
17:25jenatali: Yeah. My driver doesn't currently use it so I'd like to see if I can force zink down a copy-to-vram path
17:25zmike: you'd have to hack the heap detection in zink_screen.c to overwrite the rebar path with a vram path
17:25zmike: which is the default if rebar isn't found
17:26jenatali: I see, I think I can do that
17:28jenatali: Nope, I'm just getting asserts that buffers are host_visible during map
17:29jenatali: Anyways, once I work around the wgl-specific assert I was hitting, zink renders fine because it uses CPU-visible VRAM for the uploads instead of staging copies
17:29jenatali: I can add a path to optionally do that (and really I should be doing that for UMA...) but I can't rely on that path so this still seems broken and was hoping to fix it once and for all
17:34jenatali: https://www.opengl.org/archives/resources/faq/technical/displaylist.htm
17:34jenatali: > When a display list is modified in one context (deleting is a form of modification), the results of that modification are immediately available in all shared contexts.
17:35jenatali: So... seems a flush should be there
18:09zmike: guess it needs a driconf
18:09jenatali: I could do that, sure
18:09jenatali: I proposed a change to just check against the GL shared state refcount
18:17zmike: hm not sure we do anything like that currently?
18:19jenatali: I saw other RefCount checks, e.g. bind_texture_object