TDMS bandwidth limits

TDMS bandwidth limits

[Edgar Fuß]

I'm curious what the TDMS bandwidth limit values in get_tmds_link_bandwidth() are based on.
We're using chipset == 44 cards that happily run 1600x1200@60 using the propriety driver and which also used to work with nouveau up to Linux 2.6.36.2. Since 2.6.37, nouveau refuses to use that mode because the required 163M pixel clock exceeds the computed TDMS bandwidth of 155M (earlier versions allowed for 165M regardless of chipset value).
Although I cannot tell for sure which timing the closed-source driver runs 1600x1200@60 with on these monitors, I find it unlikely that it uses some built-in, non-EDID timing requiring a lower pixel clock. I also don't suspect NVidia running their own chips above specs.
So either NVidia doesn't disclose the specs even to their own programmers, the values in get_tmds_link_bandwidth() are wrong, or, more likely, I'm missing something.
Patching get_tmds_link_bandwidth() to allow for 165M already for chipset >= 0x44 appears to work. However, I don't feel comfortable with stretching rates above spec.

Re: TDMS bandwidth limits

[Francisco Jerez]

[-- Attachment #1.1.1: Type: text/plain, Size: 1669 bytes --]

Edgar Fuß <ef-o02PS0xoJP/q4qjOmvqfQQ@public.gmane.org> writes:

> I'm curious what the TDMS bandwidth limit values in get_tmds_link_bandwidth() are based on.

They're based on what the nvidia proprietary driver itself refuses to
do, though, I'm not 100% sure that I had nv44 in my sample when I made
that change.

> We're using chipset == 44 cards that happily run 1600x1200@60 using the propriety driver and which also used to work with nouveau up to Linux 2.6.36.2. Since 2.6.37, nouveau refuses to use that mode because the required 163M pixel clock exceeds the computed TDMS bandwidth of 155M (earlier versions allowed for 165M regardless of chipset value).
> Although I cannot tell for sure which timing the closed-source driver runs 1600x1200@60 with on these monitors, I find it unlikely that it uses some built-in, non-EDID timing requiring a lower pixel clock. I also don't suspect NVidia running their own chips above specs.

It might be using a reduced-blanking mode, check your Xorg.0.log to be
sure. See the "-logverbose" option if you don't get all the timings
printed out with the default verbosity level.

> So either NVidia doesn't disclose the specs even to their own programmers, the values in get_tmds_link_bandwidth() are wrong, or, more likely, I'm missing something.
> Patching get_tmds_link_bandwidth() to allow for 165M already for chipset >= 0x44 appears to work. However, I don't feel comfortable with stretching rates above spec.
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: TDMS bandwidth limits

[Edgar Fuß]

> They're based on what the nvidia proprietary driver itself refuses to do,
Ah, I see. Thanks.

> though, I'm not 100% sure that I had nv44 in my sample when I made
> that change.
Looks like you were correct with the 155 limit for 44.

> It might be using a reduced-blanking mode,
Indeed it does. I had regarded this as unlikely given that, after all, the driver simply can't know how much blanking reduction the monitor will be able to cope with.

> check your Xorg.0.log to be sure. See the "-logverbose" option if you don't
> get all the timings printed out with the default verbosity level.
I do get the timings printed with -logverbose 9. I also get a message to the effect that reduced blanking was used to get the pixel clock within limits. What I don't get is the timing actually being used. Looks I have to figure out the values myself (and see how to teach the nouveau fb to use it).

Thanks for your help.

Re: TDMS bandwidth limits

[Edgar Fuß]

So my problem continues.

> They're based on what the nvidia proprietary driver itself refuses to do,
I see, thanks.

> though, I'm not 100% sure that I had nv44 in my sample when I made that change.
Looks like it limits to 155M in the nv44 case too, so your change is totally correct.

> It might be using a reduced-blanking mode,
Indeed it does, thanks. I had ruled out this too early as highly improbable.

> check your Xorg.0.log to be sure. See the "-logverbose" option if you don't
> get all the timings printed out with the default verbosity level.
It does tell at least on level 9, thanks.

However, what it doesn't tell is the timing actually used. Anyone more familiar with the relevant reverse engineering methods (MmioTrace or whatever) to find out?

The other problem is that nouveaufb doesn't (like matroxfb) provide a method of specifying the exact timing to use (and I would presumably need it in order not to change between FB console and X11).

One would come to think that video=1600x1200RM would result in a reduced-blanking mode, but drm.debug=7 shows it actually does not.
Reading the source of drm_fb_helper.c reveals that it's almost impossible to achieve rb=1.

Any chance of implementing implicit reduced blanking in nouveau? If someone could hint me at where to architecturally correctly put it in I will be happy to start implementing it myself.

I'm afraid more people than me will run into this and will regard the (absolutely plausible) TDMS bandwidth limiting as a regression ("Help! Help! My 1600x1200 used to work, but now it's broken!") when there's no reduced-blanking workaround.

Re: TDMS bandwidth limits

[Francisco Jerez]

[-- Attachment #1.1.1: Type: text/plain, Size: 2300 bytes --]

Edgar Fuß <ef-o02PS0xoJP/q4qjOmvqfQQ@public.gmane.org> writes:

> So my problem continues.
>
>> They're based on what the nvidia proprietary driver itself refuses to do,
> I see, thanks.
>
>> though, I'm not 100% sure that I had nv44 in my sample when I made that change.
> Looks like it limits to 155M in the nv44 case too, so your change is totally correct.
>
>> It might be using a reduced-blanking mode,
> Indeed it does, thanks. I had ruled out this too early as highly improbable.
>
>> check your Xorg.0.log to be sure. See the "-logverbose" option if you don't
>> get all the timings printed out with the default verbosity level.
> It does tell at least on level 9, thanks.
>
> However, what it doesn't tell is the timing actually used. Anyone more familiar with the relevant reverse engineering methods (MmioTrace or whatever) to find out?
>
A register dump [1] would be the easiest way to find out the exact
timings, but any standard 1600x1200 reduced-blanking mode should do it.

> The other problem is that nouveaufb doesn't (like matroxfb) provide a method of specifying the exact timing to use (and I would presumably need it in order not to change between FB console and X11).
>
You could just use the same CVT reduced-blanking mode on both X and the
framebuffer console.

> One would come to think that video=1600x1200RM would result in a reduced-blanking mode, but drm.debug=7 shows it actually does not.
> Reading the source of drm_fb_helper.c reveals that it's almost impossible to achieve rb=1.
>
Well, that works for me, can I have a look at your kernel logs?

> Any chance of implementing implicit reduced blanking in nouveau? If someone could hint me at where to architecturally correctly put it in I will be happy to start implementing it myself.
>
> I'm afraid more people than me will run into this and will regard the (absolutely plausible) TDMS bandwidth limiting as a regression ("Help! Help! My 1600x1200 used to work, but now it's broken!") when there's no reduced-blanking workaround.
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[1] http://cgit.freedesktop.org/~currojerez/tvdump/

[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: TDMS bandwidth limits

[Edgar Fuß]

> A register dump [1] would be the easiest way to find out the exact timings,
OK, I'll ask a colleague to give this a try. The problem is to set up a machine that both runs the proprietary driver and a recent enough Debian to have libpciaccess available.

> but any standard 1600x1200 reduced-blanking mode should do it.
Yes, but having the exact same timings on the FB console and X11 results a smoother switch between the two modes.

> You could just use the same CVT reduced-blanking mode on both X and the
> framebuffer console.
Sorry for the apperantly dumb question, but how do tell X to use the CVT mode?

> Well, that works for me, can I have a look at your kernel logs?
Hm. I tried to reproduce the problem I faced on friday, but it disappeared. Now I get the "reduced blanking" message in the drm_fb_helper_connector_parse_command_line debug output. Strange.

Now I tried to give the modeline the drm debug output to xorg.conf, but it doesn't pick it up. I must be doing something stupidly wrong again:

[...]
Section "Monitor"
	Identifier	"Bildschirm"
	Option		"DPMS"
	ModeLine	"reduced"	130 1600 1648 1680 1760 1200 1203 1207 1235
EndSection

Section "Screen"
[...]
	Monitor		"Bildschirm"
	DefaultDepth	24
	SubSection	"Display"
		Depth	24
		Virtual	1600 1200
		Modes	"reduced"
	EndSubSection
EndSection

Section "ServerLayout"
	Identifier	"Server"
	Screen		"Schrirm"
[...]
EndSection

Re: TDMS bandwidth limits

[Edgar Fuß]

> Now I tried to give the modeline the drm debug output to xorg.conf,
> but it doesn't pick it up.
> I must be doing something stupidly wrong again:
For the record: It picked up my Monitor section for the VGA output, not for DVI-D as intended.
I should have read my logs more carefully.
Sorry for the partial noise.