[directfb-dev] Re: [PATCH] Preliminary AGPONLY support

[Denis Oliver Kropp <dok@directfb.org>]

Quoting Ville Syrj?l? (syrjala@sci.fi):
> > Why shouldn't it be cacheable anymore?
> 
> To avoid some cache coherency problems I think. Or is that just for the
> normal mapping and not the AGP aperture?
> 
> Well I just tried with a simple app that just allocates some AGP memory,
> mallocs some normal memory and does memcpy()s a few times. Now the results
> are even worse than with Blit()
> 
> sys->agp: 90 MB/s
> agp->sys: 17 MB/s

That's because dfb_memcpy() is faster than memcpy().

> but if I change the AGP aperture mtrr to write-back I get:
> 
> sys->agp: 180 MB/s
> agp->sys: 150 MB/s
> 
> 
> Ok I just ripped mem2agpcpy() from mplayer and things got interesting.
> 
> write-combining:
> sys->agp: 390 MB/s
> agp->sys:  30 MB/s
> 
> write-back:
> sys->agp: 400 MB/s
> agp->sys: 370 MB/s
> 
> So with this optimized routine write-combining is almost as fast as
> write-back. I just tried with "uncachable" too and sys->agp went to 130
> MB/s and agp->sys reamined at 30 MB/s. So with write combining reads are
> uncacheable. No very nice at all. Some googling revealed some linux-kernel
> discussion about the very same thing. Apparently the AGP protocol requires
> this :(

I can't imagine that it's essential for framebuffer memory. Maybe command
buffers are only required to.

What's the performance of mem2agpcpy() for sys-sys, sys-vid and vid-sys
compared to dfb_memcpy()?

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH


-- 
Info:  To unsubscribe send a mail to listar@directfb.org with 
"unsubscribe directfb-dev" as subject.