On Mon, 2009-05-25 at 16:58 +0100, Dave Airlie wrote:
> > 
> > OK, with that hint the convolutions became a little bit more clear. The
> > exact problem is:
> > 
> > drm_buffer_object_create() is called with flags=DRM_BO_FLAG_MEM_TT
> > (DRM_BO_FLAG_CACHED is not included because this is a AGP system)
> >    
> >   bo->mem.flags = BO_FLAG_MEM_LOCAL | ...
> >   bo->mem.proposed_flags = BO_FLAG_MEM_TT | ...
> > 
> >   drm_bo_do_validate()
> >    drm_buffer_object_validate(..., move_buffer=TRUE)
> >     drm_bo_move_buffer()
> >       drm_bo_add_ttm()
> >         drm_ttm_create(page_flags=DRM_BO_FLAG_WRITE)
> >         drm_ttm_bind() 
> >           drm_ttm_set_caching(noncached=DRM_TTM_PAGE_UNCACHED, 
> > alloc_cached=FALSE)
> >             drm_ttm_populate(cached=FALSE)
> >               Allocates uncached memory from pool
> >             proceeds to mark memory uncached, expensively
> > 
> > The problem was introduced with:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=37136c81b28e45f30c8d45d212315c0b4ce6c6b0
> > 
> > (I'm unclear what the "upstream" referred to in the commit message is, maybe
> > the original had a more informative commit message...)
> 
> From the new ttm code, just quick response is the original code did what 
> you say below, only setting caching before populating, however that
> caused the black bar lines on migration.
> 
> I didn't get a chance to solve both speed and correctness so just got the 
> black bars fixed despite it slowing down the GART buffer allocs.
> 
> I'd like to fix this at some point, but I never got to understand wtf the 
> blackbars were coming from, apart from it being something to do with 
> evicted buffers.

Aha!

So, two characteristics of the black bars I remember:

 - They were 16-pixel (64-byte) horizontal stripes, 64-byte aligned.
   That is, cache lines.
 - They were black.
   That is, the cache-line contents for a newly zeroed page

Note also that the function to add pages to the page free lists - 
drm_add_pages_locked() - calls set_memory_wc(), but it doesn't do the
other thing that drm_ttm_set_caching() does: call drm_clflush_pages()

So, I believe the black bar problem was simply that when migrating a
buffer from vram to newly allocated system memory pages, cached data
written to those pages by the CPU wasn't flushed before blitting the
migrated data.

If that theory makes sense, then 37136c81 is pretty much entirely
extraneous - it fixes the black bars by defeating the point of the free
list of uncached pages and doing the work of drm_ttm_set_caching() on
every page pulled out of the free list.

- Owen



------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to