[FFmpeg-devel,3/3] hwcontext: Add test for device creation and derivation

Submitted by Michael Niedermayer on May 15, 2018, 2:16 a.m.

Details

Message ID 20180515021638.GW20131@michaelspb
State New
Headers show

Commit Message

Michael Niedermayer May 15, 2018, 2:16 a.m.
On Mon, May 14, 2018 at 10:58:58PM +0100, Mark Thompson wrote:
> This uses any devices it can find on the host system - on a system with no
> hardware device support or in builds with no support included it will do
> nothing and pass.
> ---
>  libavutil/Makefile         |   1 +
>  libavutil/tests/hwdevice.c | 234 +++++++++++++++++++++++++++++++++++++++++++++
>  tests/fate/libavutil.mak   |   4 +
>  tests/ref/fate/hwdevice    |   1 +
>  4 files changed, 240 insertions(+)
>  create mode 100644 libavutil/tests/hwdevice.c
>  create mode 100644 tests/ref/fate/hwdevice

does not work here (over ssh if that matters)
Test hwdevice failed. Look at tests/data/fate/hwdevice.err for details.
X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  154 (DRI2)
  Minor opcode of failed request:  1 (DRI2Connect)
  Serial number of failed request:  11
  Current serial number in output stream:  11
make: *** [fate-hwdevice] Error 1

[...]

Comments

Mark Thompson May 15, 2018, 9:31 a.m.
On 15/05/18 03:16, Michael Niedermayer wrote:
> On Mon, May 14, 2018 at 10:58:58PM +0100, Mark Thompson wrote:
>> This uses any devices it can find on the host system - on a system with no
>> hardware device support or in builds with no support included it will do
>> nothing and pass.
>> ---
>>  libavutil/Makefile         |   1 +
>>  libavutil/tests/hwdevice.c | 234 +++++++++++++++++++++++++++++++++++++++++++++
>>  tests/fate/libavutil.mak   |   4 +
>>  tests/ref/fate/hwdevice    |   1 +
>>  4 files changed, 240 insertions(+)
>>  create mode 100644 libavutil/tests/hwdevice.c
>>  create mode 100644 tests/ref/fate/hwdevice
> 
> does not work here (over ssh if that matters)
> --- ./tests/ref/fate/hwdevice	2018-05-15 04:12:44.462164238 +0200
> +++ tests/data/fate/hwdevice	2018-05-15 04:13:04.606164152 +0200
> @@ -1 +0,0 @@
> -Passed.
> Test hwdevice failed. Look at tests/data/fate/hwdevice.err for details.
> X Error of failed request:  BadRequest (invalid request code or no such operation)
>   Major opcode of failed request:  154 (DRI2)
>   Minor opcode of failed request:  1 (DRI2Connect)
>   Serial number of failed request:  11
>   Current serial number in output stream:  11
> make: *** [fate-hwdevice] Error 1

In some sense this is success - the test found that some hardware device doesn't work in your setup.

This is presumably either libva or some OpenCL ICD running with X forwarding enabled?  I'm aware that they can blindly make Xlib calls which end up in the default error handling (call abort()) when they fail - I run "DISPLAY= ./ffmpeg..." when in an X forwarded session to avoid this.

I think that means there should be something gating this test (and any other hardware tests) - how about a configure option --(en|dis)able-hw-tests, with default value the same as autodetect?  (I think that has the right properties?  Or it could just be disabled by default, but that would probably mean it would never get run even in places where it should be.)

- Mark
Hendrik Leppkes May 15, 2018, 9:36 a.m.
On Tue, May 15, 2018 at 11:31 AM, Mark Thompson <sw@jkqxz.net> wrote:
>
> I think that means there should be something gating this test (and any other hardware tests) - how about a configure option --(en|dis)able-hw-tests, with default value the same as autodetect?  (I think that has the right properties?  Or it could just be disabled by default, but that would probably mean it would never get run even in places where it should be.)
>

I don't think having that flag in configure makes a lot of sense. It
should probably just be a separate make target and not be included in
"make fate". Default fate should test our code, not external libraries
or drivers.
If someone wants to set this up on their fate box after making sure it
actually worked at least during setup, they can easily add it as a
second target to the make invocation - ie. "make fate fate-hw" or
something like that (and the fate.sh script probably most of us use
for that could be extended to take that as an option), and both get
accumulated in one result.

- Hendrik
Michael Niedermayer May 15, 2018, 12:04 p.m.
On Tue, May 15, 2018 at 11:36:13AM +0200, Hendrik Leppkes wrote:
> On Tue, May 15, 2018 at 11:31 AM, Mark Thompson <sw@jkqxz.net> wrote:
> >
> > I think that means there should be something gating this test (and any other hardware tests) - how about a configure option --(en|dis)able-hw-tests, with default value the same as autodetect?  (I think that has the right properties?  Or it could just be disabled by default, but that would probably mean it would never get run even in places where it should be.)
> >
> 
> I don't think having that flag in configure makes a lot of sense. It
> should probably just be a separate make target and not be included in
> "make fate". Default fate should test our code, not external libraries
> or drivers.
> If someone wants to set this up on their fate box after making sure it
> actually worked at least during setup, they can easily add it as a
> second target to the make invocation - ie. "make fate fate-hw" or
> something like that (and the fate.sh script probably most of us use
> for that could be extended to take that as an option), and both get
> accumulated in one result.

sounds good. 
I would be fine with a configure option too as an alternative but i think
its better if changing it doesnt require redoing configure and the whole
build

thx

Patch hide | download patch | download mbox

--- ./tests/ref/fate/hwdevice	2018-05-15 04:12:44.462164238 +0200
+++ tests/data/fate/hwdevice	2018-05-15 04:13:04.606164152 +0200
@@ -1 +0,0 @@ 
-Passed.