Re: 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 )
On 26/01/17 06:47 AM, Michael wrote: > Hello, > > On Wed, 18 Jan 2017 11:24:03 +0900 > Michel Dänzerwrote: > > 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 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
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 )
Hello, On Wed, 18 Jan 2017 11:24:03 +0900 Michel Dänzerwrote: > >>> 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 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel