Go Down

Topic: Vidor's Graphic possibility. (Read 839 times) previous topic - next topic

narit

I wonder , is it possible to increase the HDMI resolution and degrading bit depth resolution?

I have look in IP core, it seems to be 720p for the frame buffer's counter but my current output is still lower.

Also, I'm quite a little bit confusing between the IP core. My current understanding is the neopixel is the graphic engine?

Therefore,could we make a direct access to sdram? (like bitblt,dma?) or could we embed some graphic generator/classical graphic generator techniques like in Atari/ 8 bit controller?




pert

Neopixel is Adafruit's marketing fluff term for the WS2812 (or clones thereof) addressable LEDs.

jaholmes

#2
Aug 13, 2018, 08:46 pm Last Edit: Aug 13, 2018, 08:50 pm by jaholmes
I gather from prior posts by the Arduino folks that the limitations of the current Vidor graphics stem (at least in part) from a desire to share RAM bandwidth with other Vidor functionality.  This seems ok for an out-of-the-box configuration, but if you're mainly after graphics, it would be good to be able to say "screw it" to that other functionality and dedicate the FPGA and RAM to a full-featured graphics configuration.

These would be the main things on my wish list:
1) 24-bit color.  Let me kill all the other IP and hog the RAM bandwidth if I know I can safely do that.
2) Double-buffering.  The 8Mb of RAM is enough for double-buffering at 720p with 24bit color.  That would be a really nice mode of operation.  The API would need trivial modification to allow for page-flipping synchronized with the vertical blanking interval.  Then we could do smooth animation without flickering and tearing.


DarioPennisi

hi guys,
i tested hdmi output up to 1080p30 (at a slightly lower than standard pixel clock) so yes, vidor can do that as well and of course can support 1280x720p60 (still at slightly lower than standard pixel clock).
rgb 24 bits is not a problem and yes,we can easily do double buffering but again the bottleneck is memory bandwidth. a good rule of thumb is that you should ad between 15 to 20% overhead to pixels being spit out to calculate memory transaction overhead. this means that 1280x720@24bit would take almost all memory bandwidth with little left only for processor accesses to write there.
on the other hand, having a palettized 8 bit per pixel access would result in much lower bandwidth and could be a nice solution to have high res video.
ip blocks are parametrizable so you can actually set them at the resolution you want, provided you know how to do that and that we release the tools for the flow (which hopefully won't take long).

i am about to release (probably next week) an upgraded version of the graphics library which has support for multiple fonts and can use gfx also to draw into neopixel memory. maybe next step could be to have selectable output resolution and bit depth but i guess that would be a separate fpga image.

narit

I think double buffering is quiet easiest thing to be implemented. It requires just 1 flip-flop to swap the address.However, there should be another implementation such as ISR or "Pin as a flag" to create WaitRetrace() process.

Another fancy stuff is the offset mapping that remap the sdram address (X,Y) and Data Pipe that passes the data  though internal FPGA-FIFO and use them as a buffer (It is abandoned and I think, it require less resources than implement a DMA).

I believe this board will resurrect the old school techniques alive. Also, it is possible to direct drive the LVDS LCD screen.

Glad to hear and I am looking forward for the next update.

Go Up