[PATCH v3] drm/fourcc: document modifier uniqueness requirements

[Michel Dänzer]

On 2020-05-29 5:01 p.m., Daniel Stone wrote:
> On Fri, 29 May 2020 at 15:36, Alex Deucher <alexdeucher at gmail.com> wrote:
>> On Fri, May 29, 2020 at 10:32 AM Daniel Stone <daniel at fooishbar.org> wrote:
>>> On Fri, 29 May 2020 at 15:29, Alex Deucher <alexdeucher at gmail.com> wrote:
>>>> Maybe I'm over thinking this.  I just don't want to get into a
>>>> situation where we go through a lot of effort to add modifier support
>>>> and then performance ends up being worse than it is today in a lot of
>>>> cases.
>>>
>>> I'm genuinely curious: what do you imagine could cause a worse result?
>>
>> As an example, in some cases, it's actually better to use linear for
>> system memory because it better aligns with pcie access patterns than
>> some tiling formats (which are better aligned for the memory
>> controller topology on the dGPU).  That said, I haven't been in the
>> loop as much with the tiling formats on newer GPUs, so that may not be
>> as much of an issue anymore.
> 
> Yeah, that makes a lot of sense. On the other hand, placement isn't
> explicitly encoded for either modifiers or non-modifiers, so I'm not
> sure how it would really regress.

Without modifiers, only linear buffers could be shared between devices
with amdgpu. With modifiers, such shared buffers might end up tiled but
located in system memory.


Anyway, as you explained well, the benefits of modifiers aren't limited
to inter-device buffer sharing.


-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer