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

[Christian König]

Am 22.04.2014 22:42, schrieb Pierre-Loup A. Griffais:
> On 04/22/2014 04:45 AM, Christian König wrote:
>> Hi Aaron & Pierre-Loup,
>>
>> Am 22.04.2014 01:46, schrieb Aaron Plattner:
>>> Hi Pierre-Loup,
>>>
>>> On 04/21/2014 03:35 PM, Pierre-Loup Griffais wrote:
>>>> VDPAU has gained plenty of driver and application support in the past
>>>> years and it seems to be on good track to become the de-facto 
>>>> standard.
>>>> Talking with some people, IHVs and ISVs altogether, that do not yet
>>>> support VDPAU but are considering it, two main concerns emerge:
>>>>
>>>>   - 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.
>>>
>>> One of the advantages that VDPAU has over VA-API is that there are
>>> fewer stages in the pipeline that an implementation can just fail to
>>> implement, which means fewer fallbacks that applications have to
>>> implement (and test).  I'd like to keep it that way if possible. I.e.,
>>> rather than failing to support presentation, maybe libvdpau could just
>>> fall back to the reference OpenGL presentation layer if the driver
>>> back-end indicates that it doesn't support native presentation?  Maybe
>>> combine that with a query that lets applications know if that's
>>> happening in case they really do want to implement their own fallbacks?
>>
>> Agree completely on this. VDPAU is a very well designed interface for
>> both the application as well as the driver side to work with.
>>
>> I currently don't see much need for defining a presentation queue helper
>> library that implements the VDPAU functionality on top of OpenGL.
>
> It would make it easier for HW vendors to expose their decoding 
> capabilities through VDPAU without having to worry about interfacing 
> with platform-specific windowing systems. Without going as far as 
> changing the standard, just having a reference implementation of the 
> presentation layer available for reference somewhere would be nice.
>
>>
>> On the other hand a proper define of VDPAU presentation queue over EGL
>> would be indeed quite useful.
>>
>> Christian.
>>
>>>
>>>>   - Encoding: VA-API and OpenMAX both have encoding infrastructures;
>>>> would there be any value in leveraging some of the existing VDPAU
>>>> mechanisms in order to expose hardware encoding capabilities, in order
>>>> to minimize the implementation work needed? Just as VDPAU allows
>>>> presentation compared to more traditional bitstream decodes API, its
>>>> encoding sister API could potentially specify means of achieving
>>>> screen-scraping, like NvFBC. VDEPCAU anyone?
>>>
>>> We originally punted on encode support in order to get something
>>> working shipped.  I don't have a preference as to whether it becomes
>>> part of VDPAU or exists as its own separate project.
>
> It seems like a VdpEncoder object could interface with the existing GL 
> interop extension without needing to modify its specification, in 
> order to capture frames from a game or compositor drawable. Some of 
> the spec language mentions 'decoding' and 'output' but the extension 
> was meant to be bi-directional to begin with, so this is promising.

That indeed seems to make sense. I agree that the GL extension can be 
easily used to shared image data with VDPAU in both directions.

> Does the general idea of specifying a VdpEncoder extension and 
> providing an initial sample implementation based on an existing encode 
> API sound crazy to anyone?

Not really, as long as it is sanely defined I would be happy to support 
that with our open source driver on AMD hardware.

On the other hand OpenMAX is pretty much doing the same thing already, 
also has the ability to interop with EGL and on top of that is a Khronos 
standard. The only problem is that it's not so widely adopted.

Christian.

> Thanks,
>  - Pierre-Loup
>
>>>
>>>> I'm interested in hearing high-level opinions from various 
>>>> stakeholders
>>>> to convince myself whether this is worth spending any effort on. It's
>>>> possible the consensus is that the current situation is fine, but 
>>>> to me
>>>> it seems we're still in a little bit of a wild west. VA-API, OpenMAX,
>>>> nvcuvenc, nvcuvid, NvFBC, XvBA, XvMC, Xv are quite unfortunately still
>>>> all paths viable to target as a SW vendor depending on what your 
>>>> usecase
>>>> / HW combination is. It does seem like the full scope of all of the
>>>> above could be captured by a "VDEPCAU" without necessarily becoming 
>>>> too
>>>> bloated.
>>>>
>>>> Curious what your thoughts are; thanks for your time.
>>>>   - Pierre-Loup
>>>
>>> _______________________________________________
>>> VDPAU mailing list
>>> VDPAU at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/vdpau
>>
>
> _______________________________________________
> VDPAU mailing list
> VDPAU at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/vdpau