Gurchetan, can you confirm that the stride returned at alloc() is only used for CPU access and not for display programming?
Thanks, Marek On Wed, Apr 25, 2018 at 11:23 PM, Marek Olšák <mar...@gmail.com> wrote: > Why would you want to modify it? It's exactly what you get when you map > it, but that stride can't be used for modesetting. > > Marek > > > On Wed, Apr 25, 2018 at 11:14 PM, Gurchetan Singh < > gurchetansi...@chromium.org> wrote: > >> That sounds fine to me. We can just modify the stride after >> dri_bo_create(..). >> >> On Wed, Apr 25, 2018 at 7:30 PM, Marek Olšák <mar...@gmail.com> wrote: >> > On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh >> > <gurchetansi...@chromium.org> wrote: >> >> >> >> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák <mar...@gmail.com> wrote: >> >> > From: Nicolai Hähnle <nicolai.haeh...@amd.com> >> >> > >> >> > Allow the caller to specify the row stride (in bytes) with which an >> >> > image >> >> > should be mapped. Note that completely ignoring USER_STRIDE is a >> valid >> >> > implementation of mapImage. >> >> > >> >> > This is horrible API design. Unfortunately, cros_gralloc does indeed >> >> > have >> >> > a horrible API design -- in that arbitrary images should be allowed >> to >> >> > be >> >> > mapped with the stride that a linear image of the same width would >> have. >> >> >> >> Yes, unfortunately the gralloc API doesn't return the stride when >> >> (*lock) is called. However, the stride is returned during (*alloc). >> >> Currently, for the dri backend, minigbm uses >> >> __DRI_IMAGE_ATTRIB_STRIDE to compute the pixel stride given to >> >> Android. >> >> >> >> Is AMD seeing problems with the current approach (I haven't seen any >> >> bugs filed for this issue)? >> >> >> >> Another possible solution is to call mapImage()/unmapImage right after >> >> allocating the image, and use the stride returned by mapImage() to >> >> compute the pixel stride. That could also fix whatever bugs AMD is >> >> seeing. >> > >> > >> > Thanks. You cleared it up to me. It looks like that everything we've >> been >> > told so far is BS. This series isn't needed. >> > >> > The solution is to do this in the amdgpu minigbm backend at alloc time: >> > stride = align(width * Bpp, 64); >> > >> > Later chips should change that to: >> > stride = align(width * Bpp, 256); >> > >> > No querying needed. What do you think? >> > >> > Marek >> > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
