Commen=
t # 5
on bug 10514=
5
from k.philipp@gm=
ail.com
(In reply to Christian K=C3=B6nig from comment #4)
> (In reply to k.philipp from comment #3)
> > Also, that VAAPI has to weave the first few textures before they'=
ve been
> > exported once is not very nice. Is there some kind of hint we cou=
ld give the
> > driver that we want to have progressive surfaces?
>=20
> Not that I know of, but feel free to suggest something.
There are some surface hints, but I'm not sure if they fit this use case. Y=
ou
could argue that VA_SURFACE_ATTRIB_USAGE_HINT_DISPLAY ("Surface used f=
or
display") kind of applies here, since to display you have to export an=
d to
export you have to have it as frame (both for vaDeriveImage and
vaExportSurfaceHandle). But yeah, there's also the third way of using
vaPutSurface or vaGetSurfaceBufferWl (in theory, not sure how well mesa
supports it) which would not inherently be limited to working with frames.
"used for display" does not seem very well-defined in either case=
, so we could
get away with it.
Cleaner solution could be to think of something new, of course. Something l=
ike
VA_SURFACE_ATTRIB_USAGE_HINT_EXPORT_AS_FRAME? It really depends on what most
accurately describes what info mesa needs.
If we agree on a name, I can try to bring it up with the libva people.
> General problem with
> VA-API seems to be that suggestions made by AMD seems to be mostly ign=
ored.
That sounds very unfortunate. To be fair, I think that the TOP/BOTTOM field
flags would have been added if this was raised during the vaExportSurfaceHa=
ndle
discussion (https://git=
hub.com/intel/libva/pull/125) - maybe it was raised
somewhere else, then please forgive my ignorance :-) It was my understanding
that the addition of vaExportSurfaceHandle was done at least in part to be =
able
to support VA-API in a usable fashion on AMD hardware at all.
>=20
> Also don't call it interlaced/progressive (that was just me trying to =
make
> sense of what the hardware is doing).
>=20
> Instead call it something in the line of FIELD and FRAME, that is the =
more
> common terminology at least in the different MPEG standards.
OK!