On Wed, 2008-05-14 at 16:36 +0200, Thomas Hellström wrote: > >> 2) Reserving pages when allocating VRAM buffers is also a very bad > >> solution particularly on systems with a lot of VRAM and little system > >> RAM. (Multiple card machines?). GEM basically needs to reserve > >> swap-space when buffers are created, and put a limit on the pinned > >> physical pages. We basically should not be able to fail memory > >> allocation during execbuf, because we cannot recover from that. > >> > > > > Well this solve the suspend problem we were discussing at xds ie what > > to do on buffer. If we know that we have room to put buffer then we > > don't to worry about which buffer we are ready to loose. Given that > > opengl don't give any clue on that this sounds like a good approach. > > > > For embedded device where every piece of ram still matter i guess > > you also have to deal with suspend case so you have a way to either > > save vram content or to preserve it. I don't see any problem with > > gem to cop with this case too. > > > No. Gem can't coop with it. Let's say you have a 512M system with two 1G > video cards, 4G swap space, and you want to fill both card's videoram > with render-and-forget textures for whatever purpose.
Who's selling that system? Who's building that system at home? -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
