I'm having a go at using the ORGFX core and I was wondering if it reads / writes single pixels at a time to the memory system, or does it work with multiple pixels at once ?
It would be nice if the graphics accelerator simply had outputs/inputs that requested a pixel fetch / put from the video system, and allowed the video system to fetch/put the pixel.
As it is I need to make an adapter core for the pixel fetch / put, which would be placed between the ORGFX and the memory system. I'm using unevenly mapped pixels to conserve memory space in some circumstances. Eg. 10, 12 bit pixels are placed into a memory strip of 128 bits with 8 bits left over. (Or 21, 6 bit pixels).
So I'm wondering if I can easily decode the address request outputs and turn them into pixel X,Y co-ordinates. Then feed that into a pixel fetch / put core.

Can you point me at an interface for the ORGFX system you are trying to implement?

Thanks!

I decided to rewrite the portions of the graphics core to do what I needed rather than add an external interface. I found the core easy to modify. I added an address calculation module.
The changes(untested yet) to the core are on my github account at:

http://github.com/robfinch/Cores/tree/master/orsoc_graphics_accelerator/trunk/rtl/verilog/gfx

Everything you are suggesting sounds reasonable ... certainly I would think you would want to read/write as many pixels as possible at one time.

I mean, let's think about this, the only reason you are writing a graphics engine is to speed up graphics processing. To go as fast as you can, you want to work on pipelined reads/writes, no? Not only will pipeline read/writes get rid of wait states on the wishbone, but it will also make a maximum use of such memories as DDRx SDRAMs.

Have I captured the essence of your question?

Not really. I was hoping it worked a single pixel at a time because then it would be easier to interface to, if having to build an external interface. Primarily I wanted to interface the core so it would use 12 bit pixels packed into 128 bits. The display module uses 128 bit read accesses to update the display.
The memory system of the SoC I'm using always reads / writes 128 bits at a time to the DDR RAM so it's somewhat inefficient to make use of only 32 bit read/writes. The SoC's memory controller caches reads to allow better performance for 32 bit reads. I've re-written part of the gfx writer to buffer pixels into 128 bit buffer (if possible) then write the whole buffer out at once. I also modified the reader to use a 128 bit access because pixels are bit aligned and not byte aligned and may cross a 32 bit boundary. While I was at it, I added support for some more color depths.
But, I haven't got it work yet....

Okay, but ... let's think through this:

Are there graphics operations that require only a single pixel change? Then the engine should be able to read and write a single pixel at a time.

Memory, though, often works faster in a pipelined fashion. Certainly the wishbone works faster in a pipelined mode.

Some graphics operations can work nicely on pipelined memory: drawing rectangles, triangles, polygons, circles, and even to some extent lines. These should be able to operate on a run of pixels in a row.

So ... if you have to build a graphics engine that works on one pixel at a time in order to get the first operation to work, can this be expanded/extended to get the second operation to work? Then, when rectangles work one pixel at a time, can the rectangle operation be pipelined to work faster?

I mean, can it be done in a two step process? Get it working slowly first, and then get it running faster?

Just a thought,

Dan