EXA vs. weirdo graphics chips ( was Re: [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 26/01/17 06:47 AM, Michael wrote:
> Hello,
> 
> On Wed, 18 Jan 2017 11:24:03 +0900
> Michel Dänzer <michel at daenzer.net> 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 .
> 
> Thanks for the hint - I'm playing with this right now. 
> So if I'm not completely mistaken, this way I can just pretend that all
> pixmaps are usable by the accelerator in general, weed out the
> impossible cases in Prepare*() and avoid any and all unnecessary
> migration?

Yeah, that's basically it.


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