Live data from Hacker News

Exploring FPGA Graphics

projectf.io

31–40 of 47 posts

Re: Exploring FPGA Graphics

#31
post #7

Why are we still generating video signals as if there is a CRT on the other end? E.g. we could save power by only sending parts of the display image that change.

Displayport has two features that allow this, Panel-self-refresh and Panel Replay. Otherwise if you don't send the entire frame every sync cycle, the display will lose signal and go blank.

Re: Exploring FPGA Graphics

#32
This is so cool - great work on the writing, teaching, and general clarity.

I hope I can find time to play with it.

As a pure software guy I'm just mystified and awed by FPGAs and the possibilities of the design.

Re: Exploring FPGA Graphics

#33
post #26

Earlier quoted context omitted.

I’ve done nand2tetris a couple times (taking good notes the second time) and coincidentally played through nandgame.com for the first time this weekend. I’ve been trying out what people have done with bare metal Forth on a raspberry pi using a frame buffer and using C libraries to get input from a USB keyboard. I don’t really like having such dependencies so I was just thinking I should get out my Arty FPGA with the…

This sounds very cool - it's interesting to hear what projects lie further down this trail. I was initially looking at the Arty board, as it was referenced by a text book - all the exercises were based on it. It's a bit more pricey than the ice40 (enough to force a comparison against other boards), but it certainly looks more capable.

The icebreaker looks cool too, and small. I see they sell an HDMI output PMOD for it too. I wonder how that works (not that it's necessarily related to this VGA output example, anyway)

Re: Exploring FPGA Graphics

#35
post #2

Hello, I'm the author of the Project F blog. I've almost finished a complete overhaul of this series: animation and double-buffering are coming in October. I'd be happy to field any questions you have.

metagripe, the font you are using is too thin, top 10% of hard to read websites.

> "游ゴシック", YuGothic, "ヒラギノ角ゴ Pro", "Hiragino Kaku Gothic Pro", "メイリオ", Meiryo, sans-serif;

Re: Exploring FPGA Graphics

#36

Earlier quoted context omitted.

Have you writing an spec compatibile HDMI/DP controller in HDL? It's insanely complex. VGA is a walk in the park that's sane and easy to understand for beginners. You just need to modulate the 3 primary colors between 0-255 for 8 bit color, and two clock signals, and the monitor will display a picture. VGA is also very simple to debug since as long as there's some signal on the color and clock lines, the monitor will…

DVI is almost literally digitized VGA, with analog signals replaced by differential signalling and symbol encoding to keep it DC-balanced. HDMI extends it by encoding audio and extra metadata (eg. used colorspace) inside blanking intervals (yes, they still use blanking intervals that were originally required for CRT displays). It doesn't do any handshake. Main difficulty is just high clocks required, and necessity to…

> It doesn't do any handshake.

HDMI 2.0 requires bidirectional communication between source and sink through SCDC registers to set parameters such as scramble_enable, clock ratio, and to read status flags such as clock detection, channel lock status, bit error rates etc.

Re: Exploring FPGA Graphics

#37
post #27

Earlier quoted context omitted.

I think from a hardware perspective this would be non-trivial, despite sounding like an obvious thing in principle. In sending the entire frame with every refresh you get pixel addressing "for free", since you just send the data for each pixel sequentially in a predefined order. If you only wanted to update a single pixel, you would need to effectively send an instruction saying "set pixel x to rgb: a, b, c" or whate…

I think people can come up with more efficient protocols than sending x,y,rgb for every pixel. What you call "edge detection" is not necessary if you use shadow buffers. Yes, the display would need some memory, but this is measured in tens of megabytes which is not much by today's standards.

* a sink side memory of tens of megabytes is either on-chip memory (very costly) or on-PCB DRAM (still costly). For high refresh rate monitors, the memory would need to be high BW too. Note that there aren't any modern memory standards that are high BW but low storage. DRAMs with just a capacity of just a few MB would be very much pad limited.

* source side, you'd need a shadow buffer as well, and you need double the read BW to detect the difference between previous and the current frame.

All of that is technically achievable, but none of it matter for desktop monitors: the power savings are just too low to matter.

Laptops are a different matter. Many laptop LCD panels already support self-refresh. (Google "Panel Self Refresh")

But that's for cases where the screen is static: the user is staring at the screen, not moving their mouse, the cursor is static. The benefit is not just putting the link but also putting the GPU to sleep.

That's the low hanging fruit. Partial screen update doesn't save a lot more, because you'd need to power up the GPU for that.

Re: Exploring FPGA Graphics

#38
post #35
post #2

Hello, I'm the author of the Project F blog. I've almost finished a complete overhaul of this series: animation and double-buffering are coming in October. I'd be happy to field any questions you have.

metagripe, the font you are using is too thin, top 10% of hard to read websites. > "游ゴシック", YuGothic, "ヒラギノ角ゴ Pro", "Hiragino Kaku Gothic Pro", "メイリオ", Meiryo, sans-serif;

If you'd link to a screenshot of what you see, that would be helpful.

I have noticed the font renders thinner on Windows.

I plan to look at the design over the winter: some things could definitely be improved.

Re: Exploring FPGA Graphics

#40

Even if you don’t have an FPGA, you can run these hardware designs on your PC with SDL and Verilator. It’s really simple to set up: https://projectf.io/posts/verilog-sim-verilator-sdl/

The big disadvantage of not having a real FPGA is that you won't be concious of the very real LUT/gate limits. A simulation will happily allow you to apply all sorts of nice compartmentalizations and abstractions, without making your understand that they will cost significant money if you tried to find an FPGA to fit them into.

This was my biggest shock when first working with FPGAs, while naively using a software mentality. Most everything had to be re-written once the simulations were done.

Post reply on HN