Bug 26114

Summary:	Black screen on The Sims 3 beginning
Product:	Mesa	Reporter:	Rafał Miłecki <zajec5>
Component:	Drivers/DRI/R600	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Rafał Miłecki 2010-01-19 04:12:37 UTC

When I start The Sims 3 with Wine there should be some beginning, 3D introduction right after start. Using r600 there is only black screen.

I suspect this is R6xx only issue, AFAIR I have seen this 3D introduction demo using R7xx GPU and r600 driver (same git commit).

I'll try to provide more information when I test this once again with R7xx GPU.

Comment 1 Rafał Miłecki 2010-01-22 13:06:15 UTC

Unfortunately R7xx also displays black screen only. AFAIK black screen is displays instead of 3D EA logo, instead of 3D The Sims 3 loader and instead of animation that should be played. So maybe there is some specific way of creating OpenGL context that The Sims 3 performs? Or maybe some unsupported glEnable(...)?

Is this possible to hack Mesa to dump all OpenGL calls?

Comment 2 Rafael Monica 2010-01-23 09:45:30 UTC

(In reply to comment #1)
> 
> Is this possible to hack Mesa to dump all OpenGL calls?
> 

I haven't tried it myself. But have a look at:

src/mesa/main/dispatch.c

and then this line:

#if 0  /* Use this to log GL calls to stdout (for DEBUG only!) */

Comment 3 Rafał Miłecki 2010-01-24 03:17:10 UTC

(In reply to comment #2)
> (In reply to comment #1)
> > 
> > Is this possible to hack Mesa to dump all OpenGL calls?
> > 
> 
> I haven't tried it myself. But have a look at:
> 
> src/mesa/main/dispatch.c
> 
> and then this line:
> 
> #if 0  /* Use this to log GL calls to stdout (for DEBUG only!) */

This can be it, however it didn't change anything for me after chainging to "1" and recompiling. I guess it's due to:

"This code is not used if optimized assembly stubs are available (e.g., using x86/glapi_x86.S on IA32 or sparc/glapi_sparc.S on SPARC).".

Any ideas?

Comment 4 Rafael Monica 2010-01-24 08:39:17 UTC

Try adding --disable-asm to configure

Comment 5 Rafał Miłecki 2010-01-24 11:31:38 UTC

(In reply to comment #4)
> Try adding --disable-asm to configure

Thanks you!

Comment 6 Rafał Miłecki 2010-04-07 12:58:44 UTC

As mentioned in bug #27521 it may be worth to try BuGLe. It seems to nicely translate magic numbers to GL definitions.

Comment 7 Rafał Miłecki 2010-04-23 04:34:34 UTC

This is totally crazy/random :|

Earlier this month I updated mesa to:

commit 4c26cdbe01619abad413b09317f2842dcf1a4d57
Author: Dave Airlie <airlied@redhat.com>
Date:   Sat Apr 3 21:52:09 2010 +1000
r300g: fix color tiling for buffer from X server.

and tested. It didn't work.

Today I updated mesa again, to commit:

commit eb4dc547885994cc7961f7996c33ff484f664964
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Fri Apr 23 11:56:06 2010 +0200
r600: don't enable depth test if there is no depth buffer

(without testing before updating) and tested... It worked!

So I went back to commit 4c26cdbe01619abad413b09317f2842dcf1a4d57 and... it still works.

I've no idea why using 1 mesa commit it can work or not. I even cold booted to make sure registers were cleaned.

For now it looks like resolved, but due to that weird problems, I'll test it in next days.

Comment 8 Andreas Boll 2012-11-02 16:22:51 UTC

Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

Comment 9 Andreas Boll 2014-07-07 15:59:09 UTC

The classic r600 driver has been abandoned long ago.
It was replaced by the Gallium driver r600g.

If you have issues with r600g please file a new bug report with component Drivers/Gallium/r600

Thanks.

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.