[Intel N10 Graphics] Need Compiz' "Copy to Texture" plugin so can display on multi-head layouts bigger than the max GL texture size

I have a dell mini 9. It should be very similar CPU (if not the same) as the N10.
I updated it today.
Following that, I plug in an external monitor (max res 1280x1024) through a VGA cable. I was able to run Unity in these configuration:

laptop: 1024x600 external monitor: 800x600: no major issue to report. Unity works well.

laptop: 1024x600 external monitor: 832x624: no major issue to report. Unity works well.

laptop: 1024x600 external monitor: 1024x768: starting to see some empty regions on the external monitor (black). Probably the limited video memory of the dell mini 9 is kicking in...

laptop: 1024x600 external monitor: 1152x864: unusable

My dell mini 9 system only has 1 GigaByte of RAM so it is possible that past a certain resolution, the system can't handle an external monitor correctly. It is also likely that the driver doesn't provide much help either...

However, I couldn't reproduce the bug as reported here. From the picture of the bug, it looks like the system is trying to drive an HD monitor; probably one with an even higher resolution than my external monitor. So, I wonder if the system has enough RAM for that. Even if it does, we can't be certain how that RAM it is allocated (between the GPU and the CPU).

 - Is it possible to know the details of that particular system (in the picture): how much RAM does it has?
 - What is the resolution of the external monitor?
 - Is it possible to lower the external monitor resolution when setting up a multi-monitor configuration?
 - Does the problem shown in the picture still occurs when the external monitor resolution is at its lowest?

Hi Jay,

As with other systems exhibiting this problem, I retested this with the Oneiric image from 20110823. Rather than the corruption as reported by Jeff, on the external screen I see a black background and only the panel, while the internal screen shows some ghosting of windows and is sluggish/unresponsive. Bug 807161has a more detailed description and pictures.

It seems to me that once the Compiz problem out of the way, we hit that other bug again. Also see bug 790824 for a more technical discussion of this behavior.

To answer your questions:

- Is it possible to know the details of that particular system (in the picture): how much RAM does it has?

I can give you any details you need on the Inspiron Mini 1018 which had the same behavior as Jeff described. This has 1 GB RAM. Please let me know if you need any more data.

 - What is the resolution of the external monitor?

Native 1280x1024.

 - Is it possible to lower the external monitor resolution when setting up a multi-monitor configuration?

Yes :) This is best done by opening a terminal prior to plugging in the external screen and using xrandr to switch modes, as once the external is plugged in, things are too sluggish to use the GUI.

 - Does the problem shown in the picture still occurs when the external monitor resolution is at its lowest?

The internal display has 1024x600 resolution. I found that I can bring the external display from 640x480 all the way to 1024x768 and things continue to work fine. The first resolution that fails is 1152x864. At the default resolution for the external monitor (1280x1024) things also don't work.

By the way, I also tried and reported on this under Maverick and Natty for bug 807161 (see comment #9), where the findings were similar: at a low enough resolution, the external display works fine.

Thanks for all your help!

I talked with Jay yesterday, and he is going to try to find a way to setting a limit to resolutions via software

There seems to have been some changes in the monitor display setting. As of today if I plug in an external monitor into my Dell mini 9, the monitor display settings no longer shows all supported resolutions of the external monitor. It shows only 800x600 and 1024x768. My external display support up to 1280x1024.

I am not sure if this is a new development from the driver in order to reduce the external resolution to something that can be handle properly by the dell mini 9 GPU.

Can you report if you are getting the same thing on your N10 systems?

Same. Is this still an active issue or an instllation problem?

What do you mean? I still see this in the latest Natty.

Hi,

I tried this on the Dell Inspiron Mini 1018 with N10 chipset, using the Oneiric image from 20110906. I'm still seeing the same faulty behavior :(

Unlike Jay (comment #5), when I plug in the external display the system tries to drive it at 1280x1024 (native resolution), resulting in sluggishness as originally reported.

Also if I go into the displays control panel, I can see all resolutions for the external monitor, from 640x480 up to 1280x1024.

I'll mark as Triaged again. Thanks!

Ok, so this sounds like an another HW limitation problem, where the addition of a second head prevents the chipset to drive all screens that the initial resolution and results in poor results.

Intrisically it is a driver bug: the driver shouldn't force the HW to go beyond its limits. Either it should lower the resolution forcefully, or disable support for the 2nd head.

Okay, then I added it affecting the Intel X driver.

Adding the Desktop Team to have a look at this to see if this is indeed an issue in x-x-v-intel

This cannot be usefully handled as a driver bug; the hardware is perfectly capable of running at that resoluton. The driver cannot know that you're going to try to use a GL compositor that doesn't handle running at resolutions greater than the maximum GL texture size.

This is either a compiz bug or a unity bug. Didn't compiz grow support for running at > max_gl_texture_size this cycle? That would be slower (I'm not sure how much slower) but shouldn't fail. There might be mesa bugs causing that to be slower than it has to be, but that doesn't seem to be this bug.

This situation should no longer be easy to trigger - as a workaround for Oneiric we've disallowed setting a broken setup in gnome-desktop's RANDR code (see bug #824099).

Users could still manually set a broken mode with the xrandr commandline tool, but GNOME should no longer automatically set a broken mode, and will not allow the GUI tools to set a broken mode.

Per discussion with DX team on IRC
<smspillaz> jibel: that looks like a driver bug to me
<smspillaz> hrm
<smspillaz> jibel: mark it a dupe of that max gl texture size bug
* Saviq|lunch is now known as Saviq
<smspillaz> there's a plugin I can enable to work around that problem but we can't enable new plugins for O
* tseliot1 has quit (Leaving.)
<jibel> smspillaz, ok, so that's a won't fix for O and I target to P. I won't mark it as dupe of 824099 because its purpose was to split 824099 with a bug per driver.

Could anyone confirm that Chris's fix improved the situation.

Hi!

I'm testing this fix (actually the one for 824099) on a couple of N10-based systems (Dell Latitude 2110 and Dell Inspiron Mini 1018).

Native panel resolution is 1366x768 on the Latitude 2110 and 1024x600 on the Mini 1018.

When I plug in the external monitor, it doesn't get activated automatically. I need to go into the "displays" panel and set it to "On". The external monitor is 1280x1024. As expected, if I just click "Apply", I get a dialog asking me to arrange things so they fit within 2048x2048 or use Ubuntu 2d.

If I make things fit within the required resolution (either by reducing resolutions or by arranging the display, for instance, vertically so the total resolution is 1024x1624) things work well, the second display gets activated correctly and performance is good, no sluggishness or crashes.

On the Latitude 2110 I can't bring the external display resolution low enough for a side-by-side arrangement (lowest allowable is 800x600, so on the horizontal total resolution is 2166). But a vertical arrangement, even at 1280x1024 for the external display (total display size is 1366x1792) works fine.

I also tried rotating the displays and as long as the resolutions fit within the 2048x2048 box, everythinig works fine.

As for the software, these systems were installed from an image dated 20111003 and then dist-upgraded to the latest packages today.

Thanks for this fix!

may I say that crippling options so that we can't use external monitors at their native resolution is not a solution? the solution to this problem is breaking the desktop into tiles smaller than max texture size, doing compositing/transforms and then combining them afterwards for display (or something more clever someone who is an actual graphics programmer can come up with, this seems the most straightforward approach to me)

<rant>
and no, saying "screw you, get a real computer" is not a solution either; my Atom 570 netbook has plenty of power (dual core + HT => 4 virtual cores) in a small, cheap and light package, I'm not giving it up for a 4 kg 17 inch monster with the nvidia mobile card du jour (it also has a nvidia ION2 which eats about as much power as the rest of the system); it's sad that Intel chose to cripple both the video card (2048x2048 max texture size) and the CPU (can't address more than 2 GB of RAM -- maybe they have a thing for 2^11), but the former can be overcome by smart programmers and the latter by SSD (seek times approaching zero make swapping significantly less painful)
</rant>

On Tue, 2011-10-04 at 21:32 +0000, Sabin Iacob wrote:
> may I say that crippling options so that we can't use external monitors
> at their native resolution is not a solution?

You can use your external monitors at their native resolution. You just
can't use Unity 3D at the same time, because it's broken. Allowing you
to set a broken configuration is not an improvement.

> the solution to this
> problem is breaking the desktop into tiles smaller than max texture
> size, doing compositing/transforms and then combining them afterwards
> for display (or something more clever someone who is an actual graphics
> programmer can come up with, this seems the most straightforward
> approach to me)
>

This is indeed a correct solution, but not one that can be implemented
and tested in the 8 days before release. So, for Oneiric, we're going
to prevent you from setting a configuration that won't work. In P,
we'll fix compiz and unity so that this configuration will work.

>You can use your external monitors at their native resolution. You just
>can't use Unity 3D at the same time, because it's broken. Allowing you
>to set a broken configuration is not an improvement.

While I get that point, and I get that it's 8 days before release, dual monitor support is a pretty big feature and one of the largest complaints of linux distro's in general is difficultly in getting graphics drivers to cooperate with other features. This seems to work fine for me in Natty. This bug will probably prevent me (and I'd suspect quite a few others) from upgrading.

It doesn't (or shouldn't) work fine in Natty - the same limitations
should apply. Or, it might "work" by crashing Compiz which autospawns
Metacity, which doesn't have this limitation.

Unity2d will work fine.

My second monitor showed a big white and blue stripe down the middle and after a reboot a dithered screen with every other scan line blacked out.

The shocker of this incident is Wont Fix!!! Unbelievably unprofessional. The screen is the most important as it's your interface with the computer.

See attachment for what is happening.

This bug affects me in both Natty and Oneiric.

00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge
00:02.0 PCI bridge: ATI Technologies Inc RS480 PCI-X Root Port
00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller
00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 10)
00:14.1 IDE interface: ATI Technologies Inc IXP SB400 IDE Controller
00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge
00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge
00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 01)
00:14.6 Modem: ATI Technologies Inc SB400 AC'97 Modem Controller (rev 01)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X700 (PCIE)
02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
02:04.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
02:04.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 04)
02:09.0 Network controller: Ralink corp. RT2800 802.11n PCI

processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 36
model name : AMD Turion(tm) 64 Mobile Technology MT-37
stepping : 2
cpu MHz : 800.000
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up rep_good nopl pni lahf_lm
bogomips : 1591.55
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

Removing the blocks-hwcert tag, as this bug no longer blocks certification (we accepted the workaround)

Seen with Sam: the configuration key needs to be updated to enable the plugin by default

David, can we know why this plugin wasn't enabled previously by default then (as it seems to only do that)?
Are we sure we won't hit performance issues with it enabled?

Please, assign it back to me when you can answer my question. Poked three times on IRC.

1. Performance issues will not be hit, the plugin only kicks in when tfp binding fails (eg, more than max texture sizE)
2. We need to fix the framebuffer object capture code to allow for multiple texture bindings too.

The code for this plugin had not been thoroughly tested and enabling it without enough user feedback was considered risky. There were a lot of compiz issues at the time. This one had a lower priority unfortunately.

Sam confirms btw that there is no pre-requisite for this plugin. The easiest solution to validate it before the change is committed is for user of N10 systems to activate and confirm that the plugin does allow them to drive a multi-head setup.

How is the plugin tested? Is Precise version of Ubuntu needed?

David, we have a lot of N10 systems ready to test the fix.

Can you provide some guidelines on how to do show, please?

To verify that the plugin works:
1. Call 'ccsm' on the command line to load the configuration tool, look for 'texture' and you should see the 'Copy to texture' plugin
2. Enable the plugin
3. Restart your session

Now, to verify that multi-head works you will need to use the 'xrandr' command as mentioned by Chris in comment #13

re Ara, David and others; if I understand the situation:

  1. Hardware has a max texture target of 2048x2048.
  2. 1024 wide (internal) + 1280 wide (external) > 2048; so Unity 3D fails, Unity 2D works; error message shown
  3. 600 high (internal) + 1024 high (external) <= 2048; so Unity 3D works, Unity 2D works. Nothing shown
  4. On *some* N10 systems, somehow the machine ends up setting/enabling the impossible (2) situation, without warning

Two questions:

  a. Is the summary above correct?
  b. If so, how to cause (4) reliably?

NB: While enabling the copy to texture plugin on the compiz side of things will allow compiz to work correctly on its own, unity and nux do not have code to handle splitting up textures and drawing them individually, ensuring that they do not exceed GL_MAX_TEXTURE_SIZE .

This means that you'll be able to run compiz on its own, but it is likely that drawing past any dimention which is larger than the maximum texture size that unity does will fail. This means that full-screen effects such as full-screen blur will not work correctly. There isn't code in unity in place at the moment to disable such effects in this case - please use CompizConfig Settings Manager to disable the Dash blur before testing monitor add / remove.

That being said, all of unity's widgets are done per-monitor, and unless the actual monitor dimentions are larger than GL_MAX_TEXTURE_SIZE itself, then it isn't likely that this limit will be hit.

You can query the maximum texture size by doing

glxinfo -l | grep GL_MAX_TEXTURE_SIZE

Which will return a single value for how large the screen space can be in any one direction. Any window that draws a desktop window shared over both monitors (I believe nautilus does this) will request a backing pixmap that large. Else - you can test this by resizing a window to be so large that it exceeds that size (check the dimentions with xwininfo)

Hi,

To test the "copy to texture" fix I did this:

- Installed Precise on a Dell Inspiron Mini 1018 with N10 chipset.
- Installed all updates (dist-upgrade) and ccsm.
- Fired up ccsm, enabled "copy to texture" plugin.
- Rebooted the system
- Re-checked that "copy to texture" is enabled in ccsm
- Plugged in external monitor.
- xrandr --output VGA1 --mode 1680x1050

Instead of two horizontal desktops, they were "overlapped"; on the large monitor, the top left, 1024x600 area was a "mirror" of what I was seeing on the laptop's internal screen. Performance is good with no lagginess.

I fired up the "displays" applet and tried to move the screens to be side-by-side (closer to what a normal user would do). Of course, the display applet complained about resolutions, so I brought the external down to 800x600.

With the monitors arranged like this, I tried again using xrandr to set VGA1 to 1680x1050.

When I did this, both displays got "corrupted" showing garbled, vaguely-horizontal bands. If I try to type something on the opened terminal window, it eventually refreshes and shows correctly, but the rest of the display(s) continues to be garbled. Also, display is extremely laggy, stuff I type takes about 3 seconds to appear on screen.

If I bring the external screen back down to 800x600 it all works fine again.

So this is still apparently not working for this use case :( Let me know if I can do further testing or if some of the steps I followed are wrong.

Thanks for working on this!

On Thu, 2012-01-19 at 22:23 +0000, Daniel Manrique wrote:
> Hi,
>
> To test the "copy to texture" fix I did this:
>
> - Installed Precise on a Dell Inspiron Mini 1018 with N10 chipset.
> - Installed all updates (dist-upgrade) and ccsm.
> - Fired up ccsm, enabled "copy to texture" plugin.
> - Rebooted the system
> - Re-checked that "copy to texture" is enabled in ccsm
> - Plugged in external monitor.
> - xrandr --output VGA1 --mode 1680x1050

Running “xrandr --output VGA1 --right-of LVDS1” would have done the
trick here. By default, all outputs share the same origin until
specified otherwise.

Hello Ara, or anyone else affected,

Accepted unity into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Please ignore the previous comment, wrong bug.

Hi Chris,

Just for kicks I tried

xrandr --output VGA1 --mode 1680x1050 --right-of LVDS1

results were the same as reported on comment #33.

compiz release got delayed, moving milestone.

I have tested with a Dell mini 9 hooked on an external 1600x1200 monitor.

The display resolution of the dell mini 9 is 1204x600

When I use the gnome display setting and I try to set a configuration that is not supported (size is too high), I am being warned to choose a lower resolution for the external monitor. For a system, like the Dell mini 9, this works fine as I can't expect such a system to have the resources to drive Unity on an external monitor with 1600x1200 resolution.

I then used xrandr to configure the displays. With xrandr i got similar results as mentioned in #33. I could get Unity to work with xrandr provided the external display resolution isn't too high. Xrandr worked fine for an external resolution of 1024x768. For an external resolution of 1152x864, the rendering of the display was very slow, which suggest a software mode. Note that gnome display setting prevent me from setting an external resolution of 1152x864.

From a user perspective, the preferred display configuration tool is the gnome display setting. From my experience, it produces the expected results.

As for using xrandr directly and activating the "Copy to Texture" plugin in Compiz, this solution cannot work with Unity for external resolution that are too high. As state in #32, it would only work fine with standalone Compiz. Unity has no support for the "Copy to Texture" plugin and cannot be expected to work.

I think the "Copy to Texture" plugin should be deactivated and users should use the gnome display setting as there preferred display setting tool.

Xrandr, does the job of configuring the display resolution. But without any knowledge of the desktop environment memory requirements it cannot check the ability of the system to support a certain resolution. Yet, it is very useful tool as a low level display configuration utility.

Why is this set to invalid/won't fix?

I don't see this behavior anymore in Precise, but instead a new bug #962217, which is the same with "Copy to Texture" enabled.

Why "won't fix"?

On my ASUS eeePC 1005P (Ubuntu 12.04, 3.2.0-24-generic) I can reproduce this bug. The internal display has 1024x600 resolution. I plugged in an external monitor (resolution: 1920x1080) and arranged it with gnome display setting horizontally. The result is the described slow display rendering. If I arrange the display vertically everything is fine.

Then I tried the same after activating the plugin ("Copy to texture") in ccsm. I restarted my mashine, arranged the window horizontally but the problem is still there. "xrandr --output VGA1 --right-of LVDS1" has the same effect.

$ glxinfo -l | grep GL_MAX_TEXTURE_SIZE
GL_MAX_TEXTURE_SIZE = 2048

@MrPotter

see your result "GL_MAX_TEXTURE_SIZE = 2048" now try to add 1024+1920 that's definitely more than 2048. So it is not supported by the hardware.