Nouveau - Sep 2020 - VAAPI on GeForce GT 620M

>
> It does indicate a config problem, but why do you want to use the
> nvidia GPU for video accel? I'd rely on intel to provide acceleration
> as this also reduces power consumption of the entire system. Also I
> think vaapi on the secondary GPU is pretty much untested.


Well you've got a point there. It's just that the dang nvidia is pretty
much sitting there on its hiney doing nothing (the mediaserver is running
headless), while the CPU block is doing all the heavy lifting (I'm running
torznab grabbers, DLNA streaming etc off an old laptop whose screen's
busted).

I tried nvenc/nvdec, but the 650M doesn't seem to support it according to my
reading of the support page
<https://developer.nvidia.com/video-encode-decode-gpu-support-matrix>
Doesn't support CUDA either, it seems. so I switched the hardware
transcoding to vaapi on the intel gpu.

I figure if the nvidia took some load off then the heat would be more
evenly distributed across the motherboard, increasing the server's shelf
life, plus the nvidia actually gets to do something.

On Tue, 1 Sep 2020 at 18:01, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Tue, Sep 1, 2020 at 3:31 AM Analabha Roy <hariseldon99 at
gmail.com>
> wrote:
> >
> > Hi,
> >
> > If I am reading the featurematrix right, VAAPI is supported for
nouveau
> on the GeForce650M (my card).
> >
> > Here is the output of inxi -F
> >
> > System:    Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64
> Console: tty 1 Distro: Ubuntu 18.04.5 LTS
> > Machine:   Device: laptop System: SAMSUNG product:
300E4C/300E5C/300E7C
> v: 0.1 serial: N/A
> >            Mobo: SAMSUNG model: NP300E5X-U01IN v: FAB1 serial: N/A
> >            UEFI [Legacy]: Phoenix v: P06RAC date: 10/25/2012
> > Battery    BAT1: charge: 47.5 Wh 100.0% condition: 47.5/47.5 Wh (100%)
> > CPU:       Dual core Intel Core i3-2310M (-MT-MCP-) cache: 3072 KB
> >            clock speeds: max: 2100 MHz 1: 835 MHz 2: 1031 MHz 3: 905
MHz
> 4: 927 MHz
> > Graphics:  Card-1: Intel 2nd Generation Core Processor Family
Integrated
> Graphics Controller
> >            Card-2: NVIDIA GF108M [GeForce GT 620M]
> >            Display Server: X.org 1.20.8 driver: i915 tty size: 171x45
> Advanced Data: N/A out of X
> >
> >
> > I have installed nouveau, and extracted the firmware from the prop
> nvidia drivers separately as per instructions on
> https://nouveau.freedesktop.org/wiki/VideoAcceleration/
> > See installed firmware @ https://pastebin.com/Gaqxb88g
> >
> > But running vainfo yields error: https://pastebin.com/NyULBhXt
> >
> > Does the error mean that VAAPI is unsupported, or does it indicate a
> config problem?
>
> As Karol suggests, using the onboard CPU's decoding capabilities will
> yield better results. However if there's some specific reason you
> want/need to use the NVIDIA card, it should still work. I note that
> you don't have an X server running - is that on purpose?

Yes. This is a headless media server hosting jellyfin. Hence the tinkering
around with hardware transcoding.
This was an old laptop whose screen got busted, so am repurposing as a
media server/streamer.

> I believe
> that va-api needs some sort of winsys to be available, but I guess I'm
> not entirely sure.
>
>
vainfo works off the intel driver even though there is no X running:
https://pastebin.com/pnaAMCFd

vaapi is happily transcoding off the intel on the headless machine if I'm
reading the ffmpeg logs correctly

> Do you see any errors in dmesg after running vainfo?
>
>
nope.

> Cheers,
>
>   -ilia
>

Any suggestions on how to trace the config issues? Do I have to debug
the va_openDriver() function?

-- 
Analabha Roy
Assistant Professor
Department of Physics
<http://www.buruniv.ac.in/academics/department/physics>
The University of Burdwan <http://www.buruniv.ac.in/>
Golapbag Campus, Barddhaman 713104
West Bengal, India
Emails: daneel at utexas.edu, aroy at phys.buruniv.ac.in, hariseldon99 at
gmail.com
Webpage: http://www.ph.utexas.edu/~daneel/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20200901/1cd64338/attachment.htm>

On Tue, Sep 1, 2020 at 9:10 AM Analabha Roy <hariseldon99 at gmail.com>
wrote:
> Any suggestions on how to trace the config issues? Do I have to debug the
va_openDriver() function?
My guess, without reading any code, is that DRI_PRIME isn't doing what
you want it to, and the nouveau driver is being handed an intel
device. This does not work well. Fixing this will require tracing
through the va winsys code which to figure out how it invokes the
loader.

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/frontends/va/context.c#n111

For the DRM/rendernodes "platform", it will just take whatever fd it
is given. vainfo appears to give it a fixed device:

https://github.com/intel/libva-utils/blob/master/common/va_display_drm.c#L39

However it looks like you can pass in --device /dev/dri/renderD129 or
whatever the right one is, which should pass in the right render node,
as seen here:

https://github.com/intel/libva-utils/blob/master/common/va_display.c#L80

Note that I've never tried this, just did a few google searches to
find this stuff.

Cheers,

  -ilia

On Tue, 1 Sep 2020 at 18:59, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Tue, Sep 1, 2020 at 9:10 AM Analabha Roy <hariseldon99 at
gmail.com>
> wrote:
> > Any suggestions on how to trace the config issues? Do I have to debug
> the va_openDriver() function?
>
> My guess, without reading any code, is that DRI_PRIME isn't doing what
> you want it to, and the nouveau driver is being handed an intel
> device. This does not work well. Fixing this will require tracing
> through the va winsys code which to figure out how it invokes the
> loader.
>
>
>
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/frontends/va/context.c#n111
>
> For the DRM/rendernodes "platform", it will just take whatever fd
it
> is given. vainfo appears to give it a fixed device:
>
>
>
https://github.com/intel/libva-utils/blob/master/common/va_display_drm.c#L39
>
> However it looks like you can pass in --device /dev/dri/renderD129 or
> whatever the right one is, which should pass in the right render node,
> as seen here:
>
> https://github.com/intel/libva-utils/blob/master/common/va_display.c#L80
>
> Note that I've never tried this, just did a few google searches to
> find this stuff.
>
>
Brilliant googling. get_drm_device_name() does seem to do a crude argparse
of "--device"

So I ran

$ DRI_PRIME=1 LIBVA_DRIVER_NAME=nouveau vainfo --device /dev/dri/renderD128

*vainfo: unrecognized option '--device'*Show information from VA-API
driver
Usage: vainfo --help
        --help print this message

Usage: vainfo [options]
Display options:
        --display display | help         Show information for the specified
display, or the available display list

*        --device device                  Set device name, only available
under drm display*


What does this mean?

 Note that I also ran


$ nm -Dn -o /usr/lib/x86_64-linux-gnu/libva*|grep get_drm_device_name

Didn't get anything...

Cheers,
>
>   -ilia
>

-- 
Analabha Roy
Assistant Professor
Department of Physics
<http://www.buruniv.ac.in/academics/department/physics>
The University of Burdwan <http://www.buruniv.ac.in/>
Golapbag Campus, Barddhaman 713104
West Bengal, India
Emails: daneel at utexas.edu, aroy at phys.buruniv.ac.in, hariseldon99 at
gmail.com
Webpage: http://www.ph.utexas.edu/~daneel/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20200901/9bf947ab/attachment.htm>