> Probably, something popular needs building that demands 10G-in-the-home to use, in order to get volume up so pricing can come down a bit.
HDMI 2.0 for 4K is 14.4 Gbit/s
HDMI 2.1 for 8K is 42.7 Gbit/s
HDMI 2.0 for 4K is 14.4 Gbit/s
HDMI 2.1 for 8K is 42.7 Gbit/s
Receiving non-visual data from the GPU has the interesting property that the shaders and video RAM are generally kind of very close to the HDMI port, so I could potentially be "sending" the result of running a shader on data in video RAM.
Something something using VRAM for caching...?
I've been meaning to figure out how to capture HDMI, at line speed, for a while. My current thinking is to use a PCIe FPGA capable of bus-master DMA, a horribly-hacked-apart kernel that doesn't touch a few GB of RAM, and a kernel driver to "chase" after the gigantic ring buffer the FPGA copies into.
Hmm, I probably wouldn't be able to copy at HDMI 2.1 line rate.
Unless there are very very scary FPGA contraptions that use TWO PCI-e slots? :D:D [EDIT: I now realize this would need two PCI-e root complexes. Woops]
I believe any FPGA with a decent PCIe implementation should be able to bus-master, and if you set up the drivers properly you don't have to do anything with the kernel, it'll just allocate a block of transfer RAM for you.
You can use multiple PCIe lanes easily? If you need more than an x16 slot I'd be very surprised.
Right. I wouldn't be surprised if that encoder is a single chip designed to ingest TMDS so the 10-40Gb/s of raw data only travels a few mm.
And MPEG encoding is the only reasonable way to handle data of this size, considering that it compresses 10Gbps down to <80Mbps and typically <10Mbps.
> I believe any FPGA with a decent PCIe implementation should be able to bus-master, and if you set up the drivers properly you don't have to do anything with the kernel, it'll just allocate a block of transfer RAM for you.
As for the first part, cool.
With the 2nd part, you're seeing my complete lack of hardware knowledge :)
I was envisaging having the host system "ignore" several GB of RAM - have linux's memory manager simply not touch it - and then turning it into a gigabyte+-wide circular buffer to copy into.
Then, the processing/do-whatever code is written as a kernel module that "chases" after wherever the "head" is in the circular buffer (presumably this would be a pointer written to a fixed memory location). Because the buffer is gigabytes wide the kernel driver can stall (for whatever reason) for multiples of seconds and have wild swings in "chase performance" before there are any real issues.
This design enables an important goal which I wanted to implement: pressing PrtScr or hitting a hardware button flushes the last few seconds of whatever was on the screen to disk - ie, you can achieve hardware-level, pixel-perfect, video capture. Frame glitch? Saved. "LOOK, the GPU displayed a single frame wrong again, agh, you missed it"? Saved. Weird timing glitch in graphics stack you can't reproduce? Saved. Weird timing/race-condition-related graphics issues that only happen when your test code is removed and are too fast to diagnose? Saved. Suddenly you can just spray debug data into the corner of the screen and analyze the captures later.
Ideally, some simple compare-while-copying code running in the FPGA could store simple frame deltas and distil whole-screen updates into a list of changed rects. Maybe you could even do that on-CPU, as a kernel task.
But here's the thing. In the worst case, with no compression/reduction code present, you'd be able to store 1 minute of 60fps 1080p in 20.85GB of RAM, and 6 minutes in 125.15GB. 1 minute of 3840x2160 uses 83.42GB, 3 minutes uses 250.28GB. 1 minute of 8K takes 333GB :D
Of course, flushing to disk is a major operation; it would likely require multiple PCI NVMe devices, in either RAID or driven via a threaded storage engine, to flush the memory to storage fast enough - in the 8K example, you need to copy 333GB of RAM to disk in 1 minute, so your solution needs to receive 5GB (44.4Gb) per second, sustained, no performance spikes/dips. :P
(This is where the gigantic circular buffer comes in to play; the idea is that the wraparound hits RAM with new data just as the old data got saved.)
What's potentially interesting with this are the situations doing desktop-type work, small-scale tests, etc, where not all of the screen is going to be updated, and the reduction system will diff the updates very effectively. In these situations, if you're careful, you may go from minutes to tens-of-minutes or even hours of recording time, on a 128GB or 256GB RAM system. And that's only spending a few hundred $. (For the RAM, that is.)
If you're doing game development - every screen effectively new data - and you need pixel-perfect HDMI capture, well, 2TB RAM workstations are only low/mid-5 figures now...
> You can use multiple PCIe lanes easily? If you need more than an x16 slot I'd be very surprised.
The GP mentioned that HDMI 2.1 is 42.7Gbps. Elsewhere in this thread it's mentioned that PCI-e's limit is 50Gbps. [EDIT: Just noticed the other comment about PCI-e speed. This makes things a little easier!]