Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 01-16-09, 12:22 PM   #13
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: VDPAU: multithreading issues

Testing with the following rpms on Fedora 10 repro's the hang/deadlock issue:

libX11-1.1.4-5.fc10.i386
libxcb-1.1.91-5.fc10.i386

With a short video clip I have (video1.ts), xine will hang after playing this video just a few times. I experienced hang the 6th, 3rd, 3rd time I played the video in 3 test runs.

If I recompile the libX11 rpm with "configure --without-xcb", I can run xine 3 separate times, each playing the video 50 times without a hang.

If I use the current Fedora rawhide rpms:

libX11-1.1.99.2-2.fc11.i386.rpm
libxcb-1.1.93-2.fc11.i386.rpm

on the same Fedora 10 test machine, I can also run xine 3 separate times, each playing the video 50 times without a hang.

So, I believe this confirms that it's a libX11/libxcb bug.
Stephen Warren is offline   Reply With Quote
Old 01-16-09, 12:47 PM   #14
crisalide
Registered User
 
Join Date: Dec 2008
Posts: 173
Default Re: VDPAU: multithreading issues

Ok, thanx for clarifying this Stephen.
crisalide is offline   Reply With Quote
Old 01-16-09, 03:20 PM   #15
rnissl
Registered User
 
Join Date: Jun 2005
Posts: 36
Default Re: VDPAU: multithreading issues

Hi,

Quote:
Originally Posted by Stephen Warren View Post
Some other information: libX11 and libX11-xcb clearly are intended to operate correctly in a multi-threaded environment without the application/... calling XLockDisplay/XUnlockDisplay around all X APIs; there is a *considerable* amount of locking code in libX11/libX11-xcb that simply would not be present if it could instead be implemented by a simple mutex in XLockDisplay.
Would you be so kind and point me to documentation which says that XLockDisplay()/XUnlockDisplay() are nolonger necessary for mulithreaded application where multiple threads make calls into libX11?

I think, that the lock code in an xcb based libX11 is there to integrate it properly into the xcb system. If xcb would simply delegate the lock to the driver, then what would be the benefit of xcb?

In my opinion, the problem ist that your code calls your driver's implementation of LockDisplay() directly and that doesn't match what the xcb based libX11 expects, as it's XLockDisplay() implementation is different. Hence, we run into this deadlock trouble.

Bye.
rnissl is offline   Reply With Quote
Old 01-16-09, 03:32 PM   #16
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: VDPAU: multithreading issues

Quote:
Originally Posted by rnissl View Post
()/XUnlockDisplay() are nolonger necessary for mulithreaded application where multiple threads make calls into libX11?
Well, more to the point, I haven't seen any documentation that states XLockDisplay must be used by a multi-threaded application. The man page for that function only states that XInitThread *must* be used, and describes what XLockDisplay does; never saying that it must be used.

Other developers at NVIDIA have pointed out that XLockDisplay's intended purpose is for cases when multiple separate Xlib calls must be made atomically by a thread in the application. For example, perhaps you want to XGet...() something, then XSet...() it, but don't want other threads performing the same XSet...() in between.

My belief now is that people experimentally found that they required XLockDisplay around all X calls becaue of bugs in libX11/xcb. Subsequent to that, this bug workaround became "known" as a requirement of the API definition, in addition to being a requirement of the buggy implementation.

Quote:
Originally Posted by rnissl View Post
I think, that the lock code in an xcb based libX11 is there to integrate it properly into the xcb system. If xcb would simply delegate the lock to the driver, then what would be the benefit of xcb?
I don't know why xcb was created, so I can't speak to its benefits. However, looking at the code, there is far more to locking, both in pure libX11, and libxcb, than simple integration between the two.

Quote:
Originally Posted by rnissl View Post
In my opinion, the problem ist that your code calls your driver's implementation of LockDisplay() directly and that doesn't match what the xcb based libX11 expects, as it's XLockDisplay() implementation is different. Hence, we run into this deadlock trouble.
The VDPAU implementation calls the same LockDisplay as any other X client library, including the top-level application-visible functions in libX11 itself. The implementation of LockDisplay certainly is different to XLockDisplay. This allows certain parts of libX11 to run in parallel in different threads where possible, to maximise performance. This is true of both pure libX11 and libX11/xcb.
Stephen Warren is offline   Reply With Quote
Old 01-16-09, 05:14 PM   #17
rnissl
Registered User
 
Join Date: Jun 2005
Posts: 36
Default Re: VDPAU: multithreading issues

Hi,

Quote:
Originally Posted by Stephen Warren View Post
Well, more to the point, I haven't seen any documentation that states XLockDisplay must be used by a multi-threaded application. The man page for that function only states that XInitThread *must* be used, and describes what XLockDisplay does; never saying that it must be used.
Quote:
Originally Posted by man page
The XLockDisplay function locks out all other threads from using the specified display.
In my understanding, this means any use of the display, not just XGet...() / XSet...() pairs.

Quote:
Originally Posted by Stephen Warren View Post
Other developers at NVIDIA have pointed out that XLockDisplay's intended purpose is for cases when multiple separate Xlib calls must be made atomically by a thread in the application. For example, perhaps you want to XGet...() something, then XSet...() it, but don't want other threads performing the same XSet...() in between.
Hmm, this page proves your understanding:
Quote:
Originally Posted by http://tronche.com/gui/x/xlib/display/threads.html
To lock a display across several Xlib calls, use XLockDisplay().
Quote:
Originally Posted by Stephen Warren View Post
My belief now is that people experimentally found that they required XLockDisplay around all X calls becaue of bugs in libX11/xcb. Subsequent to that, this bug workaround became "known" as a requirement of the API definition, in addition to being a requirement of the buggy implementation.
Well, then xine-ui does way to many XLockDisplay() calls.

Quote:
Originally Posted by Stephen Warren View Post
I don't know why xcb was created, so I can't speak to its benefits. However, looking at the code, there is far more to locking, both in pure libX11, and libxcb, than simple integration between the two.
Wikipedia mentions at least this one:

Quote:
Originally Posted by http://en.wikipedia.org/wiki/XCB#Aims
facilitating better multithreading
Quote:
Originally Posted by Stephen Warren View Post
The VDPAU implementation calls the same LockDisplay as any other X client library, including the top-level application-visible functions in libX11 itself. The implementation of LockDisplay certainly is different to XLockDisplay. This allows certain parts of libX11 to run in parallel in different threads where possible, to maximise performance. This is true of both pure libX11 and libX11/xcb.
Well, it's just annoying if this is still a libX11/xcb bug. I had this problem with xine-lib using nVidia's xxmc on openSUSE 10.3 (the first release using libX11/xcb) and now, more than a year later, it bugs me again with vdpau on openSUSE 11.1.

Would you please try if the deadlocks go away if you call XLockDisplay() instead of your driver's LockDisplay()?

Bye.
rnissl is offline   Reply With Quote
Old 01-16-09, 05:25 PM   #18
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: VDPAU: multithreading issues

Quote:
Originally Posted by rnissl View Post
In my understanding, this means any use of the display, not just XGet...() / XSet...() pairs.
Absolutely; any threads calling XLockDisplay will be completely locked against each-other for all X APIs. My references to XGet*/XSet* were just an example of why one might want that functionality.

Quote:
Originally Posted by rnissl View Post
Well, it's just annoying if this is still a libX11/xcb bug. I had this problem with xine-lib using nVidia's xxmc on openSUSE 10.3 (the first release using libX11/xcb) and now, more than a year later, it bugs me again with vdpau on openSUSE 11.1.
Yes, I imagine the last 2-3 Fedora releases are also affected; I think they started using xcb in Fedora 8. Fedora 11 will be fixed. Some number of Ubuntu releases too judging by that bug report link.

Quote:
Originally Posted by rnissl View Post
Would you please try if the deadlocks go away if you call XLockDisplay() instead of your driver's LockDisplay()?
Yes, my original fix for this problem sprinkled XLockDisplay in a few places inside the VDPAU implementation, and I validated that this does work around the problem, just like placing them in xine/xine-lib before calling VDPAU works around the problem.

However, that change failed review, because people pointed out that this was an Xlib/xcb bug.
Stephen Warren is offline   Reply With Quote
Old 01-17-09, 04:38 PM   #19
jusst
Registered User
 
Join Date: Mar 2006
Posts: 99
Default Re: VDPAU: multithreading issues

I can confirm that the guarding is not needed with libxcb-1.1.93+ libx11-1.1.99.
So this really looks like an xcb bug.
jusst is offline   Reply With Quote
Old 01-18-09, 06:26 PM   #20
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: VDPAU: multithreading issues

For a little clarification, LockDisplay/UnlockDisplay control access to the display's request and reply queues. A typical library function looks like this:
Code:
  void XDoSomething(Display *dpy) {
    LockDisplay(dpy);
    GetReq(some request)
    _XReply(dpy, reply);
    Do something with reply
    UnlockDisplay(dpy);
  }
GetReq grabs a chunk out of the display connection's request queue, and _XReply flushes the queue and waits for the appropriate reply. Then, the function processes the reply and unlocks the display again. If _XReply needs to wait, it unlocks the display temporarily. The reason the locks work this way is so multiple threads can do this:
  1. Thread 1 sends Request A
  2. Thread 2 sends Request B
  3. Thread 1 receives Reply A
  4. Thread 2 receives Reply B
Note that two requests get sent before either thread receives a reply. If you put XLockDisplay around these calls, then Thread 2 can't send Request B until thread 1 has received Reply A from the X server.

All of libvdpau-nvidia's display functions are of the simple "send request, await reply" type.
AaronP is offline   Reply With Quote

Old 12-31-09, 04:11 AM   #21
Skywalker13
Registered User
 
Join Date: Dec 2009
Posts: 1
Default Re: VDPAU: multithreading issues

Quote:
Originally Posted by Stephen Warren View Post
I don't know why xcb was created, so I can't speak to its benefits. However, looking at the code, there is far more to locking, both in pure libX11, and libxcb, than simple integration between the two.
Hello,

There is no need for something like XInitThreads() with XCB. But with Xlib, libraries like xine-lib/vdpau can not be used in other libraries.

I'm working on an abstraction layer for mediaplayer over xine-lib/libvlc/... but it is not possible to use XInitThreads at the init of the lib. According to the fact that the user of this abstraction layer initializes Evas, Qt or GTK for example before the init of the lib.

Then I see here a very good reason (a major benefit) of using XCB in libvdpau instead of Xlib.
Skywalker13 is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
xorg locks-up with newest nvidia drivers w/ vdpau. theroot NVIDIA Linux 1 06-24-12 12:04 PM
Strange RedHat 7.3 issues with A7N266-C nforceuser NVIDIA Linux 8 09-27-02 04:16 PM
Overclocking issues... mcortz_2000 CPUs, Motherboards And Memory 5 09-16-02 04:41 PM
Is there a Microsoft patch for the refresh rate issues yet? Zarich NVIDIA GeForce 7, 8, And 9 Series 22 08-24-02 02:02 PM

All times are GMT -5. The time now is 06:59 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.