Latest i810 driver

Thomas Hellström thomas at
Wed Feb 7 03:36:29 PST 2007

Lukas Hejtmanek wrote:
> On Wed, Feb 07, 2007 at 09:29:29AM +0100, Thomas Hellström wrote:
>> OK, this is how it works.
>> On startup, the DRM memory manager reserves a small portion (32MB) of 
>> AGP aperture space to work. The rest is allowed for "VideoRam". If  
>> "VideoRam" is set to something very large, the DRM memory manager setup 
>> code backs off, and disables if too little AGP aperture space is 
>> available. It will also back off if needed to make room for tiling.
>> In the first case, Potential videoRam is set to the whole aperture, and 
>> the DRM memory manager is disabled.
>> In the second case, the DRM memory manager is OK, but probably the 
>> driver doesn't set up tiling correctly since you have performance 
>> problems. You need to look at the xorg log to check this.
>> The problem is really that by default, potential videoram is set to the 
>> whole aperture space instead of the whole aperture space minus what's 
>> needed for DRM, (pI830->mmSize). The problem doesn't occur in 
>> xf86-video-intel master because potential videoram is limited there so 
>> whatever changed in this area between master and the branch you're using 
>> (modesetting ?) is causing the problem. It should IMHO be changed to be 
>> less greedy when determining potential videoram size.
>> In the end we should have a unified allocator that allocates Video 
>> memory from the DRM manager if available or from xf86 AGP if not. 
>> Something we're working on.
>> In your specific case, with a 256MB AGP aperture, I'd set VideoRam to 
>> (256 - 32) * 1024, that is 229376 (or slightly less) and hopefully you 
>> should be OK with performance again.
> I did it. But no performance boost. However, it looks like an issue in Mesa as
> older mesa libs pose lower CPU load. 
> I'm using modesetting branch. Anyway, my log file is attached.
The log looks OK, but the modesetting branch default potential VRAM size 
should really be fixed.

I also had an ancient version (don't know which) of Mesa which performed 
much better with glxgears than the i915tex when I compiled a recent mesa 
it turned out that i915tex is faster than i915, mainly due to larger 

So there is an ancient Mesa, the i915 driver of which is faster than 
current on glxgears. I didn't see much difference in other applications, 
though, and I'm not sure what may be causing it.


More information about the xorg mailing list