ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
krushia has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
pcercuei has quit [Quit: dodo]
smiles_1111 has joined #dri-devel
nmschulte has joined #dri-devel
<nmschulte> 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?
<nmschulte> 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.
idr has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
dviola has quit [Quit: WeeChat 4.0.2]
loki_val has quit []
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
<sebastiencs> Hello, in libgbm what is the difference between surface and buffer object ?
godvino has joined #dri-devel
benjaminl has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
gtristan has joined #dri-devel
<gtristan> Hi o/
godvino has quit [Quit: WeeChat 3.6]
<gtristan> 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
<psykose> it's disabled by default from around that time
<gtristan> Oh... there is a nice clue :)
<psykose> -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc
<psykose> well
<psykose> maybe 21 isn't new enough for that..
<psykose> i forget which version was the toggle
<psykose> maybe 22.something
* gtristan looks at the meson options...
<psykose> do you mean 23.1.0? 21 is really old
<gtristan> Oh so sorry yes that's what I meant
<psykose> yeah it would be that then
<gtristan> aha yes there it is in meson_options.txt... thanks a lot !
* gtristan has been swimming down gstreamer-vaapi -> libva -> mesa codepaths all afternoon ;-)
<psykose> :)
benjaminl has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
smiles_1111 has quit [Ping timeout: 480 seconds]
gtristan has quit [Remote host closed the connection]
gtristan has joined #dri-devel
Duke`` has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
smiles_1111 has joined #dri-devel
gtristan has quit [Remote host closed the connection]
gtristan has joined #dri-devel
fab has joined #dri-devel
gtristan has quit [Ping timeout: 480 seconds]
gtristan has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Danct12 is now known as Guest7286
Danct12 has joined #dri-devel
nmschulte has quit [Ping timeout: 480 seconds]
gtristan has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
anarsoul has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
yyds has quit [Remote host closed the connection]
idr has quit [Quit: Leaving]
yyds has joined #dri-devel
yyds has quit []
anarsoul has joined #dri-devel
sima has joined #dri-devel
yyds has joined #dri-devel
godvino has joined #dri-devel
luc has joined #dri-devel
<luc> 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)
<psykose> is that illegal?
<luc> 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
<psykose> it sounds like when destroying one it should free/not-reuse glx_context_ still too
<jannau> why does glmark2 still use the destroyed glxcontext pointer for anything? sounds to me like a application bug
godvino has quit [Ping timeout: 480 seconds]
<luc> 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
<luc> however it doesn't happen to -Dglx=dri, http://ix.io/4BLo 1326, 1328
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<luc> 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 ...
<psykose> what we mean to say is the pointer reference is cached after being freed
<psykose> then it gets a new one
<jannau> oh, I missed that glmark2 compares the the context with glXGetCurrentContext()
<psykose> hmm
crabbedhaloablut has joined #dri-devel
<MrCooper> luc: freeing memory and then allocating memory of the same size is quite likely to return the just-freed memory
djbw has quit [Read error: Connection reset by peer]
<luc> MrCooper: thanks, looks like indeed. so how should we cope with this situation? any suggestion?
<jannau> this seems to be a glx issue though, glXCreateNewContext() shouldn't be able to return the same value as glXGetCurrentContext() without calling glXMakeCurrent()
<luc> MrCooper: i am still puzzled at why this would not happen to dri-based glx?
dviola has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
Mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Mangix has joined #dri-devel
<MrCooper> jannau: true; maybe glXDestroyContext doesn't keep the context alive if it's current for a thread, as it should?
<luc> it works if i add ``SetCurrentContext(NULL)`` in ``glXDestroyContext()``
YuGiOhJCJ has joined #dri-devel
junaid has joined #dri-devel
heat has joined #dri-devel
smiles_1111 has joined #dri-devel
yyds has quit [Remote host closed the connection]
<MrCooper> luc: can you pastebin the corresponding output of glxinfo?
junaid has quit [Ping timeout: 480 seconds]
luc_ has joined #dri-devel
luc_ has quit []
luc_ has joined #dri-devel
luc_ has left #dri-devel [#dri-devel]
luc_ has joined #dri-devel
luc has quit [Quit: Page closed]
luc_ has quit []
luc has joined #dri-devel
luc has quit [Quit: Page closed]
luc has joined #dri-devel
<luc> MrCooper: here is glxinfo -B output http://ix.io/4BLN
<luc> this is the full one http://ix.io/4BLO
<lina> 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.
<lina> 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
fab has quit [Quit: fab]
<lina> 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...
fab has joined #dri-devel
<emersion> sounds like a mutter bug
<emersion> implicit modifiers are the legacy world
<lina> Yeah, I think the part where it tries to use implicit/DRM_FORMAT_MOD_INVALID is a mutter bug...
<emersion> i'd recommend just using LINEAR for implicit, that way there are less sources of bugs and people are incentivized to use explicit modifiers :)
<lina> 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?
<emersion> that means that mutter advertises support for explicit modifiers and implicit modifiers, so that's normal
<emersion> if xwayland picks INVALID, yeah, that sounds like a wayland bug
<emersion> er, xwayland
godvino has quit [Ping timeout: 480 seconds]
<jannau> 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
<lina> The X.Org Foundation Xwayland Version 21.1.99 (12101099)
<lina> ... why am I on such an old version?
<lina> but the package version is 23.1.2
<jannau> package is built with automake and upstream updates on the the mson version, maybe?
<psykose> 23.1.2 doesn't have autotools
<psykose> check PATH first
<lina> Oh wait... this is a local build from when I was experimenting... ;;
<lina> psykose: Thanks
<psykose> :)
<lina> But the one mutter is running is the system one, so that's all fine
<jannau> looking at https://gitlab.freedesktop.org/xorg/xserver/-/commit/73e0510dee175b5c834c1d4c2cb24071b7f84bbf it seems that xwayland uses scanout intentionally
<lina> If it actually requested SCANOUT it would've worked, since that did already force LINEAR for us
<lina> So I don't think that's the codepath
<emersion> this only happens when a window is candidate for direct scanout
camus has quit [Ping timeout: 480 seconds]
<emersion> under mutter, if it's fullscreen
<emersion> lina, what broke exactly? no explicit modifier == implicit modifier
<lina> 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
<lina> mutter, and then that when imported was assumed linear.
<jannau> could xwayland maybe end up using the dcp drm device which doesn't support modifiers?
<lina> It does though, it supports LINEAR
<lina> Which is different from implicit/none
<emersion> lina, if you pick the "best modifier" in the implicit modifier case, you need to also import modifier-less buffers with the same
<emersion> and handle USE_LINEAR correctly (ie, have some kind of back-channel)
<luc> MrCooper: P.S. glmark2 's apitrace after ``SetCurrentContext(NULL);`` added
godvino has joined #dri-devel
<emersion> so it's just simpler to not do that and always pick LINEAR in the implicit modifier case
<emersion> so i think there are two issues here (1) your driver doesn't handle implicit modifiers correctly (2) xwayland no longer picks explicit modifiers
junaid has joined #dri-devel
<lina> emersion: Yeah, that's what that patch fixes, it just forces LINEAR for anything shared
tobiasjakobi has joined #dri-devel
jfalempe has quit [Quit: Leaving]
<emersion> ah yes
godvino has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit [Quit: Leaving]
psykose has quit [Remote host closed the connection]
<jannau> 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
<emersion> which one is which?
<emersion> asahi render, dcp display?
<jannau> dcp is the display, asahi is the gpu
<jannau> kwin reports the apple modifiers and LINEAR, weston reports INVALID, LINEAR and the apple modifiers
<lina> It looks like the issue is xwayland is preferring INVALID over the rest for some reason?
<lina> It should just pass through the whole list to the allocator, but that doesn't seem to be what is happening...
psykose has joined #dri-devel
<lina> From the driver I just see the regular create call, without modifiers
Danct12 has quit [Quit: WeeChat 4.0.2]
<lina> emersion: That is running with device=dcp and comparing against a list that contains only the gpu, so it is returning false
<emersion> the joys of split render/display
<lina> 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
kts has joined #dri-devel
<jannau> lina: use wayland-info to see what the compositor returns
<lina> just the render device (at least with the interface)
<lina> That codepath in xwayland checks the version, if >=4 it queries by device, otherwise just by format
<jannau> I "fixed" xwayland with a couple of printfs which don't even print anything
<lina> ????
<jannau> https://paste.debian.net/1287296/ "fixes" glxgears in weston/Xwayland
<jannau> time to run valgrind
<lina> 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
<emersion> one problem is that it uses the device from wl_drm
<emersion> which is probably display
<lina> jannau: What on earth...
<emersion> and then passes that to GBM, GBM under-the-hood opens the render node, but there is no way for Xwayland to know
<emersion> i feel like i've seen this story a hundred times
<lina> Yeah...
<emersion> it would be a lot nicer for Xwayland to open the device sent in dmabuf feedback
<emersion> but what would _really_ be a lot nicer is throwing away renderonly/kmsro and replacing it with samething sane
<emersion> xwayland could also query the EGLDevice from GBM's EGL platform, to figure out the real underlying device
<emersion> but that's just more hacks
aissen has quit [Ping timeout: 480 seconds]
<lina> I don't really know where to go from here...
<jannau> I don't know why those frpintfs fix rendering, the buffer is still created with DRM_FORMAT_MOD_INVALID
<lina> Does it tell the real modifier to the compositor? Try WAYLAND_DEBUG=1
<lina> What I saw was it was also passing INVALID there instead of the real modifier
<jannau> yes, it still sets invalid as modifier in the dmabuf create_params
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
nmschulte has joined #dri-devel
nmschulte is now known as Guest7299
kts has quit [Quit: Leaving]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kts has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
<kisak> dcbaker: sorry what? mesa 23.2.0 (non-release candidate) tagged?
Guest7299 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
<daniels> I don’t think Xwl should filter by device at all
<daniels> importing into primary_device is always required; target_device is just an additional optimisation
<daniels> so the only reason you should consider devices is if you’re going to modify your allocation for e.g. different placement
<daniels> Xwl doesn’t do that so it shouldn’t bother filtering either
kts has joined #dri-devel
<lina> daniels: Should I send a MR to remove that codepath and just always use xwl_get_modifiers_for_format?
junaid has quit [Ping timeout: 480 seconds]
<daniels> lina: I think that’s the best thing, yeah
<emersion> daniels: but xwl also renders
junaid has joined #dri-devel
kzd has joined #dri-devel
<daniels> 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
<daniels> and it can’t guarantee that it’ll be usable for scanout if target_device for that tranche is different, but … meh
<daniels> 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
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<emersion> i remember bugs where xwayland picked modifiers it couldn't render with
<daniels> hrm, how did that happen … ?
<dcbaker> kisak: %#}{ no, that should bed rc2. Apparently the script went off the rails. I will fix that today
heat has quit [Read error: Connection reset by peer]
heat_ has joined #dri-devel
<zamundaaa[m]> daniels: the compositor exposes format+modifiers that it can sample from, not that it can render to
<zamundaaa[m]> So it may expose modifiers that egl considers external_only, like linear on NVidia for example
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
jkrzyszt_ has joined #dri-devel
junaid has quit [Quit: leaving]
<daniels> 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
<zamundaaa[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
<zamundaaa[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
eukara has joined #dri-devel
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
Surkow|laptop has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
smiles_1111 has quit [Ping timeout: 480 seconds]
heat_ has quit [Read error: No route to host]
heat_ has joined #dri-devel
junaid has joined #dri-devel
pcercuei has joined #dri-devel
Venemo has quit [Quit: No Ping reply in 180 seconds.]
Venemo has joined #dri-devel
urja has quit [Quit: WeeChat 3.6]
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
<DemiMarie> Which drivers support virtio-GPU native contexts?
<DemiMarie> Is the list freedreno, AMD, and Intel?
APic has quit []
APic has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Scorpi has quit []
gouchi has joined #dri-devel
gouchi has quit []
Scorpi has joined #dri-devel
iive has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
iive has quit [Remote host closed the connection]
iive has joined #dri-devel
djbw has joined #dri-devel
luc has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
fxkamd has quit []
junaid has quit [Remote host closed the connection]
fab has quit [Quit: fab]
sima has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<dcbaker> kisak: should have a proper rc2 in a few
yyds has joined #dri-devel
<lumag> 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
<lumag> repo? What would be your preference?
kts has quit [Ping timeout: 480 seconds]
<lumag> 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.
<emersion> i'm not sure
kts has joined #dri-devel
<emersion> 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
heat_ has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
crabbedhaloablut has quit []
exit70_ has quit []
iive has quit [Quit: They came for me...]
exit70 has joined #dri-devel