[PATCH 1/2] glamor: add support for allocating linear buffers

[Emil Velikov]

On 22 June 2015 at 07:56, Michel Dänzer <michel at daenzer.net> wrote:
> On 20.06.2015 07:32, Dave Airlie wrote:
>>>
>>>> at which point you'd want to continue
>>>> the versioning from the mesa point to avoid epochs. So I don't
>>>> take your argument, the API version is what we ship in the gbm.pc
>>>> file, compatible implementations should make the same API changes
>>>> in their same versions.
>>>>
>>> Other companies may use different versionning schemes (YYYY/MM/DD) and
>>> which they cannot shift away from for whatever reason. Based on that
>>> (plus the libEGL <> libgbm ABI mentioned above) sticking with "use
>>> mesa's version" seems a bit impossible/narrow minded imho. I think we
>>> can all agree things are less than perfect and checking the version in
>>> the pc file is not a good idea.
>>
>> gbm.pc is the gbm API version number. It isn't the Mesa version number,
>> it just happens at the moment they are the same thing because nobody
>> has split them, and because there isn't much value to Mesa in doing so.
>>
>> Other projects implementing the gbm API need to use the same version
>> number for their gbm.pc file. it sucks but otherwise they are not API
>> compatible. This doesn't mean they cannot use other versioning schemes
>> for their project, but their gbm.pc needs to be compatible with Mesa.
>>
>> But yes checking the version sucks and I'd rather not do it, but it doesn't
>> escape the fact that other gbm implementations are currently doing it
>> wrong if they want to be API compatible.
>
> I think one fundamental issue is that we're trying to determine the GBM
> runtime ABI from compile time constants. One possible solution might be
> to add something like
>
>  enum gbm_bo_flags gbm_bo_get_supported_flags(struct gbm_device *gbm)
>
> which returns the mask of flags supported by the implementation.
>
In theory the "packager's responsibility" should kick way before that,
although this would be a great addition.

-Emil