IEGD 10.3 VA is NOT thread safe (crashing on iegd_drv_video.so), regression to old PSB driver

[AStrz1]

Sorry for another post, but this is last bug report for new IEGD drivers. Hope you don't mind that.

Latest IEGD 10.3 VA API drivers are NOT thread safe, which means it is not possible to use VA API functions in several threads in one application, like doing several stream video decompression on separate therads (ie using FFmpeg VA API). IEGD 10.3 crashes my application in various Xorg communication related places.

Drivers that crash are from IEGD 10.3 Gallium 0.1, pipe/psb/Poulsbo on IEGD

NOTE HOWEVER using old drivers from 2008 available as psb-kernel-source_4.41.1 package version Mesa DRI Intel(R) GMA500 20081116 - 5.0.1.0046 x86/MMX/SSE2 it works absolutely fine with multiple threads.

So it is regression in the new drivers based on Gallum.

Is it any way to bring back mutlithreaded support to new drivers??

Regards,

Adam

P.S. Here are crash logs from my VA API based app running on IEGD 10.3 VA drivers... that can help you:

../../src/xcb_io.c:543: _XRead: Assertion `dpy->xcb->reply_consumed + size <= dpy->xcb->reply_length' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x71cccb70 (LWP 1112)] 0x4001d422 in __kernel_vsyscall () (gdb) bt # 0 0x4001d422 in __kernel_vsyscall () # 1 0x401974d1 in raise () from /lib/tls/i686/cmov/libc.so.6 # 2 0x4019a932 in abort () from /lib/tls/i686/cmov/libc.so.6 # 3 0x40190648 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 # 4 0x4060d8f3 in _XRead () from /usr/lib/libX11.so.6 # 5 0x61a677a7 in ?? () from /usr/lib/va/drivers/iegd_drv_video.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) ../../src/xcb_io.c:176: process_responses: Assertion `!(req && current_request && !(((long) (req->sequence) - (long) (current_request)) <= 0))' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x71cccb70 (LWP 1118)] 0x4001d422 in __kernel_vsyscall () (gdb) bt # 0 0x4001d422 in __kernel_vsyscall () # 1 0x401974d1 in raise () from /lib/tls/i686/cmov/libc.so.6 # 2 0x4019a932 in abort () from /lib/tls/i686/cmov/libc.so.6 # 3 0x40190648 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 # 4 0x4060dfd3 in ?? () from /usr/lib/libX11.so.6 # 5 0x4060e526 in _XReply () from /usr/lib/libX11.so.6 # 6 0x61a67765 in ?? () from /usr/lib/va/drivers/iegd_drv_video.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) Intel(r) Embedded Graphics Driver 10.2 Build 1448: [Error: Out of memory]. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 308 requests (308 known processed) with 0 events remaining. X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 5 (X_DestroySubwindows) Serial number of failed request: 343 Current serial number in output stream: 343 XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 306 requests (306 known processed) with 0 events remaining. Intel(r) Embedded Graphics Driver 10.2 Build 1448: [Error: Out of memory]. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 381 requests (381 known processed) with 0 events remaining.</pre>

[Kirk_B_Intel]

We are always interested in hearing about any questions or issues that people have with our products.

First off, you should know that the GMA500 driver is a totally different code base than IEGD. IEGD is developed and supported by the Embedded Products Division for embedded applications with long life support needs. The other is likely from our Ultra Mobile Group (MID guys) and does not have any sustaining support possible.

Next, I believe the VA API is not multi-threaded at the API level in IEGD by design. It was not a requirement that any potential customers needed when it was added to the IEGD driver. It does share some code silimarities to the UMG codebase but has been modified to work well within the IEGD driver framework. If you think the VA API interface in IEGD or future versions, you should try to influence your platform segment via your Intel field reps to get the need know from the platform segment point of view. This will help us to prioritize the huge number of enhancements we want to do to the driver but just do not have enough resources to do all of them (like this).

[AStrz1]

I know that old UMG driver is a different driver. But the one (Gallium based) coming IEGD is supposed to replace it. So I believe IEGD should not be any worse than older PSB(UMG) driver, since the old one is not supported anymore and IEGD is the "right" one.

But in this case it is, because I am unable to use VAAPI acceleration in multi-threaded application.

I am using FFmpeg (which is notably the only one library having good VAAPI support available to public) for H.264 playback. I have no other choice but to use multiple threads because VAAPI calls are kind of synchronous (lock the application/CPU), and FFmpeg uses callback mechanism to access VAAPI. If I try to do it all together in single thread it does NOT crash, however the performance is very very poor (so the CPU usage). So the only choice it to use multiple threads to fully use hw potential. Moreover if you look at the most of FFmpeg samples (SDL FFmpeg player) or applications most of them are multithreaded, so it means most of them will crash with IEGD when coupling them with VAAPI.

I applied for CNDA here, but my application is still pending (somebody was supposed to contact me?). It is actually my client who buys intel HW (US15W boxes), I am doing the software for them. So I asked them to apply for CNDA too.

Is there anything else particular we can do to influence anyhow IEGD drivers development.

I don't want to contact Intel sales in my country, because they are not responsible for development and technical stuff, so they won't be any help.

We get our http://www.portwell.com/products/detail.asp?CUSTCHAR1=WEBS-1010 http://www.portwell.com/products/detail.asp?CUSTCHAR1=WEBS-1010" rel="nofollow" target="_blank">WEBS-1010 boxes from Portwell, but those guys get the chips from you and assemble them in nice box, but cannot help either.

[Kirk_B_Intel]

The older US15W driver from UMG is also Gallium based- with IEGD, we have just done a better job of utilizing it. We are starting to move away from Gallium toward a newer architecture that better supports the US15w type graphics engine.

For FFMGEG, obviously the Splitted Desktop patches are needed to make it VA API aware. We are trying to move that back into the main code base but that will be done when it gets done. Those are needed to use the hardware for decode rather than the CPU in software. We do not see excessive CPU utilization but we may not be trying to single thread multiple accesses to the decoder. I have not found a way to help you make multi-threaded accesses work better. I wonder if you trying to get the chip/driver to do more than it was designed to do?

There are also VA API aware codecs available for Gstreamer (from Fluendo) and for Helix (eval ones from us and productions ones from Real Player). Maybe those would help your situation. Since we do not know in detail what you are trying to accomplish or the way you are doing it, we just cannot help much more.

[AStrz1]

Kirk wrote:

For FFMGEG, obviously the Splitted Desktop patches are needed to make it VA API aware. We are trying to move that back into the main code base but that will be done when it gets done. Those are needed to use the hardware for decode rather than the CPU in software. We do not see excessive CPU utilization but we may not be trying to single thread multiple accesses to the decoder. I have not found a way to help you make multi-threaded accesses work better. I wonder if you trying to get the chip/driver to do more than it was designed to do?

My application displays variable number of live H.264 streams, the architecture is following:

--+ main thread displaying OpenGL based interface and video from texture queue

|

+-- 1st video decode thread (using FFmpeg) pushing decoded frames as OpenGL textures into render queue

...

+-- n-th video decode thread ....

When using software decoding I have no problem as I comply with OpenGL limitation that OpenGL command buffer/commands may be issued from single thread for single OpenGL context, which is only main thread that deals with OpenGL.

All other threads do network handling and H.264 decoding, and produce image buffers/textures which are used later on by main thread in OpenGL rendering. And I have to use threads to get best performance here as FFmpeg decode calls lock at various places, such as network reading, etc. and of course I want to get use of multiple cores if present.

However when using IEGD VAAPI driver (yes I use Splitted Desktop version of VAAPI) with my application, driver calls seem to interfere themselves causing application crash. Surprisingly old UMG driver works well with my multithreaded architecture. But this driver is a DEAD END.

So replying you, anyway (1st) I don't see anything wrong with my architecture, this is architecture with separate decoding threads is well known, and it is the way FFplay (reference FFmpeg player) is implemented, (2nd) I don't think I am trying to do anything more than the chip was supposed to do as it works fine with UMG driver (so it is IEGD fault), (3rd) decoding more than single stream is nothing extraordinary, many SetTopBoxes offer PIP functionality and such require multiple streams decoding at once.

Kirk wrote:

There are also VA API aware codecs available for Gstreamer (from Fluendo) and for Helix (eval ones from us and productions ones from Real Player). Maybe those would help your situation. Since we do not know in detail what you are trying to accomplish or the way you are doing it, we just cannot help much more.

I'll give them a try. Thanks a lot for this information. Maybe they will integrate better than FFmpeg, that has few minor flaws.

[FMcNu1]

Hello http://embedded.communities.intel.com http://embedded.communities.intel.com target="_self">onomatopej:

Welcome to the Intel® Embedded Community.

Regarding your request for CNDA with Intel, I assume you are referring to requesting Privileged Account status with Intel® Embedded Design Center. Can you advise when you requested? It typically can take up to 10 working days to process a request. Do you know if your client's request was approved?

Also I would encourage you to make contact with the local Intel representatives in your country. Even though they are not directly responsible for technical development, Intel does rely on the field representatives as the "eyes and ears" to the customer and they do influence the product roadmap. The same is true for board companies like Portwell. They are members of the Intel® Embedded Alliance (Intel's trusted ecosystem), and they have a close working relationship with Intel.

Thanks for your continued interest in Intel products.

Felix

[KSupe]

Any news on this subject?? We are walking in circles since few months because of this issue, we are sent forth to Intel representative, he is sending us to embedded support forums, then we are sent back to Intel representative.

When we can have our hands on IEGD with fixed multithreading for VAAPI, this may be beta, or whatever. Please respond.

Regards,

Cerber Poland