Latest i810 driver

[Thomas Hellström]

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.
>
>   
Lukas,
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 
batch-buffers.

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.

/Thomas