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.

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

Reply via email to