No dri (and therefore no compiz) for virtual screen greater than 2048x2048

Reported by Manuel Teira on 2007-09-29
266
This bug affects 19 people
Affects Status Importance Assigned to Milestone
Mesa
Fix Released
Wishlist
mesa (Ubuntu)
High
Unassigned
Declined for Intrepid by Timo Aaltonen
Jaunty
High
Unassigned

Bug Description

Scenario:

Toshiba L20 laptop, with builtin 1024x768 builtin LCD, Intel i915 graphics card.
External monitor of 1280x1024 resolution

Using the default configuration (after dpkg-reconfigure -phigh xserver-xorg):

mteira@sombra:~$ xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024
VGA disconnected (normal left inverted right)
LVDS connected 1024x768+0+0 (normal left inverted right) 304mm x 228mm
   1024x768 60.0*+
   800x600 60.3
   640x480 59.9
TV disconnected (normal left inverted right)

With this default configuration, the maximum width (1024) is not enough for a multimonitor mode using my two monitors (1024 + 1280), so, I changed my Display Screen subsection to:

        SubSection "Display"
                Modes "1024x768"
               Virtual 2304 1024
        EndSubSection

After this, I'm able to setup a multimonitor mode using randr, but DRI is no longer available. I'm getting this log:

(EE) intel(0): Cannot support DRI with frame buffer width > 2048.

So, no compiz, no google-earth, no fancy screensavers,...

I've found this thread where it seems that the coordinate registers for the 3D engine are only 11 bits:
http://lists.freedesktop.org/archives/xorg/2007-June/025501.html

BTW, I tested a hacked OSX version on this box some time ago, and it was able to operate Quartz Extreme with both screens at the same time without problems. Probably the screen/display design could be the problem? I find it frustrating, as with a relatively new graphics card I'm not able to use two monitors (with a not that high resolution) and hardware accelerated display at the same time.

[Workaround]
For now, you must not use a Virtual setting larger than 2048x2048 (or 1024x1024 on some chips, or 4096x4096 on some others) if you wish to use compiz. DRI simply isn't supported yet for virtual resolutions greater than that.

Bryce Harrington (bryce) wrote :

As Keith said in the aforementioned post, it is a limitation of the -intel driver and not likely to get fixed upstream.

Changed in xserver-xorg-video-intel:
importance: Undecided → Wishlist
status: New → Confirmed
Sam Peterson (peabodyenator) wrote :

Reading the readme for the driver states that this is a hardware limitation. I don't believe it's physically possible for the hardware to provide dri for any virtual resolution past 2048, meaning the driver never will support it.

Bryce Harrington (bryce) wrote :

Thanks Sam, closing as won't fix, since it's a limit of the hardware.

Changed in xserver-xorg-video-intel:
status: Confirmed → Won't Fix

So, the problem is the X architecture combined with that hardware limitation, since I'm able to have Quartz Extreme working on OSX in this machine, working with two monitors at the same time exceeding the 2048 resolution limit? Sadly to hear that this is not going to be fixed.

Jarno Suni (jarnos) wrote :

Manuel Teira, have you tried making a virtual desktop where the screens are one above other? Then you need only "Virtual 1280 1792". I tried it like that, but glxinfo tells me "direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)". How do you make such a setting? Which log told you "Cannot support DRI with frame buffer width > 2048"?

Zach (uid000) wrote :

This limitation exists on i945 as well. This is the graphics chipset in the 2nd gen Apple MacBook. The macbook has no problem with direct rendering at high resolutions in OS X, so this must be a limitation of the driver, at least on the 945. I'll open a new bug if this one can't be reopened.

sibidiba (sibidiba) wrote :

This is a limitation in the driver for all intel chipsets. ;(

http://www.thinkwiki.org/wiki/Xorg_RandR_1.2#the_Virtual_screen

Zach (uid000) wrote :

I agree. However, an important point it whether it is /just/ a driver limitation or a hardware limitation. I believe that, at least for 945, it is just a driver limitation, which means that this bug should remain open, and we need to work with upstream to get it fixed.

El lun, 10-03-2008 a las 09:58 +0000, Jarno Suni escribió:
> Manuel Teira, have you tried making a virtual desktop where the screens
> are one above other? Then you need only "Virtual 1280 1792".
Yes, that works for me, but I'm not able to get used to that (since my
screens are stacked vertically and not horizontally).

> I tried it
> like that, but glxinfo tells me "direct rendering: No (If you want to
> find out why, try setting LIBGL_DEBUG=verbose)". How do you make such a
> setting?
For example, on a command line, type:
$ LIBGL_DEBUG=verbose glxinfo

> Which log told you "Cannot support DRI with frame buffer width
> > 2048"?
I guess it was in /var/log/Xorg.0.log
>

Ralf (ralf-kaestner) wrote :

any plan to incorporate the fix or is there any known 3rd party deb package already available?

Mika Fischer (zoop) wrote :

It apparently is a driver bug, at least for some intel chipsets, see comment #10.

Changed in xserver-xorg-video-intel:
status: Won't Fix → Confirmed
Ralf (ralf-kaestner) wrote :

got that, to make my question a bit more clear, as it was fixed upsteam, what is the plan to release a ubuntu deb including the fix, or, is there any (even beta) deb available already somewhere for testing. I would have the alternative to compile the latest upsteam version but hate doing things like that as it is a lot of work and makes my system "dirty" ;-) I could create my own deb but this would be even more work for me since I never did that.

So finally I know what I would have to do but I would like to decide if this is even necessary. if someone tells me this will be fixed earliest in 3 months I would probably start working on it, otherwise I would most likely just wait for the official ubuntu patch.

Mika Fischer (zoop) wrote :

Ralf, sorry, my comment was not meant for you but for the developers to explain why I reopened this bug :)

I suspect that you will have to wait for Intrepid for a fix or use unofficial packages (I don't know of any), sorry...

Maybe Bryce has some git versions packaged, but I don't know about that either...

Mika Fischer (zoop) wrote :

The fix for the intel X driver is here: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=4f5500abe209b92b39ae1f2d7a1118362ac95034

But Mesa/DRI also needs to be fixed accordingly. See the following response by Keith Packard:
> Any ideas? Do I need other patches, too?

Yeah, but you'll be limited to 4096 pixels -- Mesa can't go beyond that.

Here's what I tried:

diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_c!
index 1601f6d..c06f5da 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -138,10 +138,10 @@ GLboolean brwCreateContext( const __GLcontextModes *mesaVis,
    /* Advertise the full hardware capabilities. The new memory
     * manager should cope much better with overload situations:
     */
- ctx->Const.MaxTextureLevels = 12;
+ ctx->Const.MaxTextureLevels = 13;
    ctx->Const.Max3DTextureLevels = 9;
    ctx->Const.MaxCubeTextureLevels = 12;
- ctx->Const.MaxTextureRectSize = (1<<11);
+ ctx->Const.MaxTextureRectSize = (1<<12);
    ctx->Const.MaxTextureUnits = BRW_MAX_TEX_UNIT;

 /* ctx->Const.MaxNativeVertexProgramTemps = 32; */

I suspect the 3DTextureLevels and CubeTextureLevels need frobbing as
well, but I didn't try to figure out what the right values might be.

Mika Fischer (zoop) wrote :
Mika Fischer (zoop) wrote :

And BTW, I'd also like someone to raise the importance on this bug, since at leat for 965 it is definitely not a wishlist bug, bug a very real bug which provents people from using Compiz in most dual-head scenarios.

Marius Gedminas (mgedmin) wrote :

Confirming: after applying the two patches Mika Fischer mentioned to xorg-xserver-video-intel and mesa in Hardy, I can use a dual-head desktop larger than 2048x2048 and Compiz works with no problems.

When applying the fixes on a 965 laptop (HP 6710b), I get graphical errors when trying dual head mode. There are parts of the screen that don't update, and sometimes when I change from --left-of to --right-of for example, the screens can get scrambled in bad ways. If you want me to try to explain this further please ask!

Marius Gedminas (mgedmin) wrote :

Kieran: Compiz sometimes gets very confused after an xrandr change. Alt-F2 "compiz --replace" usually fixes the problem. It's a different bug (but I don't have a handy bookmark right now).

Thanks, that fixes it.
The compiz bug looks like #218000

CDM (durward-his) wrote :

My laptop has a i945GM chipset. I understand the hardware limit leading
to no DRI with width or height > 2048, but I still don't understand why
things got worse when I upgraded to Ubuntu 8.04 from 7.10. What
magic do I have to put in xorg.conf to get, e.g., firefox scrolling to
be decent again? Thanks for any advice.

CDM (durward-his) wrote :

Nothing like posting a question in a public forum to get you to find the
(obvious) answer yourself. In xorg.conf, I replaced
Option "AccelMethod" "exa"
with
Option "AccelMethod" "xaa"
and now everything is speedy again. I'm not clear on what I'm losing
by doing this, but I don't do anything that pushes the graphics too far.

Bryce Harrington (bryce) wrote :

Thanks, we've got the newer -intel in Intrepid with this, but it looks like the patch isn't in mesa-7.1~rc3. If it's not included in the final release we should consider carrying it as a Ubuntu patch.

Changed in xserver-xorg-video-intel:
assignee: nobody → bryceharrington
importance: Wishlist → High
status: Confirmed → In Progress
Jon Dowland (jond) wrote :

Mesa 7.1 has now been released. I'm not sure whether the patch has gone in or not.

Marius Gedminas (mgedmin) wrote :

I just looked at the sources: Mesa 7.1 does not have the patch to src/mesa/drivers/dri/i965/brw_context.c applied.

What's the status on that? I see Intrepid carries Mesa 7.2, but as far as I see, the file brw_context.c (upstream) is still as it used to be. Does this set the limit to 2048 or 4096?

Alberto Milone (albertomilone) wrote :

Alexander: Mesa is limited to 4096 pixels, however your hardware might not support 4096.

What's the output of this commad?
glxinfo -l | grep GL_MAX_TEXTURE_SIZE

Chow Loong Jin (hyperair) wrote :

I'm using Intrepid on a Lenovo Y410 (Intel GM965 GPU), but glxinfo -l | grep GL_MAX_TEXTURE_SIZE shows 2048. What's with that?

Alberto Milone (albertomilone) wrote :

hyperair: your limit is 2048 then. This means that DRI will be disabled if you set the framebuffer size to something higher or wider than 2048.

Alberto, my understanding was that chips 965 and above should be able to do more than 2048, provided the necessary patches are applied to video-intel and mesa. Is Intrepid lacking those patches then?

Nick Maynard (nick-maynard) wrote :

Alexander, my i965 box (running pre-release Intrepid) doesn't appear to have these patches, else I'd hope it would work!

nick@niagara:~$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)

nick@niagara:~$ glxinfo -l | grep GL_MAX_TEXTURE_SIZE
    GL_MAX_TEXTURE_SIZE = 2048

Bryce Harrington (bryce) wrote :

Yeah, mesa-7.2 did not include this. However, I'm uncomfortable including it without understanding it's potential consequences better. I think we should forward this upstream for comment, and try it for jaunty.

This is most noticeable when you're trying to use Compiz and a dual-head screen, where the desktop size exceeds 2048 pixels in at least one direction. The desktop window exceeds the Mesa texture limit and fails to draw.

Keith Packard floated a patch to increase the Mesa texture size limit to 4096x4096 on the xorg mailing list in April: http://lists.freedesktop.org/archives/xorg/2008-April/034707.html

With that patch applied I can use Compiz with dual-head.

The bug is also reported in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/146859

Mika's comment (#16) has a broken link. Here's the currently working link to Keith Packard's email that originated the mesa patch in question: http://lists.freedesktop.org/archives/xorg/2008-April/034707.html

Changed in mesa:
status: Unknown → Confirmed

After applying the fix above, I get graphics problems and extreme slowness when using any 3D program. I think it's very good to hold off for now!

Bryce Harrington (bryce) wrote :

Marius, thanks for reporting it upstream. We'll await their response.

I know there is tons and tons of work going on upstream related to this, and to performance with EXA. I know this is a top priority for them and so will get solved in hopefully good time. Likely, we don't want to get too aggressive at pulling in unofficial patches, and risk introducing instability. I'd be much more comfortable waiting until this fix is in an official release.

Changed in mesa:
assignee: bryceharrington → nobody

Tested this patch on Fedora 10 and seems to be working.

I'm seing all kind of issues when using compiz with the patch applied. It doesn't seem to be complete.

I don't read this patch in Mesa master and Q3 release. Is it missed? or there is another resolution for this.

any comment?

Stefan: what kind of issues? (I'd like to know what to look out for).
And do they occur directly after launching compiz or after a while?

So my question is regaurding the 945gm chipset. Does the hardware support > 2048 and if so are there patches, fixes planned to get it working??

Ralf (ralf-kaestner) wrote :

it works on a GM965/GL960 (00:02) with ubuntu 8.10 + the mesa patch above (comment 15) without any issues on my side.

I created a deb for libgl1-mesa-dri_7.2-1ubuntu2_i386 from source and added the patch.
The limit is now 4096x4096 where it was 2048x2048 before.

If you need help how to do that by yourself read http://sarth.thallos.org/2009/01/building-from-source-package-on-debian.html

As you can read above, others had issues with the same steps but on my side its fine.

Herbert V. Riedel (hvr) wrote :

just wanted to confirm, that rebuilding with the mentioned mesa-dri patch applied, seems to work fine on my DG35EC mainboard with integrated (multihead capable) G35 graphics controller and screen sizes larger than 2048x2048 :-)

00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)
        Subsystem: Intel Corporation Device d701
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at e0100000 (32-bit, non-prefetchable) [size=1M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 3410 [size=8]
        Capabilities: <access denied>

00:02.1 Display controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)
        Subsystem: Intel Corporation Device d701
        Flags: bus master, fast devsel, latency 0
        Memory at e0000000 (32-bit, non-prefetchable) [size=1M]
        Capabilities: <access denied>

The patch has been committed into mesa master, so I guess this bug can be closed?

Author: Keith Packard <email address hidden>
Date: Fri Jan 30 21:51:32 2009 -0800

i965: bump texture limit to 4kx4k

Rendering and textures are limited to 8kx8k, but mesa limits things to
4kx4k, and magic guard band stuff may break on 8kx8k drawing. This is safe
though, and makes compiz work on bigger screens.

(In reply to comment #5)
> The patch has been committed into mesa master, so I guess this bug can be
> closed?
>
> Author: Keith Packard <email address hidden>
> Date: Fri Jan 30 21:51:32 2009 -0800
>
> i965: bump texture limit to 4kx4k
>
> Rendering and textures are limited to 8kx8k, but mesa limits things to
> 4kx4k, and magic guard band stuff may break on 8kx8k drawing. This is safe
> though, and makes compiz work on bigger screens.
>

Gordon, the commit seems the same as http://lists.freedesktop.org/archives/xorg/2008-April/034707.html. However based on based on comment#2, Seems Stefan still has some problem with this patch.

Stefan, would you like to list the issues when you use compiz with this patch? It will be helpful for upstream to track what the side effect is?

Thanks

Yes, it's exactly the same patch I have used in the past, but disabled after all.
The issues were, that with compiz enabled changing resolution via RANDR 1.2 (xrandr, ...) weren't possible any longer at all or resulted in strange effects.
See https://bugzilla.novell.com/show_bug.cgi?id=441572 for more details. Unfortunately it contains a lot of confusing comments. :-(

Trying to follow that link to Novell's bug tracker redirects me to a login page.

I have the following issues with Compiz and xrandr:

  * Sometimes after you change the desktop size Compiz doesn't notice and renders only to a part of the area, keeping the rest filled with garbage. Sometimes it stops rendering at all, so you see the old picture (plus some garbage in new areas) and a moving mouse cursor. Alt+F2, compiz --replace, Enter fixes this.

  * Sometimes after I shrink the desktop size mesa crashes the X server with "Assertion `intel->batch->cliprect_mode != REFERENCES_CLIPRECTS' failed".

I never thought to attribute those problems to this patch. I suppose I could revert to pristine mesa and do some testing, if I can find the time.

Bryce Harrington (bryce) on 2009-02-10
description: updated
bamed (bamed) wrote :

The value reported by glxinfo is not accurate. Probably a bug in the driver. One ugly workaround that works is to edit /usr/bin/compiz and hard set the value of TEXTURE_LIMIT. So find the line:

        TEXTURE_LIMIT=$(glxinfo -l | grep GL_MAX_TEXTURE_SIZE | sed 's/.*=[^0-9]//g')

and change it to something like:

## Commented out to fix bug in driver
## TEXTURE_LIMIT=$(glxinfo -l | grep GL_MAX_TEXTURE_SIZE | sed 's/.*=[^0-9]//g')
             TEXTURE_LIMIT = 3000

Not pretty, but it works!

I think this bug should be closed as the fix against the original problem has been committed. The new issue (found by Stefan) should be filed as another bug.

This is fixed by:

commit 954dfba12986f578f2d8461818f9e9ac1f8f2b41
Author: Keith Packard <email address hidden>
Date: Fri Jan 30 21:51:32 2009 -0800

    i965: bump texture limit to 4kx4k

and

commit 88b702e8c47c8930940c396132b2a191d4a3e7ca
Author: Robert Ellison <papillo@i965-laptop.(none)>
Date: Fri Feb 13 15:19:04 2009 -0700

    i965: Eric Anholt's patch for bumping up texture sizes

One of the unrelated reports in here should be fixed by:

commit 73aa23d9150121a4e4b70a78cab910acd164abf5
Author: Eric Anholt <email address hidden>
Date: Fri Dec 5 13:06:05 2008 -0800

    DRI1: Update sarea (and other information) when CRTC configuration changes.

All other issues: go get your own bugreport.

Changed in mesa:
status: Confirmed → Fix Released

Would it work on 945?

On Sat, Mar 7, 2009 at 12:32 PM, Bug Watch Updater
<email address hidden> wrote:
> ** Changed in: mesa
>       Status: Confirmed => Fix Released

For which graphic cards will this work?

Shouldn't there be something done in the intel driver? xserver-xorg-video-intel?

--
 .
..: Lucian

Marius Gedminas (mgedmin) wrote :

As far as I know, Intel graphics older than the 965 do not support textures above 2048x2048.

The Intel driver supports textures larger than that on appropriate hardware already, and has done so for quite a while. Support in Mesa was the missing part, and has now been fixed upstream.

(In reply to comment #10)
> commit 73aa23d9150121a4e4b70a78cab910acd164abf5
> Author: Eric Anholt <email address hidden>
> Date: Fri Dec 5 13:06:05 2008 -0800
>
> DRI1: Update sarea (and other information) when CRTC configuration changes.

... which requires this fix:

commit dc12c4b3eb297b2f225409eacf1f3cd521453ab6
Author: Eric Anholt <email address hidden>
Date: Sat Mar 7 23:22:54 2009 -0800

    Flip the update_dri_buffers test around to only run when DRI1 is active.

    Fixes segfaults at startup with DRI2 and load detection, or with DRI
    disabled entirely.

BTW, both commits are from xf86-video-intel, the previous two from Mesa git.

Is that fixed with todays upload of mesa 7.4 to the jaunty repos? I see it has a patch that influences the max texture size.

Timo Aaltonen (tjaalton) wrote :

Should be fixed, yes.

Changed in mesa (Ubuntu Jaunty):
status: In Progress → Fix Released
Marius Gedminas (mgedmin) wrote :

Definitely fixed; I've used compiz on extended desktops larger than 2048x2048 in Jaunty with the standard packages.

Valentin Neacsu (bkraptor) wrote :

In Jaunty, as opposed to Intrepid, when setting a vritual desktop larger than 2048x2048 using 915GM, I get software renderer:
valentin@valentin-laptop:~$ glxinfo | grep renderer
OpenGL renderer string: Software Rasterizer

Using a virtual desktop size less or equal than 2048x2048 I get the normal renderer:
valentin@valentin-laptop:~$ glxinfo | grep renderer
OpenGL renderer string: Mesa DRI Intel(R) 915GM GEM 20090326 2009Q1 RC2 x86/MMX/SSE

Hope this is related and gets fixed, because it is preventing me from using my dual screen setup side-by-side.

unggnu (unggnu) wrote :

I915 only supports hardware acceleration to 2048x2048. This is a hardware limitation afaik so there will be no fix.

Valentin Neacsu (bkraptor) wrote :

I know it's a hardware limitation to 2048x2048 when using DRI, but what about when not using DRI? As I said, when I set a virtual desktop size greater than 2048x2048, the driver is switched to software renderer, as shown above. This was not happening in Intrepid.

lunomad (damon-metapaso) wrote :

My symptoms seem to have similar causes, but I'm not sure if this is the same bug.

I upgraded to the Jaunty RC on April 17, and had decent luck running DRI and UXA on a dual-screen Virtual 2944x1200.

X did crash every couple of hours, but while it ran, the performance was great, glxgears 1100+fps, smooth alt+tab switching, great cube switching.

On April 18, I upgraded to the mesa 7.4-0ubuntu3 packages (glx, libglu, dri, etc..), and compiz would not start. It complained about the MAX_TEXTURE_SIZE of 2048 and fell back to metacity.

When I downgraded to the mesa 7.4-0ubuntu2 packages, compiz worked fine. I did this upgrade/downgrade a few times to make sure.

So I just did bamed's TEXTURE_LIMIT=4096 hack above, but "glxinfo -l" also reports a
             GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 2048
which is what I assume is limiting how my right-hand screen handles redraws and the desktop cube.

lunomad—

7.4-0ubuntu3 backed out the patch that increased the texture size. See Bug#146298 and Bug#359392.

After reading all the queue bug I have a doubt:

Intel GM945, ubuntu Jaunty, 2 19" monitors of 1440x900 with a total of 2880x900.
It's actually possible with compiz?

Tested with default configuration of jaunty (pretty slow)- Don't work.
Tested with UXA and greedy - Don't work.
Tested with 2.4 intel driver - Don't work.

lunomad (damon-metapaso) wrote :

C Snover --

Thanks. I was following Bug#146298 but not Bug#359392. Somehow I missed the rollback on the 4096 patch.

I just want to throw in my data points on intel G45 (Asus P5Q-EM) hardware, dual monitors 1920x1200 & 1024x768

1. Intrepid with home-built mesa including the 4096 patch: stable for several months, EXA acceleration, compiz ok. glxgears 500-600.

2. Stock Jaunty + EXA. I've tried a couple of configurations with EXA and every time I get a "can't pin front buffer" error.

3. Stock Jaunty + UXA + NoDRI. Stable, but no compiz.

4. Stock Jaunty + UXA + Ludovico Cavedon's ppa https://edge.launchpad.net/~cavedon/+archive/ppa
Frequent and unpredictable lock-ups on X, otherwise great performance.

5. xorg-edgers ppa enabled + rebuilt DRI with MAX_TEXTURES=4096 patch.
Similar performance to #4. Awesome glxgears 1200+ but unpredictable lockups on X.

It's hard not to be frustrated when this was working so well on Intrepid, but hopefully it can be resolved soon. If I can do any testing, please let me know.

I only really like compiz for the grid plugin and the screenshot plugin. If these were available in metacity I'd be perfectly happy!

Hello,

I'm also interested in this bug, but I just wanted to point out that
you still can use compiz with your dual screen configuration if you
'put' one above the other instead of beside. I know it's a little
messy to work with, but at least it works:

 SubSection "Display"
  Virtual 1920 1978
 EndSubSection

On Tue, Apr 28, 2009 at 2:25 AM, lunomad <email address hidden> wrote:
> C Snover --
>
> Thanks.  I was following Bug#146298 but not Bug#359392.  Somehow I
> missed the rollback on the 4096 patch.
>
> I just want to throw in my data points on intel G45 (Asus P5Q-EM)
> hardware, dual monitors 1920x1200 & 1024x768
>
> 1. Intrepid with home-built mesa including the 4096 patch:  stable for
> several months, EXA acceleration, compiz ok.  glxgears 500-600.
>
> 2. Stock Jaunty + EXA.  I've tried a couple of configurations with EXA
> and every time I get a "can't pin front buffer" error.
>
> 3. Stock Jaunty + UXA + NoDRI.  Stable, but no compiz.
>
> 4.  Stock Jaunty + UXA + Ludovico Cavedon's ppa https://edge.launchpad.net/~cavedon/+archive/ppa
> Frequent and unpredictable lock-ups on X, otherwise great performance.
>
> 5. xorg-edgers ppa enabled + rebuilt DRI with MAX_TEXTURES=4096 patch.
> Similar performance to #4.  Awesome glxgears 1200+ but unpredictable lockups on X.
>
>
> It's hard not to be frustrated when this was working so well on Intrepid, but hopefully it can be resolved soon. If I can do any testing, please let me know.
>
> I only really like compiz for the grid plugin and the screenshot plugin.
> If these were available in metacity I'd be perfectly happy!
>
> --
> No dri (and therefore no compiz) for virtual screen greater than 2048x2048
> https://bugs.launchpad.net/bugs/146859
> You received this bug notification because you are a direct subscriber
> of the bug.
>

aporter (aporter) wrote :

Hi,

This Intel DRI limitation, whether it be hardware or driver, still exists in Jaunty and Karmic.

When I put two 1280x1024 monitors side-by-side, I see:
  (EE) intel(0): Cannot support DRI with frame buffer width > 2048.
  and glxinfo says software rendering
When I put them one-above-the-other, I get full 2d hardware rendering and glxinfo says Mesa DRI Intel.

My only question is this: If this is a hardware limitation, with the Intel chipset, why isn't this also a limitation in WinXP? Am I misunderstanding something? OSX is mentioned above in the same vein, but the question wasn't really answered. One of the other duplicates to this bug mentioned the absence of the limitation in windows (Bug #360713).

I've looked around on the web, and I think this limitation is possible to work around ( http://lists.freedesktop.org/pipermail/xorg/2008-June/036151.html mentions two frame-buffers).

Thanks.

DDDDD (dedieko) wrote :

I think this is a hardware limitation, except for I965 which has 8192x8192
MAX TEXTURE SIZE

To enable this, you need to patch Mesa DRI driver according to instruction
found in this blog:
http://soundmonster.wordpress.com/2009/02/17/dual-head-with-compiz-and-i965-on-ubuntu-intrepid/

On Wed, May 6, 2009 at 6:37 AM, aporter <email address hidden> wrote:

> Hi,
>
> This Intel DRI limitation, whether it be hardware or driver, still
> exists in Jaunty and Karmic.
>
> When I put two 1280x1024 monitors side-by-side, I see:
> (EE) intel(0): Cannot support DRI with frame buffer width > 2048.
> and glxinfo says software rendering
> When I put them one-above-the-other, I get full 2d hardware rendering and
> glxinfo says Mesa DRI Intel.
>
> My only question is this: If this is a hardware limitation, with the
> Intel chipset, why isn't this also a limitation in WinXP? Am I
> misunderstanding something? OSX is mentioned above in the same vein,
> but the question wasn't really answered. One of the other duplicates to
> this bug mentioned the absence of the limitation in windows (Bug
> #360713).
>
> I've looked around on the web, and I think this limitation is possible
> to work around (
> http://lists.freedesktop.org/pipermail/xorg/2008-June/036151.html
> mentions two frame-buffers).
>
> Thanks.
>
> --
> No dri (and therefore no compiz) for virtual screen greater than 2048x2048
> https://bugs.launchpad.net/bugs/146859
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Zach (uid000) wrote :

So far I have not seen an explanation for why thie i945 in the 2006 MacBook supports compositing and direct rendering in OS X, even at high virtual resolutions, when it can't in compiz. This is inconsistent with the "it's a hardware limitation" explanation.

Ferrix Hovi (ferrix) wrote :

Obviously the change that fixed this for me has been rolled back. I can confirm that it did not cause a hang on GM45 and I suggest that the patch would be restored conditionally for chips having no problem with it.

aporter (aporter) wrote :

DDDDD: you skipped my question. I realize many people think it's a hardware problem. But that's inconsistent with my experience in WinXP. Zach is basically saying the same thing except for OSX.

Should we re-tag this bug ticket? If there is a fix (the one that worked for Ferrix) that has been rolled back, then this ticket isn't "Fix Released", right?

Thank you,

Ferrix Hovi (ferrix) on 2009-05-06
Changed in mesa (Ubuntu Jaunty):
status: Fix Released → Confirmed
Ferrix Hovi (ferrix) wrote :

@aporter: I don't know where the rumors and hunches come from. It is true that I run out of memory before achieving 4096x4096 resolution but that results in a decent error message.

I have made the rolled back feature available in my PPA: https://launchpad.net/~ferrix/+archive/ppa

The patch is still available in the Ubuntu source package, it has just been commented out in the series file. The reason for the patch to have been disabled is Bug#359392 and there seems to be enough reason to have done so. Be sure to have the official packages available in case you face problems.

aporter (aporter) wrote :

@Ferrix: Hunches/rumors? "(EE) intel(0): Cannot support DRI with frame buffer width > 2048." That's not a hunch, it's an error. :)

Seriously though, I'm not sure what you mean. We are trying to describe a limitation. If it's a limitation in the hardware, then fine. We haven't seen anything that says it's a limitation in the hardware.

Thanks,

Martin Olsson (mnemo) wrote :

The comments in this bug are raising a range of different issues for different cards (DRI, UXA/EXA accel vs noaccel, different chipsets are what not). Lumping together a lot of issues mostly makes the bug reports messy and unusable. There is no point in posting further comments to _this_ particular bug.

Now, if anyone had better experience in a previous version of Ubuntu (better performance, better handling of dual screen etc), then we're dealing with a new regression for that hardware. In so, please use the command "ubuntu-bug xserver-xorg-video-intel" to file a _new_ bug report that deals with your issue on your chipset specifically.

As for the question about the hw/sw driver limitation.. Basically for gen3 hardware and earlier (that's 915/945 and older) there is a _hardware_ limitation, however, if you go to great lengths it's technically possible to circumvent that limitation using a software workaround. Doing so would likely incur a significant runtime performance penalty and it would also be a significant amount of work for very little gain compared to other potential efforts... that said, just as you point out, it can be done. The upstream developers have at this time, however, opted to prioritize things like UXA, KMS, DRI2 etc and have basically said they are unlikely to hack around the hw limitation. If someone is prepared to step up and create a driver capable of >2048 sized DRI for these 915/945 and older cards, we'd be happy to ship it of course but if there isn't anyone interested in implementing it there is no point in having a bug tracking it. Thanks.

Changed in mesa (Ubuntu Jaunty):
status: Confirmed → Fix Released

Martin, thanks for the explanation. I sure feel sorry for my not-so-old laptop with 945, but I know how it works in FOSS world...

PS It would be more honest to set the status to WONTFIX, wouldn't it?;)

I registered for this bug because of this problem on a X4500, which certainly does support larger textures but is artificially limited to 2048×2048. So this is still a problem for people with i965 and newer cards that do support large textures. See my comment #51.

Martin Olsson (mnemo) wrote :

@Sergey, there was originally a generic limitation in mesa for all chipset and that was fixed. I agree though that for 915/965 the status is sadly WONTFIX for the foreseeable future.

@C Snover, you're right. For that hardware you should not be seeing any limitations of this type at all. Please use the command "ubuntu-bug xserver-xorg-video-intel" to open a specific bug for your chipset.

Ferrix Hovi (ferrix) wrote :

I reopened a bug #372741 for GM45 which I marked as duplicate before.

On Wed, May 06, 2009 at 10:38:34PM -0000, Martin Olsson wrote:
> @Sergey, there was originally a generic limitation in mesa for all
> chipset and that was fixed. I agree though that for 915/965 the status
> is sadly WONTFIX for the foreseeable future.

Make that just 915. The 965 supports textures up to 8192x8192 in
hardware.

Marius Gedminas
--
C, n:
        A programming language that is sort of like Pascal except more like
        assembly except that it isn't very much like either one, or anything
        else. It is either the best language available to the art today, or
        it isn't.
                -- Ray Simard

Martin Olsson (mnemo) wrote :

You're right, I meant to say 915/945. The required texture support is definitely there for 965, Gx45 and later.

Henri Cook (ph8) wrote :

This problem affects me on Jaunty but I swear I had a virtual desktop working fine in Intrepid, I can get it working now but with the Software Renderer as previously reported and even scrolling down pages in Firefox is ridiculously jumpy.

The setup works fine in windows so it doesn't appear to be a hardware limitation, just a bad driver.

I'm using an Intel Corporation 82Q35 Express Integrated Graphics Controller - i'm not sure if that falls into an i965 category or any of the ones mentioned above?

lspci info ->

00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
 Subsystem: Intel Corporation Device 4f4a
 Flags: bus master, fast devsel, latency 0, IRQ 2297
 Memory at 90380000 (32-bit, non-prefetchable) [size=512K]
 I/O ports at 2488 [size=8]
 Memory at 80000000 (32-bit, prefetchable) [size=256M]
 Memory at 90200000 (32-bit, non-prefetchable) [size=1M]
 Capabilities: <access denied>

00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
 Subsystem: Intel Corporation Device 4f4a
 Flags: bus master, fast devsel, latency 0
 Memory at 90300000 (32-bit, non-prefetchable) [size=512K]
 Capabilities: <access denied>

-----------

Would really appreciate a fix for this, i'm already trying Ferrix's Mesa rebuild to no success :/

mjpelmear (mjpelmear) wrote :

Henri Cook:

I had the same "jumpy" issue when upgrading to Jaunty.

Fixed it using a solution from further up in comments-- adding Option "AccelMethod" "xaa" to my xorg.conf

I'm not sure what "xaa" does (I'll do some reading later today, 'cause I'm curious now) but it significantly improved my user experience (i945/GM).

Khalil (siddiqui) wrote :

Regarding Martin's post #62:

Forgive me if this is a dumb question, as I'm new around here -- you say there's a _hardware_ limitation with the i915/i945 cards and DRI at >2048. Why is it that WinXP can run DX9 quite satisfactorily on the same hardware? I'm running 2 monitors, 1900x1200 & 1600x1200, and playing around with dual-booting XP and Mint7. My XP extended desktop at 3520x1200 works beautifully. But when I boot up Mint7, using the latest kernel (2.6.31-rc6) and updated xorg-edgers drivers, I kiss acceleration goodbye above 2048. I'm trying really hard to make Mint my default environment at work, but I have to keep going back to XP because my second monitor, sitting blankly, is silently mocking me.

Thanks,
Khalil

Travis Watkins (amaranth) wrote :

Windows XP and OS X work around this hardware limitation, most likely by doing the same thing as the shatter work for Xorg. Basically it splits the screen into "shards" and renders them separately which works around the limitation. However, there is a still a lot of work that needs to be done for this to work in Xorg so I would not expect to see it any time soon. Maybe in a year or so at the rate it has been going so far.

Changed in mesa:
importance: Unknown → Wishlist
Changed in mesa:
importance: Wishlist → Unknown
Changed in mesa:
importance: Unknown → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.