How to troubleshoot intel 3D performance?

[Alex Bennee]

2009/2/17 Alex Bennee <kernel-hacker at bennee.com>:
> 2009/2/17 Colin Guthrie <gmane at colin.guthr.ie>:
>> 'Twas brillig, and Vasily Khoruzhick at 17/02/09 09:05 did gyre and gimble:
>>> On Tuesday 17 February 2009 10:12:56 you wrote:
>>>> Looking at the code it looks like a failure of the kernel side. Is
>>>> there a kernel tree that tracks the Linus one with the latest pending
>>>> fixes I can try?
>>>
>>> I suspect this one:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
>>
>> I believe the "drm-next" branch is usually the bleeding edge stuff fro
>> the next stable kernel (but I'm not 100% sure on this).
>
> I'll give that a spin.
>
> An additional data point, Dave Airle's tree (commit
> eaaffe54249d4444bb4de3631b9d968456bb0458) gave a slightly different
> error on start up:
> <snip>
> But that may well be because it went through a different call path
> still being EXA. I shall give the latest "official" intel tree a go
> and report back.

No I didn't. The intel tree is in the same state as Airle's tree (the
magic of git cherry told me so). So here is the attached full Xorg.log.0
for that tree with UXA enabled. The tiling errors are different but
the result is the same. Very poor 3D performance.

I stand ready to try any suggested patches.

Is it likely that the tiling stuff is responsible for the poor
performance or could it be a red hearing? I can have a poke around in
the code and see if anything stands out although reading the
xf86-intel-driver code tree I can see the error message but not by
what interface the request to the kernel is made.

--
Alex, homepage: http://www.bennee.com/~alex/
CV: http://www.bennee.com/~alex/cv.php
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: application/octet-stream
Size: 33309 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090217/19153801/attachment.obj>