On Mon, 2002-08-05 at 15:32, Jens Owen wrote:
> Charl P. Botha wrote:
> > On Mon, Aug 05, 2002 at 06:13:45AM -0600, Jens Owen wrote:
> >>>The only possible issue I see is that the GLX visuals are only
> >>>initialized on server startup. Could that cause apps to fail if the
> >>>server has initialized the DRI on startup but it's not available when
> >>>the app starts?
> >>Can you explain why that visual wouldn't be available?
> > Michel will have to answer this one.
> I believe you answered this below when you state the DRI may not be=20
> re-initialized when returning from a VT switch. This is problematic,=20
> because it's not always possible to fall back to software rendering for=20
> 3D after a 3D context has been successfully created.
It doesn't get disabled in the first place if there's a 3D context.
> >>I'd like to get a better handle on this patch before it goes in the=20
> >>trunk...perhaps you can help me with some questions that came up when I=
> >>looked at the patch:
> >>1) What are the rules governing the directRenderingInitialized flag?=20
> >>Have you changed the rules for directRenderingEnabled as well?
> > If the server was able to initialise direct rendering at _initial_ serv=
> > startup, directRenderingInitialized is TRUE. This means that this serv=
> > direct rendering capable. directRenderingEnabled can be TRUE or FALSE
> > (toggling at VT switches), but only IF directRenderingInitialized is TR=
> > So, if the server starts up and DRI is available, directRenderingInitia=
> > and directRenderingEnabled are set to true. At every LeaveVT() call th=
> > server de-initialises DRI. When we switch back to the server VT (i.e.
> > EnterVT() is called) and directRenderingInitialized is TRUE, a
> > re-initialisation of the DRI is attempted. If this re-initialisation i=
> > successful, directRenderingEnabled is set to TRUE and FALSE if it fails=
> Setting directRenderingEnabled to FALSE, and continuing with software=20
> rendering is not a feasible option. Why would the reinit be failing?=20
For all the same reasons that it can traditionally fail on startup. In
particular, another server can be using the DRM.
> Can this be fixed? If so, I'd recommend reinitializing everytime=20
> regardless and forcing a server error if reinitialization isn't=20
> possible. In this scenario, you don't need to track if reinitization=20
> worked, or not. Just use the old semantics of directRenderingEnabled=20
> and delete directRenderingInitialized.
I don't think just dying is a workable scenario.
> >>2) It looks like you are trying to support delayed DRI initialization?=20
> >>Does the server even support this?
> > A server can only perform "delayed" DRI initialisation if it was able t=
> > initialise DRI successfully at the _initial_ startup. If this is the c=
> > the server can disable/enable DRI at every VT switch.
> If DRI initialization is required at ScreenInit time, then I was=20
> mistaken in my interpretation of the "delayed" init. Again, for=20
> clarifitcation, if the DRI in supported for a screen, it should always=20
> be there for the life of that screen.
What requires this that we've been missing?
> >>3) Why are the 2D *CP* functions checking for !directRenderingEnabled?=20
> >>Doesn't the entire radeon driver get swapped out for a memory driver on=
> >>a VT switch?
> > Because it's possible that these functions can be called _after_ a VT s=
> > where successful DRI re-initialisation took place OR where the DRI
> > re-initialisation failed, in which case it has to use software renderin=
> > that session (until the next VT switch).
> I'm not sure how far you want to go to try and recover when the DRI=20
> won't initialize. The system may be having other serious problems at=20
> that point. However, if you really want to try and keep the server=20
> alive, and just kill the 3D window,
Again, there's no 3D window in that case. Not a direct rendered one,
> you should look at changing the jump table to use the non-cp routines
That's the long term solution I described in my other post.
> >>I've got more questions, but let's start with those. Your answers may=20
> >>clear up the rest.
> > In short: a server that could initialise DRI at startup
> > (directRenderingInitialized=3D=3DTRUE) DE-initialises DRI at every Leav=
> > tries to re-initialise DRI at every EnterVT(). If the re-initialisation
> > fails, it gracefully falls back to software rendering, but is able to r=
> > DRI during a subsequent VT switch. directRenderingEnabled indicates th=
> > CURRENT state at any time.
> Sorry, but this isn't a "gracefull" fallback.
It's the same as when DRI initialization failed before.
Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast