[PATCH and additional rambling] cache glyphs in the destination format requested to make sure the hardware can use the cached glyphs

[Adam Jackson]

On Sat, 2017-01-14 at 12:30 -0500, Michael wrote:

> The Creator is weirder - it's got what Sun calls '3dRAM' - little ALUs
> built into the memory chips which can do things like ROPs and alpha
> blending. So basically you can set up a few registers, then write a
> texture into memory and have it PictOpOver-ed at more or less the speed
> you can get it through the UPA bus. The 'blitter' has no copy
> operation, and it can't handle A8 textures, so storing textures in video
> RAM is useless. Also, its organization is weird and, for off-screen
> areas, undocumented.
> What would be a sane way to make EXA deal with these?

The driver's CheckComposite hook could inspect the destination picture,
and only return true if its drawable points into VRAM.

>  I'm not asking
> for EXA to change to accommodate old and weird hardware, but I bet
> there are other cases where we'd want to do blending operations
> directly from RAM to VRAM. What I'm thinking of doing in that case is
> to just set aside some actual RAM and coax EXA into using that as
> off-screen memory. Or have the driver replace exaGlyphs().

exa's already got old-and-weird quirks, a few more isn't going to hurt.

How much of this 3dRAM do you have to work with, and how fast can you
read back from it once you've written it?

- ajax