Bug 63532

Summary: Heroes of Newerth Water renders Black instead of transparent with reflections on Ultra [r600g]
Product: Mesa Reporter: romulasry
Component: Drivers/Gallium/r600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: romulasry
Version: git   
Hardware: x86-64 (AMD64)   
OS: All   
URL: http://www.heroesofnewerth.com/download/
Whiteboard:
i915 platform: i915 features:
Attachments: screenshot of wrong rendering at start
screenshot of wrong rendering at middle
glxinfo
dmesg
xorg log

Description romulasry 2013-04-15 00:15:55 UTC
Created attachment 77962 [details]
screenshot of wrong rendering at start

The water in the river in the middle and start of the map renders complete black, not blueish with reflections like it should.

Will post glxinfo if requested. Attaching screenshots.
Comment 1 romulasry 2013-04-15 00:16:49 UTC
Created attachment 77963 [details]
screenshot of wrong rendering at middle
Comment 2 Alex Deucher 2013-04-15 12:41:44 UTC
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.
Comment 3 romulasry 2013-04-15 21:50:03 UTC
Created attachment 78041 [details]
glxinfo
Comment 4 romulasry 2013-04-15 21:51:04 UTC
Created attachment 78042 [details]
dmesg
Comment 5 romulasry 2013-04-15 21:52:56 UTC
Created attachment 78043 [details]
xorg log
Comment 6 romulasry 2013-04-15 21:58:20 UTC
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.
Comment 7 romulasry 2013-04-16 01:43:53 UTC
I tested from 9.0.2 (might be earlier) to master, with the same bug present.
Comment 8 romulasry 2013-04-16 02:05:53 UTC
I can't find a gallium version that doesn't have this bug.
Comment 9 Vadim Girlin 2013-04-16 03:19:11 UTC
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.
Comment 10 romulasry 2013-04-16 06:39:48 UTC
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)
Comment 11 romulasry 2013-04-16 06:48:29 UTC
Closing... Not a bug in Mesa, it is a bug in the game renderer.
Comment 12 Ian Romanick 2013-04-16 17:28:36 UTC
(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.
Comment 13 Vadim Girlin 2013-04-16 20:03:16 UTC
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
Comment 14 Ian Romanick 2013-04-17 21:03:17 UTC
(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
Comment 15 Vadim Girlin 2013-04-18 00:25:37 UTC
(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.

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.