[Intel-gfx] [PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2

Rob Clark robdclark at gmail.com
Fri Jan 30 06:51:48 PST 2015


On Fri, Jan 30, 2015 at 9:35 AM, Tvrtko Ursulin
<tvrtko.ursulin at linux.intel.com> wrote:
>
> On 01/30/2015 01:43 PM, Rob Clark wrote:
>>
>> On Fri, Jan 30, 2015 at 5:51 AM, Tvrtko Ursulin
>> <tvrtko.ursulin at linux.intel.com> wrote:
>>>>
>>>> +/*
>>>> + * Format Modifier tokens:
>>>> + *
>>>> + * When adding a new token please document the layout with a code
>>>> comment,
>>>> + * similar to the fourcc codes above. drm_fourcc.h is considered the
>>>> + * authoritative source for all of these.
>>>> + */
>>>
>>>
>>>
>>> On one side modifiers are supposed to be opaque, but then this suggest
>>> they
>>> are supposed to be added in this file and described. Is that right?
>>
>>
>>
>> correct..   opaque as in basically enum values.
>>
>> We do want a description of the format so when someone comes along and
>> adds a new value, we have a chance of realizing that it is the same as
>> an existing value, since there are cases where gpu's from different
>> vendors can support (for example) the same tiling formats.
>
>
> Opaque kind of suggests it is driver private and from that angle definitions
> and descriptions wouldn't belong in the core uapi header. So I think that's
> just confusing and I'd drop opaque from the description and just call it a
> token.

hmm, to me, 'opaque' just meant 'do not try to interpret the bits'..
but if that is confusing, I don't mind to just call it a token

> (And another reason why I was suggesting to split the space for potential
> common and vendor/driver specific tokens.)

(which works well until some vendor introduces some format, and later
another vendor adds support for it :-P)

BR,
-R

> Regards,
>
> Tvrtko


More information about the Intel-gfx mailing list