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.

R Horn

_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to