cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

madshi
Journeyman III

ADL ModeTimingOverride bugs

uses different timings than asked for

XPSP3 32bit, HD 3850, Catalyst 10.9

The ADL ModeTimingOverride APIs *appear* to work just fine. Meaning, I can set timing overrides, they are accepted, and they are enumerated exactly as I set them. Unfortunately, it's rather rare that a custom timing mode is actually *applied* as it was specified. Some examples:

(1) Standard CEC 1080p60 timing (hTotal 2200, hDisplay 1920, hFrontPorch 88, hSyncWidth 44, hBackPorch 148; vTotal 1125, vFrontPorch 4, vSyncWidth 5, vBackPorch 36, pixelClock 14850). This one works just fine. The driver sets exactly the values I specified.

(2) Standard CEC 1080p60 timing with small modifications, e.g. vTotal set to 1126 or 1127 instead of 1125. What the driver actually sets is *very* different: (hTotal 2072, hDisplay 1920, hFrontPorch 32, hSyncWidth 28, hBackPorch 92; pixelClock 13950).

And this happens all the time. The driver appears to "like" some timing combinations, which are then applied correctly, but most custom timings are totally reinterpreted by the driver, which usually results in my screen going black, because it doesn't accept the funny timings set by the driver.

For people trying to reproduce this problem, simply start with the standard 1080p60 timings listed above, then slightly modify one timing parameter at a time. E.g. try increasing pixelClock or hTotal or vTotal by 1 or 2. You can verify what the driver really applies with PowerStrip (won't work for 5xxx cards, because PowerStrip doesn't support them).

BTW, the pixel clock adjustment steps are VERY coarse. It's really hard to hit target refresh rates like 24/1.001 or 59/1.001 this way. The pixel clock should be adjustable in much finer steps...

0 Likes
7 Replies
Byron
Staff

Can you provide the exact structure fields and parameters you are calling ADL_Display_ModeTimingOverride_Set with?

Make sure that the timing standard (iTimingStandard)is set to ATIDL_MODETIMING_STANDARD_CUSTOM.

0 Likes

Thanks for your reply. Here's a list of the exact structure fields for various timings I tried to set, and the actual results I got instead. Please let me know if you need any more information.

"wanted": is the exact structure fed into ModeTimingOverride_Set
"actual": is what the GPU hardware is actually programmed to by the GPU driver

ModeTimingOverride_Enum enumerates the "wanted" values, but not the "actual" values. The "actual" values can be taken from PowerStrip (when using a GPU which is supported by PowerStrip).

official 1080p60: wanted: (8, 15, 60, 1920, 1080, (96, 0, 2200, 1920, 1920 + 88, 44, 1125, 1080, 1080 + 4, 5, 14850, 0, 0, 0, 0, 0, 0)) actual: 2200, 1920, 1920 + 88, 44, 1125, 1080, 1080 + 4, 5, 14850 -> ok official 1080p60, with vTotal modified wanted: (8, 15, 60, 1920, 1080, (96, 0, 2200, 1920, 1920 + 88, 44, 1127, 1080, 1080 + 4, 5, 14850, 0, 0, 0, 0, 0, 0)) actual: 2072, 1920, 1920 + 32, 28, 1127, 1080, 1080 + 4, 5, 13950 -> horizontal timing incorrect, pixel clock incorrect official 1080p23: wanted: (8, 11, 24, 1920, 1080, (96, 0, 2750, 1920, 1920 + 638, 44, 1125, 1080, 1080 + 4, 5, 7417, 0, 0, 0, 0, 0, 0)) actual: 2750, 1920, 1920 + 638, 44, 1125, 1080, 1080 + 4, 5, 7417.6 -> pixel clock modified to better match 23.976Hz official 1080p23, with pixel clock modified up: wanted: (8, 11, 24, 1920, 1080, (96, 0, 2750, 1920, 1920 + 638, 44, 1125, 1080, 1080 + 4, 5, 7418, 0, 0, 0, 0, 0, 0)) actual: 2750, 1920, 1920 + 638, 44, 1125, 1080, 1080 + 4, 5, 7425 -> pixel clock incorrect official 1080p23, with pixel clock modified down: wanted: (8, 11, 24, 1920, 1080, (96, 0, 2750, 1920, 1920 + 638, 44, 1125, 1080, 1080 + 4, 5, 7416, 0, 0, 0, 0, 0, 0)) actual: 2750, 1920, 1920 + 638, 44, 1125, 1080, 1080 + 4, 5, 7425 -> pixel clock incorrect special 1080p23: wanted: (8, 11, 24, 1920, 1080, (96, 0, 2750, 1920, 1920 + 638, 44, 1183, 1080, 1080 + 4, 5, 7800, 0, 0, 0, 0, 0, 0)) actual: 2750, 1920, 1920 + 638, 44, 1183, 1080, 1080 + 4, 5, 7788.5 -> pixel clock incorrect special 1080p59: wanted: (8, 11, 24, 1920, 1080, (96, 0, 2200, 1920, 1920 + 88, 44, 1183, 1080, 1080 + 4, 5, 15600, 0, 0, 0, 0, 0, 0)) actual: 2048, 1920, 1920 + 32, 28, 1141, 1080, 1080 + 1, 3, 14006.2 -> horizontal timing incorrect, vertical timing incorrect, pixel clock incorrect

0 Likes

We'll have to investigate...

 

Our driver should support 23.976Hz (24/1.001 Hz ) natively so we are still not clear as to why you need to create a new timing for this. 

0 Likes

Originally posted by: Byron Our driver should support 23.976Hz (24/1.001 Hz ) natively so we are still not clear as to why you need to create a new timing for this.


23.976Hz was just an example. Here's a list of what I need custom modes / timings for:

(1) Some of my users have CRTs (or plasmas with funny native resolutions) and need specific resolutions / refresh rates for optimal image quality which are not offered by your driver.

(2) In some situations custom video timings work better than standard CE timings, so I want my users to be able to set custom timings, if they feel the need for that. That is actually a very common thing to do in the HTPC world.

(3) Your driver doesn't offer all needed standard output modes on all OSs in all situations. E.g. on my XPSP3 PC I haven't managed to make your driver output 1080p23, even through the EDID is correct. I only get 1080i24, but not 1080p23 nor 1080p24.

(4) I can't possibly test all your GPUs in all OSs with all driver versions. So I can't be sure that your driver uses proper CE timings for all my users in all situations. So I want to have the ultimate control, so I can fix/add whatever is wrong/missing (see (3)).

In addition to custom timings functionality it would be great if there was a new ADL API to create a custom output mode. Something like this:

ADL_Display_CreateCustomOutputMode(width, height, refreshRate, interlacedOrProgressive, [frontPorch, syncWidth, ...]);

E.g. I could use this to create Digital Cinema output modes (2K, 4K) etc. Or simply to add needed missing output modes not offered by your driver by default. (FWIW, NVAPI contains such an API.)

Thank you.

 

0 Likes

Would you please provide the test utility that call ModeTimingOverride APIs to set custom timing mode for debugging.

0 Likes

Our engineer emulated the mode timing override.

 

And while the timing is 1080p@60hz, if he modified the vsync total and synce total more than 1 or 2, the timing are both OK.

 

See data below,

 

official 1080p60:

wanted:   2200, 1920, 1920 + 88, 44, 1125, 1080, 1080 + 4, 5, 14850

actual:     2200, 1920, 1920 + 88, 44, 1125, 1080, 1080 + 4, 5, 14850

-> ok

 

Official 1080p60, with hTotal modified

wanted:   2201, 1920, 1920 + 88, 44, 1125, 1080, 1080 + 4, 5, 14850

actual:     2201, 1920, 1920 + 88, 44, 1125, 1080, 1080 + 4, 5, 14850

-> ok

 

Official 1080p60, with vTotal modified

wanted:   2200, 1920, 1920 + 88, 44, 1127, 1080, 1080 + 4, 5, 14850

actual:     2200, 1920, 1920 + 88, 44, 1127, 1080, 1080 + 4, 5, 14850

-> ok

 

 

 

0 Likes

Byron schrieb:

We'll have to investigate...

Our driver should support 23.976Hz (24/1.001 Hz ) natively so we are still not clear as to why you need to create a new timing for this.

Actually, I am pretty certain you have a typo in your driver when calculating the pixel clock: please check if you accidently calculate with 23.967 instead of 23.976. I have calculated pixel clock straight forward (Htotal*Vtotal*23.976), created a new cutstom mode using ADL, and all of the sudden Powerstrip reports 23.976Hz and not 23.967! Also Media Player Homecinema reports now 23.976  (pressing CTRL+J), no framedrops anymore, red+green line running perfectly parrallell (before, the green line was driving upwards). Driver: Win 7, 32 bit, version 12.1

0 Likes