While rendering to an x11 surface, the frames appear in wrong order, making the graphics look corrupted. This probably depends on how the swap chain was created, since vkcube for example works fine. I bisected the problem to this commit: 6f880f128f9862a047a5ba543c2843e14517b1e6 vulkan/wsi: update swapchain status on vkQueuePresent Reproduced on: OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
What application are you using to reproduce this problem?
I was looking if there would be some minimal test case to demonstrate this, but couldn't find one so far. One case where this gets reproduced is the desktop compositor I've been working on. The build instructions and setup is here: https://jaelpark.github.io/chamferwm-docs/setup.html#building-with-meson After building, change the terminal emulator in line 504 of config/config.py to your preference, and once running, launch the terminal with Alt+Enter. Typing something will reveal how the frames come disordered and lagging. Using a recent version of mesa before this particular commit will result in expected behavior.
(In reply to jaelpark from comment #2) > I was looking if there would be some minimal test case to demonstrate this, > but couldn't find one so far. One case where this gets reproduced is the > desktop compositor I've been working on. The build instructions and setup is > here: > https://jaelpark.github.io/chamferwm-docs/setup.html#building-with-meson > > After building, change the terminal emulator in line 504 of config/config.py > to your preference, and once running, launch the terminal with Alt+Enter. > Typing something will reveal how the frames come disordered and lagging. > Using a recent version of mesa before this particular commit will result in > expected behavior. I think I can spot the bug in your compositor : compositor.cpp:984 : currentFrame = (currentFrame+1)%swapChainImageCount; That's incorrect, the image indice returned by acquireNextImage() might not increment.
I would recommend using a list in which you push indices returned by acquireNextImage() and when you need a new currentFrame, you pull from that list.
Okay, thanks a lot. I'll try fix this later and see how it goes.
Thanks, feel free to open if you still have the issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.