Bug 56405

Can you checkout mesa from git an bisect?  Also please attach your xorg log and dmesg output.

Created attachment 69132 [details]
dmesg

Created attachment 69133 [details]
Xorg.0.log

The dmesg and xorg log files are done with the top of the 9.0 branch
5fe5aa8e55a8db0b80f6ff9838bad47ce0406fd0

And the bug still exists when using the top of the
master branch:
	b78b62497f1e5cc64eb924c64e4685fe5d814fd7

I'm not so sure what commits I should start the bisecting with since
8.0 and 9.0 are split. It is not a linear history.

You can just checkout a commit on master around the time 8.0 was branched.

I have not found the bug by bisecting, but I can't go on because the
commits do not compile anymore. So far my results are:

e656c4a07420fbb34cf00f9b827b1d2f4c45e0f6 bad
67e9ae856355be532455c1cf1211d59b3a4c5992 bad
bee2edbf3d2da2c2351c70e56da0dca205caa8ea bad
10e552d056dd080c4e763a31df517c2d7684a9cf bad
72f7632c6bbbfc062ac7d90290e99f71272f6059 bad
94b634eca0e2bd32d4b5bd92d06d510eae8a5625 broken, does not compile


used instead of the broken commit, it compiles but is bad
97b4b97b2f9b0e4532c8ba9cedfff9f013a76fc2 bad 

here I stop

*** Bug 56464 has been marked as a duplicate of this bug. ***

*** Bug 56666 has been marked as a duplicate of this bug. ***

I could still do some bisecting if anyone could help me
building the packages ati-dri and libg. I'm using
a modified PKGBUILD. I guess I don't need everything
build by that script. In order to get around
some compilation errors that occurs in parts I don't
need anyway it would probably help to tailor the
building exactly for what I need. But I don't know
what is needed. Maybe someone can help on this.

I attach PKGBUILD.

Created attachment 69497 [details]
script to build libraries and drivers

What are the compile errors?

Created attachment 69640 [details]
compilation errors

These are the compile errors I get with the above mentioned commit.
The compile errors are fixed in the commit also mentioned above.

When I choose the start end endpoints for the bisecting
I looked at the date of the commit.
And the commit I related to the 8.0 tag by the date
does not compile either. So this was not a good starting point
in the first place.
I guess it would be better to bisect between the mesa-8.0.4 and mesa-9.0 tags.
If I try this git asks me to check a merge base first.
This merge base dates back to January and it seams to have
a very different configure/build structure.

(In reply to comment #13)
> These are the compile errors I get with the above mentioned commit.
> The compile errors are fixed in the commit also mentioned above.

One strategy for such cases is to look at the commit fixing the compile error and see if (part of) it can be applied on top of other commits to be tested for the bisect.


> And the commit I related to the 8.0 tag by the date
> does not compile either. So this was not a good starting point
> in the first place.

Indeed, you should never declare a commit good or bad if it doesn't even compile. :)


> I guess it would be better to bisect between the mesa-8.0.4 and mesa-9.0
> tags.
> If I try this git asks me to check a merge base first.

Yes, that's how it deals with non-linear history (so you don't have to worry about that yourself).

> This merge base dates back to January and it seams to have
> a very different configure/build structure.

Maybe it would be easier to just do manual builds instead of using PKGBUILD for the bisect? You can point to the directory containing the manually built r600_dri.so with the environment variable LIBGL_DRIVERS_PATH. You may also want to set LIBGL_DEBUG=verbose to verify it's picking up the expected r600_dri.so.

Also, especially for older commits, you may need to run make clean or even autogen.sh between bisection steps to prevent inconsistent builds.

I tried to compile c1f4867c89adb1a6b19d66ec8ad146115909f0a7
the commit taged with mesa-8.0.4 and I get the following compilation error:

g++ -c -I. -I../../../src/gallium/include -I../../../src/gallium/auxiliary -I../../../src/gallium/drivers  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2  -fPIC  -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0301 -fvisibility=hidden -I/usr/include   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS gallivm/lp_bld_debug.cpp -o gallivm/lp_bld_debug.o
gallivm/lp_bld_debug.cpp: In function ‘void lp_disassemble(const void*)’:
gallivm/lp_bld_debug.cpp:240:66: error: no matching function for call to ‘llvm::Target::createMCInstPrinter(unsigned int&, const llvm::MCAsmInfo&, const llvm::MCSubtargetInfo&) const’
gallivm/lp_bld_debug.cpp:240:66: note: candidate is:
In file included from gallivm/lp_bld_debug.cpp:37:0:
/usr/include/llvm/Support/TargetRegistry.h:395:20: note: llvm::MCInstPrinter* llvm::Target::createMCInstPrinter(unsigned int, const llvm::MCAsmInfo&, const llvm::MCInstrInfo&, const llvm::MCRegisterInfo&, const llvm::MCSubtargetInfo&) const
/usr/include/llvm/Support/TargetRegistry.h:395:20: note:   candidate expects 5 arguments, 3 provided
make[3]: *** [gallivm/lp_bld_debug.o] Error 1
make[3]: Leaving directory `/home/michael/src/Mesa/mesa/src/gallium/auxiliary'
make[2]: *** [default] Error 1
make[2]: Leaving directory `/home/michael/src/Mesa/mesa/src/gallium'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/michael/src/Mesa/mesa/src'
make: *** [default] Error 1

I compiled the commit 6671d0dad300e591ac7c0e5110c6778373d0149a
which I picked to start bisecting. (I picked it because the date
is related to the date of the 8.0 branch as mentioned above)

It shows the same problem.

In order to get it compiled I had to do the foloowing change:

--- a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
@@ -53,7 +53,7 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx,
 
    switch (ctx->ClientAPI) {
    case EGL_OPENGL_ES_API:
-      switch (ctx->ClientVersion) {
+      switch (ctx->ClientMajorVersion) {
       case 1:
          api = ST_API_OPENGL;
          *profile = ST_PROFILE_OPENGL_ES1;
@@ -64,7 +64,7 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx,
          break;
       default:
          _eglLog(_EGL_WARNING, "unknown client version %d",
-               ctx->ClientVersion);
+               ctx->ClientMajorVersion);
          break;
 


And I changed my build script in order not to build vdpau and radeonsi
and some other things I beleive are not related to the driver r600 I beleive 
I need.

(In reply to comment #14)
> (In reply to comment #13)


> Maybe it would be easier to just do manual builds instead of using PKGBUILD
> for the bisect? You can point to the directory containing the manually built
> r600_dri.so with the environment variable LIBGL_DRIVERS_PATH. You may also
> want to set LIBGL_DEBUG=verbose to verify it's picking up the expected
> r600_dri.so.

At which point would I need to have the environment setup in order to pick the driver? Can I just stop gdm set the environment and start gdm with  systemctl?

> 
> Also, especially for older commits, you may need to run make clean or even
> autogen.sh between bisection steps to prevent inconsistent builds.

There are a lot of options. Which are relevant?
    COMMONOPTS="--prefix=/usr \
    --sysconfdir=/etc \
    --with-dri-driverdir=/usr/lib/xorg/modules/dri \
    --with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \
    --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \
    --enable-gallium-llvm \
    --enable-egl \
    --enable-gallium-egl \
    --with-egl-platforms=x11,drm \
    --enable-shared-glapi \
    --enable-gbm \
    --enable-glx-tls \
    --enable-dri \
    --enable-glx \
    --enable-osmesa \
    --enable-gles1 \
    --enable-gles2 \
    --enable-texture-float \
    --enable-xa \
    --enable-vdpau "

(In reply to comment #17)
> Can I just stop gdm set the environment and start gdm with systemctl?

I don't think so. It mainly needs to be in gnome-shell's environment, but I'm not sure offhand how best to achieve that with your setup.


>     --with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \

You only need r600 and maybe swrast here.

>     --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \

You can set this to an empty string.

>     --enable-egl \
>     --enable-gallium-egl \
>     --with-egl-platforms=x11,drm \

Shouldn't need these.

>     --enable-gbm \

Shouldn't need this.

>     --enable-osmesa \

Don't need this.

>     --enable-gles1 \
>     --enable-gles2 \

Shouldn't need these.

>     --enable-xa \
>     --enable-vdpau "

Don't need these.

I'm stuck with:
g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0301 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp  -L../../../../lib -Wl,-R/usr/lib/xorg/modules/dri -ldricore -lglsl  -ldrm   -lexpat -lm -lpthread -ldl  -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/lib/llvm  -lpthread -lffi -ldl -lm ;
r600_dri.so.tmp: undefined reference to `st_gl_api_create'

I have 15 commits left to test. I did skip commits in order to get rid of the 
missing reference. I already skipped 5 commits and the reference still is missing.

I had to apply some other patches already.

Anyway I'm not even convinced my test is a good test. Because since a while I
only get the r600_dri.so built. And I only exchange this object. 

I wonder if really nobody of the developers sees the problem at all?

Even if I would succeed in finding the bad commit how would you fix
it if you can not reproduce the problem?

(In reply to comment #19)
> Even if I would succeed in finding the bad commit how would you fix
> it if you can not reproduce the problem?

It will help narrow down what's causing the problem and give us a place to start looking.  It may be a very simple fix.  Without narrowing it down further, it's hard to even propose any fixes.

(In reply to comment #19)
> I have 15 commits left to test.

Which ones?


> Anyway I'm not even convinced my test is a good test. Because since a while I
> only get the r600_dri.so built. And I only exchange this object. 

FWIW, that's perfectly plausible as you're narrowing down the range of potential culprit commits. This object does contain the bulk of relevant code.

Created attachment 70326 [details]
bisect log

I think all the information can be derived by replaying
bisect log information from the file I attached.

Created attachment 70327 [details] [review]
patch I used for compilation

This is git diff -p output showing the patches I applied to get some thing compiled.

(In reply to comment #22)
> bisect log

It does look like you're getting close to isolating a commit. Most likely it's one of the remaining r600g commits, but there's still too many of them to guess which one.


(In reply to comment #23)
> patch I used for compilation

Some of this looks a little dubious, but I guess it should do for the bisection.


For the latest compile problem, have you tried manually applying the two revert commits at the end of the remaining commits?

I have not tried that before.

Now I cherry picked 
0b616b2f5164621e3a63caeb15c6eb1d01bbc55a
4a162f6eba73a8cb2654cd99a2bd12bd468925a6

on top of 
302862defa61b2cee1ae24159aca306f090ca854

The r600_dri.so did compile now.

But now gnome starts in fallback mode
with the new r600_dri.so.

And in this mode I can not test the problem.

(In reply to comment #25)
> But now gnome starts in fallback mode with the new r600_dri.so.

Does

 LIBGL_DEBUG=verbose glxinfo | grep render

give any hints as to what might be wrong with this r600_dri.so?

(In reply to comment #26)
> (In reply to comment #25)
>  LIBGL_DEBUG=verbose glxinfo | grep render
I don't have glxinfo

(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> >  LIBGL_DEBUG=verbose glxinfo | grep render
> I don't have glxinfo

Ah I found it on archlinux AUR in the
package mesa-demo-git. I'm just
building it.

(In reply to comment #28)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > (In reply to comment #25)
> > >  LIBGL_DEBUG=verbose glxinfo | grep render
> > I don't have glxinfo
> 
> Ah I found it on archlinux AUR in the
> package mesa-demo-git. I'm just
> building it.

Here is the result:

libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/r600_dri.so
libGL error: dlopen /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libglsl.so: undefined symbol: hash_table_string_hash)
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/swrast_dri.so

I found I made a mistake during bisecting.

In order to get rid of the latest compile problem
I upgraded libgl to the 9.0.1 version.
Now gnome starts and does not show the problem.
I finished bisecting and found no more bad commits.
To cross check I tried the last bad commit
8c436b4ea670d4630767a742dac5aad14e18aef9.
But I found it good this time.
I downgraded libgl again to 8.0.4.
Now gnome does not start but finds
a problem it can not recover from.
I don't know what I had the firost time I checked
8c436b4ea670d4630767a742dac5aad14e18aef9.

(In reply to comment #29)
> libGL error: dlopen /usr/lib/xorg/modules/dri/r600_dri.so failed
> (/usr/lib/libglsl.so: undefined symbol: hash_table_string_hash)

Is /usr/lib/libglsl.so built from your Mesa tree? Generally check that r600_dri.so, libGL.so.1 and any binaries they link against are picked up from your Mesa tree for the bisection.


(In reply to comment #30)
> In order to get rid of the latest compile problem
> I upgraded libgl to the 9.0.1 version.
> Now gnome starts and does not show the problem.

So that got rid of the undefined symbol above? Hmm. Sounds like it was/is not picking up all relevant binaries from your Mesa tree.

Created attachment 70453 [details]
new bisect log

I started bisecting from the second last bad commit.
I could verify it's bad. The new bisect log output
shows the current status.

I'm now testing the r600_dri.so with both libgl libraries.

I do not point to my built tree for loading the libraries
or objects.

What I do is replace the r600_dri.so in
/usr/lib/xorg/modules/dri/r600_dri.so
with the one I built.

I now test it twice with libgl 8.0.4 and 9.0.1.

Created attachment 70454 [details]
the patch I used lately

This is a patch I need to apply in order to get at least
r600_dri.so compiled.

Could the bug be in there? I guess not.

I finished bisecting (again).

The result looks like this:

git bisect bad
c0c979eebc076b95cc8d18a013ce2968fe6311ad is the first bad commit
commit c0c979eebc076b95cc8d18a013ce2968fe6311ad
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Mon Jan 30 17:22:13 2012 -0500

    r600g: add support for common surface allocator for tiling v13
    
    Tiled surface have all kind of alignment constraint that needs to
    be met. Instead of having all this code duplicated btw ddx and
    mesa use common code in libdrm_radeon this also ensure that both
    ddx and mesa compute those alignment in the same way.
    
    v2 fix evergreen
    v3 fix compressed texture and workaround cube texture issue by
       disabling 2D array mode for cubemap (need to check if r7xx and
       newer are also affected by the issue)
    v4 fix texture array
    v5 fix evergreen and newer, split surface values computation from
       mipmap tree generation so that we can get them directly from the
       ddx
    v6 final fix to evergreen tile split value
    v7 fix mipmap offset to avoid to use random value, use color view
       depth view to address different layer as hardware is doing some
       magic rotation depending on the layer
    v8 fix COLOR_VIEW on r6xx for linear array mode, use COLOR_VIEW on
       evergreen, align bytes per pixel to a multiple of a dword
    v9 fix handling of stencil on evergreen, half fix for compressed
       texture
    v10 fix evergreen compressed texture proper support for stencil
        tile split. Fix stencil issue when array mode was clear by
        the kernel, always program stencil bo. On evergreen depth
        buffer bo need to be big enough to hold depth buffer + stencil
        buffer as even with stencil disabled things get written there.
    v11 rebase on top of mesa, fix pitch issue with 1d surface on evergreen,
        old ddx overestimate those. Fix linear case when pitch*height < 64.
        Fix r300g.
    v12 Fix linear case when pitch*height < 64 for old path, adapt to
        libdrm API change
    v13 add libdrm check
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>

:100644 100644 af1e914f35aebf24c4824e93804c9f9088be7333 b2b1ab8f41a131089b84325fef962f7d4d79bb8d M	configure.ac
:040000 040000 facdf8849a029e15e166ffcf17c2db2d57ee9530 fa9bf703af2882d35c8d7e83022c8b80d43ae390 M	src

To confirm, does:
Option "ColorTiling2D" "false"
in the device section of your xorg.conf also fix the issues?

(In reply to comment #35)
> To confirm, does:
> Option "ColorTiling2D" "false"
> in the device section of your xorg.conf also fix the issues?

No it does not solve this bug but it solves bug #56986 for me.

For me "ColorTiling2D" "false" doesn't help too.

The distorted graphics problem disappears when setting the option
Option "NoAccel" "on". 
(This may be obvious to the experts.)

In this mode a new phenomenon appears: When moving th mouse to the Activities corner and the "summarizing display" is shown, the background consists of a corrupted image.

(In reply to comment #38)
> The distorted graphics problem disappears when setting the option
> Option "NoAccel" "on". 
> (This may be obvious to the experts.)
> 
> In this mode a new phenomenon appears: When moving th mouse to the
> Activities corner and the "summarizing display" is shown, the background
> consists of a corrupted image.

That option disables all hardware acceleration.  All rendering is done in software.

Any update?

Created attachment 71284 [details] [review]
Patch gpu pipe

Does this kernel patch fix the issue ?

 	case CHIP_SUMO2:
-		rdev->config.evergreen.num_ses = 1;
+		rdev->config.evergreen.num_ses = 2;

None of the APUs have multiple SEs.

(In reply to comment #42)
>  	case CHIP_SUMO2:
> -		rdev->config.evergreen.num_ses = 1;
> +		rdev->config.evergreen.num_ses = 2;
> 
> None of the APUs have multiple SEs.

So it waste of time, to try that patch?

(In reply to comment #43)
> (In reply to comment #42)
> >  	case CHIP_SUMO2:
> > -		rdev->config.evergreen.num_ses = 1;
> > +		rdev->config.evergreen.num_ses = 2;
> > 
> > None of the APUs have multiple SEs.
> 
> So it waste of time, to try that patch?

Please try it.  Your card is not a SUMO2.

(In reply to comment #41)
> Created attachment 71284 [details] [review] [review]
> Patch gpu pipe
> 
> Does this kernel patch fix the issue ?
Yes it does solve the bug! And it seams 
to solve bug  #56720 too.
Excellent, well done, thank you Jerome.

*** Bug 56720 has been marked as a duplicate of this bug. ***

*** Bug 58115 has been marked as a duplicate of this bug. ***

(In reply to comment #41)
> Created attachment 71284 [details] [review] [review]
> Patch gpu pipe
> 
> Does this kernel patch fix the issue ?

Does this patch get into kernel 3.8?

(In reply to comment #48)
> Does this patch get into kernel 3.8?

Yes.  It will be in 3.8 and the stable kernels.

*** Bug 58634 has been marked as a duplicate of this bug. ***

A patch referencing this bug report has been merged in Linux v3.8-rc1:

commit bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Tue Dec 11 11:56:52 2012 -0500

    drm/radeon: fix amd afusion gpu setup aka sumo v2

Fix works for me.

Yesterday I installed 3.8rc1 and also can confirm - fix works for me too.
Thanks!

Michael, if you also doesn't have this problem anymore please close the ticket.

The patch works for me, as alread reported. I have not tried a kernel including the patch. But I still think this bug is fixed.

I'm running the latest mesa and kernels from git and I think I may have encountered this issue

Everything works fine using i965, using prime with R600_LLVM=1 is also ok however when running with R600_LLVM=0 I got similar error messages about being out of memory 

This seemed to happen when I was testing out the highest settings of WoW - disappointingly the i965 had the highest fps

Created attachment 75082 [details]
Dmesg output

I got lots of radeon: The kernel rejected CS, see dmesg for more information. from the wine process

If this is a separate issue I'll look into it more tomorrow