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.
Exploring FPGA Graphics
31–40 of 47 posts
Re: Exploring FPGA Graphics
#32I 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
#33Earlier 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.
Re: Exploring FPGA Graphics
#34Re: Exploring FPGA Graphics
#35Hello, 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.
> "游ゴシック", YuGothic, "ヒラギノ角ゴ Pro", "Hiragino Kaku Gothic Pro", "メイリオ", Meiryo, sans-serif;
Re: Exploring FPGA Graphics
#36Earlier 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…
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
#37Earlier 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.
* 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
#38Hello, 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;
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
#39Re: Exploring FPGA Graphics
#40Even 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/
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.