On Mon, 2008-03-17 at 11:51 +0100, Thomas Hellström wrote: > Thomas Hellström wrote: > > Xiang, Haihao wrote: > > > >> Hi, thomas > >> > >> Many texture cases(see fd.o bug > >> https://bugs.freedesktop.org/show_bug.cgi?id=14656, test case > >> https://bugs.freedesktop.org/attachment.cgi?id=14547) with the following > >> usage model fail on 965 after merging with intel-post-reloc branch: > >> > >> 1. draw a primitive with a texture > >> 2. map/unmap this texture image (which is used in the implementation of > >> some GL apis such as glReadPixels, glTexImage2D in 965). > >> 3. change some GL states and draw a primitive again. However this > >> primitive is rendered with some unexpected color. > >> > >> In 965 driver, all BOs used for textures and texture surface states are > >> created with LOCAL|CACHED|CACHED_MAPPED flag, the base address of a > >> texture (buffer object offset) is written into the corresponding texture > >> surface state (relocation entry). > >> > >> After 1, the BOs for texture and texture surface state are bound into > >> the GART with unsnooped PTEs. After 2, the texture BO is unbound, the > >> texture surface state BO is still bound. At 3, the texture BO is bound > >> to a new GART offset, and the relocation entry of the texture surface > >> state BO is also updated in relocation process. Note that the texture > >> surface state BO is bound with unsnooped PTEs. It seems that the GPU > >> doesn't know the offset of the texture BO is changed. So I think an > >> eviction is need before writing relocations which is added in DRM commit > >> 638353103d009d44bd5bdbe97cc7cef1bf011cdf. However this fix is removed > >> from DRM after merging with intel-post-reloc. > >> > >> Could you take a look? > >> > >> Thanks > >> Haihao > >> > >> > > Haihao, > > The intention with the intel-post-reloc branch was that the code-path > > for the mesa master drivers should remain completely unchanged compared > > to pre-merge, but apparently I missed that commit. > > > > I'll have a look. > > > > /Thomas > > > > > > > Haihao, > I've pushed a slight variant of the fix. Please let me know if it > doesn't fix the problem. Thanks. now these cases work well for me.
> A more efficient solution would perhaps be to clflush() the cache line > containing the updated value, > just after the relocation has been applied. (On processors that support > clflush()). Then the whole buffer doesn't need to be evicted. > /Thomas > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > -- > > _______________________________________________ > > Dri-devel mailing list > > Dri-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
