-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[question] HDMI pixel clock limits #10
Comments
Hi Ilia, sorry for failing to reply to this question for so long. The logic for maximum pixelclock within the proprietary driver is convoluted, but for serial output resources (SORs) driving TMDS, I think it is effectively this:
(we use maxPixelClockKHz for mode validation, and maxSingleLinkPixelClockKHz to choose between single- and dual- link) Where:
SorCapDualTMDS and SorCapMaxTMDSClkKHz are computed like this: if [gf100,gf119) if [gf119,...) Let me know if I can answer any other questions around that. Sorry again for the slow response.
|
Thanks for the detail. Based on what I'm reading, for pre-GF119, there's no way to ever have a single-link pixel clock > 225mhz, even if passiveDpDongle == DP2HDMI_TYPE_2 (I have no idea what these are btw, just reading the pseudocode). However we have at least one report of a GF106 user for whom the proprietary drivers support a 297MHz mode (and in practice it works fine too): https://bugs.freedesktop.org/show_bug.cgi?id=91236 Am I misunderstanding your response, or is there more to it? [Also, I'll have to double-check, but as I recall in the case of a passive dongle, there's no DPCD, and we don't do the usual DP link training/etc stuff, so we wouldn't even know it was a passive dongle there... details on how that's computed might be nice.] |
I think the GF106 scenario would fall into the SorCapDualTMDS=true case, and result in maxPixelClockKHz = 330000. I'll dig up how passiveDpDongle is computed. |
You mean the !SorIsDrivingHdmi case? In that case, maxSingleLinkPixelClockKHz = 165000, and HDMI is never dual-link... or are you saying it'd be presented as dual-link anyways? |
For the DP passive dongle detection: it looks like we do some i2c reads on the DDC bus to detect the dongle. I'm told this interoperability is dictated by the "VESA DisplayPort Dual-Mode Standard". For the GF106 case: sorry, I didn't originally read the freedesktop.org bug, so I didn't realize this was HDMI. Reading the code, I must be missing something obvious, but from my read the proprietary driver's behavior in this case would match the pseudo code I described earlier, resulting in a 225MHz cap. I'll try to pull together a comparable hardware config and step through to see how this is getting validated with the proprietary driver. |
Various HDMI versions enable higher and higher pixel clocks. However individual GPUs are not required to support the maximum pixel clock supported by the spec in order to be compliant. It appears that some GPUs max out at 225MHz while others at 297MHz (while others still, I assume, are limited to 165MHz, esp among the older ones).
We've been unable to find this in the VBIOS (I had a thought that it was in the table pointed to by the 'T' table, but we have a counterexample to that). Could you suggest a way to find this information either from the VBIOS or based on the GPU? Are there differences between regular HDMI and DP -> HDMI (passive)?
This is becoming more and more relevant as 2560x1440/3840x2160 displays are become more common, while (dual-link) DVI-D is on its way out.
For now nouveau assumes Fermi = 225, Kepler+ = 297, but we definitely know that some Fermi's can do 297 (and the blob driver recognizes this fact).
The text was updated successfully, but these errors were encountered: