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

[Michel Dänzer]

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.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer