Why the vram always with WC flag even if the architecture don't support WC memory

[Michel Dänzer]

On 2018-01-18 12:08 PM, Lvzhihong (ReJohn) wrote:
> Hi All,
> 
>      I have a logical question when create buffer object in the amdgpu
> kernel driver code. My ARM64 architecture don't support WC memory , but
> in the driver , the VRAM BO still set WC flags.
> 
> At file: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> 
> In function amdgpu_bo_do_create ,
> 
> it determine the bo->flags by the architectures like below:
> 
>          if (!drm_arch_can_wc_memory())
>                    bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
> 
> but then in the function :amdgpu_ttm_placement_from_domain(bo, domain);
> it still set  TTM_PL_FLAG_WC for the VRAM bo:
> 
>  
> 
>          if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
>                    unsigned visible_pfn = adev->mc.visible_vram_size >>
> PAGE_SHIFT;
> 
>                    places[c].fpfn = 0;
>                    places[c].lpfn = 0;
>                    places[c].flags = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
>                             TTM_PL_FLAG_VRAM;
> 
>                   ……
> }
> 
>      I want to know why vram always with WC flag even if the
> architecture don't support WC memory,  And in the architecture which are
> not support WC memory,  vram bo with WC flag may cause some unpredicted
>  results ?

I think it's fine. Platforms without write-combining should fall back to
normal uncacheable mappings. This is fine for VRAM, because it can't be
cacheable. But for GTT, we want to use cacheable mappings if
write-combining isn't available, because uncacheable mappings would be
much slower.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer