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

Newegg Daily Deals

Reply
 
Thread Tools
Old 05-19-09, 11:09 AM   #25
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: 185.19 + VDPAU blit path == stall

Quote:
Originally Posted by Jotti View Post
My system is a Core2Quad Q9450 at 3.2GHz running Debian AMD64 (testing) with KDE4.2 with compositing enabled, powered by a GTX280. The following may sound a bit incoherent, but I will post my findings for the sake of completeness anyway.
Given you have a compositing manager running, this sounds like a slightly different problem; it could either be a VDPAU issue, PowerMizer issue (like other people), or in your case additionally some issue with the compositing manager path. do you see stutters if you leave the X composite extension turned on, but disable the X composite manager, so that VDPAU (and not the composite manager) is rendering directly to the screen?
Stephen Warren is offline   Reply With Quote
Old 05-19-09, 11:33 AM   #26
crisalide
Registered User
 
Join Date: Dec 2008
Posts: 173
Default Re: 185.19 + VDPAU blit path == stall

Stephen,

I have reproduced this with 185.18.10:
- only one performance level
- composite disabled
- VDPAU_NVIDIA_NO_OVERLAY=1
- 2X temporal_spatial deinterlacing

Here is a videoshot of the problem: http://hftom.homelinux.org/tmp/clip0018.avi
Hope this helps.
crisalide is offline   Reply With Quote
Old 05-19-09, 12:29 PM   #27
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: 185.19 + VDPAU blit path == stall

crisalide, and this is a regression from earlier driver releases that didn't have sync-to-VBLANK in the blit-based presentation queue?
Stephen Warren is offline   Reply With Quote
Old 05-19-09, 12:48 PM   #28
Jotti
Registered User
 
Join Date: Apr 2004
Posts: 3
Default Re: 185.19 + VDPAU blit path == stall

Stephen: after disabling the compositing manager, I did not experience any problems any more... still figures why an old driver did work without issues with the same compositing manager, but I have a workaround for now Thanks.
Jotti is offline   Reply With Quote
Old 05-19-09, 04:04 PM   #29
crisalide
Registered User
 
Join Date: Dec 2008
Posts: 173
Default Re: 185.19 + VDPAU blit path == stall

Quote:
Originally Posted by Stephen Warren View Post
crisalide, and this is a regression from earlier driver releases that didn't have sync-to-VBLANK in the blit-based presentation queue?
Yes.
I've just retried with 180.44 and it works well (with tearing, of course).
crisalide is offline   Reply With Quote
Old 05-20-09, 05:57 AM   #30
Jotti
Registered User
 
Join Date: Apr 2004
Posts: 3
Default Re: 185.19 + VDPAU blit path == stall

It seems I must retract my statement... I just got another stall, this time without a compositing manager running...
Jotti is offline   Reply With Quote
Old 10-20-09, 11:53 AM   #31
crisalide
Registered User
 
Join Date: Dec 2008
Posts: 173
Default Re: 185.19 + VDPAU blit path == stall

Any news on this ?
Still the same with 190.40.
crisalide is offline   Reply With Quote
Old 10-20-09, 03:25 PM   #32
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: 185.19 + VDPAU blit path == stall

Sorry, I can't reproduce this.
Stephen Warren is offline   Reply With Quote

Old 10-20-09, 08:01 PM   #33
crisalide
Registered User
 
Join Date: Dec 2008
Posts: 173
Default Re: 185.19 + VDPAU blit path == stall

What could i do to help ?
This is a major issue since composite is enabled by default and requiring users to disable it is not an acceptable solution, so this prevent merging xine-vdpau upstream.

Note 1)
I have notived that the freezes disappear when changing code from:

vdp_queue_get_time( ... &current_time );
vdp_queue_display( ... 0 );
vdp_queue_display( ... current_time+frame_duration );

to:

vdp_queue_get_time( ... &current_time );
vdp_queue_display( ... 0 );
vdp_queue_display( ... 0 );

(displaying on a 60Hz monitor the difference is hardly noticeable, but that's of course not an acceptable solution)

Note 2)
Increasing the number of output_surfaces just increase the time beetween freezes.
crisalide is offline   Reply With Quote
Old 10-21-09, 06:42 PM   #34
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: 185.19 + VDPAU blit path == stall

Let me try and repro this again. (Well, I tried with some random MPEG file I have here and didn't see the issue even though I validated that video_out_vdpau.c is going through the apparently-failing path)

Can people who're having this problem supply:
a) nvidia-bug-report, and output of "grep 'NVIDIA GPU' /var/log/Xorg.0.log" Perhaps the bug exists on some subset of our GPUs.
b) File that repro's the problem, long enough portion to be fairly likely to repro. Perhaps the issue is tickled by some particular frame rate that my clips happen not to have.
c) xine command-line used (I assume it occurs with xine-ui-0.99.5; that's what I just tested with)
d) Any relevant xine configuration required
e) Details on your display device - VGA vs. DVI vs. TV-out vs. HDMI. What mode (resolution, refresh rate) you're running at. Perhaps the bug only manifests with some particular display connector type (since sync-to-VBLANK interacts somewhat with DACs/... etc.)

This bug has been nagging at me all these months, even though I haven't been able to make any useful progress...

Thanks.
Stephen Warren is offline   Reply With Quote
Old 10-22-09, 02:12 PM   #35
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: 185.19 + VDPAU blit path == stall

One thing for people to try: Please set the following options in xorg.conf:

Code:
Option "UseEvents" "False"
Option "DamageEvents" "False"
the second of these requires that the xine window not be redirected, so no compiz for example.

Also note that the first option only affects the X server, not VDPAU's own operation. However, VDPAU uses some of the same operations that X does when the option is enabled, so if the option affects the frequency, that would be useful to know. If there is an effect, knowing which individual option caused it would be useful.

Thanks.
Stephen Warren is offline   Reply With Quote
Old 10-22-09, 06:28 PM   #36
crisalide
Registered User
 
Join Date: Dec 2008
Posts: 173
Default Re: 185.19 + VDPAU blit path == stall

I'll give these options a try.

Next week, I'll try to collect as much infos as possible for you to reproduce, but it will take some time ; for example, 190.42 behaves different and it seems stall only when window is maximized or fs. Have to confirm this and more. Please be patient, and thanx for looking at it.

( Btw, i use kaffeine 0.8.8 (qt3/kde3). Have tried xine-ui for some minutes and got only one stall. So it's possible that you can't reproduce with xine-ui )
crisalide 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


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


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