Hello, On Mon, 16 Jan 2017 15:16:47 -0500 Adam Jackson <a...@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. EXA apparently assumes that composite operations can only be accelerated with all sources in VRAM. That's not even true on all 'normal' chips - Permedia 2 for example will happily apply compositing to host blits ( but not to vram-to-vram blits, then you have to use the texture unit for some reason ) - I doubt it's the only one, it's just the one where I noticed it. > 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? Depends on the model - most cards have 15MB which is usually divided up into front, back and z-buffer but can be run as one big framebuffer. Some older ones have only 5MB. There are newer ones ( like XVR1000 and 4000 ) that have 72MB or more, plus plenty of regular RAM, but those are rare and undocumented. I'm not sure how long it takes for a write through the ALU to be visible when reading directly from the actual RAM, can't be more than a few cycles though. I do have the datasheet for the 3dRAM chips somewhere... Evidently the whole thing was designed to avoid read-modify-write cycles. 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