On Mon, 2006-10-02 at 15:17 -0500, Federico Mena Quintero wrote: > On Sun, 2006-10-01 at 20:25 +0300, Tero Huttunen wrote: > > > What evidence do you have that GTK+ probably isn't drawing through > > > Render? > > > > I thought it wouldn't do solid fills through Render. However, I did a > > new hack, by modifying R200SubsequentCPUtoScreenTexture to return > > immediately. Result: > > > > http://www.students.tut.fi/~huttune2/accel2.png > > > > Clearly Qt can accelerate some of the Render-operations, since some of > > the text is missing, however, Gtk doesn't seem to accelerate anything. > > What other functions should I test? > > This is very interesting! > > Keep in mind that GTK+ draws everything to a Pixmap to avoid flicker, > and then paints the pixmap to the final Window. I wonder if your hack > contemplates this. Since those hooks were apparently placed in the driver's acceleration routines (and eventually all of them), yes, it applies to pixmaps too. > That said, I don't know how pixmaps work when they fall outside of video > memory. Does the X server just draw to them "by hand", to normal RAM? X's handling of pixmaps varies depending on your acceleration architecture: XAA has a big rectangular chunk of offscreen memory where it sticks pixmaps. When you create a pixmap, it gets stuck in, and if somebody is bumped out, they lose forever. I couldn't find any mechanism for somebody to get back onto the card after they got the boot. EXA has a bigger (well, except for #7524), linear chunk of offscreen memory where it sticks pixmaps. In the scheme we appear to be settling on, any time you could accelerate an operation, your pixmaps are stuck onto the card so you can accelerate. But the default at the moment (since exa-damagetrack hasn't been merged yet) is that your pixmap is sometimes put back into card memory if it's currently in system, based on some guessing. For either AA, if your pixmap is in system memory for the operation because the AA decided that's how it should be, then yes, you're stuck rendering using the CPU[1]. That's actually not so terrible. Worse is when you're rendering with the CPU to/from something that's on the card, because your driver doesn't support the operation (as is the case with XAA for pretty much all Render stuff except for text). Framebuffer read speed is pretty bad across the board, and Render usage tends to result in lots of reads of the destination. > [ObFlame: if @#$% Mozilla would not fill VRAM with pr0n, then GTK+'s > pixmaps may fit in VRAM...] Yeah, AFAIK they still haven't fixed their pixmap cache limiting. [1] There is interesting potential here for page table tricks using AGP, so that even though it's not on the card, you could still address it from the card when needed. We haven't done any experimentation with this yet, but hopefully soon. -- Eric Anholt anholt FreeBSD org eric anholt net eric anholt intel com
Attachment:
signature.asc
Description: This is a digitally signed message part
