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

Newegg Daily Deals

Reply
 
Thread Tools
Old 04-24-10, 01:34 PM   #1
UrbenLegend
Registered User
 
Join Date: Feb 2007
Posts: 21
Default Automatic VDPAU V-sync in TwinView

Is there anyway to make VDPAU autodetect which monitor it's running on and sync to that monitor? It's kinda annoying having to type
Code:
export VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=CRT-0
and running smplayer in a terminal in order to get correct V-sync on my videos.
UrbenLegend is offline   Reply With Quote
Old 04-26-10, 10:38 AM   #2
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: Automatic VDPAU V-sync in TwinView

If you use the overlay-based presentation queue, it will sync-to-vblank on both displays at once.

When using the blit-based presentation queue, it will always sync to a single statically configured display, as set by that environment variable.

The most likely way to get the blit-based presentation queue is to disable the X composite extension. See the VDPAU section of the README for complete details on the selection algorithm.
Stephen Warren is offline   Reply With Quote
Old 05-10-10, 01:14 PM   #3
sophana
Registered User
 
Join Date: Feb 2006
Posts: 10
Default Re: Automatic VDPAU V-sync in TwinView

Hi
Quote:
If you use the overlay-based presentation queue, it will sync-to-vblank on both displays at once.
How do you do that?
I'm having tearing problems with v195.36.15 on my second twinview monitor with smplayer and vdpau.
Strange, because I think it was working yesterday. My computer resumed from suspend to ram, could it be related?
sophana is offline   Reply With Quote
Old 05-10-10, 01:18 PM   #4
sophana
Registered User
 
Join Date: Feb 2006
Posts: 10
Default Re: Automatic VDPAU V-sync in TwinView

...duplicate..
sophana is offline   Reply With Quote
Old 05-10-10, 03:00 PM   #5
mocharhw
Registered User
 
Join Date: May 2008
Posts: 113
Default Re: Automatic VDPAU V-sync in TwinView

Quote:
Originally Posted by Stephen Warren View Post
The most likely way to get the blit-based presentation queue is to disable the X composite extension. See the VDPAU section of the README for complete details on the selection algorithm.
Didn't you mean "The most likely way to get the blit-based presentation queue is to enable the X composite extension"?

The README says:

The following conditions or system configurations will prevent usage of the overlay path:

X composite extension enabled on the given screen.
mocharhw is offline   Reply With Quote
Old 05-10-10, 04:30 PM   #6
sophana
Registered User
 
Join Date: Feb 2006
Posts: 10
Default Re: Automatic VDPAU V-sync in TwinView

I confirm that rebooting solved the tearing problem.
Then I logged out then back in, and tearing restarted. (I have fedora 12)
Can someone confirm?
sophana is offline   Reply With Quote
Old 05-10-10, 04:40 PM   #7
sophana
Registered User
 
Join Date: Feb 2006
Posts: 10
Default

x
sophana is offline   Reply With Quote
Old 05-11-10, 11:28 AM   #8
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: Automatic VDPAU V-sync in TwinView

Quote:
Originally Posted by mocharhw View Post
Didn't you mean "The most likely way to get the blit-based presentation queue is to enable the X composite extension"?
Sorry, I meant to say disable like I did, but meant to talk about the overlay-based presentation queue, not the blit-based presentation queue, i.e.:

The most likely way to get the overlay-based presentation queue is to disable the X composite extension.

sophana, I'm not sure why rebooting would affect sync-to-vblank in any way.
Stephen Warren is offline   Reply With Quote

Old 05-23-10, 05:27 AM   #9
sophana
Registered User
 
Join Date: Feb 2006
Posts: 10
Default Re: Automatic VDPAU V-sync in TwinView

Quote:
sophana, I'm not sure why rebooting would affect sync-to-vblank in any way.
Sorry I reconfirm this bug as reproductible
My system has twinview configured on 2 different monitors with different resolutions and frequency.
With fedora 10, there had always been tearing on the second monitor.
After upgrading to fedora12 (and using vdpau), It was resolved. Very cool.
But everytime I logout, then log back in, tearing reappears on the second monitor.
I found no other workaround than rebooting to make it disappear.

Can anyone try this?

Attached is the bug report (after logout/login when the tearing bug occurs)

here is a part of the vdpau debug log (at the end, because I have to move the window on the second screen to see tearing)
Code:
vdp_presentation_queue_block_until_surface_idle(3, 5, -)
    -> 0, 1274604516911477184
vdp_video_mixer_render(4, 4294967295, NULL, 2, 2, {11, 11}, 9, 1, {9}, {0, 0, 1920, 1078}, 5, NULL, {0, 61, 1920, 1139}, 0, NULL)
    -> 0
vdp_presentation_queue_display(3, 5, 1920, 1200, 0)
    -> 0
vdp_video_surface_put_bits_y_cb_cr(10, 1, {0xb27aaa30, 0xb2698ea8, 0xb271eea8}, {1952, 976, 976}, )
    -> 0
vdp_presentation_queue_block_until_surface_idle(3, 6, -)
    -> 0, 1274604516944790848
vdp_video_mixer_render(4, 4294967295, NULL, 2, 2, {9, 9}, 10, 1, {10}, {0, 0, 1920, 1078}, 6, NULL, {0, 61, 1920, 1139}, 0, NULL)
    -> 0
vdp_presentation_queue_display(3, 6, 1920, 1200, 0)
    -> 0
vdp_video_surface_put_bits_y_cb_cr(11, 1, {0xb2ff0a30, 0xb2edeea8, 0xb2f64ea8}, {1952, 976, 976}, )
    -> 0
vdp_presentation_queue_block_until_surface_idle(3, 7, -)
    -> 0, 1274604516994819104
vdp_video_mixer_render(4, 4294967295, NULL, 2, 2, {10, 10}, 11, 1, {11}, {0, 0, 1920, 1078}, 7, NULL, {0, 61, 1920, 1139}, 0, NULL)
    -> 0
vdp_presentation_queue_display(3, 7, 1920, 1200, 0)
    -> 0
vdp_video_surface_put_bits_y_cb_cr(9, 1, {0xb1c6da30, 0xb1b5bea8, 0xb1be1ea8}, {1952, 976, 976}, )
    -> 0
vdp_presentation_queue_block_until_surface_idle(3, 5, -)
    -> 0, 1274604517028095616
vdp_video_mixer_render(4, 4294967295, NULL, 2, 2, {11, 11}, 9, 1, {9}, {0, 0, 1920, 1078}, 5, NULL, {0, 61, 1920, 1139}, 0, NULL)
    -> 0
vdp_presentation_queue_display(3, 5, 1920, 1200, 0)
    -> 0
vdp_video_surface_put_bits_y_cb_cr(10, 1, {0xb2bcda30, 0xb2abbea8, 0xb2b41ea8}, {1952, 976, 976}, )
    -> 0
vdp_presentation_queue_block_until_surface_idle(3, 6, -)
    -> 0, 1274604517078070816
vdp_video_mixer_render(4, 4294967295, NULL, 2, 2, {9, 9}, 10, 1, {10}, {0, 0, 1920, 1078}, 6, NULL, {0, 61, 1920, 1139}, 0, NULL)
    -> 0
vdp_presentation_queue_display(3, 6, 1920, 1200, 0)
    -> 0
vdp_video_surface_destroy(9)
    -> 0
vdp_video_surface_destroy(10)
    -> 0
vdp_video_surface_destroy(11)
    -> 0
vdp_video_mixer_destroy(4)
    -> 0
vdp_presentation_queue_destroy(3)
    -> 0
vdp_presentation_queue_target_destroy(2)
    -> 0
vdp_output_surface_destroy(5)
    -> 0
vdp_output_surface_destroy(6)
    -> 0
vdp_output_surface_destroy(7)
    -> 0
vdp_output_surface_destroy(8)
    -> 0
vdp_device_destroy(1)
    -> 0
Attached Files
File Type: gz nvidia-bug-report.log.gz (69.4 KB, 67 views)

Last edited by sophana; 05-23-10 at 06:35 AM. Reason: attached bug report
sophana 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 10:46 AM.


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