Keith Packard wrote:
On Fri, 2007-12-21 at 13:21 +0100, Thomas Hellström wrote:
Keith,
This is purely an optimization.
Buffers that are evicted due to a memory aperture space shortage ends up
in a
state where they are unbound from the aperture, but retain the uncached
state assuming the
On Sat, 2007-12-22 at 10:19 +0100, Thomas Hellström wrote:
There is indeed, although you and Eric have improved the situation
considerably.
I hope there will be some time available to document things more
properly soon.
I think it works fairly well for me to try and document things as I
Keith Packard wrote:
On Mon, 2007-12-17 at 21:07 +, Keith Whitwell wrote:
Keith Packard wrote:
Here are some proposed cleanups and documentation for the drm_ttm.c APIs.
One thing I didn't change was the name of drm_ttm_fixup_caching, which is
clearly a badly named function. Can
On Fri, 2007-12-21 at 13:21 +0100, Thomas Hellström wrote:
Keith,
This is purely an optimization.
Buffers that are evicted due to a memory aperture space shortage ends up
in a
state where they are unbound from the aperture, but retain the uncached
state assuming the next operation on
Keith Packard wrote:
Here are some proposed cleanups and documentation for the drm_ttm.c APIs.
One thing I didn't change was the name of drm_ttm_fixup_caching, which is
clearly a badly named function. Can anyone explain why you wouldn't just
always use drm_ttm_unbind instead? The only
On Mon, 2007-12-17 at 21:07 +, Keith Whitwell wrote:
Keith Packard wrote:
Here are some proposed cleanups and documentation for the drm_ttm.c APIs.
One thing I didn't change was the name of drm_ttm_fixup_caching, which is
clearly a badly named function. Can anyone explain why you
Here are some proposed cleanups and documentation for the drm_ttm.c APIs.
One thing I didn't change was the name of drm_ttm_fixup_caching, which is
clearly a badly named function. Can anyone explain why you wouldn't just
always use drm_ttm_unbind instead? The only difference is that
