07:45pmoreau: karolherbst: I’ll try to, but days only have 24 hours sadly. :-/
08:25pmoreau: karolherbst: I saw you updated your patch for the SPIR-V extensions to be in `spirv::`; I have now updated mine for SPIR-V versions to also be in `spirv::`, and added a `SPV_MAKE_VERSION()` macro and used it rather than writing `0x00010000` (as `SPV_MAKE_VERSION(1, 0)` is a lot more readable and failure-proof). I think the MR should be ready to merge, once we get an ACK from curro on the updated version.
08:25pmoreau: And thanks for improving the Meson patch!
09:20pmoreau: karolherbst: Computer was busy updating Windows to 2004, so you got a partial review of !6367. :-)
09:23RSpliet: pmoreau: Is that the 20.04 upgrade for Windows 10, or were you updating Windows XP to SP2 released in 2004? :-P
09:23pmoreau: It’s the 20.04 upgrade
09:24RSpliet: Be nice if Windows ever caught up and entered the year 2004 </troll>
09:26pmoreau: And it failed, again… Oh well, I think I won’t bother and just do an installation from scratch when I get my new computer whenever it happens.
09:45karolherbst: fixing wine is less painful than windows :p
09:46bencoh: not certain that's 100% true, but ... somehow, yeah :)
10:01RSpliet: Problem is that often the best way to fix wine is to run Windows and reverse-engineer behaviour. That's like the worst of both worlds...
10:27tagr: karolherbst: I think I might have an idea on how to solve this that doesn't rely on the PIPE_BIND_SCANOUT flag
10:28tagr: karolherbst: the idea would be to rely on ->resource_get_handle() getting called on a resource with type WINSYS_HANDLE_TYPE_KMS
10:29tagr: at that point we know that the buffer will be used for display
10:29tagr: that way we work around the dri3 loader issue that we discussed yesterday
10:30tagr: it also seems that in the case of fullscreen glxgears, glamor (or something else, because I'm not sure that this is glamor at all anymore at that point) will actually call ->flush_resource() for every frame
10:32tagr: so we could do something like this in ->resource_get_handle(): if the requested handle is of type KMS, check whether we've already imported the resource (i.e. done the export/import dance) and export/import if not, we can then do ->resource_get_handle() on the underlying resource from the GPU and check if the modifier is non-linear and if so, we allocate another, forced-linear buffer, so that at
10:33tagr: ->flush_resource() time we can do a de-tiling blit
10:33tagr: for the windowed case this should work fine because we'll simply end up compositing onto the root window
10:34tagr: although the above should also work if for whatever reason X ends up showing a windowed glxgears in a DRM plane, which I don't think currently ever happens (probably because it'd be inefficient to do if you've got decorations, etc.)
10:34tagr: that mechanism should also work for non-Weston Wayland compositors
10:36tagr: actually we may need one more bit of state in the resource to save whether or not the resource was allocated with a modifier, because in that case we can assume that it'll be added to KMS with the ADDFB2 IOCTL and the correct modifier
10:44karolherbst: sounds like it could work
11:00tagr: there's a bit of a downside to that in that the pitch-linear allocation may fail, and it may be odd for it to fail at ->resource_get_handle() time
11:07karolherbst: is there any kind of fallback we could do to deal with it?
11:07karolherbst: but I guess that could still be fine? dunno
11:09tagr: I suppose we could try to allocate a full screen-size pitch-linear buffer that's global to the screen and use that as scratch space, but there'd be concurrency issues with that
11:09tagr: yeah, I think it should be fine even if we don't
11:10tagr: once I get this working I'll try to inject an error in the allocation to see how X deals with it
11:10karolherbst: mhh, but failing at resource_get_handle is not something we would run into with modifier aware userspace, would we?
11:10karolherbst: As long as nothing changes for modifier aware I think at this point everything goes
11:10tagr: no, modifier aware userspace would not even use this code path
11:10karolherbst: because the alternative would be that it doesn't work at all
11:13karolherbst: what are the condition that resource_get_handle might fail? just ENOMEM or something more API related as well?
11:13tagr: I think it would only be ENOMEM
11:13karolherbst: yeah okay.. then it doens't matter I guess
11:14tagr: well, I think there can also be other conditions, such as any that make drmPrimeFDToHandle() fail
11:14tagr: but I think any of those would be pretty exotic and likely to fail in the modifiers case as well
11:14karolherbst: I think at this point it's more about if userspace would be able to recover if it would get the error ealier
11:15karolherbst: if it just fails a little later then I guess it doesn't matter all that much
13:07tagr: karolherbst: okay, so this now works with glxgears -fullscreen as well and it properly does the de-tiling blit
13:07tagr: karolherbst: but the problem with windowed glxgears remains because there it doesn't actually end up calling ->flush_resource()
13:08tagr: karolherbst: interestingly I did find out why X works fine if we don't enforce pitch-linear in the non-modifiers case
13:08tagr: karolherbst: the reason is that the modesetting driver doesn't actually allocate with framebuffer modifiers, but it will query the modifiers of a BO and pass those to drmModeAddFB2() when presenting
13:09tagr: so we end up in a situation where Tegra's Mesa driver will allocate a "don't care" buffer, which ends up being one of the block-linear formats, which typically wouldn't work (for example, kmscube without modifiers will "properly" show a garbled screen in that situation, as will probably gnome-shell)
13:10tagr: but the modesetting driver "accidentally" does the right thing =)
13:11tagr: glxgears itself also seems to do the right thing now in both cases, so it'll properly de-tile the buffer (glx ends up calling ->flush_resource() in both windowed and fullscreen modes) and presumable that will then be composited on the screen
13:12tagr: so the problem now is really only in the X server since that doesn't call ->flush_resource() on the root window framebuffer at all
13:12tagr: I wonder if I should write any of this up in some way, because I'm sure to forget all of these details again at some point
13:22karolherbst: yeah... not sure if we can call flush_resource inside X as this concept of "frame is done" is pretty.. well broken in X?
13:23tagr: I'm looking at the modesetting driver to see if we can somehow do that there
13:23karolherbst: then you have those users with vsync disabled
13:23tagr: I mean, right before we do a flip/swap of the framebuffer would be a good time to flush the resource
15:54karolherbst: tagr: but is it guarenteed that we flip at all? Although I guess with modesetting it is?
15:55karolherbst: at least when we run glamor...