[lkcl]

yes. HDCP has "infected" HDMI, eDP, USB-C and so on.

this can entirely be avoided with:

* TFP410a (RGBTTL to DVI/HDMI)

* SN75LVDS83b (RGBTTL to LVDS)

* SSD2828 (RGBTTL to MIPI)

* various other converter ICs

4k btw is MENTAL bandwidth. multiply 3840 by 2160, then by 4, then by 60: this gives the number of bytes per second required of the internal memory bus.

turns out to be 2 gigabytes per second, doesn't it?

now check the datasheets on what affordable FPGA boards can do, what memory ICs they have, and whether they can cope with that level of bandwidth.

you'll find that there aren't any.

i do find it ironic that "incremental steps" are recommended, "to get something running", but lack of knowledge of the difficulty surrounding DRM and in ramping up to high speed leads to "disbelief". ah well :)

[Teknoman117]

To be fair, I wasn't constraining myself to "affordable" FPGA boards. An expensive FPGA board is a one-time expense, but the license for a proprietary HDMI IP core and HDMI membership is at last an order of magnitude larger, and a recurring expense. You can get some fairly high-end FPGAs before needing the paid tier of the Xilinx tools.

As far as memory bandwidth goes for 4K, HDR10 content is about 2 GB/s, regular SDR content is 1.5 GB/s for normal 24 bit color, and if you're running SDR content with chroma subsampling (4:2:0), you're at 750 MB/s.

If we're considering the "affordable" tier of FPGA boards:

An Artix 7 can be found on boards <= $200, and the GTP channels are capable of HDMI 2.0 speeds (6 Gb/s per lane). HDMI uses an 8/10b encoding, so the gearbox setup would be 600 MHz, which is doable on the -3 and -2/-2L speed tiers. You can also use 64 bit DDR3 @ 1066 MT/s (8.5 GB/s) on -3 speed grades and 64 bit DDR3 @ 800 MT/s on -2/-2L speed grades (6.4 GB/s).

You don't necessarily have to be rendering a 4K stream from RAM to want a 4K output. You could be generating the higher resolution content on demand and not be putting that much pressure on the memory. Think tiled graphics, or native resolution overlays over an upscaled input stream.

[lkcl]

unfortunately the data still has to be in a full 32BPP framebuffer (in order for 2D or 3D Window Managers to write to it).

all the graphics software will write at that full 32BPP rate: it is unfortunately not reasonable to expect all Graphics Software to perform data compression.

yes there will be a few opportunities for compressed streaming, and funnily enough we were just thinking "what if the GPU were to do the same trick as the Amiga used to do, 40 years ago, by following the scan-lines?"

in the case of video playback you might reasonably expect that an area of the screen is "reserved" (not written to) but that when the Video-Output HDL gets to that pixel instead reads directly from a completely different device: one that is formatted already in HDR/SDR or YUV.

effectively this is a modern "sprite" engine.

... but, again, we have significantly diverged from the original "Just Make It Real Simple Why Don't You Just", yeh? :)