SecondLife does not reach the login screen using direct rendering. Indirect Rendering works fine. Tested on OpenSuSE 10.2+r200 (R9250) and Deban/etch+r300 (R9600), Mesa 6.5.1 to Mesa-git. Process is killable on r200, r300 leaves the desktop unresponsive, but killable from remote shell.
Do you get a black screen (with only right mouse pointer)? I get that from when I'm using Xorg 7.2 and Mesa 6.5.2; I get the same also using Globs Benchmarks http://globs.sourceforge.net/
globs works here as of http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=6f9b1afc862851532e4820705c412388b497ad58 No idea about Second Life.
I tested Second Life on r300 and noticed that login screen is not visible until you change size of the window. After that you can use the menu and even play.
(In reply to comment #3) > I tested Second Life on r300 and noticed that login screen is not visible until > you change size of the window. After that you can use the menu and even play. That's the same here... Maybe on first loading the window isn't designed, so after resizing there's a forced redesign that make the game show again...
(In reply to comment #4) > (In reply to comment #3) > > I tested Second Life on r300 and noticed that login screen is not visible until > > you change size of the window. After that you can use the menu and even play. > > That's the same here... Maybe on first loading the window isn't designed, so > after resizing there's a forced redesign that make the game show again... > but why is indirect rendering working then?
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > I tested Second Life on r300 and noticed that login screen is not visible until > > > you change size of the window. After that you can use the menu and even play. > > > > That's the same here... Maybe on first loading the window isn't designed, so > > after resizing there's a forced redesign that make the game show again... > > > > but why is indirect rendering working then? > No idea, I was just wondering...
Can somebody test the patch I pushed? It sounds like it could help.
BTW Second Life client is free, with source.
(In reply to comment #7) > Can somebody test the patch I pushed? It sounds like it could help. I planned that, I've to recompile my mesa... I'll report after testing ;)
(In reply to comment #9) > (In reply to comment #7) > > Can somebody test the patch I pushed? It sounds like it could help. > > I planned that, I've to recompile my mesa... I'll report after testing ;) Just finished to compile the patched version and it works like a charm :) I mean, there's no more a black screen neither on GL.O.B.S. neither on SecondLife, so good patch! I've applied to the ubuntu mesa 6.5.2 and patched all correctly (no warnings, no errors) so I'll post on launchpad too! Bye and again thanks, I think we can close the bug :)
michael: can you also patch r200 please. I tried it myself, but seems my patch was so poor, that it crashed the application :-( was something like that: diff --git a/src/mesa/drivers/dri/r200/r200_context.c b/src/mesa/drivers/dri/r200/r200_context.c index fc6eb93..25e697e 100644 --- a/src/mesa/drivers/dri/r200/r200_context.c +++ b/src/mesa/drivers/dri/r200/r200_context.c @@ -680,6 +680,8 @@ r200MakeCurrent( __DRIcontextPrivate *dr r200UpdateWindow( newCtx->glCtx ); r200UpdateViewportOffset( newCtx->glCtx ); + + r200SetCliprects(newCtx, GL_BACK_LEFT); } _mesa_make_current( newCtx->glCtx, diff --git a/src/mesa/drivers/dri/r200/r200_lock.c b/src/mesa/drivers/dri/r200/r200_lock.c index bcc0c91..8eec3c6 100644 --- a/src/mesa/drivers/dri/r200/r200_lock.c +++ b/src/mesa/drivers/dri/r200/r200_lock.c @@ -98,7 +98,7 @@ void r200GetLock( r200ContextPtr rmesa, r200SetCliprects( rmesa, GL_FRONT_LEFT ); r200UpdateViewportOffset( rmesa->glCtx ); driUpdateFramebufferSize(rmesa->glCtx, drawable); - rmesa->lastStamp = drawable->lastStamp; +// rmesa->lastStamp = drawable->lastStamp; } R200_STATECHANGE( rmesa, ctx ); diff --git a/src/mesa/drivers/dri/r200/r200_state.c b/src/mesa/drivers/dri/r200/r200_state.c index bdb487f..2856b75 100644 --- a/src/mesa/drivers/dri/r200/r200_state.c +++ b/src/mesa/drivers/dri/r200/r200_state.c @@ -1889,6 +1889,8 @@ void r200SetCliprects( r200ContextPtr rm if (rmesa->state.scissor.enabled) r200RecalcScissorRects( rmesa ); + + rmesa->lastStamp = drawable->lastStamp; }
> I've applied to the ubuntu mesa 6.5.2 and patched all correctly (no warnings, > no errors) so I'll post on launchpad too! Here you are the launchpad bug I've posted: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/90169
(In reply to comment #11) > michael: can you also patch r200 please. I tried it myself, but seems my patch > was so poor, that it crashed the application :-( I think if anything you should set the front cliprects, but I doubt that's why it crashes. I'm afraid someone with the hardware will have to do it, e.g. Roland. Although it might help if you could attach a backtrace from gdb.
(In reply to comment #13) > (In reply to comment #11) > > michael: can you also patch r200 please. I tried it myself, but seems my patch > > was so poor, that it crashed the application :-( > > I think if anything you should set the front cliprects, but I doubt that's why > it crashes. I'm afraid someone with the hardware will have to do it, e.g. > Roland. Although it might help if you could attach a backtrace from gdb. Marc, your patch works for me (tested with globs, not 2nd life though), no matter if GL_FRONT_LEFT or GL_BACK_LEFT is used in r200MakeCurrent. If you're seeing an assertion fail in _mesa_reference_framebuffer as I do, this is a different problem in mesa git not directly related to this patch. Otherwise, as Michel said, a backtrace might be helpful. Oh, and I'd bet radeon would need the same fix too.
(In reply to comment #14) > Marc, your patch works for me (tested with globs, not 2nd life though), no > matter if GL_FRONT_LEFT or GL_BACK_LEFT is used in r200MakeCurrent. > If you're seeing an assertion fail in _mesa_reference_framebuffer as I do, this > is a different problem in mesa git not directly related to this patch. seems to be fixed meantime. > Otherwise, as Michel said, a backtrace might be helpful. > Oh, and I'd bet radeon would need the same fix too. I can confirm that with upper patch+GL_FRONT_LEFT shows the login screen on r200. The crash I have seen is possible related to something else. Will file another bug, when I know who is causing it.
Created attachment 9022 [details] [review] Patch for r200 on Mesa 6.5.2 I've modified the patch posted by Marc to make it work on Mesa 6.5.2 base for ubuntu package.
*** Bug 10192 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.