[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesa3d-dev
Subject:    Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
From:       Mike Mestnik <cheako911 () yahoo ! com>
Date:       2004-05-25 2:00:19
Message-ID: 20040525020019.70727.qmail () web11905 ! mail ! yahoo ! com
[Download RAW message or body]

These seem to be good requierments of any conclusion that is reached.

1. On the fly context switching.
 1a. Even if the GART is %100 full for the new/old context.
 1b. Even if the VideoRam is %100 full for the new/old context.
 1c. Even if the Card(s) are locked for exlusive use.
 1d. Even if add you fav gripe here.
 1e. Even if hell has frozen over and a nutron boom has damaged your video
card.

--- Holger Waechtler <holger@qanu.de> wrote:
> Mike Mestnik wrote:
> > --- Jon Smirl <jonsmirl@yahoo.com> wrote:
> > 
> >>There are two types of VTs - text and graphical. It is only practical
> to
> >>have a
> >>single graphical VT because of the complexity of state swapping a
> >>graphical VT
> >>at VT swap.
> >>
> > 
> > Right now we can all-ready run X on multiple VTs and with DRI-reinit
> can
> > run GL apps on all of them.  It may noy be the most elegant thing but
> it
> > workes.  We need the OS to keep state, even graphical, GART and all. 
> I
> > don't see how a 128M GART is diffrent then 2Gb system memory.  Should
> we
> > have GART swap space on the HD, a GART partition?
> > 
> > I'm for making the OS VT swap multiheaded DR?I? setups at whatever
> cost.
> 
> An elegant implementation would not swap the entire GART at VT switches 
> but only present the new VT framebuffer as new display on the screen 
> while maintaining the AGP states.
> 
> Check out e.g. MacOS-X's animated multiple login screen: At every new 
> session start the current session just rotates smoothly animated into 
> the background and a new one is brought up.
> 
> In this model you can retain the entire graphics state at VT switch, 
> only another (currently invisible) frambuffer/screen/display/VT is made 
> visible. This allows straightforward multihead implementations, any 
> frambuffer/screen/display/VT can get attached to any head, they are just
> 
> a piece of framebuffer memory which is either located in graphics memory
> 
> or system memory and can get relocated on request, even to other 
> graphics cards.
> 
> 
> >>How about this for a new way to look at the problem?
> >>
> > 
> > System based xterm, that's a new one.  I don't see how it's better
> then
> > what we have now.
> 
> probably not -- the MacOS-X alike approach looks more promising. At SAK 
> a new display framebuffer would get launched and brought to front, the 
> currently running application is only need get killed if it locks the 
> graphics engine in an locked state.
> 
> Unfortunally that means that parts of the window stack implementation 
> need to run in kernel space (or a tightly connected trusted agent in 
> userspace). Don't know whether this is a problem, the DirectFB core 
> showed that it's possible to implement this cleanly in a few thousand 
> lines of code.
> 
> Holger
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[prev in list] [next in list] [prev in thread] [next in thread]