Hacker News Reader

Comment by phkahler | Hacker News Reader

>> is there any known promising projects besides libregpu?

I think the most useful thing right now would be a high quality version of the "easy" parts of a GPU. Basic scan out, possibly overlays, color space conversion, buffer handling. This would allow ANY open processor projects to have frame buffer graphics and run LLVMpipe for basic rendering and desktop compositing. This may be slow, but it is required for every open GPU project, while a SoC can live without the actual GPU for some applications.

IMHO, first thing first.

View on HN

this is easy to chuck together in a few days, literally, from pre-existing components found on the internet.

* litex (choose any one of the available cores)

* richard herveille's excellent rgb_ttl / VGA HDL https://github.com/RoaLogic/vga_lcd

* some sort of "sprite" graphics would do https://hackaday.com/2014/08/15/sprite-graphics-accelerator-...

the real question is: would anyone bother to give you the money to make such a project, and the question before that is: can you tell a sufficiently compelling story to get customers - real customers with money - to write you a Letter of Intent that you can show to investors?

if the answer to either of those questions is "no" then, with many apologies for pointing this out, it's a waste of your time unless you happen to have some other reason for doing the work - basically one with zero expectation up-front of turning it into a successful commercial product.

now, here's the thing: even if you were successful in that effort, it's so trivial (Richard Herveille's RGB/TTL HDL sits as a peripheral on the Wishbone Bus) that it's like... why are you doing this again?

the real effort is the 3D part - Vulkan compliance, Texture Opcodes, Vulkan Image format conversion opcodes (YUV2RGB, 8888 to 1555 etc. etc.), SIN/COS/ATAN2, Dot Product, Cross Product, Vector Normalisation, Z-Buffers and so on.

Seriously? VGA with DVI outputs? And a link to a Sprite engine?

We need HDMI output, preferably 4K capable. I also mentioned colorspace conversion. Should have also said to "just throw in" video decoder for VP9 and AV1 if that's available. The point is that the likes of SiFive and other Risc-V SoC vendors should be making desktop chips, not just headless Linux boards or ones with proprietary GPUs.

Like I said, the "easy" part should be done and available - not theoretically assemblable from various pieces.

If this were readily available, I'd be able to buy it from someone today. There IS a market for it and that will be growing fast. Add a real GPU and things look even better.

The problem with HDMI is the patent encumbrance. DisplayPort would be a better target for "libre" applications. It looks like you may even need to be actively licensing HDMI to buy a displayport to hdmi bridge as well.

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 :)

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.

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? :)

Yeah. I also miss the small but firm steps approach.

this is what we're doing in Libre-SOC, and using standard python software engineering practices (writing unit tests at every step of the way) to do it. some of those unit tests are actually Formal Correctness Proofs (asserts, but for hardware).

i was stunned to find that in the hardware world, test-driven development is not standard practice: people simply haven't been trained that way. they write thousands to tens of thousands of lines of unverified code and finally do an integration test.

Reply on news.ycombinator.com