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

[Emil Velikov]

On 23 June 2015 at 02:46, Michel Dänzer <michel at daenzer.net> wrote:
> On 23.06.2015 04:28, Emil Velikov wrote:
>> 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.
>
> Not sure how that could work with different GBM implementations having
> different capabilities.
>
That depends on the scenario:
 1) Distribution provides xserver package against one gbm
implementation - user swaps the gbm underneat the disto's back. This
practise is unsupported/illadvised by distros and will likely lead to
a crash. Here is where your suggestion will minimise the damage.
 2) Distros provides xserver package, annotate against a meta gbm
(with multiple providers of gbm, properly versioned) - user can swap
between mesa gbm and other supported implemenations without any
problems. This approach is not addopted for gbm yet, but other
packages do make use it.

Now I'm stopping with the dairycrafting :-)

-Emil