[VDPAU] VDPAU future direction; reducing _and_ expanding its scope?

[Stephen Warren]

Pierre-Loup Griffais wrote at Monday, April 21, 2014 4:36 PM:
...
>  - Presentation: implementing (or targeting) a VDPAU presentation queue is tricky, and on some
> hardware implementing it might not provide any significant value over handing off the decoded buffer
> to OpenGL for presentation, which is the model that VA-API happens to adopt. Could
> VdpPresentationQueue (or a higher-level object) be extended to expose capabilities just like the
> decoder does today, and let the implementation convey to the client that it does not support
> presentation? That, along with a reference presentation implementation based on OpenGL that
> applications can use as-is as a fallback, seems like it could greatly reduce friction for potential
> implementers.

If an implementation doesn't support a presentation queue, it can simply
fail the "get proc address" call for VdpPresentationQueueCreate. So, I don't
think we need any additional "get caps" APIs to report this.

The question of whether a conforming VDPAU implementation should be allowed
to do this is a separate issue:-)

-- 
nvpublic