<div dir="ltr"><div>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.<br><br></div>Marek<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 25, 2018 at 11:14 PM, Gurchetan Singh <span dir="ltr"><<a href="mailto:gurchetansingh@chromium.org" target="_blank">gurchetansingh@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That sounds fine to me.  We can just modify the stride after dri_bo_create(..).<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Apr 25, 2018 at 7:30 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br>
> On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh<br>
> <<a href="mailto:gurchetansingh@chromium.org">gurchetansingh@chromium.org</a>> wrote:<br>
>><br>
>> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br>
>> > From: Nicolai Hähnle <<a href="mailto:nicolai.haehnle@amd.com">nicolai.haehnle@amd.com</a>><br>
>> ><br>
>> > Allow the caller to specify the row stride (in bytes) with which an<br>
>> > image<br>
>> > should be mapped. Note that completely ignoring USER_STRIDE is a valid<br>
>> > implementation of mapImage.<br>
>> ><br>
>> > This is horrible API design. Unfortunately, cros_gralloc does indeed<br>
>> > have<br>
>> > a horrible API design -- in that arbitrary images should be allowed to<br>
>> > be<br>
>> > mapped with the stride that a linear image of the same width would have.<br>
>><br>
>> Yes, unfortunately the gralloc API doesn't return the stride when<br>
>> (*lock) is called.  However, the stride is returned during (*alloc).<br>
>> Currently, for the dri backend, minigbm uses<br>
>> __DRI_IMAGE_ATTRIB_STRIDE to compute the pixel stride given to<br>
>> Android.<br>
>><br>
>> Is AMD seeing problems with the current approach (I haven't seen any<br>
>> bugs filed for this issue)?<br>
>><br>
>> Another possible solution is to call mapImage()/unmapImage right after<br>
>> allocating the image, and use the stride returned by mapImage() to<br>
>> compute the pixel stride.  That could also fix whatever bugs AMD is<br>
>> seeing.<br>
><br>
><br>
> Thanks. You cleared it up to me. It looks like that everything we've been<br>
> told so far is BS. This series isn't needed.<br>
><br>
> The solution is to do this in the amdgpu minigbm backend at alloc time:<br>
>    stride = align(width * Bpp, 64);<br>
><br>
> Later chips should change that to:<br>
>    stride = align(width * Bpp, 256);<br>
><br>
> No querying needed. What do you think?<br>
><br>
> Marek<br>
</div></div></blockquote></div><br></div></div></div></div>