-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
| On Fri, 2008-06-13 at 13:18 +0300, Timo Jyrinki wrote:
|> 2008/6/12 Eric Anholt <[EMAIL PROTECTED]>:
|>> I'm really having a hard time caring until someone comes up with
|>> something other than a microbenchmark that has issues wit
On Fri, 2008-06-13 at 13:18 +0300, Timo Jyrinki wrote:
> 2008/6/12 Eric Anholt <[EMAIL PROTECTED]>:
> > I'm really having a hard time caring until someone comes up with
> > something other than a microbenchmark that has issues with teximage
> > performance.
>
> I'm not sure if it's about teximage
On Thu, 2008-06-12 at 17:44 +0200, Thomas Hellström wrote:
> Eric Anholt wrote:
> > We're getting close to ready to mark GEM on Intel as done. We've got
> > one failing testcase that we isolated this week with interrupt handling,
> > and we've got a fix in testing that appears to be doing the job.
> 2008/6/12 Eric Anholt <[EMAIL PROTECTED]>:
>
>> I'm really having a hard time caring until someone comes up with
>> something other than a microbenchmark that has issues with teximage
>> performance.
>>
Is there a single CPU-bound app using GEM that comes even near the
performance of i9
2008/6/12 Eric Anholt <[EMAIL PROTECTED]>:
> I'm really having a hard time caring until someone comes up with
> something other than a microbenchmark that has issues with teximage
> performance.
I'm not sure if it's about teximage performance, but try (whoever
interested) rotating a cube in compiz
Keith Whitwell wrote:
>> If this was a test of just two memory manager implementations, the
>> benchmarks would speak for themselves. However, there are at least two
>> driver changes I caught on first review of gallium-i915-current's
>> i915simple (which I assume is what you were testing, given t
> If this was a test of just two memory manager implementations, the
> benchmarks would speak for themselves. However, there are at least two
> driver changes I caught on first review of gallium-i915-current's
> i915simple (which I assume is what you were testing, given that the last
> tests I've
Dave Airlie wrote:
>> However so far I can't get glxgears on TTM to not flicker as do all my
>> other apps. Am I missing something?
>>
>> Granted my gears numbers are better with TTM, but the flicker does leave
>> me to think something broke.
>>
>
> Ah keithp pointed out single buffered rend
>
> However so far I can't get glxgears on TTM to not flicker as do all my
> other apps. Am I missing something?
>
> Granted my gears numbers are better with TTM, but the flicker does leave
> me to think something broke.
Ah keithp pointed out single buffered rendering due to visual failure.
I
> *GEARS* (Should be GPU bound)
> i915tex (TTM):1035fps @ 70% CPU
> GEM, no buffer reuse: 863fps @ 95% CPU
> GEM, buffer reuse: 1000fps @ 80% CPU
> Unichrome CX700 1009fps @ 70% CPU
So just to try and do some testing off my own, I can't get TTM code from
i91
On Thu, 2008-06-12 at 17:17 +0200, Thomas Hellström wrote:
> Eric Anholt wrote:
> > We're getting close to ready to mark GEM on Intel as done. We've got
> > one failing testcase that we isolated this week with interrupt handling,
> > and we've got a fix in testing that appears to be doing the job.
Keith Packard wrote:
> On Thu, 2008-06-12 at 16:06 +0100, Johannes Engel wrote:
>
>> Quoting He, Shuang:
>>
>>> You may need to build mesa with --enable-ttm-api, and update drm
>>> kernel modules as well whose source is under drm/linux-core,
>>>
>> Thanks for your hint, I had that s
On Thu, 2008-06-12 at 16:06 +0100, Johannes Engel wrote:
> Quoting He, Shuang:
> > You may need to build mesa with --enable-ttm-api, and update drm
> > kernel modules as well whose source is under drm/linux-core,
> Thanks for your hint, I had that symbol already enabled. Once I enabled
> ttm-api
He, Shuang wrote:
> Johannes Engel ??:
>> Quoting Eric Anholt:
>>
>>> We're getting close to ready to mark GEM on Intel as done. We've got
>>> one failing testcase that we isolated this week with interrupt handling,
>>> and we've got a fix in testing that appears to be doing the job.
>>>
>>> To
Eric Anholt wrote:
>
> Please clarify which commits of which branches were used in the test,
> along with which kernel version.
>
> I can't really analyze your results, which differ significantly from
> ours, without that.
>
>
Sure.
I'm using the drm-gem branches of mesa, drm and xf86-video-inte
Eric Anholt wrote:
> We're getting close to ready to mark GEM on Intel as done. We've got
> one failing testcase that we isolated this week with interrupt handling,
> and we've got a fix in testing that appears to be doing the job.
>
> Tomorrow I'm planning on merging the GEM code to master of all
Eric Anholt wrote:
> 2) Remove the existing TTM userland API.
> Dave Airlie has requested this as it's expected that if the TTM kernel
> implementation ends up being used by an open-source driver, it'll be
> under device-specific ioctls. This means things in installed *.h that
> are TTM-specific,
Eric Anholt wrote:
> We're getting close to ready to mark GEM on Intel as done. We've got
> one failing testcase that we isolated this week with interrupt handling,
> and we've got a fix in testing that appears to be doing the job.
>
> Tomorrow I'm planning on merging the GEM code to master of all
Quoting He, Shuang:
> You may need to build mesa with --enable-ttm-api, and update drm
> kernel modules as well whose source is under drm/linux-core,
Thanks for your hint, I had that symbol already enabled. Once I enabled
ttm-api in Mesa I get the following (of course after recompiling xserver
a
Johannes Engel ??:
> Quoting Eric Anholt:
>
>> We're getting close to ready to mark GEM on Intel as done. We've got
>> one failing testcase that we isolated this week with interrupt handling,
>> and we've got a fix in testing that appears to be doing the job.
>>
>> Tomorrow I'm planning on merg
Quoting Eric Anholt:
> We're getting close to ready to mark GEM on Intel as done. We've got
> one failing testcase that we isolated this week with interrupt handling,
> and we've got a fix in testing that appears to be doing the job.
>
> Tomorrow I'm planning on merging the GEM code to master of a
We're getting close to ready to mark GEM on Intel as done. We've got
one failing testcase that we isolated this week with interrupt handling,
and we've got a fix in testing that appears to be doing the job.
Tomorrow I'm planning on merging the GEM code to master of all 3
repositories. At that po
22 matches
Mail list logo
