Introduce VADisplayAttribSurfaceAttribs

[emersion]

This allows applications to query the supported surface attributes.

This is useful to allow applications to make sure their attributes
are taken into account, and allow them to have a fallback when a
surface attribute is not supported.

ffmpeg already needs a workaround to figure out whether a driver
supports VASurfaceAttribMemoryType.

The concept of a "HW attribute" is borrowed from #513 and #514.

[XinfengZhang]

not sure whether I understand your purpose, I dont think we need a special attribute to report whether we support another attributes. when a attributes is un-support. it should return with a value VA_ATTRIB_NOT_SUPPORTED, if it is a pointer, it should be set to null. so, why we need to use vaQueryDisplayAttributes to query whether a surface attribute is support or not?

[emersion]

when a attributes is un-support. it should return with a value VA_ATTRIB_NOT_SUPPORTED

Ah, I was wondering about this. It doesn't seem like intel media driver is doing it. I've filled a pull request to fix that: intel/media-driver#1176

so, why we need to use vaQueryDisplayAttributes to query whether a surface attribute is support or not?

It's a little tricky for the caller to figure out which attribute caused the failure. If the application provided both VASurfaceAttribUsageHint and VASurfaceAttribMemoryType, which one caused the failure?

If they know in advanced the surface attributes supported by the display, applications can have a fallback. For instance, if VASurfaceAttribUsageHint is not supported, applications can remove it, since it's just a hint.

[XinfengZhang]

the normal call sequence should be:
vaQuerySurfaceAttributes/vaGetSurfaceAttributes then call vaCreateSurfaces

so , before vaCreateSurfaces, it should already know which attribute could be supported.

with your PR, the call sequence seems be changed to
vaQueryDisplayAttributes/vaGetDisplayAttributes ===> vaCreateSurfaces

it looks a little strange.

[emersion]

Ah, I guess my question is: how does the application know that the driver supports attributes which aren't readable (only writable)? Examples: VASurfaceAttribExternalBufferDescriptor and VASurfaceAttribDRMFormatModifiers.

Should the driver return the writable attribute without any value in vaQuerySurfaceAttributes?

[XinfengZhang]

query function support this flag https://github.com/intel/libva/blob/master/va/va.h#L1600 and the value could be
VA_SURFACE_ATTRIB_GETTABLE , VA_SURFACE_ATTRIB_SETTABLE or VA_SURFACE_ATTRIB_GETTABLE | VA_SURFACE_ATTRIB_SETTABLE

[dvrogozh]

Let's prioritize #514 - you will need to rebase once that one will be merged.

[emersion]

Closing since drivers should return settable attributes in vaQuerySurfaceAttributes. I checked intel-media-driver and Mesa, both already do so for VASurfaceAttribExternalBufferDescriptor.