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

[Michel Dänzer]

On 18/01/17 01:47 AM, Michael wrote:
> 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.

Sounds like the "classic" EXA mode, where the core EXA code is in full
control of managing "offscreen" (i.e. GPU accessible) memory. There are
"mixed" and "driver" modes, providing increasing levels of control over
this to the driver. See exa/{exa_driver,exa_migration_mixed,exa_mixed}.c .


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer