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.
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>
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>
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?
<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
<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
<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
<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]
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]