When I launch DRI_PRIME=1 glxgears, I get only black window. However, with XRender-based compositing (KWin), everything works fine. Fullscreen applications work without compositing. glxgears prints framerate to console, dmesg doesn't contain any errors. Happens with: Mesa 9.1.6 and Mesa Mesa 9.2.0 (git-9586f4d) Xorg server 1.13.4 and Xorg server 1.14.2.902 I tried both SNA and UXA for Intel driver, no difference. Hardware: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6730M/6770M/7690M XT] (rev ff) There are also problems with KWin OpenGL compositing. However, maybe it's KWin bugs: 1) Black window for windowed applications. However, if I resize the window, the application starts to render correctly. 2) Black screen for fullscreen applications, unless I enable unredirection or disable compositing. Or, if I switch to another window and return back, the application starts to render correctly too.
You need to enable compositing for PRIME to render correctly (and you figured that out for yourself already). I don't recall having any problems under KWin or Xfwm4.
(In reply to comment #1) > You need to enable compositing for PRIME to render correctly (and you > figured that out for yourself already). Not true for fullscreen windows. > I don't recall having any problems under KWin or Xfwm4. Xfwm uses XRender, I don't have any problems with XRender too. However, KWin 4.11 with OpenGL backend causes multiple problems.
Tried Ubuntu 13.04 and KUbuntu 13.04 live usbs: - Both KWin and Compiz can't handle fullscreen games with compositing enabled - KWin can handle games with unredirection, Compiz can't - glxgears work correctly on older KWin And without DRI_PRIME=1 everything works everywhere, with or without compositing, windowed or fullscreen.
By any chance are you using SNA rather than UXA on xf86-video-intel? I'm experiencing the same issues as you
> And without DRI_PRIME=1 everything works everywhere, with or without > compositing, windowed or fullscreen. I would imagine this is because you're not offloading anything at that point and running it on the IGP. >I don't recall having any problems under KWin or Xfwm4. This is because KWin defaults to Xrender, and Xfwm4 is *only* Xrender. xcompmgr works fine, too, as do the default settings on Compton. If you try this on: * GNOME3 * Cinnamon * Compton with --backend glx You will get a black screen. However, if the screen is *not* full screen, you can resize the screen and the image will appear (such as with glxgears or glxspheres). Unfortunately, in screens that are "full screen windowed", as are many Wine games, it still shows up black and there's no way to resize the screen in order to make the image show up. In any case, that's not really an acceptable workaround because it just shows that there's something wrong with PRIME offloading that causes this odd behavior on GLX-based compositors.
I find this happens in Gnome when using the SNA backend but not with UXA As a work around I use a shortcut to toggle effects in kwin - this usually fixes the issue within one or two goes - this is most useful when you can't resize the window
I've got no problem using UXA, as I'm not doing much high performance stuff with the IGP. The trouble I run into is that UXA doesn't seem to like PRIME -- whenever I start X with UXA enabled it doesn't show the radeon card in xrandr --listproviders This is with xorg 1.15.
If you're using kernel 3.12 try the latest 3.13-rc7 there's an issue with vgaswitcheroo that's just been fixed - you'll also be able to boot with radeon.runpm=1 which will power off your card when you're not using it (i.e. running an app with DRI_PRIME=1) I've just tested out UXA again and it works great - no black screens - SNA still causes issues - I need to resize or toggle compositing I'm running xorg-server 1.15, xf86-video-intel 2.99.907, the latest mesa from git and kernel 3.13-rc7 with radeon.dpm=1 and radeon.runpm=1 If the kernel fix doesn't work try attaching your dmesg and Xorg.0.log and hopefully a developer can help you
Actually there are still a few PRIME rendering issue with UXA as well as SNA - they just don't happen as frequently
I'll have to give rc7 a shot -- didn't realize it had dropped today. Looks to have a lot of promising things in it (Marek's shader engine fixes too, which will be nice.)
Even with UXA, I still have black window instead of fullscreen games
I see only comments about intel+radeon here. It would be interesting to know if there are same problems with intel+nouveau or radeon+radeon
(In reply to comment #5) > > And without DRI_PRIME=1 everything works everywhere, with or without > > compositing, windowed or fullscreen. > > I would imagine this is because you're not offloading anything at that point > and running it on the IGP. > > >I don't recall having any problems under KWin or Xfwm4. > > This is because KWin defaults to Xrender, and Xfwm4 is *only* Xrender. > xcompmgr works fine, too, as do the default settings on Compton. > I've used KWin OGL3.1 backend. For Xfwm4, if you don't enable Display Compositing in Settings -> Window Manager Tweaks -> Compositor, you'll get black screen too. > If you try this on: > > * GNOME3 > * Cinnamon > * Compton with --backend glx > > You will get a black screen. > > However, if the screen is *not* full screen, you can resize the screen and > the image will appear (such as with glxgears or glxspheres). > > Unfortunately, in screens that are "full screen windowed", as are many Wine > games, it still shows up black and there's no way to resize the screen in > order to make the image show up. In any case, that's not really an > acceptable workaround because it just shows that there's something wrong > with PRIME offloading that causes this odd behavior on GLX-based compositors.
Prime only works with compositing, so you have to have compositing enabled.
(In reply to comment #12) > I see only comments about intel+radeon here. > It would be interesting to know if there are same problems with > intel+nouveau or radeon+radeon On my nvd9 + snb (gnome3): glxgears works ok openarena works ok (fullscreen) Unigine Heaven/Valley shows black screen, it seems to be running (even blind clicking works) it just shows black window. The window is not resizable, but moving it around or minimize/restore does not help.
If you're running the lastest verion of Heaven or running Valley on drivers that don't yet have OpenGL 3.2 it'll fail to render (SNB doesn't) - try passing MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150 to see if it then works
Well, some people here talk about PRIME not working with compositing, some people are talking about PRIME having some issues with OpenGL compositing. The second one is still an issue and maybe it's some race condition or so, because some things (almost?) never work, and some things work often, and fail sometimes. To summarize: With Xrender Compositing there's no problem, but with OpenGL compositing there is. With both compton --backend glx and kwin with opengl compositing I randomly get the black screen by just starting and quitting DRI_PRIME=1 glxgears a few times. It works about half the time. It was already in the kde bugtracker: https://bugs.kde.org/show_bug.cgi?id=324864 and comment 15 said: "Resizing will recreate and rebind the window texture" So maybe there is some starting point to investigate why that happens?
On Arch Linux: Xorg 1.15, Mesa 10.0.3, Linux 3.13.2, KWin 4.11.6 with OpenGL 3.1 compositing. libdrm 2.4.52 xf86-video-ati 7.3.0 xf86-video-intel 2.99.909 (sna) No more black screens with xonotic-sdl. Glxgears don't need to be resized too. Looks like things finally started to work as they should.
Oops, forgot to mark it as "Fixed" (In reply to comment #18) > On Arch Linux: > Xorg 1.15, Mesa 10.0.3, Linux 3.13.2, KWin 4.11.6 with OpenGL 3.1 > compositing. > libdrm 2.4.52 > xf86-video-ati 7.3.0 > xf86-video-intel 2.99.909 (sna) > > No more black screens with xonotic-sdl. Glxgears don't need to be resized > too. > > Looks like things finally started to work as they should.
I'm glad things are fixed for yourself but I'm still seeing this bug - i.e. it never went away I'm running kernel 3.14-rc1, xorg 1.15, llvm, libdrm, mesa and xf86-video-intel (sna) from git along with kwin 4.11.6 with OpenGL 3.1 rendering It show up for me with Unigine Valley in Windowed mode - usually toggling compositing gets things working for me at the moment this can trigger gpu lockups since the GS branch for r600 was merged (or possibly slightly before). I'll raise a separate bug for this tonight Alexander can you confirm you have any issues with Valley (you might need to run it with MESA_GLSL_VERSION_OVERRIDE=150 set
Yes, unigine valley renders fully transparent window with OpenGL compositing, and everything works fine with XRender. Also, looks like first launched windowed application still renders black window. If I run glxgears just after startup, it still has black window. However, on second launch and later it works fine.
Can anyone test this patch? https://bugzilla.kernel.org/show_bug.cgi?id=65761#c41 Beware, it currently breaks opencl and possibly other things, but if it helps, then we at least know a little bit more about what causes the problem.
With the patch glxgears launches successfully around 50% of the time - which is an improvement - this is on r600g from mesa master - opencl still works for me though
(In reply to comment #22) > Can anyone test this patch? > https://bugzilla.kernel.org/show_bug.cgi?id=65761#c41 > > Beware, it currently breaks opencl and possibly other things, but if it > helps, then we at least know a little bit more about what causes the problem. the patch does not change anything for me. glxgears and openarena works ok with or without the patch (modulo nvd9 crashes) unigine heaven/valley show transparent window (and then crash)
Okay then, sorry to bother you. People are still talking about different issues here, aren't they? Curiously for me with ivy bridge + radeonsi with this patch 64 bit glxgears works every start now and 32 bit glxgears has a black screen every start until it's resized etc. It's a strange issue.
I was asked to comment here. I'm using a dual AMD graphics system (radeon 6520g + 6750m), my OS is Kubuntu with the radeon driver and mesa 10.4-dev (10.4.0-devel git-eb4541e) and I don't have, and never have had, this issue, even when KWin's OpenGL composition is enabled. Perhaps is an intel + radeon issue?
Hi guys! Fedora 22 x86_64, kernel 4.0.4-303, KDE Frameworks 5.10.0, KWin 5.3.1-2, OpenGL 3.1 backend for KWin compositor, xorg-x11-drv-ati-7.5.0-3 and xorg-x11-drv-intel-2.99.917-10.20150526 vga drivers, XOrg-xserver 1.17.1-14, the second monitor is connected to the D-SUB output of my laptop (Lenovo G570) lspci gives: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Subsystem: Lenovo Device 397a Kernel driver in use: i915 Kernel modules: i915 -- 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Robson CE [Radeon HD 6370M/7370M] (rev ff) Kernel driver in use: radeon Kernel modules: radeon I've already done xrandr --setprovideroffloadsink radeon Intel The problem still remains: when I run glxgears (or another OpenGL app) without DRI_PRIME=1 all seems good but with that variable I get black screen. The problem disappears when I switch to another window and back. With XRender backend for KWin all works like a charm but I don't want to use XRender because of high CPU load and overheating.
(In reply to viktor from comment #27) > Hi guys! snip > > I've already done xrandr --setprovideroffloadsink radeon Intel > > The problem still remains: when I run glxgears (or another OpenGL app) > without DRI_PRIME=1 all seems good but with that variable I get black > screen. The problem disappears when I switch to another window and back. > With XRender backend for KWin all works like a charm but I don't want to use > XRender because of high CPU load and overheating. Its a known issue and i guess it wont get resolved (with DRI2), with DRI3 this does not happen, you don't depend on compositing as well with it. (And you are saved from the xrandr --setprovideroffloadsink dance as well!)
As I know current mesa drivers for intel IGP doesn't support DRI3 by default for Fedora 22... but I can be wrong. Any ways to enable DRI3?
(In reply to viktor from comment #29) > As I know current mesa drivers for intel IGP doesn't support DRI3 by default > for Fedora 22... but I can be wrong. Any ways to enable DRI3? http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/configure.ac?id=b6eeb7a1f7efa591504070b606be655e27e6e9c2 disabled DRI3 support for everyone because it's "buggy and lead to server crashes and lockups". I think you have to recompile the driver if you really wanted that…
I also have a very similar problem except the windows are... white. Setup is hybrid muxless AMD/AMD (6480G/6650M). I'm running on Ubuntu 16.04/Unity (meaning Compiz) with Mesa 11.2 (or 11.3-devel) and on kernel 4.6-rc6. The issue only occurs when booting without grub options (dpm is thus enabled by default), it may be linked to another issue which is that the xrandr --listproviders only outputs iGPU when DPM is enabled (even if I use DRI_PRIME=1), though DRI_PRIME=1 glxinfo | grep OpenGL outputs the dGPU as it should. DPM on, and with DRI3 enabled in /etc/X11/xorg.conf.d/r.conf, if I launch apps with DRI_PRIME=1 %command%, it renders a white window (no decorations). I don't think resizing the window works, not sure I've ever tried. vgaswitcheroo shows DynPwr on the dGPU when DRI_PRIME=1 is used (DynOff otherwise) and the fans are definitely going a notch higher, meaning it looks like it works, just the rendering that is off (well, white). If I stay on DRI2, the rendering on windows works fine, though DRI_PRIME=1 launches on integrated GPU (half of the fps, and dGPU remains on DynOff). If I insert radeon.runpm=0 as grub option, still on DRI3, both GPUS are listed with xrandr --listproviders and vgaswitcheroo outputs Pwr for both (not good for battery life), only then DRI_PRIME=1 is working nice with dGPU, though system freezes when navigating context menus in Steam (unless I add LIBGL_DRI3_DISABLE=1 before DRI_PRIME=1 %command%). To summarize, white windows occurs only with dpm on, DRI3 enabled and launching apps with DRI_PRIME=1. With a different configuration, it has other kind of issues. No perfect setup yet (except discontinued fglrx). I still have to try this on Manjaro on a test partition to see if it the results are the same. Anyway, this bug is not solved.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/903.
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.