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. > I'm not asking > for EXA to change to accommodate old and weird hardware, but I bet > there are other cases where we'd want to do blending operations > directly from RAM to VRAM. What I'm thinking of doing in that case is > to just set aside some actual RAM and coax EXA into using that as > off-screen memory. Or have the driver replace exaGlyphs(). exa's already got old-and-weird quirks, a few more isn't going to hurt. 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? - ajax _______________________________________________ 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