Comment # 5
on bug 105145
from k.philipp@gmail.com
(In reply to Christian König 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 could give the > > driver that we want to have progressive surfaces? > > 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. You could argue that VA_SURFACE_ATTRIB_USAGE_HINT_DISPLAY ("Surface used for display") kind of applies here, since to display you have to export and 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 like 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 ignored. 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 vaExportSurfaceHandle discussion (https://github.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. > > Also don't call it interlaced/progressive (that was just me trying to make > sense of what the hardware is doing). > > 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!
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
