Running hello-encode example on Intel UHD Graphics 620

[miwa_agc]

From what I have read in the online documentation I have drawn the conclusion that the oneVPL dispatcher can be used on platforms with older GPUs, and there it will load the imsdk runtime (for hardware encode). So I tried building the hello-encode example on a system with Intel UHD Graphics 620 (gen 8 GPU), and modified the source as to require API version 1.35 (last supported imsdk runtime) instead of 2.2 as was originally in the example. This was the only modification done.

This worked fine for creating the session and initializing the encoder, but then the call to MFXMemory_GetSurfaceForEncode() fails with error MFX_ERR_INVALID_HANDLE. The session was valid for initializing the encoder, so why is it invalid when getting the surface? Is this a known bug?

I am running oneVPL 2022.0.0.

[miwa_agc]

I can add the output of the program:

libva info: VA-API version 1.13.0

libva info: User environment variable requested driver 'iHD'

libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so

libva info: Found init function __vaDriverInit_1_13

libva info: va_openDriver() returns 0

Implementation details:

  ApiVersion:           1.35  

  Implementation type:  HW

  AccelerationMode via: VAAPI

  Path: /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1.35

libva info: VA-API version 1.13.0

libva info: User environment variable requested driver 'iHD'

libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so

libva info: Found init function __vaDriverInit_1_13

libva info: va_openDriver() returns 0

Encoding out.raw -> out.h264

Input colorspace: NV12

Could not get encode surface

Encoded 0 frames

[miwa_agc]

As additonal info, the printed output of running hello-encode on my system when it fails:

libva info: VA-API version 1.13.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0
Implementation details:
  ApiVersion:           1.35  
  Implementation type:  HW
  AccelerationMode via: VAAPI
  Path: /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1.35

libva info: VA-API version 1.13.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0
Encoding out.raw -> out.h264
Input colorspace: NV12
Could not get encode surface
Encoded 0 frames

---

[AthiraM_Intel]

Hi,

Thank you for posting in Intel Communities.

Could you please share the following details:

1. OS details
2. Sample reproducer code that contains the changes you have made.
3. exact steps and commands you used.

Thanks

[miwa_agc]

Hi, thanks for your reply, here is further information:

1. OS is Ubuntu 20.04.4, oneVPL version is 2022.1.0

2. I used the hello-encode example code in oneVPL 2022.1.0, with this patch:

index db49242..c2a797b 100644
--- a/hello-encode.cpp.orig
+++ b/hello-encode.cpp
@@ -16,8 +16,8 @@
 #define FRAMERATE                  30
 #define OUTPUT_FILE                "out.h265"
 #define BITSTREAM_BUFFER_SIZE      2000000
-#define MAJOR_API_VERSION_REQUIRED 2
-#define MINOR_API_VERSION_REQUIRED 2
+#define MAJOR_API_VERSION_REQUIRED 1
+#define MINOR_API_VERSION_REQUIRED 35
 
 void Usage(void) {
     printf("\n");
@@ -161,6 +161,7 @@ int main(int argc, char *argv[]) {
         // Load a new frame if not draining
         if (isDraining == false) {
             sts = MFXMemory_GetSurfaceForEncode(session, &encSurfaceIn);
+            printf("MFXMemory_GetSurfaceForEncode() returned %d\n", sts);
             VERIFY(MFX_ERR_NONE == sts, "Could not get encode surface");
 
             sts = ReadRawFrame_InternalMem(encSurfaceIn, source);

3. Here are the full steps in detail:

I copied /opt/intel/oneapi/vpl/latest/examples/hello/ to a temporary directory (where 'latest' points to '2022.1.0')

Then run

mkdir build && cd build && cmake ..

which gives output:

-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Default CMAKE_BUILD_TYPE not set using Release with Debug Info
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") 
-- Checking for modules 'libva>=1.2;libva-drm>=1.2'
--   Found libva, version 1.14.0
--   Found libva-drm, version 1.14.0
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE  
-- Configuring done
-- Generating done

Then run 'make' and then try running the app:

./hello-encode -hw -i out.raw -w 1920 -h 1080
libva info: VA-API version 1.14.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Cannot create session -- no implementations meet selection criteria
Encoded 0 frames

  This is due to the API requirements in the app, so I applied the patch that I showed above. Running make and then running the app again:

./hello-encode -hw -i out.raw -w 1920 -h 1080
libva info: VA-API version 1.14.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Implementation details:
  ApiVersion:           1.35  
  Implementation type:  HW
  AccelerationMode via: VAAPI
  Path: /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1.35

libva info: VA-API version 1.14.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Encoding out.raw -> out.h265
Input colorspace: NV12
MFXMemory_GetSurfaceForEncode() returned -6
Could not get encode surface
Encoded 0 frames

I can add that I have tried all this on a different machine with Intel UHD graphics 770 that uses the oneVPL runtime and that works without any problems. Also, running the app with the sw option works as well, see here with the patch applied:

./hello-encode -sw -i out.raw -w 1920 -h 1080
libva info: VA-API version 1.14.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Implementation details:
  ApiVersion:           2.6  
  Implementation type:  SW
  AccelerationMode via: NA 
  Path: /opt/intel/oneapi/vpl/2022.1.0/lib/libvplswref64.so.1

Encoding out.raw -> out.h265
Input colorspace: I420 (aka yuv420p)
MFXMemory_GetSurfaceForEncode() returned 0
MFXMemory_GetSurfaceForEncode() returned 0
...
MFXMemory_GetSurfaceForEncode() returned 0
Encoded 1297 frames

[miwa_agc]

Hi, thanks for your reply, here is further information:

1. OS is Ubuntu 20.04.4, oneVPL version is 2022.1.0

2. I used the hello-encode example code in oneVPL 2022.1.0, with this patch:

index db49242..c2a797b 100644
--- a/hello-encode.cpp.orig
+++ b/hello-encode.cpp
@@ -16,8 +16,8 @@
#define FRAMERATE 30
#define OUTPUT_FILE "out.h265"
#define BITSTREAM_BUFFER_SIZE 2000000
-#define MAJOR_API_VERSION_REQUIRED 2
-#define MINOR_API_VERSION_REQUIRED 2
+#define MAJOR_API_VERSION_REQUIRED 1
+#define MINOR_API_VERSION_REQUIRED 35

void Usage(void) {
printf("\n");
@@ -161,6 +161,7 @@ int main(int argc, char *argv[]) {
// Load a new frame if not draining
if (isDraining == false) {
sts = MFXMemory_GetSurfaceForEncode(session, &encSurfaceIn);
+ printf("MFXMemory_GetSurfaceForEncode() returned %d\n", sts);
VERIFY(MFX_ERR_NONE == sts, "Could not get encode surface");

sts = ReadRawFrame_InternalMem(encSurfaceIn, source);

3. Here are the full steps in detail:

I copied /opt/intel/oneapi/vpl/latest/examples/hello/ to a temporary directory (where 'latest' points to '2022.1.0')

Then run

mkdir build && cd build && cmake ..

which gives output:

-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Default CMAKE_BUILD_TYPE not set using Release with Debug Info
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for modules 'libva>=1.2;libva-drm>=1.2'
-- Found libva, version 1.14.0
-- Found libva-drm, version 1.14.0
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Configuring done
-- Generating done

Then run 'make' and then try running the app:

./hello-encode -hw -i out.raw -w 1920 -h 1080
libva info: VA-API version 1.14.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Cannot create session -- no implementations meet selection criteria
Encoded 0 frames

This is due to the API requirements in the app, so I applied the patch that I showed above. Running 'make' and then running the app again:

./hello-encode -hw -i out.raw -w 1920 -h 1080
libva info: VA-API version 1.14.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Implementation details:
ApiVersion: 1.35
Implementation type: HW
AccelerationMode via: VAAPI
Path: /usr/lib/x86_64-linux-gnu/libmfxhw64.so.1.35

libva info: VA-API version 1.14.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Encoding out.raw -> out.h265
Input colorspace: NV12
MFXMemory_GetSurfaceForEncode() returned -6
Could not get encode surface
Encoded 0 frames

I can add that I have tried all this on a different machine with Intel UHD graphics 770 that uses the oneVPL runtime and that works without any problems. Also, running the app with the sw option works as well, see here with the patch applied:

./hello-encode -sw -i out.raw -w 1920 -h 1080
libva info: VA-API version 1.14.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Implementation details:
ApiVersion: 2.6
Implementation type: SW
AccelerationMode via: NA
Path: /opt/intel/oneapi/vpl/2022.1.0/lib/libvplswref64.so.1

Encoding out.raw -> out.h265
Input colorspace: I420 (aka yuv420p)
MFXMemory_GetSurfaceForEncode() returned 0
MFXMemory_GetSurfaceForEncode() returned 0
...
MFXMemory_GetSurfaceForEncode() returned 0
Encoded 1297 frames

[miwa_agc]

I have been trying to reply to this but my replies keeps being marked as spam and deleted. Can you help me with that?

[miwa_agc]

Thank you, I see my reply attempts have all now shown up, so there are duplicates, but at least they are visible now.

[AthiraM_Intel]

Hi,

Thank you for sharing the details. we are checking on it internally.

Thanks

[AthiraM_Intel]

Hi,

We are able to reproduce the issue from our end. You can source the oneAPI environment to run the program successfully.

Please use the below command to source oneAPI environment

source /opt/intel/oneapi/setvars.sh

Please find the below screenshot for reference.

Thanks

[miwa_agc]

Hi,

I have sourced that file already, that does not appear to be my problem. Also, it looks in your screenshot that you are using the sw implementation, but that one works fine for me too, as previously described. What does not work is the hw implementation. Can you reproduce this problem with the hw implementation?

[AthiraM_Intel]

Hi,

We are able to reproduce the issue with hw implementation in ubuntu 20.04. We are working on this internally. We will get back to you soon with an update.

Thanks

[AthiraM_Intel · Accepted solution]

Hi,

You should use the samples under examples/coreAPI for support on the full range of HW. These samples use the 1.35 API which supports the MSDK GPU implementation on older HW and the VPL GPU implementation on newer HW. 

The samples under examples/hello use the 2.x API, which is only available from the VPL GPU implementation and only supports Xe and newer hardware. They check the API level because they depend on features added in the 2.x API. They are not intended to be compatible with legacy HW.

Hope this clarifies your question. If you have any further issue please let us know.

Thanks.

[AthiraM_Intel]

Hi,

Could you please give us an update? Can we close this case?

Thanks

[miwa_agc]

Hi,

yes that makes sense, the difference between the legacy example and the newest example is the addition in the latter of the internal memory allocator, the rest seems to be much the same. I have not yet tested the legacy example but I'm sure this is the correct answer, thank you very much for your help, you can close this case.

[AthiraM_Intel]

Hi,

Thanks for accepting our solution. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.

Thanks