[Mesa-dev] [PATCH 1/5] clover/memory: Copy data when creating buffers with CL_MEM_USE_HOST_PTR

[Grigori Goronzy]

On 2017-08-03 22:26, Alex Deucher wrote:
> 
> IIRC, user_ptrs require page alignment.
> 
> Alex
> 

I didn't follow the whole discussion (sorry if I'm saying something 
redundant), but AMD's older OpenCL Optimization Guide [1] has some notes 
regarding the implementation of the USE_HOST_PTR flag.
It initially recommends 4KB (aka page) alignment but also supports 
arbitrary alignment (with additional overhead, I suppose it pins an 
extra page for bad alignments). It also does some optimizations to 
minimize mapping/unmapping operations, called "pre-pinning". Not sure if 
that is applicable to Mesa/Clover, aren't (GTT) buffers usually mapped 
forever?

Grigori

[1] 
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_OpenCL_Programming_Optimization_Guide.pdf

>> 
>> Right now it's hard-coded to R600_MAP_BUFFER_ALIGNMENT in si_pipe.c
>> and r600_pipe.c which has a value of 64 (bytes, I believe).
>> 
>>> 
>>>> 
>>>> And also change si_pipe.c:si_get_param's switch statement value to 
>>>> return:
>>>>   case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
>>>>     return sscreen->b.info.gart_page_size;
>>> 
>>> I'm not sure what the correct value is here. AFAIK, EG uses 256B 
>>> cache
>>> lines so I'd expect the value of to be at least that
>> 
>> Depending on how the weather works out tonight, I might be able to at
>> least find out what NI reports for gart page sizes and compare that to
>> my SI.  I haven't tried to test user pointer support on r600g yet, so
>> either it's working alright with the existing 64-byte alignment, or
>> it's broken when we allocate pointers using the actual alignments
>> reported by clGetDeviceInfo. If it's broken, I'll try 256B, then keep
>> bumping it up until it either starts working or I hit GART page size.
>> 
>> --Aaron
>> 
>>> 
>>> Both NI and GCN should be able to use 4K pages (which is what
>>> gart_page_size is set to), but we might want higher alignment for
>>> better performance[0]
>>> 
>>> [0]https://lists.freedesktop.org/archives/dri-devel/2014-May/058858.htm
>>> l
>>>> 
>>>> Then I can successfully create buffers from user pointers on my SI 
>>>> card.
>>>> 
>>>> I'm a bit fuzzy on what alignment restrictions exist for SI/GCN 
>>>> cards,
>>>> but the winsys seems to indicate we should align things to gart page
>>>> size, which makes sense on the surface at least.
>>>> 
>>>> If the alignment restrictions have changed between R600 and GCN, 
>>>> that
>>>> might explain why what's broken for me is working for you/Grigori 
>>>> (on
>>>> r600).
>>> 
>>> I remember there was a buffer alignment patch form AMD recently for
>>> SI/CI vs. VI+, but I can't find it.
>>> It looks like a separate issue however. if incorrect alignment makes
>>> user_ptr fail, and the test still fails, it looks like the 
>>> no-user_ptr
>>> fallback is broken.
>>> 
>>> Jan
>>> 
>>>> 
>>>> --Aaron
>>>> 
>>>> >
>>>> > Jan
>>>> >
>>>> >
>>>> > >
>>>> > > Signed-off-by: Aaron Watry <awatry at gmail.com>
>>>> > > CC: Francisco Jerez <currojerez at riseup.net>
>>>> > > ---
>>>> > >  src/gallium/state_trackers/clover/core/memory.cpp | 2 +-
>>>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>>>> > >
>>>> > > diff --git a/src/gallium/state_trackers/clover/core/memory.cpp b/src/gallium/state_trackers/clover/core/memory.cpp
>>>> > > index b852e6896f..912d74830a 100644
>>>> > > --- a/src/gallium/state_trackers/clover/core/memory.cpp
>>>> > > +++ b/src/gallium/state_trackers/clover/core/memory.cpp
>>>> > > @@ -30,7 +30,7 @@ memory_obj::memory_obj(clover::context &ctx, cl_mem_flags flags,
>>>> > >                         size_t size, void *host_ptr) :
>>>> > >     context(ctx), _flags(flags),
>>>> > >     _size(size), _host_ptr(host_ptr) {
>>>> > > -   if (flags & CL_MEM_COPY_HOST_PTR)
>>>> > > +   if (flags & (CL_MEM_COPY_HOST_PTR | CL_MEM_USE_HOST_PTR))
>>>> > >        data.append((char *)host_ptr, size);
>>>> > >  }
>>>> > >
>>>> >
>>>> > --
>>>> > Jan Vesely <jan.vesely at rutgers.edu>
>>>> 
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev