[Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Marek Olšák]

On Fri, Apr 27, 2018 at 5:00 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:

> On 26.04.2018 04:30, Marek Olšák wrote:
>
>> On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh <
>> gurchetansingh at chromium.org <mailto:gurchetansingh at chromium.org>> wrote:
>>
>>     On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák <maraeo at gmail.com
>>     <mailto:maraeo at gmail.com>> wrote:
>>     > From: Nicolai Hähnle <nicolai.haehnle at amd.com <mailto:
>> nicolai.haehnle at 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?
>>
>
> I don't see how this approach can possibly work unless we always map the
> whole texture.
>

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).

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180427/bb38f332/attachment.html>