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

[Michel Dänzer]

On 24.06.2015 20:38, Emil Velikov wrote:
> 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.
>>
> [...]
>  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.

I meant: How can this deal with one GBM implementation supporting a flag
such as GBM_BO_USE_LINEAR but the other not?


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