https://bugs.freedesktop.org/show_bug.cgi?id=104306

--- Comment #2 from eric vz evonzee+freedesktop@themxgroup.com --- Working on narrowing down the source of the issue, I've found so far that 17.2.7 builds work fine (though I had to change --enable-omx-bellagio back to --enable-omx), and 17.3.0-rc3 does not. I'll try an -rc1 build, then I may be on to learning how to package from a locally bisected git.

https://bugs.freedesktop.org/show_bug.cgi?id=104306

--- Comment #4 from eric vz evonzee+freedesktop@themxgroup.com --- Created attachment 136333 --> https://bugs.freedesktop.org/attachment.cgi?id=136333&action=edit Bisect log

Bisect log attached. I also had to revert c4ed39f85b (which I did via cherrypick applying b6f41e393e)to build some of these versions.

https://bugs.freedesktop.org/show_bug.cgi?id=104306

--- Comment #6 from eric vz evonzee+freedesktop@themxgroup.com --- Created attachment 136345 --> https://bugs.freedesktop.org/attachment.cgi?id=136345&action=edit Hung glxinfo backtrace

gnome-shell 3.26.2+9+ga3736d3a3-1 xorg-server-xwayland 1.19.5-1

Backtrace attached. I've also got strace output if it would be useful. Thanks for your help!

https://bugs.freedesktop.org/show_bug.cgi?id=104306

Emil Velikov emil.l.velikov@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |breno.ec@gmail.com

--- Comment #8 from Emil Velikov emil.l.velikov@gmail.com --- *** Bug 104351 has been marked as a duplicate of this bug. ***

https://bugs.freedesktop.org/show_bug.cgi?id=104306

--- Comment #10 from eric vz evonzee+freedesktop@themxgroup.com --- Following up on this, it looks like my bisect wa bad. I retried commit 255573996cc997cb61be9adad3e8fcaa78db5d1f and it works fine.

I will re-bisect to find the real offending commit and report when I have an answer.

https://bugs.freedesktop.org/show_bug.cgi?id=104306

--- Comment #12 from eric vz evonzee+freedesktop@themxgroup.com --- Subsequent bisects (starting at different ranges so different commits would be tested) have led me to the same place. No idea why I thought 255573996 worked for a while; all new builds from it break for me. I have Pacman packages for every build I've made if anyone would find them useful.

I narrowed the problem to the final return statement by replacing it with "return true;" which resulted in a working build. I also tried to rule out side-effects from the call by adding "bind = screen->check_resource_capability(screen, image->texture, bind) ? 1 : 0;" before the return true so the method would be called but its return value ignored, assuming the compiler is not smart enough to optimize that out. That build worked too.

I assume that capability check must sometimes be returning false in some unexpected situations, and something is not handling that. I tried making a debug build of mesa-demos, then gdb glxinfo and set a breakpoint on dri2_validate_usage, but that method appears not to be called before the process hangs. I assume something during system startup calls it, caches the result, and leads to these issues downstream?

If anyone has any guidance on next steps, I'd appreciate it.

https://bugs.freedesktop.org/show_bug.cgi?id=104306

--- Comment #14 from eric vz evonzee+freedesktop@themxgroup.com --- Thanks, Michel. On a hanging call to glxinfo, dri2_validate_usage is being called from gbm_dri_bo_import, which gets parameters of a 100x100 FD image buffer for usage 5 (scanout | rendering). However, the image texture winds up with is_displayable = 0, so si_check_resource_capabilities returns false, gbm_dri_bo_import destroys the image, and glxinfo hangs. I confirmed that if I set variable usage = 0 the problem does not occur. I have not yet been able to trace where the texture flags are set, but I got far enough to find that they're being read from the image buffer as metadata.

However, it occurs to me that as a newcomer to the domain (e.g., I had to google what a scanout is), I don't know the real problem:

* Should usage include scanout? * Should the image metadata include is_displayable? * Should the null return from gbm_dri_bo_import cause the caller to hang?

Either point 1 or point 2 seems like it must be wrong, and might be the easiest fix. Point 1 seems the stronger case, since glxinfo doesn't actually draw anything as far as I'm aware. Since Firefox, Chromium, and other apps also seem to fail on this, I'm expecting to find some kind of common initialization code that does it. Will report back when I get time to dig. Or, if anyone knows better than I do which avenue to pursue, I'm happy to be redirected. I don't expect to have time to look at this until the weekend.

https://bugs.freedesktop.org/show_bug.cgi?id=104306

--- Comment #16 from eric vz evonzee+freedesktop@themxgroup.com --- Thanks a lot, Michel! I confirmed that 255573996 plus the linked patch works for me as well.