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
