Created attachment 68139 [details]
Header file for modified sample code

I should also mention the speed at which Xorg ramps up for testing and reproduction. On my Ubuntu 12.04 box Xorg went from about 20% CPU usage to 50% CPU usage over the course of 9 minutes.

As an additional note I said that creating multiple contexts was my workaround, however I've found that is not an acceptable workaround either. The problem with that method is that it ends up using an excessive amount of memory per context created. You can see this by simply modifying the sample to use one of the other wxGLCanvas constructors so that each has its own context and then the memory jumps from 76MB virtual and 17MB physical to 471MB virtual and 84MB physical. Also note that this is with the latest packages available off of xorg-edgers. Previous drivers will use even more memory. However, this is a separate issue so I'll create a separate bug for it.

I finally managed to get the thing built (lame non-pkgconfig packages), but it's just showing a bunch of black boxes except for one full of undefined in the upper left.  I'm not sure what I'm supposed to be looking at here.

The test program itself doesn't have anything to see. It just demonstrates the performance ramping and Xorg CPU gradually increasing. Just run the sample app and watch the Xorg process slowly increase CPU. As mentioned before it will grow to around 50% after around 9 minutes on my box. If you leave it running for longer it will eventually get to 90% or higher and make everything very sluggish.

The black boxes and undefined garbage are expected as I commented out all the actual OpenGL calls to demonstrate that it is specifically the glxMakeContextCurrent (in wxWidgets via SetCurrent) call that is causing the issue. Technically I think I left the SwapBuffers call in there too, but that can be removed and the issue still happens.

Created attachment 77499 [details]
repeated glXMakeCurrent and glXSwapBuffers calls on different drawables

I think I faced same behavior on ironlake (8086:0046). My code boils down to three calls:

      glXMakeCurrent(dpy, wnd1, glc);
      glXMakeCurrent(dpy, wnd2, glc);
      glXSwapBuffers(dpy, wnd2);

repeated many times. See attachment for full code. It takes around 1-2 minutes
to make Xorg process eat 100% CPU on my machine.

This still seems to be an issue in the latest Ubuntu 13.04 release. Because of this issue we have to disable OpenGL support in our application for Sandybridge and Ivybridge chipsets. Our application is a video security application that displays anywhere from 1 to 30+ cameras at a time. Each camera uses its own independent GLXDrawable hence the frequent calls to glxMakeCurrent/glxMakeContextCurrent.

If there is any more info I can provide please let me know. Here is the latest version/package information I used when testing with Ubuntu 13.04.

uname -a
Linux exacq-desktop 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:36:13 UTC 2013 i686 i686 i686 GNU/Linux

glxinfo
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop x86/MMX/SSE2
OpenGL version string: 3.0 Mesa 9.1.1
OpenGL shading language version string: 1.30

Xorg -version
X.Org X Server 1.13.3
Release Date: 2013-03-07
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-37-generic i686 Ubuntu
Current Operating System: Linux exacq-desktop 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:36:13 UTC 2013 i686
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-19-generic root=UUID=b2a8e0f0-e720-450f-97d1-850243e167c1 ro quiet splash vt.handoff=7
Build Date: 17 April 2013  10:42:56PM
xorg-server 2:1.13.3-0ubuntu6 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.28.2
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.

xserver-xorg-video-intel (2:2.21.6-0ubuntu4)

OK, I reproduced the problem using the simple testcase from comment 6.  Note: vblank mode default of enabled is needed to really see the problem, as makecurrent-spam/xorg cpu usage goes from 10%/5% to 30%/10% to 55%/15% over the course of  a couple of minutes.  I think what's happening is DRI2DestroyDrawable is not being called from the client because of mesa commit:

commit 4ebf07a426771b62123e5fcb5a8be0de24037af1
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Mon Sep 13 08:39:42 2010 -0400

    glx: Don't destroy DRI2 drawables for legacy glx drawables

But even if you revert that, your drawables don't get freed because of server commit:

commit 1da1f33f2dd5b437dd56cd9f5d6782de4ad5a1bc
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Fri Apr 16 05:55:34 2010 -0400

    DRI2: Track DRI2 drawables as resources, not privates

in which DRI2DestroyDrawable is turned into a no-op stub.  The result is the server keeps getting more and more DRI2Drawables associated with the X drawable as we create and "destroy" them, so the reference_list keeps growing and grown, and the client gets a thundering herd of invalidate events on every swap.

*** Bug 99347 has been marked as a duplicate of this bug. ***

The invalidate event storms are easily reproducible with recent versions of plasma 5 plasmashell (e.g. version 5.8.5)

uname -a
Linux localhost 4.9.3-desktop-1.mga6 #1 SMP Thu Jan 12 23:02:31 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

glxinfo
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 6000 (Broadwell GT3) 
OpenGL version string: 3.0 Mesa 13.0.3
OpenGL shading language version string: 1.30

Xorg -version
X.Org X Server 1.19.0
Release Date: 2016-11-15
X Protocol Version 11, Revision 0
Build Date: 10 January 2017  12:05:11AM
Build ID: x11-server 1.19.0-9.mga6 
Current version of pixman: 0.34.0

-- 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/xorg/xserver/issues/207.