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

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

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.

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

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.

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"?

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.

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

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

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
>

This is fixed upstream: http://lists.freedesktop.org/archives/xorg/2008-April/034573.html (at least for 965)

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

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

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.

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...

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.

Here's his response in the archive: http://lists.freedesktop.org/archives/xorg/2008-April/034960.html

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.

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!

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

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.

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.

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.

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

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?

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

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?

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?

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

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.

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

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!

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.

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??

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.

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 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!

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

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.

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.

Should be fixed, yes.

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

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.

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

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.

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.

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.
>

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.

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.
>

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.

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.

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,

@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.

@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,

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.

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.

@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.

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

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

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 :/

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).

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

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.