[Mesa-dev] [PATCH 2/3] radv: rename global extension properties structs

[Emil Velikov]

On 16 January 2017 at 14:16, Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl> wrote:
> On Mon, Jan 16, 2017 at 2:51 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 14 January 2017 at 02:31, Andres Rodriguez <andresx7 at gmail.com> wrote:
>>> On Fri, Jan 13, 2017 at 8:13 PM, Emil Velikov <emil.l.velikov at gmail.com>
>>> wrote:
>>>>
>>>> On 13 January 2017 at 23:44, Andres Rodriguez <andresx7 at gmail.com> wrote:
>>>> > All extension arrays are global, but only one of them refers to instance
>>>> > extensions.
>>>> >
>>>> > The device extension array refers to extensions that are common across
>>>> > all physical devices. This disctinction will be more imporant once we
>>>> Typos: "distinction" and "important"
>>>>
>>>> > have dynamic extension support for devices.
>>>> >
>>>> I think that this and 3/3 are very good idea, but since RADV supports
>>>> only one device I'm not sure that they're applicable, yet.
>>>> Not too familiar with the RADV code so I might be off there.
>>>
>>>
>>> Besides differences in HW functionality, another use for this feature would
>>> be to expose an extension only if the software stack supports it.
>>>
>> Guess I was drooling too much over someone adding multiple devices
>> support for radv ;-)
>>
>>> Eg. something like:
>>>
>>> if (libdrm_version >= x && drm_version >= y)
>>>     register_extension(...)
>>>
>>> This will come into play with some of the other patches on amd-gfx that
>>> you've helped me review :)
>>>
>> Yw. As you get to the respective work - please don't base it on libdrm
>> version. Please check that the kernel module is old enough either via
>> a) a module version check or b) -EINVAL as returned by the module
>> input validation. Former seems to be used by radeon/amdgpu userspace
>> while the latter by the i915 one.
>
> Using the kernel exported DRM version seems to be common practice for
> radeonsi and the amdgpu and radeon winsyses though?
Indeed that's the case. I kind of said[meant to say] the same :-]

> That version has
> been increased in both kernel drivers to indiciate new features too.
> libdrm version will probably need to be compile time though anyway.
>
I would not bother with the latter - just bump LIBDRM_AMDGPU_REQUIRED and enjoy.

-Emil