On 4 Sep 2001, Owen Taylor wrote:
>
> [EMAIL PROTECTED] writes:
>
> > 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.
>
> > These are not reasonable for the bulk of users who want to use
> > pre-compiled X server and module from some distribution. Perhaps we
> > should look at some X startup options instead of compile time options
> > for this code. This would then enable the mode that would best match
> > what I do: an X server that uses software 3D even on hardware capable of
> > hardware 3D via DRI. The gaming and other 3D users would consider this
> > totally absurd. I don't need frames per second because I am generating
> > scenes and manipulating 2D images.
>
> Well, you certainly don't have to recompile to turn off DRI, just turn
> off the options in your XF86Config. To get a command line option,
> you could use the -xf86config option to XFree86 and switch between
> two config files.
>
> I'd agree that the gobble-most-ram-for-3D is detrimental for people
> doing only 2D. The pretty clear long term right solution is to
> dynamically adjust the allocation of video ram when a 3D client
> is started, but I would suppose that to be a moderately ambitious
> project.
>
> Regards,
> Owen
>
> (I've also noticed that on my 32Meg G400, a lot more ram is being
> used for the tile/stipple cache than seems justified, at 16bpp,
> it allocates 32 128x128 tiles, 32 256x256 tiles, 16 512x512 tiles...
> I can't really conceive of an app that would continually paint
> with that many different titles/stipples at once. So some static
> improvements in memory allocation may also be possible)
This cache configuration is not static. It is the maximum
configuration assuming no offscreen Pixmap or YUV surface allocations
(the configuration at startup).
It gets reconfigured as other allocations take place. XAA uses all
that it's given. If there are no pixmaps to put in offscreen, the
only thing it can use the memory for is tile/stipple caching, so it
does.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
