Hello,
On Wed, 18 Jan 2017 11:24:03 +0900
Michel Dänzer <[email protected]> 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?
have fun
Michael
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
