Re: EXA requirements (was: Re: Improved memory detection for cgsix)

On Thu, 3 Mar 2022 19:42:43 +0100
Hello,

Romain Dolbeau <[email protected]> wrote:

> Le jeu. 3 mars 2022 à 19:26, Michael <[email protected]> a écrit :
> > EXA more or less depends on being able to address VRAM by offset +
> > coordinates with arbitrary pitch, so off-screen pixmaps can be neatly
> > treated as simple memory ranges.  
> 
> Fully arbitrary, or can it work with some required level of roundings?
> Unaligned accesses are problematic for most HW. So a stride of 16x8-bits
> pixels or 4x32-bits pixels (or integer multiple of) is easy to implement
> with a 128-bits memory controller, but 15x8 or 17x8 or 3x32 aren't.

It allows you to specify alignment requirements for pitch and data,
most modern and not so modern blitters have those in one way or another.
In order to let exa use any off-screen memory at all suncg6 just
requests pixmap pitch to be the same as the screen's. Wastes a lot of
VRAM but allows to use at least some...
The suncg14 driver requests 8 byte alignment for pitch & data mostly
for convenience - memory accessing SX instructions require 64bit
alignment but allow for a 3bit displacement, it's less complicated if
the displacement stays the same for each scanline.

> I'm thinking of ways to implement a vector engine that could do arbitrary
> copy, but it's not easy.
> (the VexRiscv core I currently use can do arbitrary 32-bits, but that
> versatility comes at a cost in terms of performance, so I want to address
> the memory controller directly).

Look at the suncg14 accel code, specifically the 8bit stuff. IIRC I
wrote at least three different routines to copy 8bit pixmaps around,
mostly to deal with alignment mismatches and avoid less than 32bit
accesses whenever possible.

> > If your hw can't do that, off-screen memory is mostly a cache for
> > frequently used pixmaps.  
> 
> Well that's the benefit of rolling your own hardware in a FPGA - you
> can adapt it to the needed requirements :-)

Indeed ;)

have fun
Michael