| Summary: | Black screen when using xrandr 1.4's offloadsink - AKA Prime | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Mike Lothian <mike> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | companheiro.vermelho, haagch.christoph, kde.org |
| Priority: | NOR | ||
| Version: | 4.11.1 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Mike Lothian
2013-09-13 01:25:53 UTC
(Note aside:
suspending the compositor when running heavy games is likely the best option anyway.)
Now on the bug:
Please try whether
- enabling unredirection ("suspend for fullscreen windows")
- disabling unredirection ("suspend for fullscreen windows")
- setting the "tearing prevention" to "full repaints"
*before* launching the game has deterministic impact.
*** Notice ***
that if you ever set "tearing prevention" to "reuse screen contents", you must restart "kwin --replace &" in order to get rid of effects that this setting causes in the MESA drivers.
Small note: prime support is still rather untested as AFAIK none of our developers has such hardware. We have some code but it has only been tested in theory and I think the drivers do not even fully support it yet. I've cycled through all the options in vsync with and without suspending desktop effects for fullscreen windows but none of the options render correctly when first started I' say it would work with an unredirected window, but (just coming to my mind) since you're likely running kwin on the intel chip we probably currently forcefully disable that (noticed the setting switched back?) because of bug #252817. Since you're runnig gentoo, can you "patch -R" https://git.reviewboard.kde.org/r/111476/diff/raw/ and try again? Would games running in windows (I.e. not full screen) be affected by this too? No. Ah the tests I did above were on Heaven 3.0 in windowed mode as this was easier to close rather than killing the process from a VT I removed the lines manually (the patch wasn't applying cleanly) and recompiled kwin - this has fixed heaven 3 running in full screen and now launches successfully every time Windowed mode however is still broken it always shows black until a resize or playing with the kwin settings gets it rendering properly again The full screen option is slightly annoying as the controls in a fullscreen smplayer don't show with it switched on Lastly is it possibly to gray out the unredirect option if it's going to be ignored anyway? (In reply to comment #8) > this has fixed heaven 3 running in full screen and now > launches successfully every time Ok, at least it#s not completely screwed. > Windowed mode however unaffected by the patch, but > until a resize or playing with the kwin settings gets it rendering properly that's actually interesting. kwriteconfig --file kwinrc --group Compositing --key GLStrictBinding true > Lastly is it possibly to gray out the unredirect option if it's going to be > ignored anyway? We cant test for the GL renderer in the config dialog because crashing driver installations make the dialog inaccessible then (been there...) Forcing that disabled for certain systems is no long term solution anyway, just the crash reports took off. I've just tried running: kwriteconfig --file kwinrc --group Compositing --key GLStrictBinding true and restarted kwin Unfortunately glxgears still starts as blank (In reply to comment #10) > Unfortunately glxgears still starts as blank Thanks for testing, please revert the setting, ideally remove the entry from ~/.kde/share/config/kwinrc, [Compositing] group. I have a similar problem. In my case, if I change the compositing type from OpenGL to XRender, it always works. Can you confirm if that I have a similar problem. In my case, if I change the compositing type from OpenGL to XRender, it always works. Can you confirm if that's your case? Kwin_gles behaves the same way. I'm using Arch Linux and trying to offload to a RadeonSI card. I'm on archlinux too. Ivy bridge + radeonsi. kwin 4.11.3 it seems. I can confirm that with xrender it always works. With OpenGL compositing, fullscreen applications most often have problems and windowed applications sometimes have problems. It can even be provoked with DRI_PRIME=1 glxgears, but with glxgears it's more rare and I have to start it a few times before the black window happens. Resizing the window makes the contents appear. Also disabling compositing with the alt+shift+f12 hotkey and re-enabling it makes it work. Sometimes minimizing and restoring the window helps too. Another workaround is disabling compositing with the hotkey and starting xcompmgr. It makes me think that this is just some timing problem in kwin... I haven't seen any other compositor having this problem. (In reply to comment #14) > It makes me think that this is just some timing problem in kwin... I haven't > seen any other compositor having this problem. XCompmgr operates on XRender, so does eg. metacity. Also if (fullscreen) windows are simply unredirected by the compositor, this would of course not occur. FTR: Resizing will recreate and rebind the window texture, the question is whether there'd be some signal (by the client) to know that this is required. (In reply to comment #15) > XCompmgr operates on XRender, so does eg. metacity. I have nothing new to add, but you are right and there is another compositing manager that shows the same problem: compton. It can use glx and xrender as backend. With "compton --backend xrender" I do *not* see the problem, but with "compton --backend glx" I *do* see the problem, also verified with it running on another noncompositing window manager than kwin. So unless compton is doing the same as kwin with respect to glx compositing, the problem is not in kwin. Maybe it's noteworthy that a 32 bit glxgears shows the problem (almost?) every time and with 64 bit glxgears it's maybe 80% working and 20% the problem. Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone! This issue report is quite old. Can you please confirm, that it still persists with Plasma 5.23? I can off load fine on 5.23 under X11 I believe everyone has switched to DRI3 by now. This was only an issue with DRI2. |