<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 27, 2018 at 5:00 AM, Nicolai Hähnle <span dir="ltr"><<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26.04.2018 04:30, Marek Olšák wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh <<a href="mailto:gurchetansingh@chromium.org" target="_blank">gurchetansingh@chromium.org</a> <mailto:<a href="mailto:gurchetansingh@chromium.org" target="_blank">gurchetansingh@chromiu<wbr>m.org</a>>> wrote:<br>
<br>
    On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a><br></span>
    <mailto:<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>>> wrote:<br>
    > From: Nicolai Hähnle <<a href="mailto:nicolai.haehnle@amd.com" target="_blank">nicolai.haehnle@amd.com</a> <mailto:<a href="mailto:nicolai.haehnle@amd.com" target="_blank">nicolai.haehnle@amd.co<wbr>m</a>>><span class=""><br>
    ><br>
    > Allow the caller to specify the row stride (in bytes) with which an 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 have<br>
    > a horrible API design -- in that arbitrary images should be allowed to 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 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>
</span></blockquote>
<br>
I don't see how this approach can possibly work unless we always map the whole texture.<br></blockquote><div><br></div><div>Even if ChromeOS doesn't map the whole texture, we still need the stride change, because the hw can't use the display stride for mappings (it's an unsupported user stride).<br><br></div><div>Marek<br></div></div><br></div></div>