Similar to:
bfb6b98ed6 exclude vgem node and invalid drm node in vainfo
But adapted to use drmGetDevices2() for more generic handling.
It's possible to have a vgem node at 128, and the VA-API node is at 129,
for example.
Signed-off-by: Brian Norris <briannorris@chromium.org>
In Vaapi unit test VAAPIQueryConfig, CheckEntrypointsForProfile
the default initialization value chnaged from zero to VAProfileNone
as zero is a valid profile matches with MPEG2Simple and this unit
test misinterpret it as part of return value from vaQueryConfigProfiles
Signed-off-by: Himanshu Nayak <himanshu.nayak@amd.corp-partner.google.com>
Reduces test runtime on my radeonsi system by 20%. Likely a lot of
the improvement here is from being able to userspace recycle the BOs
that are being allocated.
Fixes: #247
I don't love the way I have the fixture usage brought in, and maybe
this should be a subclass or something to get this behavior. I'm not
great at C++, though.
This is commit e2239ee6043f73722e7aa812a459f54a28552929 from git.
This brings in SetUpTestSuite support. Note that it required a few
minor updates to the tests mostly to quiet deprecation warnings, and
also to include a header we need that used to be brought in by gtest.
it is used to fix such issue, version from libva-utils and libva is different.
because older libva-utils should also work with newer libva.
Signed-off-by: Carl Zhang <carl.zhang@intel.com>
This fixes a GCC 10.0.1 compiler error for the
VA_STATUS_ERROR_UNKNOWN 0xFFFFFFFF conversion from
unsigned to int.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
drmDevicePaths is static/constant and only used in one
method (getDisplay). Thus, it is unnecessary to declare
it as a member variable. Instead, just declare and
initialize in getDisplay and use proper C++ semantics.
This also fixes a GCC 10.0.1 error due to improper
C++11 constructor list-initialization syntax:
error: list-initialize for non-class type must not
be parenthesized.
Fixes#191
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Since intel/libva#250, driver names are no longer restricted
to a whitelist. Thus, any driver name is legal except for
a few corner cases (i.e. empty name and name > 255 chars).
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Conformance tests should be as generic as possible and
not assume availability of any specific driver.
Fixes#93Fixes#94Fixes#95
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
v2: remove gtest meson file
v3: install binaries
respect disabled libraries
apply cpp_args to all test files
add full version
v4: define HAVE_* macros
v5: Downgrade meson requirement to 0.42.0
Driver should allow 0x0 (i.e. VA_ENC_PACKED_HEADER_NONE) value
for the VAConfigAttribEncPackedHeaders attribute during
vaCreateConfig when the attribute is supported.
This test supercedes intel/intel-vaapi-driver#361
Also see intel/intel-vaapi-driver#358 and intel/libva#178
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Drivers aren't required to implement display attribute
support. Thus, handle and validate paths where this
is the case.
Fixes#96
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Allow custom skip test message.
Basic checks to determine whether a test should be
skipped could fail (e.g. query profiles/entrypoints
to determine if test should be skipped). Thus, don't
log test as skipped if there are any failures before
the test fixture destructs.
Fixes#99
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
vaCreateBuffer needs the sizeof the actual buffer
data structure associated with the buffer type, which
could be profile specific.
Previous test logic was passing the sizeof the
buffer "type" enum, which is wrong.
Fix the tests so that the correct buffer size is
calculated based on profile specific buffer types.
Several buffer types were removed from the previous test
parameters since their size may be application specific,
arbitrary, and/or require additional setup beyond the
capabilities of the current buffer test cases. These
rules will need to be fleshed-out and tests for them
added later on.
Fixes#89
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
The result of doGetMaxNumConfigAttribs is only needed
by queryConfigAttributes. Thus, just call
vaMaxNumConfigAttributes in queryConfigAttributes when
necessary (it should have low call overhead). This
also removes the need to use a member state variable.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Existing profile/entrypoint methods require too
much state overhead in the fixture and force tests
to make multiple calls to different methods to get
the information they need. Thus, add new methods
for profile/entrypoint queries so tests can regain
more control and simplicity. These new methods
also do not require member variables to operate.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Define valid bitmasks for remaining read/write config
attributes...
VAConfigAttribEncPackedHeaders
VAConfigAttribEncInterlaced
VAConfigAttribFEIFunctionType
This will ensure VAAPIGetCreateConfig/CreateConfigWithAttributes
test cases only use one bitmask for each supported value when
calling vaCreateConfig for these bitfield config attributes.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
These fixture methods have been replaced with consolidated
and more flexible methods and are no longer used.
Also, remove associated legacy member variables.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Take into account bitfield attributes when creating
config and surfaces.
Use new fixture methods for greater control in test
cases.
Fixes#91Fixes#92
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Consolidate surface methods with refactored logic to allow
tests to take more control of parameters. Also, the
existing doCreateSurfaces suffers from a surface format
logic bug. The new consolidated createSurfaces does not
suffer from this bug.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Use the new config methods from fixture.
Also, properly handle config attributes that use bitfields.
That is, some attributes require only one bitmask/value
for vaCreateConfig, therefore we cannot directly use
the attribute returned from vaGetConfigAttributes since
those bitfield attributes will return a bitfield value with
"all" OR'd supported bitmask choices.
Fixes#86
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Carl Zhang