>PC internals measured in gigahertz >monitors still

wow, really makes you think...

I know this is bait but I feel like venting some autism.

Consider, for a minute, how modern monitors work. The image consists of a grid of pixels, commonly around 2 million of them, right? (1920 x 1080 = 2,073,600)
The standard color depth in HDMI is 24 bits, meaning that each pixel requires 24 bits of data to be transmitted per TMDS cycle (a clock signal that is transmitted on a separate wire in the HDMI cable).

We'll ignore overhead in the HDMI signal used to denote the end of each line and the end of each image. It's basically a sequence of "0"s that is transmitted after each line / image, respectively, and effectively increases the number of pixels to be transmitted. I forget the lengths of those intervals but we'll ignore them for now. Keep this in mind though.

Now, the number of processor cycles (assuming only one processor core is tasked with producing the image) that are available for each frame -- i.e. how many single-step operations the core can perform between two frames, including those necessary for producing the image, can be calculated:
[math]N_C = \frac{f_C}{f_F}[/math]
where [math]f_C[/math] is the processor's clock frequency and [math]f_F[/math] is the desired frame rate. For a 3 GHz clock and a frame rate of 60 FPS, we arrive at 50,000,000.

Now consider the fact that each frame consists of several million pixels. The number of operations per pixel is [math]\frac{5 \cdot 10^7}{2.073 \cdot 10^6} \approx 24[/math].

And now remember that
1) we ignored the effective image size which is larger than the nominal image size, and
2) these are single CPU instructions.
Now if we already have the video data in memory, there's no problem -- we could use DMA to read the pixel data from memory and send it on each CPU cycle. We'd have a little more than 20 cycles per pixel left for other stuff, the core would be at less than 5% load. We could (theoretically) increase the frame rate by a factor of 10 and still not run into any issues on the processor side.

The bottleneck in HDMI is the cable. For a full HD image (1920 x 1080) at 60 FPS with a color depth of 24 bits per pixel, your data rate is R = 2,985,984,000 bit/s.

Using the Shannon-Hartley theorem
[math]C \leq B \log_2 \left ( 1 + \frac{S}{N} \right )[/math]
and setting [math]C = R \approx 3\,\mathrm{Gbps}[/math] and [math]B = \frac{f_C}{2}[/math] (see Shannon-Nyquist theorem) we can calculate the S/N necessary for an error-free transmission if the processor is running at 100% load, using DMA, with no HDMI protocol overhead (N is the effective noise power in Watt, S is the signal power):

[math]\frac{S}{N} \geq 2^{R/B} - 1[/math]

[math]\frac{S}{N} \geq 2^{3 \cdot 10^9 \,\mathrm{bps} ~/~ 1.5 \cdot 10^9 \,\mathrm{Hz}} - 1[/math]

[math]\frac{S}{N} \geq 2^2 - 1 ~=~ 3[/math]

That's actually pretty surprising to me, I'd have expected a much higher value. As it is, pushing the processor core to its limits (100% load, DMA meaning it takes 1 instruction to load and output the pixel data) under perfect conditions (ignoring HDMI protocol overhead, guard periods and rise times, assuming perfect synchronicity and zero latency where necessary), we can tolerate noisy interference of up to 1/3rd the power as the signal's (roughly 1/10th the voltage). In other words, an SNR of only (approximately) 10 dB is necessary for this transmission. Should be do-able (and obviously is, as you can see by the fact that plenty of people use HDMI for full-HD 60 FPS displays).

Now let's look at what happens if you wanted to, say, have a frame rate in the Megahertz range -- e.g. 30 million FPS, which is still only two orders of magnitude smaller than the previously assumed CPU clock frequency.

Operations per pixel:
[math]N_p = \frac{f_C}{f_F \cdot N} ~=~ \frac{3 \cdot 10^9\,\mathrm{Hz}}{3 \cdot 10^7\,\mathrm{FPS} ~\cdot~ (1920 \cdot 1080)\,\mathrm{px} \cdot \mathrm{frame}^{-1}} ~\approx~ 5 \cdot 10^{-5}[/math].

This alone shows that even ignoring everything else, we would have to increase the clock frequency by more than a factor of 200,000 in order to even have a shot of generating (loading and passing through) all that pixel data. That's a clock frequency of 600 Terahertz, which is... _difficult_ to transmit over copper cables. In fact, that's squat in the middle of the VISIBLE spectrum. As you might have observed, copper doesn't transmit light very well. Try looking through a solid block of copper sometime.

Alternatively, you would have to use 200,000 parallel systems (actually more, considering the overhead necessary to synchronize them) which introduces a hell of a lot of interference as well as issues with spacing -- imagine how thick those cables would be! It would also make circuit board and plug layouts incredibly (impossibly) complex, to say nothing of the issues relating to heat transfer.

>>9134131
Whoops, spotted a mistake: the increase in clock frequency (or number of systems) would only have to be around 20,000 (2e4) instead of 2e5.
My point still stands: No copper cable in the world has that kind of bandwidth (a "mere" 70 THz), and cables with 20,000 parallel wires aren't really viable either.

>>9134137
60 THz*
God damn it
Time to get off the computer.