[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)
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
