<fdobridge>
<gfxstrand> Okay, so it's really "Allow loading Zink, even if X11 does not support explicit DRM format modifiers"
<fdobridge>
<zmike.> yeah
<fdobridge>
<zmike.> though there isn't a comma there
<fdobridge>
<gfxstrand> Okay. Comment updated. Hunk fixed. Now to fix CI.
<fdobridge>
<gfxstrand> MR updated. Feel free to go look at the first two commits
<fdobridge>
<zmike.> I feel extremely free atm
<fdobridge>
<zmike.> thanks for noticing
<fdobridge>
<zmike.> @gfxstrand can you just split that out into a separate commit to make it obvious
<fdobridge>
<gfxstrand> Oh, I did split the doc update into a separate commit
<fdobridge>
<zmike.> I'm not seeing that on the MR
<fdobridge>
<gfxstrand> And I think restored behavior in the main "drop DRI2" commit
<fdobridge>
<zmike.> okay, so maybe tell me once you actually push to the MR
<fdobridge>
<zmike.> since you haven't done that yet
<fdobridge>
<gfxstrand> The MR isn't updating
<fdobridge>
<gfxstrand> Also, didn't fix hard enough
<fdobridge>
<zmike.> that much was already apparent :lul:
<fdobridge>
<gfxstrand> Okay, fixed harder. Also, gitlab seems to be updating with my changes now.
<fdobridge>
<gfxstrand> Also, now that I understand what that environment variable is supposed to do, I think I can do a better job of not breaking it. 🙂
<fdobridge>
<gfxstrand> Also, now that I understand what that environment variable is supposed to do, I think I can do a better job of not breaking it with my changes. 🙂 (edited)
<fdobridge>
<gfxstrand> Okay, `LIBGL_KOPPER_DRI2` seems to be conflating two things:
<fdobridge>
<gfxstrand> 1. Load Zink even if we don't have multibuffer
<fdobridge>
<gfxstrand> 2. Skip asking dri3 for the render node
<fdobridge>
<gfxstrand> I'm not sure why we need 2
<fdobridge>
<gfxstrand> Okay, that's fine. I just need to figure out how to plumb this through in a more obvious way that isn't smashing "software" for things that aren't software rendering
<fdobridge>
<gfxstrand> I think I need to spin myself up some RDP
<fdobridge>
<gfxstrand> Or I guess I could test on my box that has an AMD GPU
<fdobridge>
<zmike.> the thing I've been meaning to fix for a while is that the ForceSoftware stuff is no longer really valid
<fdobridge>
<zmike.> because lavapipe supports dri3
<fdobridge>
<gfxstrand> Yeah
<fdobridge>
<zmike.> so that's yet another wrinkle
<fdobridge>
<gfxstrand> I'm not trying to sort that one out today
<fdobridge>
<zmike.> yep
<fdobridge>
<gfxstrand> So I should be able to test this mess with RADV on amdgpu?
<fdobridge>
<gfxstrand> Let me give that a go.
<fdobridge>
<gfxstrand> Ugh... The DRI3 v3d doesn't like the DRI3 delete
<fdobridge>
<gfxstrand> Is vc4 still requiring DRI2?!? That can't be, can it?
<fdobridge>
<gfxstrand> It's XWayland so it can't be DRI2
<fdobridge>
<gfxstrand> I might have a pi5 here I can play with
<fdobridge>
<gfxstrand> Oh, I wonder if it's still using wl_drm
<fdobridge>
<gfxstrand> I bet it's that it's using Weston 10 from debian stale
<fdobridge>
<zmike.> lul debian stale
<fdobridge>
<gfxstrand> Somehow this "little fix" has degraded from EGL to kopper enabling shenanigans to EGL DRI2 to hacking on CI containers. What happened to me?!?
<Sachiel>
what do you mean? Sounds like the exact same you as usual
<fdobridge>
<gfxstrand> I thought I'd left EGL behind 10 years ago.
<fdobridge>
<fooishbar> it uses weston 10.0.1, but weston 10.0.1 does implement zwp_linux_dmabuf_v1 v4
<fdobridge>
<gfxstrand> I believe you. But something is falling over without wl_drm in CI and I can't reproduce it locally so I'm trimming the delta.
<fdobridge>
<fooishbar> what I'd be looking at is whether v4 is getting advertised by weston or if it's only v3. if it's only v3, then that means weston hasn't been able to discover the drm render node for its device, and that's likely because the egl query for the render node failed.
<fdobridge>
<gfxstrand> I'm getting dmabuf v4 locally, even with Weston 10.0
<fdobridge>
<gfxstrand> Not sure what I'm getting in CI
<fdobridge>
<gfxstrand> I'm adding some more logging (hopefully)
<fdobridge>
<gfxstrand> I bet we need `LIBGL_KOPPER_DRI2=true` for nvidia prop, too, don't we?
<fdobridge>
<zmike.> that's another case, yes
DodoGTA has quit [Read error: Connection reset by peer]
<fdobridge>
<Owo> just reading on the discussion: what's going on here?
<fdobridge>
<Owo> why does zink/kopper care about dri2, or multibuffer, or whatever, if it's all on Vulkan?
<fdobridge>
<Owo> especially if nvidia prop has the Vulkan version & extensions needed
<fdobridge>
<gfxstrand> DRI2 is a bad name
<fdobridge>
<gfxstrand> It has nothing to do with DRI2
<fdobridge>
<gfxstrand> It means "Skip all the checks and use Zink anyway"
<fdobridge>
<Owo> I see
<fdobridge>
<Owo> so it might get into broken territory?
<fdobridge>
<Owo> but still, what checks does it run? What would cause issues?
<fdobridge>
<Owo> why is it needed on nvidia-prop?
<fdobridge>
<gfxstrand> NVIDIA doesn't do DRI3 at all
<fdobridge>
<karolherbst> ~~not yet~~
<fdobridge>
<gfxstrand> Okay, I think I've detangled this mess.
<fdobridge>
<gfxstrand> Still need to sort out the GLX issues Daniel's patches, though.
<fdobridge>
<gfxstrand> Maybe it's XWayland?
<fdobridge>
<gfxstrand> Or it could be something GLX-specific. EGL seems okay
<fdobridge>
<Owo> how does that affect zink?
<fdobridge>
<gfxstrand> We do a bunch of checks when LIBGL_KOPPER_DRI2=false to make sure we don't load zink like it's a real driver or as a fallback if it would cause the X server or something else to blow up. This basically means DRI3+modifiers. NVIDIA fails those checks, as does AMDGPU and the RDP case.
<fdobridge>
<mhenning> does that mean that nvk+zink is broken with rdp by default
<fdobridge>
<mhenning> or is rdp sw-only or something?
<fdobridge>
<gfxstrand> RDP is SW, I think. I'm not actually sure.
<fdobridge>
<gfxstrand> But Zink+NVK is kinda broken. I'll hopefully get the branch pushed tomorrow.
<fdobridge>
<gfxstrand> But Zink+NVK is kinda broken all over. I'll hopefully get the branch pushed tomorrow. (edited)
<fdobridge>
<zmike.> xrdp is its own thing
<fdobridge>
<zmike.> do not use rdp to conflate that case
<fdobridge>
<gfxstrand> I really wish I knew what was going on in CI. I may have to run one of the containers on my laptop somehow.
<fdobridge>
<gfxstrand> (Doing two things at the same time today)