Unrecognized FlatPanelProperties property "Scaling"
[i]Debian Sid, Kernel 3.10, nVidia 325.15, 64bit[/i] [b]/var/log/Xorg.0.log[/b]: [code] (**) NVIDIA(0): Option "FlatPanelProperties" "Scaling = Aspect-Scaled" (WW) NVIDIA(0): Unrecognized FlatPanelProperties property "Scaling"; (WW) NVIDIA(0): ignoring. [/code] Any ideas?
Debian Sid, Kernel 3.10, nVidia 325.15, 64bit
/var/log/Xorg.0.log:
(**) NVIDIA(0): Option "FlatPanelProperties" "Scaling = Aspect-Scaled"
(WW) NVIDIA(0): Unrecognized FlatPanelProperties property "Scaling";
(WW) NVIDIA(0): ignoring.


Any ideas?

#1
Posted 09/05/2013 11:29 PM   
Looks like a bug since the documentation clearly says it's a valid configuration: [code]Option "FlatPanelProperties" "string" This option requests particular properties for all or a subset of the connected flat panels. The option string is a semicolon-separated list of comma-separated property=value pairs. Each list of property=value pairs can optionally be prepended with a flat panel name and GPU specifier. ... Recognized properties: o "Scaling": controls the flat panel scaling mode; possible values are: 'Default' (the driver will use whichever scaling state is current), 'Native' (the driver will use the flat panel's scaler, if possible), 'Scaled' (the driver will use the NVIDIA GPU's scaler, if possible), 'Centered' (the driver will center the image, if possible), and 'aspect-scaled' (the X driver will scale with the NVIDIA GPU's scaler, but keep the aspect ratio correct). ... Examples: Option "FlatPanelProperties" "Scaling = Centered" set the flat panel scaling mode to centered on all flat panels. [/code]
Looks like a bug since the documentation clearly says it's a valid configuration:

Option "FlatPanelProperties" "string"

This option requests particular properties for all or a subset of the
connected flat panels.

The option string is a semicolon-separated list of comma-separated
property=value pairs. Each list of property=value pairs can optionally be
prepended with a flat panel name and GPU specifier.

...

Recognized properties:

o "Scaling": controls the flat panel scaling mode; possible values are:
'Default' (the driver will use whichever scaling state is current),
'Native' (the driver will use the flat panel's scaler, if possible),
'Scaled' (the driver will use the NVIDIA GPU's scaler, if possible),
'Centered' (the driver will center the image, if possible), and
'aspect-scaled' (the X driver will scale with the NVIDIA GPU's
scaler, but keep the aspect ratio correct).

...

Examples:

Option "FlatPanelProperties" "Scaling = Centered"

set the flat panel scaling mode to centered on all flat panels.

Artem S. Tashkinov
Linux and Open Source advocate

#2
Posted 09/05/2013 11:45 PM   
Internal bug 1363966 is filed on this.
Internal bug 1363966 is filed on this.

#3
Posted 09/06/2013 07:29 PM   
The Scaling option was removed when the front-end / back-end timing stuff was removed, but it looks like the documentation wasn't updated at the time. The documentation should be up to date in the next release. Sorry about that.
The Scaling option was removed when the front-end / back-end timing stuff was removed, but it looks like the documentation wasn't updated at the time. The documentation should be up to date in the next release. Sorry about that.

Aaron Plattner
NVIDIA Linux Graphics

#4
Posted 09/09/2013 07:17 PM   
[quote="aplattner"]The Scaling option was removed when [b]the front-end / back-end timing stuff was removed[/b], but it looks like the documentation wasn't updated at the time. The documentation should be up to date in the next release. Sorry about that.[/quote] Finally - here's the reason why Kepler GPUs have significant tearing. However, how are we supposed to configure Scaling? Or you have totally removed this feature? It's still available in Windows though which is kinda puzzling.
aplattner said:The Scaling option was removed when the front-end / back-end timing stuff was removed, but it looks like the documentation wasn't updated at the time. The documentation should be up to date in the next release. Sorry about that.


Finally - here's the reason why Kepler GPUs have significant tearing.

However, how are we supposed to configure Scaling? Or you have totally removed this feature? It's still available in Windows though which is kinda puzzling.

Artem S. Tashkinov
Linux and Open Source advocate

#5
Posted 09/09/2013 07:50 PM   
Scaling is still there, it's just now configured explicitly via RandR 1.2 or via the ViewPortOut and ViewPortIn attributes in the [url="http://http.download.nvidia.com/XFree86/Linux-x86/325.15/README/configtwinview.html"]MetaMode[/url] string. Scaling should have nothing to do with tearing.
Scaling is still there, it's just now configured explicitly via RandR 1.2 or via the ViewPortOut and ViewPortIn attributes in the MetaMode string. Scaling should have nothing to do with tearing.

Aaron Plattner
NVIDIA Linux Graphics

#6
Posted 09/10/2013 05:16 PM   
I confess it's a bit off topic for [i]this[/i] thread, but anyway ... Tearing ... good point. Aaron, any chance we will receive a feedback on this? [url]https://devtalk.nvidia.com/default/topic/543305/linux/screen-video-tearing-on-gtx-6xx-7xx-titan-in-almost-all-applications-including-desktop-itself/1[/url] [url]https://devtalk.nvidia.com/default/topic/525640/linux/evga-geforce-gtx-660-ti-problems-/1[/url] It didn't happen same configuration with my 460 GTX, only since I replaced it by a GTX 660ti I would be really thankful if finally some one can spend some words...
I confess it's a bit off topic for this thread, but anyway ...

Tearing ... good point.

Aaron, any chance we will receive a feedback on this?
https://devtalk.nvidia.com/default/topic/543305/linux/screen-video-tearing-on-gtx-6xx-7xx-titan-in-almost-all-applications-including-desktop-itself/1
https://devtalk.nvidia.com/default/topic/525640/linux/evga-geforce-gtx-660-ti-problems-/1
It didn't happen same configuration with my 460 GTX, only since I replaced it by a GTX 660ti

I would be really thankful if finally some one can spend some words...

#7
Posted 09/10/2013 09:13 PM   
No, I don't have suggestions there. Those threads are kind of all over the place so it's hard to say. I should note that without an OpenGL-based composite manager, X rendering is not expected to be tear-free in general. VDPAU can do tear-free rendering when it's using the overlay presentation queue, but Xv and VDPAU with the blit presentation queue just do a best-effort wait for vblank and can still tear, for example if your video mode's vblank region is very small and the system can't quite get the rendering ready in time. Systems with high resolution displays using reduced blanking timings are becoming more common, so that might explain why people are seeing more tearing. You could try enabling the ForceCompositionPipeline and/or ForceFullCompositionPipeline options in the [url="http://http.download.nvidia.com/XFree86/Linux-x86/325.15/README/configtwinview.html"]MetaMode[/url] to see if that helps.
No, I don't have suggestions there. Those threads are kind of all over the place so it's hard to say. I should note that without an OpenGL-based composite manager, X rendering is not expected to be tear-free in general. VDPAU can do tear-free rendering when it's using the overlay presentation queue, but Xv and VDPAU with the blit presentation queue just do a best-effort wait for vblank and can still tear, for example if your video mode's vblank region is very small and the system can't quite get the rendering ready in time. Systems with high resolution displays using reduced blanking timings are becoming more common, so that might explain why people are seeing more tearing.

You could try enabling the ForceCompositionPipeline and/or ForceFullCompositionPipeline options in the MetaMode to see if that helps.

Aaron Plattner
NVIDIA Linux Graphics

#8
Posted 09/11/2013 05:09 PM   
[quote="aplattner"]No, I don't have suggestions there. Those threads are kind of all over the place so it's hard to say. I should note that without an OpenGL-based composite manager, [b]X rendering is not expected to be tear-free in general[/b]. VDPAU can do tear-free rendering when it's using the overlay presentation queue, but Xv and VDPAU with the blit presentation queue just do a best-effort wait for vblank and can still tear, for example if your video mode's vblank region is very small and the system can't quite get the rendering ready in time. Systems with high resolution displays using reduced blanking timings are becoming more common, so that might explain why people are seeing more tearing. You could try enabling the ForceCompositionPipeline and/or ForceFullCompositionPipeline options in the [url="http://http.download.nvidia.com/XFree86/Linux-x86/325.15/README/configtwinview.html"]MetaMode[/url] to see if that helps.[/quote] This issue affects [b]only[/b] Kepler based GPUs, so why all of a sudden tear-free experience is still readily [b]available[/b] in pre-Kepler GPUs? What is that has changed so drastically in this hardware? Maybe Kepler lacks some hardware synchronization features? I can swap my GTX 660 with 8800 GT and tearing will be gone immediately. On the very same PC. There's something you don't tell us and I wonder what that is.
aplattner said:No, I don't have suggestions there. Those threads are kind of all over the place so it's hard to say. I should note that without an OpenGL-based composite manager, X rendering is not expected to be tear-free in general. VDPAU can do tear-free rendering when it's using the overlay presentation queue, but Xv and VDPAU with the blit presentation queue just do a best-effort wait for vblank and can still tear, for example if your video mode's vblank region is very small and the system can't quite get the rendering ready in time. Systems with high resolution displays using reduced blanking timings are becoming more common, so that might explain why people are seeing more tearing.

You could try enabling the ForceCompositionPipeline and/or ForceFullCompositionPipeline options in the MetaMode to see if that helps.


This issue affects only Kepler based GPUs, so why all of a sudden tear-free experience is still readily available in pre-Kepler GPUs?

What is that has changed so drastically in this hardware? Maybe Kepler lacks some hardware synchronization features?

I can swap my GTX 660 with 8800 GT and tearing will be gone immediately. On the very same PC.

There's something you don't tell us and I wonder what that is.

Artem S. Tashkinov
Linux and Open Source advocate

#9
Posted 09/11/2013 06:13 PM   
Big thank's for the reply, Aaron! Upfront I want to confirm again what birdie said - I had an 460GTX before exactly same PC / OpenSuse 11.4, that time same driver, no tearing ever. As I replaced only the graphics board by a GTX 660ti this tearing started in flash videos and e.g. vlc with xv output. VDPAU still worked w/o tearing in mplayer. [b]Ok here the good news: in both cases, Success !!![/b] using ForceCompositionPipeline = On or ForceFullCompositionPipeline = On tearing is [b]gone! [/b](I tested it briefly in vlc +vo=xv with a very good test movie / DVD; it simply worked) So thank you very much! I didn't know about these two options can be set. [b] A working solution now!!![/b] Ok and here is the P.S: I also suspect sth changed specific to Kepler architecture, and worth to mention is, that the "tearing" looked very special, like a checkerboard. I just added the old screenshot here again - and hope a new driver may fix this at all. [IMG]http://i49.tinypic.com/xc428m.jpg[/IMG] See what I mean?
Big thank's for the reply, Aaron!

Upfront I want to confirm again what birdie said - I had an 460GTX before exactly same PC / OpenSuse 11.4, that time same driver, no tearing ever. As I replaced only the graphics board by a GTX 660ti this tearing started in flash videos and e.g. vlc with xv output. VDPAU still worked w/o tearing in mplayer.

Ok here the good news: in both cases, Success !!!
using
ForceCompositionPipeline = On or
ForceFullCompositionPipeline = On
tearing is gone!
(I tested it briefly in vlc +vo=xv with a very good test movie / DVD; it simply worked)

So thank you very much! I didn't know about these two options can be set.

A working solution now!!!


Ok and here is the P.S: I also suspect sth changed specific to Kepler architecture, and worth to mention is, that the "tearing" looked very special, like a checkerboard. I just added the old screenshot here again - and hope a new driver may fix this at all.

Image
See what I mean?

#10
Posted 09/11/2013 08:08 PM   
To add: I benchmarked with Unigine Valley and this of course has a significant impact on the performance ~30% less. So it's only a workaround for watching videos. Happily games (openGL) are NOT affected by tearing for me.
To add: I benchmarked with Unigine Valley and this of course has a significant impact on the performance ~30% less. So it's only a workaround for watching videos. Happily games (openGL) are NOT affected by tearing for me.

#11
Posted 09/11/2013 08:30 PM   
[quote="birdie"]This issue affects [b]only[/b] Kepler based GPUs, so why all of a sudden tear-free experience is still readily [b]available[/b] in pre-Kepler GPUs? What is that has changed so drastically in this hardware? Maybe Kepler lacks some hardware synchronization features?[/quote] Kepler and earlier GPU architectures are dramatically different. Since, as I mentioned, the sync-to-vblank mechanism for Xv and VDPAU blit presentation queue are best-effort, small changes in timing anywhere in the system can cause tearing to appear or disappear. That's why I can't speculate as to why, on your particular system, one GPU behaves differently from another.
birdie said:This issue affects only Kepler based GPUs, so why all of a sudden tear-free experience is still readily available in pre-Kepler GPUs?

What is that has changed so drastically in this hardware? Maybe Kepler lacks some hardware synchronization features?

Kepler and earlier GPU architectures are dramatically different. Since, as I mentioned, the sync-to-vblank mechanism for Xv and VDPAU blit presentation queue are best-effort, small changes in timing anywhere in the system can cause tearing to appear or disappear. That's why I can't speculate as to why, on your particular system, one GPU behaves differently from another.

Aaron Plattner
NVIDIA Linux Graphics

#12
Posted 09/11/2013 09:02 PM   
Sorry if I may sound a bit stubborn... Partially agreed. Tearing and vsync on X and KDE etc. is a difficult task. But I had a long history of Nvidia cards, starting by Riva TNT2, Geforce2, 4600, 5600XT, 8800 GTX, 460 GTX and now 660 Ti. The last three ones on the same PC. All before mentioned modells I [b]never[/b] seen this. Videos were fine. And, it makes me wonder if it's GPU specific, why my 8800 GTX and 460 GTX just "hit" the perfect timing for vsync nor does the 660 Ti now. In addition, if you look at the photo I provided, it just looks bit weird, not the "usual pattern" that happens for tearing (usually it is a single line). With Kepler it is a broader band with some squares on it. I believe Kepler is a very good [i]and[/i] complex architecture. But from what it seems this is still specific to Kepler and to improve on this topic would be in the interest for both, user and Nvidia. So maybe someone at Nvidia consider to have a closer look into that .. it is just my suggestion. I would appreciate that and of course deliver some (hopefully) reproducable test cases. Anyway, thanks for the hint above.
Sorry if I may sound a bit stubborn...

Partially agreed. Tearing and vsync on X and KDE etc. is a difficult task. But I had a long history of Nvidia cards, starting by Riva TNT2, Geforce2, 4600, 5600XT, 8800 GTX, 460 GTX and now 660 Ti. The last three ones on the same PC. All before mentioned modells I never seen this. Videos were fine. And, it makes me wonder if it's GPU specific, why my 8800 GTX and 460 GTX just "hit" the perfect timing for vsync nor does the 660 Ti now.
In addition, if you look at the photo I provided, it just looks bit weird, not the "usual pattern" that happens for tearing (usually it is a single line). With Kepler it is a broader band with some squares on it.
I believe Kepler is a very good and complex architecture. But from what it seems this is still specific to Kepler and to improve on this topic would be in the interest for both, user and Nvidia.

So maybe someone at Nvidia consider to have a closer look into that .. it is just my suggestion. I would appreciate that and of course deliver some (hopefully) reproducable test cases.

Anyway, thanks for the hint above.

#13
Posted 09/11/2013 10:07 PM   
[quote="aplattner"]Kepler and earlier GPU architectures are dramatically different. Since, as I mentioned, the sync-to-vblank mechanism for Xv and VDPAU blit presentation queue are best-effort, small changes in timing [b]anywhere in the system[/b] can cause tearing to appear or disappear. That's why I can't speculate as to why, on your particular system, one GPU behaves differently from another.[/quote] So far, the GPU has been solely responsible for tearing here. From your words I can deduce that NVIDIA drivers don't have any [b]special[/b] hacks or tricks to force sync-to-vblank in software mode (non-OpenGL) and it was just a hardware feature of the older GPUs, and for some reasons the hardware part of the GPU which is responsible for ensuring a tear free experience is just not present in the Kepler architecture. It's really sad, 'cause I refuse to run an OpenGL compositor since I've never seen them to be completely reliable (Windows' dwm.exe on the contrary has never crashed for me - but there's no way I can run it Linux even under Wine). Thank you for your comments.
aplattner said:Kepler and earlier GPU architectures are dramatically different. Since, as I mentioned, the sync-to-vblank mechanism for Xv and VDPAU blit presentation queue are best-effort, small changes in timing anywhere in the system can cause tearing to appear or disappear. That's why I can't speculate as to why, on your particular system, one GPU behaves differently from another.


So far, the GPU has been solely responsible for tearing here. From your words I can deduce that NVIDIA drivers don't have any special hacks or tricks to force sync-to-vblank in software mode (non-OpenGL) and it was just a hardware feature of the older GPUs, and for some reasons the hardware part of the GPU which is responsible for ensuring a tear free experience is just not present in the Kepler architecture. It's really sad, 'cause I refuse to run an OpenGL compositor since I've never seen them to be completely reliable (Windows' dwm.exe on the contrary has never crashed for me - but there's no way I can run it Linux even under Wine).

Thank you for your comments.

Artem S. Tashkinov
Linux and Open Source advocate

#14
Posted 09/12/2013 04:12 AM   
Scroll To Top

Add Reply