AnandTech's 'Discrete HTPC GPU Shootout'

[CiNcH]

Der ein oder andere hat diesen Artikel bestimmt gelesen. Schön, dass mal jemand auf die Belange der HTPC-User eingeht. Dennoch möchte ich hier eine Klarstellung veröffentlichen, was das Kapitel Custom Refresh Rates anbelangt. Meiner Meinung nach sieht der Verfasser hier nicht das gesamte Bild:

Hi Genesh,

 

there is just one thing about your HTPC review that is a bit misleading in my opinion. It is the thing about refresh rate. Here is my view on things...

 

You have to differ between playback speed and output speed. Playback speed is usually determined by the DirectShow graph clock, output speed by some clock on the graphics card. Question now is what the DirectShow graph clock is derived from and whether it runs at a different speed compared to the graphics cards' clock. Keep in mind that two distinct clocks never run at exactly the same speed...

 

If you use ReClock, the DirectShow graph clock is derived from the graphics card's clock. In this case it does not matter how much the refresh rate is off, as the playback speed is perfectly in sync with it. You can run a Blu-Ray movie which is mastered at 23.976 fps at for example 24.002 Hz without a single glitch, as playback is run at the very same speed (in this case at 24.002 fps) as the output.

If you use the standard MS audio renderer, DirectShow graph clock is most likely based on the rate at which the audio adapter consumes samples. Playback and output are not synchronized in this case. But it still does not matter at all how much the refresh rate is off. It only matters how fast the graph (or playback) clock and the output clock (VSync) drift apart from each other. So if refresh rate is off and the graph/audio clock is off by the same amout, everything is fine and you won't see a single glitch. This scenario is not likely though because as mentioned, two distinct clocks always drift.

So your glitch per minute (or whatever) calculations are invalid.

I have also done a test with recent a AMD GPU, the HD6570 with its on-chip audio unit. Graph, audio and video output are all based on the same clock in this case. There is no drift at all and everything is perfectly in sync. Another example for when it does not matter how much the refresh rate is off as playback speed (fps) is perfectly tied to the refresh rate. If refresh rate is 23.971 Hz then also playback rate inside the DirectShow graph is at a perfect 23.971 fps, as both are based on the same clock.

 

So either way your calculations do not tell the whole story. In a PC where every component is driven by a distinct clock, it is a matter of synchronization. And if you want to make assumptions about the drop/repeat rate you have to look at a little more than just the refresh rate.

[nuts]

Woher die Abweichungen bei der dritten Nachkommastelle wohl kommen?

Von den verbauten Taktgebern? Vom Zeitstempel des Encoders (bzw. dessen Taktgeber)?

 

Synchronisiert führt das aber zu keinem Problem, wie auch die Synckurven im Test von anandtech zeigen.

Sieht mit meiner Ati HD5670 ohne weitere Massnahmen (Sync renderer, reclock) genauso aus.

Edited September 2, 2011 by nuts

[CiNcH]

Von den verbauten Taktgebern? Vom Zeitstempel des Encoders (bzw. dessen Taktgeber)?

Da geht es allein um die Messung der Refresh Rate (Abstand der VSync's bzw. Anzahl der VSync's pro Sekunde). Frames bzw. Videowiedergabe interessieren da erstmal noch nicht. Die Ungenauigkeit kommt vom Oszillator und ist von vielen Dingen abhängig, e.g. Beschaffenheit, aber auch von äußeren Einflüssen wie Temperatur usw.

 

Synchronisiert führt das aber zu keinem Problem, wie auch die Synckurven im Test von anandtech zeigen.

Sieht mit meiner Ati HD5670 ohne weitere Massnahmen (Sync renderer, reclock) genauso aus.

Wenn du synchron zum VSync renderst und dich die Frame-Timestamps erstmal nicht interessieren, sind die Kurven immer parallel. Die Frage ist, wie sich die Frame-Timestamps dazu verhalten. Wenn die von den VSync's wegdriften, wird es entweder langsam asynchron, oder man synchronisiert, z.B. indem man von Zeit zu Zeit ein Frame verwirft/wiederholt (das würde man in der Kurve dann sehen).

ReClock verhindert das Driften von Timestamps und VSync (weil beide mit derselben Clock "gesampelt" werden). Somit sollten die Kurven stets parallel bleiben und alle Frames sollten für die vorgesehene Zeit angezeigt werden.