Hi, using the latest intel drivers and mesa from git, with kernel 3.10.5, it looks like gen 3 in two screen configurations is broken again. But maybe, also unity has to do with it. In the past it was perfectly possible to use gen3 with two screens and unity, provided that the overall size taken by the two screen was within 2048x2048 pixels. In practice, this could often be achieved by putting the second screen above or below the main screen, since putting it on the side caused the virtual size to exceed the limits. Now, when the second screen is connected, unity happily puts it to the side of the main one, the graphics card limits are exceeded and the compositor and window manager dies. Weird enough, the applications survive and you can still see their windows, but obviously without decoration. Interestingly, using xrandr from command line to put the screens one above the other and restarting the compositor often works. Now I wonder where is the problem? Is it xrandr that fails to communicate the max overall size? (can it do so, btw?). Is it unity who ignores some information and puts the windows side to side?
Note... this means that many subnotebooks cannot be used anymore to give presentations, since the compositor dies when attaching the projector.
This is a unity issue, trying to use GL where GL shouldn't be used. The hardware is perfectly capable (in theory at least, you would run into bw limitations of the encoders first) of driving a single 4096x4096 pixel monitor. X will happily combine two such monitors for you (and accelerate the operations in hardware). To say GL struggles is an understatement.
Dear Chris, thank you for confirming that this is a unity issue. I will now try to propagate this info to the unity developers. Would be glad if you could provide a couple more details for the unity developers, assuming that they are willing to help. 1) Any clue why things mostly work when manually starting things with xrandr --output VGA1 --auto --above LVDS1 and do not work when unity auto-configures the external monitor or one manually configures it with xrandr --output VGA1 --auto --left-of LVDS1 that is approximately equivalent to what unity seems to be doing? 2) Any clue why when unity/compiz are doing autoconfigure the external monitor I get intel_do_flush_locked fail no space left on device
Unity can only create a fbo as large as GL supports, for gen2/3 this is 2048x2048. In theory, GL was hacked to allow 4096x4096 fbo by forcing software fallbacks. That however has been broken for a few years, and even when it supposedly worked it always resulted in rendering corruption. The current breakage has been reported to hard lock the machine in some cases. ENOSPC is reported when the command buffer submitted by userspace requires more video memory than is currently available. (The available memory is reduced by control structures and pinned surfaces such as the scanout which cannot be moved, and so the request must fit in around them.) INTEL_DEBUG=all will give a break down of what exactly failed. This is a bug in the GL driver.
I have submitted https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1209261. One more question... If I understand properly the bug is not only in unity, but also in mesa since the software fallbacks are broken. Is this the case? Should I open a bug on mesa on this? BTW, we all agree that unity tries to do too much GL and too much magic autoconfiguration. Indeed, if at the attach of a second screen it asked the user there would be no issue. However, how can unity know that it should not do what it does if xrandr reports a max virtual size of 4096x4096 from which it seems legitimate to put one screen on the side of the other? Is there some way for it to finding out that fbos are limited to 2048x2048?
xrandr actually reports that the maximum fb size is 32k by 32k because the hardware doesn't impose any such limitation on the fb. Individual CRTCs are pruned to fit in the 4096x4096 hw limit of the pipes (and modes are pruned in case they advertise a mode too large for an individual CRTC or too be able to fit into memory). All this can be hardware accelerated even though the 3D pipeline is limited to maximum coordinate values of 2048x2048 (most operations do not exceed 2048x2048 and those that do can be tiled). Unity however has to respect the GL limits, which I think at the moment report a maximum framebuffer size of 4096x4096. Leading to the hilarity you have discovered. I share the opinion of the GL team, that one should not use GL in any system critical component.
So, could an initial step in fixing this issue be to ask mesa developers to have GL report a maximum framebuffer size of 2048x2048 on gen3 instead of 4096x4096? If I understand correctly, with this unity might even refrain by itself from putting the two screens one to the side of the other. Or if it does not, the bug in unity would at least be undisputable. As is, unity developers (who apparently think it OK to put tons of GL in it that cannot be disabled) might say that unity is fine, because in the end it does something that the hardware advertises as legitimate...
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.