On Fri, Jan 17, 2003 at 11:26:02AM -0800, Allen Akin wrote: > On Thu, Jan 16, 2003 at 11:42:31PM -0800, magenta wrote: > | I'd personally take the school of thought that if the user is running a > | game which takes up 60MB of texture memory and then tries to concurrently > | launch something which takes up another 60MB of texture memory, it's their > | own fault that the other thing can only get 20MB. :) > > That's perfectly reasonable behavior on a game console, or on some > special-purpose systems (like avionics). For a general-purpose desktop, > it's nice to virtualize texture memory. That way everything continues > to run (though it may be slow), just like with ordinary user processes.
Good point. I hadn't thought of the case of a GL-composited desktop environment like Jens had posted about, for example... My intent was that the applications would still *run*, they just wouldn't have much texture memory available. Though yeah, being able to page out other applications' video memory allocations would definitely be a good thing. > OpenGL certainly needs to give apps more control over memory management. > There have been some proposals and extensions for that in the past, and > the GL2 working-group is planning new ones for the future. -- http://trikuare.cx ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
