DirectFB - Home of the pragmatist Roadmap

[directfb-dev] Re: [PATCH] Preliminary AGPONLY support
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Quoting Ville Syrj?l? (
> > 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 |
|                 |

                            Convergence GmbH

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

Home | Main Index | Thread Index / Development / Old Archives