Bug 63532

Created attachment 77963 [details]
screenshot of wrong rendering at middle

What chip and version of mesa are you using?  Is this a regression?  If so, can you bisect?  Please attach your xorg log, dmesg output, and glxinfo output.  Also if this game is a 32 bit game running on a 64 bit distro, please make sure you are using an updated version of the 32-bit 3D driver.

Created attachment 78041 [details]
glxinfo

Created attachment 78042 [details]
dmesg

Created attachment 78043 [details]
xorg log

AMD RV770 (AMD Radeon 4870), git 20130411 mesa, I will check with this is a regression, will bisect if possible. Attached above. This is 64bit game running on 64bit system.

I tested from 9.0.2 (might be earlier) to master, with the same bug present.

I can't find a gallium version that doesn't have this bug.

I suspect it's not a driver's bug, there is a bug in the game itself. I can't login and start a game right now (looks like I need to download a special version of game client for my country), but there is an example of water rendering in the video settings screen that is accessible without login, and it becomes broken for me with evergreen card after changing and applying some options, e.g. resolution in non-fullscreen mode, that is, after engine reinitialization. 

I've looked into it and it seems the game tries to use a texture for the framebuffer attachment right after deleting it. Looks like it generates new texture object, but continues to use old name. Possibly with other drivers (non-mesa) the name returned by glGenTextures is usually the same as was deleted by glDeleteTextures right before that, and this might explain why the bug wasn't noticed.

If your issue is the same, then you should see the following error in the console when you run the game with MESA_DEBUG=1:

Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture2DEXT(non existant texture)

Also you might want to use apitrace to create the trace that reproduces this issue, and you should also see the errors like this when replaying it:

1239444: glDebugOutputCallback: High severity API error 1, GL_INVALID_OPERATION in glFramebufferTexture2DEXT(non existant texture)
0 1239444 glFramebufferTexture2DEXT(target = GL_FRAMEBUFFER, attachment = GL_COLOR_ATTACHMENT0, textarget = GL_TEXTURE_2D, texture = 67, level = 0)
1239444: warning: glGetError(glFramebufferTexture2DEXT) = GL_INVALID_OPERATION

If you believe your issue is different, please upload the trace file somewhere so that it will be easier to reproduce the bug.

This is what I get so I believe it is the same issue.

...
Mesa: User error: GL_INVALID_ENUM in glBindTexture(target)
Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture2DEXT(non existant texture)

Closing... Not a bug in Mesa, it is a bug in the game renderer.

(In reply to comment #10)
> This is what I get so I believe it is the same issue.
> 
> ...
> Mesa: User error: GL_INVALID_ENUM in glBindTexture(target)
> Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture2DEXT(non
> existant texture)

Can you (or someone):

1. Run the game in gdb.

2. Set a break point in _mesa_problem.

3. When the break point is hit, go 'up' a level and 'print target'.

4. 'bt full'

5. Report the results back here.

I'm curious what's going on.

I managed to start the game and it seems there are different problems with water rendering, and I don't see framebuffer-related errors in the game. Possibly I was wrong, I'll look into it to see if it's something related to mesa or the driver.

Btw, Ian, here is a backtrace for BindTexture error (target is 0).
Breakpoint on _mesa_problem didn't catch it, so I used _mesa_error:

Breakpoint 1, _mesa_error (ctx=0x6f31ec0, error=1280, fmtString=
    0x7f4466e38864 "glBindTexture(target)") at ../../src/mesa/main/errors.c:935
935	   debug_get_id(&error_msg_id);
(gdb) bt full
#0  _mesa_error (ctx=0x6f31ec0, error=1280, fmtString=
    0x7f4466e38864 "glBindTexture(target)") at ../../src/mesa/main/errors.c:935
        do_output = 0 '\000'
        do_log = 0 '\000'
        error_msg_id = 0
        __PRETTY_FUNCTION__ = "_mesa_error"
#1  0x00007f4466aba48f in _mesa_BindTexture (target=0, texName=2079)
    at ../../src/mesa/main/texobj.c:1238
        ctx = 0x6f31ec0
        texUnit = 0x6f34f38
        newTexObj = 0x0
        targetIndex = -1
        __PRETTY_FUNCTION__ = "_mesa_BindTexture"
        __func__ = "_mesa_BindTexture"
#2  0x00007f4485b7a63e in glBindTexture (target=0, texture=2079)
    at ../../../src/mapi/glapi/glapi_mapi_tmp.h:3574
        _tbl = 0x6f42cd0
        _func = 0x7f4466aba3ca <_mesa_BindTexture>
#3  0x00007f4467bb1f85 in ?? () from /home/vg/HoN/vid_gl2-x86_64.so

(In reply to comment #13)
> I managed to start the game and it seems there are different problems with
> water rendering, and I don't see framebuffer-related errors in the game.
> Possibly I was wrong, I'll look into it to see if it's something related to
> mesa or the driver.
> 
> Btw, Ian, here is a backtrace for BindTexture error (target is 0).
> Breakpoint on _mesa_problem didn't catch it, so I used _mesa_error:

Right, I always get those backwards.  Sorry. :(

> Breakpoint 1, _mesa_error (ctx=0x6f31ec0, error=1280, fmtString=
>     0x7f4466e38864 "glBindTexture(target)") at
> ../../src/mesa/main/errors.c:935
> 935	   debug_get_id(&error_msg_id);
> (gdb) bt full
> #0  _mesa_error (ctx=0x6f31ec0, error=1280, fmtString=
>     0x7f4466e38864 "glBindTexture(target)") at
> ../../src/mesa/main/errors.c:935
>         do_output = 0 '\000'
>         do_log = 0 '\000'
>         error_msg_id = 0
>         __PRETTY_FUNCTION__ = "_mesa_error"
> #1  0x00007f4466aba48f in _mesa_BindTexture (target=0, texName=2079)
>     at ../../src/mesa/main/texobj.c:1238
>         ctx = 0x6f31ec0
>         texUnit = 0x6f34f38
>         newTexObj = 0x0
>         targetIndex = -1
>         __PRETTY_FUNCTION__ = "_mesa_BindTexture"
>         __func__ = "_mesa_BindTexture"
> #2  0x00007f4485b7a63e in glBindTexture (target=0, texture=2079)

That's definitely no good.  0 isn't a valid target, and 2079 (0x081F) isn't either.  Weird.

>     at ../../../src/mapi/glapi/glapi_mapi_tmp.h:3574
>         _tbl = 0x6f42cd0
>         _func = 0x7f4466aba3ca <_mesa_BindTexture>
> #3  0x00007f4467bb1f85 in ?? () from /home/vg/HoN/vid_gl2-x86_64.so

(In reply to comment #14)
> > #2  0x00007f4485b7a63e in glBindTexture (target=0, texture=2079)
> 
> That's definitely no good.  0 isn't a valid target, and 2079 (0x081F) isn't
> either.  Weird.

I tested it with catalyst 13.1, there is the same rendering issue (water is black with some video settings), and similar BindTexture calls with target 0, so I think it's not a mesa/r600g's issues.