Fresh lunar install

[Auke Kok]

On 05/19/2013 01:35 PM, Zbigniew Luszpinski wrote:
> On Saturday 18 of May 2013 17:39:13 Jean-Michel Bruenn wrote:
>>> vdpauinfo | grep string
>>> Information string: NVIDIA VDPAU Driver Shared Library  319.17  Thu
>>> Apr 25 21:07:58 PDT 2013
>>>
>>> vdpauinfo command comes from vdpauinfo module.
>>
>> wdp at vulkan ~ $ vdpauinfo | grep string
>> Information string: NVIDIA VDPAU Driver Shared Library  319.17  Thu Apr
>> 25 21:44:27 PDT 2013
>>
>> and i said "yes" to mesa-lib's vdpau. So it looks like it is safe to
>> say yes. Can you verify that?
>
> Looks good. But building mesa's vdpau and using nvidia driver together
> makes no sense.
>
>>> If you see something like this you use optimal nvidia's vdpau. If you
>>> see something else like gallium or mesa the worse vdpau from mesa is
>>> active.>
>>>> Do we need the vdpau module at all in linux, if nvidia ships with
>>>> it's
>>>> own?
>>>
>>> Do not know vdpau module.
>>
>> I was refering to "libvdpau". I thought "nvidia" might provide that.
>
> No. libvdpau is universal for every gpu driver - that is why it is
> standalone. gpu driver package provides hw dependent part for vdpau.
> Nvidia binary provides vdpau for geforces, S3 graphics has vdpau for its
> chrome gpus. New opensource Radeon driver provides vdpau for radeons
> because they understood that XvBA is dead. Finally mesa-lib has shader
> accelerated vdpau. Intel has stated they are considering VDPAU.

Our gfx team is at this point only still supporting libVA, and other 
graphics vendors have joined. I'm unsure where the market will go, but 
it's unlikely that this will go one way drastically any time soon. More 
likely is that both will coexist for a longer time until either 
something better comes around or people stop backing one technology.

Auke