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 <[EMAIL PROTECTED]> wrote: > Mike Mestnik wrote: > > --- Jon Smirl <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > 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 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel