Yes the GART swap, if it needs to be done with memcpys, should be posponed
untill the user has SOME type of interface. Thats the important thing,
allowing the user to interact is above hardware based rendering.
I never liked the way GLapps froze when they where not on the current VT.
I think the answer too these problems is runnaway rendering, where the
openGL calls simply return as thought they didn't do any thing.
--- 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
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer
-------------------------------------------------------
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
