On Tue, 4 Sep 2001 [EMAIL PROTECTED] wrote:
> On 4 Sep, Mark Vojkovich wrote:
> > On Tue, 4 Sep 2001 [EMAIL PROTECTED] wrote:
> >
> >> On 4 Sep, Dr Andrew C Aitchison wrote:
> >> > On Mon, 3 Sep 2001, Robert A. Knop Jr. wrote:
> >> >
> >> >>
> >> >> Sadness. And here was me thinking that 32MB was a lot of video RAM.
> >> >> (Indeed, doing the math, it would seem that only 8MB should be necessary
> >> >> to display a 4-byte deep screen at 1600x1200... which should leave
> >> >> plenty of memory left over for off-screen buffers and 3d buffers and
> >> >> such. What's up here?)
> >> >
> >> > The code in mga_storm.c is trying to grab as much memory for textures as
> >> > possible (the author seems to value 3D performance above anything else).
> >> > I'm not convinced that it isn't grabing a little too much.
> >>
> >> This problem is not unique to mga. It is a common problem. I have
> >> noticed that if I build with DRI enabled many drivers promptly consume
> >> most of the video ram for 3D work. This is annoying but understandable.
> >> They are optimizing for 3D performance because it is important to many
> >> people.
> >>
> >> But in my case, I want lots of available space for pixrects. I do
> >> mostly 2D image work, with the occasional 3D activity. Keeping lots of
> >> pixrects in video ram definitely improves window manager manipulations
> >> and pan operations.
> >>
> >> A compile time solution does exist. I can rebuild X without DRI and only
> >> suffer the somewhat excessive pixrect consumption from XAA. (It gets too
> >> enthusiastic about texture caching when it sees all that empty video
> >> ram.) I might go look at the XAA algorithm to see whether it is easy to
> >> put some bounds on it.
> >
> > The amount of memory given to the offscreen manager (used by XAA, XV)
> > is determined by the driver. XAA uses everything it is given. That
> > is the correct behavior.
> >
>
> I assume you mean "correct" in the sense of "intended". How does XAA
> tile cache interact with pixrect allocations? Can you point me at the
> right place in the code or documents? The system behaves better with
> DRI removed so something is right. For image manipulation work it is
> just important that a few big (typically 4MB) pixrects be kept resident
> in video ram. This greatly speeds repaints, etc.
The offscreen memory manager is given an allotment by the driver
(through xf86InitFBManager and friends). Allocations from this are
made by XAA on a pixmap by pixmap basis, additionally, other parts
of the server, like Xv, can request allocations as well. XAA has
also registered a callback with the manager so it can be informed of
the *unused* space. XAA cuts the unused space up into swatches
for tile and stipple caching. When the server starts up this callback
reports the entire area as unused and XAA prints out the maximal
configuration. Pixmaps above a certain size always go in offscreen
memory on a first come basis while they fit. The tile and stipple
cache uses only what's left and gets reconfigured after each new
allocation.
I spent alot of time studying cache behavior with various applications
and this was the scheme that was iterated to.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
