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

Michael macallan at netbsd.org
Tue Jan 17 16:47:59 UTC 2017


Hello,

On Mon, 16 Jan 2017 15:16:47 -0500
Adam Jackson <ajax at nwnk.net> wrote:

> 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.

That's what I tried first - EXA won't even get to PrepareComposite()
unless all involved pictures are in VRAM. EXA apparently assumes that
composite operations can only be accelerated with all sources in VRAM.
That's not even true on all 'normal' chips - Permedia 2 for example
will happily apply compositing to host blits ( but not to vram-to-vram
blits, then you have to use the texture unit for some reason ) - I
doubt it's the only one, it's just the one where I noticed it.

> 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?

Depends on the model - most cards have 15MB which is usually divided up
into front, back and z-buffer but can be run as one big framebuffer.
Some older ones have only 5MB. There are newer ones ( like XVR1000 and
4000 ) that have 72MB or more, plus plenty of regular RAM, but those
are rare and undocumented.
I'm not sure how long it takes for a write through the ALU to be
visible when reading directly from the actual RAM, can't be more than a
few cycles though. I do have the datasheet for the 3dRAM chips
somewhere...
Evidently the whole thing was designed to avoid read-modify-write
cycles.

have fun
Michael


More information about the xorg-devel mailing list