When I offload GPU rendering to my Radon 6600M (r600g) from my Intel Sandybridge system I usually get a black screen - the sound still works If I can alt tab back and play around with the redirect fullscreen options and / or the vsync options I can usually get it to start rendering Alternatively windowed mode can be fixed by resizing the window but not all games allow this I've now emerged gnome and have tested it out under gnome-shell launching with the same options using konsole and there is no rendering issues at all - I couldn't find any settings to figure out how Gnome renders i.e. undirected or vsync options Since I know for sure it works under gnome I'm guessing this is a kwin bug - it was suggested by airlied when the feature first landed but at the time people were having issues in gnome too Reproducible: Always Steps to Reproduce: 1. xrandr --setprovideroffloadsink 0x55 0x7f 2. DRI_PRIME=1 ./heaven (or any other opengl program) 3. Actual Results: Black screen Expected Results: Amazing graphics ;-)
(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.