00:21nmschulte: I'm having trouble w/ a machine consistently recognizing a display via USB Type-C DisplayPort; amdgpu. Is this a good place to ask for help?
00:22nmschulte: Mainly, I want to know if I can get drm/amdgpu to output more information; right now the system logs are not telling me anything.
03:04sebastiencs: Hello, in libgbm what is the difference between surface and buffer object ?
04:00gtristan: Hi o/
04:03gtristan: I'm trying to debug an upgrade to mesa 21.1.0, which resulted in `vainfo` lacking the VAProfileH264Main profile... so I'm basically lacking hardware accelerated h264 decoder capabilities via the radeonsi gallium driver
04:04psykose: it's disabled by default from around that time
04:04gtristan: Oh... there is a nice clue :)
04:04psykose: -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc
04:04psykose: well
04:04psykose: maybe 21 isn't new enough for that..
04:04psykose: i forget which version was the toggle
04:04psykose: maybe 22.something
04:05gtristan:looks at the meson options...
04:05psykose: do you mean 23.1.0? 21 is really old
04:05gtristan: Oh so sorry yes that's what I meant
04:05psykose: yeah it would be that then
04:06gtristan: aha yes there it is in meson_options.txt... thanks a lot !
04:07gtristan:has been swimming down gstreamer-vaapi -> libva -> mesa codepaths all afternoon ;-)
04:09psykose: :)
08:02luc: hi, i built Mesa 23.1.0-devel (git-8f928a95e1) with -Dglx=xlib on my WSL2 Ubuntu-20.04, glmark2 will crash. after some investigation using apitrace. i finally found out ``glXCreateNewContext()`` returns the **new** GLXContext pointer shares the same value with the destroyed one's before (http://ix.io/4BLj 615, 617)
08:10psykose: is that illegal?
08:14luc: psykose: i'm not sure. but this coincidence leads glmark2 to skip ``glXMakeCurrent()`` afterwards https://github.com/glmark2/glmark2/blob/master/src/gl-state-glx.cpp#L88. finally, it ends up crashing
08:15psykose: it sounds like when destroying one it should free/not-reuse glx_context_ still too
08:16jannau: why does glmark2 still use the destroyed glxcontext pointer for anything? sounds to me like a application bug
08:26luc: jannau: the destroyed GLXContext indeed is freed. but i wonder how it comes to the same pointer value in ``create_context()`` https://elixir.bootlin.com/mesa/latest/source/src/gallium/frontends/glx/xlib/glx_api.c#L1125
08:29luc: however it doesn't happen to -Dglx=dri, http://ix.io/4BLo 1326, 1328
08:33luc: i use llvmpipe, https://elixir.bootlin.com/mesa/latest/source/src/glx/drisw_glx.c#L603, so it looks like the same allocation by ``calloc()``, but ...
08:36psykose: what we mean to say is the pointer reference is cached after being freed
08:36psykose: then it gets a new one
08:36jannau: oh, I missed that glmark2 compares the the context with glXGetCurrentContext()
08:36psykose: hmm
08:40MrCooper: luc: freeing memory and then allocating memory of the same size is quite likely to return the just-freed memory
08:44luc: MrCooper: thanks, looks like indeed. so how should we cope with this situation? any suggestion?
08:46jannau: this seems to be a glx issue though, glXCreateNewContext() shouldn't be able to return the same value as glXGetCurrentContext() without calling glXMakeCurrent()
08:47luc: MrCooper: i am still puzzled at why this would not happen to dri-based glx?
09:06MrCooper: jannau: true; maybe glXDestroyContext doesn't keep the context alive if it's current for a thread, as it should?
09:09luc: it works if i add ``SetCurrentContext(NULL)`` in ``glXDestroyContext()``
09:54MrCooper: luc: can you pastebin the corresponding output of glxinfo?
10:48luc: MrCooper: here is glxinfo -B output http://ix.io/4BLN
10:49luc: this is the full one http://ix.io/4BLO
10:59lina: Can someone explain implicit dma-buf modifiers? asahi was defaulting to optimized (compressed) resources when no explicit modifier was passed unless the resource was SCANOUT, and that apparently broke with XWayland/mutter in a recent update that started using dma-buf feedback and, for some reason, started trying to use implicit modifiers.
11:00lina: I changed it to always force LINEAR for any resource that is PIPE_BIND_SHARED and doesn't have explicit modifiers, which I saw freedreno does, but I don't know if that's correct
11:00lina: It definitely regresses performance since with dma-buf v3 mutter/xwayland was correctly picking an explicit compressed modifier, while now with v4/feedback it goes for implicit for some reason which ends up linear after this change...
11:00emersion: sounds like a mutter bug
11:00emersion: implicit modifiers are the legacy world
11:01lina: Yeah, I think the part where it tries to use implicit/DRM_FORMAT_MOD_INVALID is a mutter bug...
11:01emersion: i'd recommend just using LINEAR for implicit, that way there are less sources of bugs and people are incentivized to use explicit modifiers :)
11:02lina: I looked at the feedback with that weston tool and it actually lists all our modifiers *and* INVALID, but for some reason XWayland picks INVALID? So maybe it's an XWayland bug?
11:02emersion: that means that mutter advertises support for explicit modifiers and implicit modifiers, so that's normal
11:03emersion: if xwayland picks INVALID, yeah, that sounds like a wayland bug
11:04emersion: er, xwayland
11:08jannau: there was related work done in xwayland between 23.1.1 and 23.1.2 https://gitlab.freedesktop.org/xorg/xserver/-/commits/xwayland-23.1?ref_type=heads
11:09lina: The X.Org Foundation Xwayland Version 21.1.99 (12101099)
11:09lina: ... why am I on such an old version?
11:10lina: but the package version is 23.1.2
11:11jannau: package is built with automake and upstream updates on the the mson version, maybe?
11:13psykose: 23.1.2 doesn't have autotools
11:13psykose: check PATH first
11:14lina: Oh wait... this is a local build from when I was experimenting... ;;
11:14lina: psykose: Thanks
11:14psykose: :)
11:14lina: But the one mutter is running is the system one, so that's all fine
11:18jannau: looking at https://gitlab.freedesktop.org/xorg/xserver/-/commit/73e0510dee175b5c834c1d4c2cb24071b7f84bbf it seems that xwayland uses scanout intentionally
11:18lina: If it actually requested SCANOUT it would've worked, since that did already force LINEAR for us
11:18lina: So I don't think that's the codepath
11:19emersion: this only happens when a window is candidate for direct scanout
11:20emersion: under mutter, if it's fullscreen
11:21emersion: lina, what broke exactly? no explicit modifier == implicit modifier
11:23lina: with dma-buf v3, xwayland was creating a surface and passing through the explicit modifier (which would be compressed). with v4 (which started being used a week ago due to some chain of unrelated events), it ends up using implicit modifiers, which our driver was taking to mean (absent SCANOUT) pick the best modifier, and then xwayland was just passing the modifier as INVALID on the wayland protocol to
11:23lina: mutter, and then that when imported was assumed linear.
11:24lina: Fix on our end is here: https://gitlab.freedesktop.org/asahi/mesa/-/merge_requests/113
11:25jannau: could xwayland maybe end up using the dcp drm device which doesn't support modifiers?
11:25lina: It does though, it supports LINEAR
11:25lina: Which is different from implicit/none
11:30emersion: lina, if you pick the "best modifier" in the implicit modifier case, you need to also import modifier-less buffers with the same
11:30emersion: and handle USE_LINEAR correctly (ie, have some kind of back-channel)
11:31luc: MrCooper: P.S. glmark2 's apitrace after ``SetCurrentContext(NULL);`` added
11:31emersion: so it's just simpler to not do that and always pick LINEAR in the implicit modifier case
11:32emersion: so i think there are two issues here (1) your driver doesn't handle implicit modifiers correctly (2) xwayland no longer picks explicit modifiers
11:32luc: http://ix.io/4BLZ
11:33emersion: lina, for more info on all of that, see https://lore.kernel.org/dri-devel/20210905122742.86029-1-daniels@collabora.com/
11:43lina: emersion: Yeah, that's what that patch fixes, it just forces LINEAR for anything shared
11:51emersion: ah yes
12:11jannau: xwayland in weston is broken as well, interesting difference is that weston reports the asahi card/render device as main device while kwin reports the dcp drm device
12:11emersion: which one is which?
12:11emersion: asahi render, dcp display?
12:11jannau: dcp is the display, asahi is the gpu
12:16jannau: kwin reports the apple modifiers and LINEAR, weston reports INVALID, LINEAR and the apple modifiers
12:17lina: It looks like the issue is xwayland is preferring INVALID over the rest for some reason?
12:17lina: It should just pass through the whole list to the allocator, but that doesn't seem to be what is happening...
12:22lina: From the driver I just see the regular create call, without modifiers
12:30emersion: the relevant code is https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xwayland/xwayland-glamor.c#L334
12:36lina: emersion: That is running with device=dcp and comparing against a list that contains only the gpu, so it is returning false
12:36emersion: the joys of split render/display
12:37lina: weston-simple-dmabuf-feedback gives me two feedbacks with mutter, the first one has only gpu, then the second one has gpu and dcp tranches
12:38jannau: lina: use wayland-info to see what the compositor returns
12:38lina: just the render device (at least with the interface)
12:40lina: That codepath in xwayland checks the version, if >=4 it queries by device, otherwise just by format
12:40jannau: I "fixed" xwayland with a couple of printfs which don't even print anything
12:40lina: ????
12:41jannau: https://paste.debian.net/1287296/ "fixes" glxgears in weston/Xwayland
12:41jannau: time to run valgrind
12:41lina: xwl_screen_get_main_dev is the issue, if it uses the feedback device it works, but it has a gbm device and prefers that and it's dcp
12:42emersion: one problem is that it uses the device from wl_drm
12:42emersion: which is probably display
12:42lina: jannau: What on earth...
12:42emersion: and then passes that to GBM, GBM under-the-hood opens the render node, but there is no way for Xwayland to know
12:43emersion: i feel like i've seen this story a hundred times
12:43lina: Yeah...
12:43emersion: it would be a lot nicer for Xwayland to open the device sent in dmabuf feedback
12:44emersion: but what would _really_ be a lot nicer is throwing away renderonly/kmsro and replacing it with samething sane
12:47emersion: xwayland could also query the EGLDevice from GBM's EGL platform, to figure out the real underlying device
12:47emersion: but that's just more hacks
12:51lina: I don't really know where to go from here...
12:54jannau: I don't know why those frpintfs fix rendering, the buffer is still created with DRM_FORMAT_MOD_INVALID
12:57lina: Does it tell the real modifier to the compositor? Try WAYLAND_DEBUG=1
12:57lina: What I saw was it was also passing INVALID there instead of the real modifier
13:01jannau: yes, it still sets invalid as modifier in the dmabuf create_params
13:23kisak: dcbaker: sorry what? mesa 23.2.0 (non-release candidate) tagged?
13:55daniels: I don’t think Xwl should filter by device at all
13:56daniels: importing into primary_device is always required; target_device is just an additional optimisation
13:57daniels: so the only reason you should consider devices is if you’re going to modify your allocation for e.g. different placement
13:57daniels: Xwl doesn’t do that so it shouldn’t bother filtering either
14:10lina: daniels: Should I send a MR to remove that codepath and just always use xwl_get_modifiers_for_format?
14:17daniels: lina: I think that’s the best thing, yeah
14:18emersion: daniels: but xwl also renders
14:21daniels: emersion: right, but nothing in the modifier list influences the choice of decide for how buffers (either dmabuf from client or internal from gbm) get allocated right? like every modifier in every tranche is usable for composition
14:22daniels: and it can’t guarantee that it’ll be usable for scanout if target_device for that tranche is different, but … meh
14:22daniels: worst case you end up slightly suboptimal until the compositor realises you aren’t making it to scanout anyway and pushes you back to composition-optimal modifiers
14:28emersion: i remember bugs where xwayland picked modifiers it couldn't render with
14:41daniels: hrm, how did that happen … ?
14:54dcbaker: kisak: %#}{ no, that should bed rc2. Apparently the script went off the rails. I will fix that today
15:02zamundaaa[m]: daniels: the compositor exposes format+modifiers that it can sample from, not that it can render to
15:03zamundaaa[m]: So it may expose modifiers that egl considers external_only, like linear on NVidia for example
15:57daniels: zamundaaa[m]: right, but how does Xwl end up with a list of non-renderable modifiers … ? it should pass the full lists to GBM/etc
16:00zamundaaa[m]: passing the full list doesn't help. You need to filter the list if you want to use the buffer for rendering with some API
16:00zamundaaa[m]: GBM doesn't know if you intend to render to the buffer with OpenGL, which can't handle linear buffers on NVidia, or if you intend to use it with Vulkan, which can handle linear buffers
17:46DemiMarie: Which drivers support virtio-GPU native contexts?
17:49DemiMarie: Is the list freedreno, AMD, and Intel?
21:59dcbaker: kisak: should have a proper rc2 in a few
22:14lumag: emersion, I wanted to bring up the topic of libdrm/modetest (yep). Currently there are 10 merge requests opened against it (out of total 45). They are in various stages of completion, but some are in a good shape. We use it on an almost-daily basis, so it's sad to see it undermaintained in libdrm. What can we do to make it improved? Can we (I) volunteer to maintain it somehow? Or should we fork it instead and keep improving this tool in a separate
22:14lumag: repo? What would be your preference?
22:15lumag: The major bonus side for us is being able to test various usecases from command line, without any additional config files and/or other troubles.
22:20emersion: i'm not sure
22:23emersion: i just happen to be a libdrm developer who dislikes modetest, so i don't think i'm the right person to be part in this discussion