Bug 20129 - Large texture object obscuring display with radeon driver in dxx-rebirth
Large texture object obscuring display with radeon driver in dxx-rebirth
Status: RESOLVED WONTFIX
Product: DRI
Classification: Unclassified
Component: DRM/Radeon
XOrg 6.7.0
x86 (IA32) Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-15 18:00 UTC by jsado_sc3
Modified: 2014-01-23 11:03 UTC (History)
1 user (show)

See Also:


Attachments
Incorrect rendering of level 1. (37.17 KB, image/png)
2009-02-15 18:00 UTC, jsado_sc3
no flags Details
Correct rendering of level 1 (180.62 KB, image/png)
2009-02-15 18:02 UTC, jsado_sc3
no flags Details
Source code execution list. (126.82 KB, text/plain)
2009-03-01 15:33 UTC, jsado_sc3
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description jsado_sc3 2009-02-15 18:00:27 UTC
Created attachment 22969 [details]
Incorrect rendering of level 1.

Both d1x-rebirth and d2x-rebirth exhibit graphical bugs. These are games based off of Descent 1 and 2. The bugs that I am seeing are present when using the radeon driver, and not present when I run with LIBGL_ALWAYS_SOFTWARE=1.

My system is a Sharp Actius MM20. It is running Gentoo Linux, with kernel 2.6.25-gentoo-r8. The graphics card is an ATI Radeon Mobility M6.

The easiest way to recreate this problem is to install d2x-rebirth from http://www.dxx-rebirth.com/

If you get the source code, just extract it and type scons to build it. If you want a debug build, type scons debug=1

Then, get the demo game files from: http://www.dxx-rebirth.com/download/dxx/res/d2demo.tar.bz2

To run the game enter ./d2x-rebirth-gl -hogdir <path_to_demo_files>
Create a new character, and start a level. You will see a large texture object obscuring the main screen. I will attach screenshots showing the correct and incorrect display.
Comment 1 jsado_sc3 2009-02-15 18:02:56 UTC
Created attachment 22970 [details]
Correct rendering of level 1
Comment 2 jsado_sc3 2009-02-15 18:07:45 UTC
I forgot to add: I am currently running Mesa 7.3, xorg-xserver 1.5.3, and xf86-video-ati 6.10, though I saw this problem with earlier versions of each of these.
Comment 3 jsado_sc3 2009-02-21 16:42:13 UTC
I have done further investigation into this problem.

I am able to prevent this graphical bug by commenting out the line

OGL_DISABLE(TEXTURE_2D) in arch/ogl/gr.c line 436 if you are looking at d2x-rebirth 0.55.1.

This is a macro, and here is it's definition in include/internals.h:

#define OGL_DISABLE(a) OGL_DISABLE2(GL_ ## a,glDisable(GL_ ## a))
#define OGL_DISABLE2(a,f) {if (a ## _enabled!=0) {f;a ## _enabled=0;}}

So, all it is doing is testing whether a particular feature is enabled or not, and if it is, then it is disabling it. To be certain, I created a file with just those three lines in it and ran it through the preprocessor with this command:

gcc -E preproc.cpp

The output line is:

 {if (GL_TEXTURE_2D_enabled!=0) {glDisable(GL_TEXTURE_2D);GL_TEXTURE_2D_enabled=0;}};

GL_TEXTURE_2D_enabled is defined in arch/ogl/ogl.c:

int GL_TEXTURE_2D_enabled=-1;

There is another way to "fix" this problem. It was discovered because an earlier version of the application did not exhibit this problem. The change that caused it was when one drawing call was removed.

In the function render_gauges() in main/gauges.c, if the draw_player_ship() function is called before the draw_weapon_boxes() function, then the display is correct. Specifically I have added these two lines at line 2787 in the code:

»·if (PlayerCfg.CockpitMode == CM_FULL_COCKPIT)
»·»·draw_player_ship(cloak, old_cloak, SHIP_GAUGE_X, SHIP_GAUGE_Y);
Comment 4 jsado_sc3 2009-03-01 15:32:18 UTC
I have another observation. I noticed that during my debugging, the first frame rendered when in the game (after selecting a level and escaping out of the briefing scene) renders correctly. The second frame does not display the cockpit, and the third frame displays the door on top of everything.

I am not sure if it is useful, but I managed to instruct GDB to output a list of all of the lines executed starting with OGL_DISABLE(TEXTURE_2D) in arch/ogl/gr.c line 436. I will attach this. What I have done is to first break at main/gauges.c:2789, continue once to get to this breakpoint a second time, then break at arch/ogl/gr.c:436.

My thought is if disabling this line clears the problem, maybe something in the Radeon driver that is called from this line is causing it. Unfortunately there is a lot of code here.
Comment 5 jsado_sc3 2009-03-01 15:33:40 UTC
Created attachment 23422 [details]
Source code execution list.
Comment 6 Roland Scheidegger 2009-03-02 09:56:03 UTC
(In reply to comment #5)
> Created an attachment (id=23422) [details]
> Source code execution list.

This all looks normal (what happens is since you disable texturing on unit 0, a state change, all pending rendering is flushed).
Not sure why it wouldn't work, but disabling texturing certainly isn't something unusual. Unless units 1 or 2 are still enabled, while this should work it's something apps usually don't do and thus might have bugs unnoticed so far.
Comment 7 jsado_sc3 2009-03-02 16:53:32 UTC
Thanks for the help. I have looked further into the possibility that the application is using multitexturing. As far as I can tell, it is not. There were some stubs of code for that, but it isn't used and I commented it out to be certain.

However, if I modify the code, arch/ogl/gr.c line 436 from:

OGL_DISABLE(TEXTURE_2D)

to:

glActiveTexture(GL_TEXTURE1);
OGL_DISABLE(TEXTURE_2D);
glActiveTexture(GL_TEXTURE2);
OGL_DISABLE(TEXTURE_2D);
glActiveTexture(GL_TEXTURE0);
OGL_DISABLE(TEXTURE_2D);

Then it works. In other words, if I assume that the program is using multitexturing, and proceed to disable it, then the game renders correctly.

On the other hand, I have also put this code in at the same line (instead of the change above):

glActiveTexture(GL_TEXTURE2);
if(glIsEnabled(GL_TEXTURE_2D))
  printf("texture 2\n");
glActiveTexture(GL_TEXTURE1);
if(glIsEnabled(GL_TEXTURE_2D))
  printf("texture 1\n");
glActiveTexture(GL_TEXTURE0);
if(glIsEnabled(GL_TEXTURE_2D))
  printf("texture 0\n");

And this only prints out "texture 0". So I don't see that it is actually using texture units 1 or 2. A grep of all of the code does not show that these are being used.

So maybe there are two problems here? One is that if you have texture unit 0 disabled and another texture unit enabled, the display is messed up. The other might be that there are ways to get a texture unit enabled that you really aren't using.
Comment 8 Roland Scheidegger 2009-03-02 17:53:52 UTC
(In reply to comment #7)
> So maybe there are two problems here? One is that if you have texture unit 0
> disabled and another texture unit enabled, the display is messed up. The other
> might be that there are ways to get a texture unit enabled that you really
> aren't using.

Not sure what's going on, pretty strange. Do you also see this problem with mesa built from git master? I suspect though you would, at least if this is a r100 driver bug this driver hasn't changed much since 7.3...

Comment 9 jsado_sc3 2009-03-03 03:05:47 UTC
Oops, I made a mistake. I forgot that OGL_DISABLE(TEXTURE_2D) is a macro that tests an internal variable before executing glDisble(GL_TEXTURE_2D). So, I fixed the code to look like this instead of whats in my previous comment:

glActiveTexture(GL_TEXTURE1);
glDisable(GL_TEXTURE_2D);
glActiveTexture(GL_TEXTURE2);
glDisable(GL_TEXTURE_2D);
glActiveTexture(GL_TEXTURE0);
OGL_DISABLE(TEXTURE_2D);

And this doesn't fix the problem. So I don't think multitexturing has anything to do with the problem. Sorry about leading people down the wrong track.

What I will do now is verify that the problem still exists with the latest version of Mesa from the repository. Then I will attempt to whittle down the game until I can come up with a simple test case that causes this behavior. I think this is the best approach I can give. I attempted to understand the radeon code in Mesa, but I am not familiar with graphics card architecture, and since I don't have the hardware documentation, I really can't say which part may be in error.
Comment 10 jsado_sc3 2009-03-07 16:58:13 UTC
I have just installed the latest version of Mesa from git, and yes I do still see this problem.
Comment 11 jsado_sc3 2009-03-07 17:47:30 UTC
I don't know if this information will help, but I have run the glean test suite, and is shows failures on texCombine. Maybe this is related to the problem, and maybe these tests are simpler and can point more directly to the root cause.

Here is the output of these failures. Note also that I have other failures with polygonOffset and blendFunc.

texCombine:  FAIL rgba8, db, z24, s8, win+pmap, id 33
        expected 1, 1, 1, 0.25, got 1, 1, 1, 1 in Single Texture Test
        Current combine state:
        Incoming Fragment RGBA = 0, 0.25, 0.5, 0.75
        Texture Unit 0:
          GL_COMBINE_RGB_EXT = GL_DOT3_RGB_EXT
          GL_COMBINE_ALPHA_EXT = GL_MODULATE
          GL_SOURCE0_RGB_EXT = GL_TEXTURE
          GL_SOURCE1_RGB_EXT = GL_TEXTURE
          GL_SOURCE2_RGB_EXT = GL_CONSTANT_EXT
          GL_SOURCE0_ALPHA_EXT = GL_TEXTURE
          GL_SOURCE1_ALPHA_EXT = GL_TEXTURE
          GL_SOURCE2_ALPHA_EXT = GL_CONSTANT_EXT
          GL_OPERAND0_RGB_EXT = GL_SRC_COLOR
          GL_OPERAND1_RGB_EXT = GL_SRC_COLOR
          GL_OPERAND2_RGB_EXT = GL_SRC_ALPHA
          GL_OPERAND0_ALPHA_EXT = GL_SRC_ALPHA
          GL_OPERAND1_ALPHA_EXT = GL_SRC_ALPHA
          GL_OPERAND2_ALPHA_EXT = GL_SRC_ALPHA
          GL_RGB_SCALE_EXT = 1
          GL_ALPHA_SCALE = 1
          Tex Env RGBA = 0.25, 0.5, 0.75, 1
          Texture RGBA = 1, 0, 0.25, 0.5
texCombine:  FAIL rgba8, db, z24, s8, win+pmap, id 34
        expected 1, 1, 1, 0.25, got 1, 1, 1, 1 in Single Texture Test
        Current combine state:
        Incoming Fragment RGBA = 0, 0.25, 0.5, 0.75
        Texture Unit 0:
          GL_COMBINE_RGB_EXT = GL_DOT3_RGB_EXT
          GL_COMBINE_ALPHA_EXT = GL_MODULATE
          GL_SOURCE0_RGB_EXT = GL_TEXTURE
          GL_SOURCE1_RGB_EXT = GL_TEXTURE
          GL_SOURCE2_RGB_EXT = GL_CONSTANT_EXT
          GL_SOURCE0_ALPHA_EXT = GL_TEXTURE
          GL_SOURCE1_ALPHA_EXT = GL_TEXTURE
          GL_SOURCE2_ALPHA_EXT = GL_CONSTANT_EXT
          GL_OPERAND0_RGB_EXT = GL_SRC_COLOR
          GL_OPERAND1_RGB_EXT = GL_SRC_COLOR
          GL_OPERAND2_RGB_EXT = GL_SRC_ALPHA
          GL_OPERAND0_ALPHA_EXT = GL_SRC_ALPHA
          GL_OPERAND1_ALPHA_EXT = GL_SRC_ALPHA
          GL_OPERAND2_ALPHA_EXT = GL_SRC_ALPHA
          GL_RGB_SCALE_EXT = 1
          GL_ALPHA_SCALE = 1
          Tex Env RGBA = 0.25, 0.5, 0.75, 1
          Texture RGBA = 1, 0, 0.25, 0.5
texCombine:  FAIL rgba8, z24, win+pmap, id 86
        expected 1, 1, 1, 0.25, got 1, 1, 1, 1 in Single Texture Test
        Current combine state:
        Incoming Fragment RGBA = 0, 0.25, 0.5, 0.75
        Texture Unit 0:
          GL_COMBINE_RGB_EXT = GL_DOT3_RGB_EXT
          GL_COMBINE_ALPHA_EXT = GL_MODULATE
          GL_SOURCE0_RGB_EXT = GL_TEXTURE
          GL_SOURCE1_RGB_EXT = GL_TEXTURE
          GL_SOURCE2_RGB_EXT = GL_CONSTANT_EXT
          GL_SOURCE0_ALPHA_EXT = GL_TEXTURE
          GL_SOURCE1_ALPHA_EXT = GL_TEXTURE
          GL_SOURCE2_ALPHA_EXT = GL_CONSTANT_EXT
          GL_OPERAND0_RGB_EXT = GL_SRC_COLOR
          GL_OPERAND1_RGB_EXT = GL_SRC_COLOR
          GL_OPERAND2_RGB_EXT = GL_SRC_ALPHA
          GL_OPERAND0_ALPHA_EXT = GL_SRC_ALPHA
          GL_OPERAND1_ALPHA_EXT = GL_SRC_ALPHA
          GL_OPERAND2_ALPHA_EXT = GL_SRC_ALPHA
          GL_RGB_SCALE_EXT = 1
          GL_ALPHA_SCALE = 1
          Tex Env RGBA = 0.25, 0.5, 0.75, 1
          Texture RGBA = 1, 0, 0.25, 0.5

The results file has this:

id 33 fbcID 0 canRGBA 1 r 8 g 8 b 8 a 8 canCI 0 bufSize 32 level 0 db 1 stereo 0 aux 0 z 24 s 8 accumR 0 accumG 0 accumB 0 accumA 0 multisample 0 window 1 pixmap 1 pBuffer 0 maxPBufferWidth 0 maxPBufferHeight 0 maxPBufferPixels 0 winsys 1 fast 1 conformant 1 transparent 0 transR 0 transG 0 transB 0 transA 0 transI 1752444270
0
id 34 fbcID 0 canRGBA 1 r 8 g 8 b 8 a 8 canCI 0 bufSize 32 level 0 db 1 stereo 0 aux 0 z 24 s 8 accumR 0 accumG 0 accumB 0 accumA 0 multisample 0 window 1 pixmap 1 pBuffer 0 maxPBufferWidth 0 maxPBufferHeight 0 maxPBufferPixels 0 winsys 1 fast 1 conformant 1 transparent 0 transR 0 transG 0 transB 0 transA 0 transI 1411530100
0
id 86 fbcID 0 canRGBA 1 r 8 g 8 b 8 a 8 canCI 0 bufSize 32 level 0 db 0 stereo 0 aux 0 z 24 s 0 accumR 0 accumG 0 accumB 0 accumA 0 multisample 0 window 1 pixmap 1 pBuffer 0 maxPBufferWidth 0 maxPBufferHeight 0 maxPBufferPixels 0 winsys 1 fast 1 conformant 1 transparent 0 transR 0 transG 0 transB 0 transA 0 transI 0
0
Comment 12 jsado_sc3 2009-03-07 18:01:05 UTC
I just looked at the texCombine test and it is for an extension that this game is not using, so ignore my previous comment.
Comment 13 Roland Scheidegger 2009-03-09 07:58:12 UTC
(In reply to comment #11)
> I don't know if this information will help, but I have run the glean test
> suite, and is shows failures on texCombine. Maybe this is related to the
> problem, and maybe these tests are simpler and can point more directly to the
> root cause.
> 
> Here is the output of these failures. Note also that I have other failures with
> polygonOffset and blendFunc.
Note that this is really only one failure, reported for different visuals. Ok so not relevant to this bug, but I think I've fixed that in git.
IIRC blendFunc only fails due to precision issues, which is a hardware limitation (so reported diff between expected and actual value should be quite small). Can't remember what was wrong with polygonOffset, but I doubt the game is using that.
Comment 14 chemtech 2013-03-15 07:50:41 UTC
jsado_sc3@comcast.net,
Please attach full dmesg and output of lspci -vv
Please check the status of your issue.
Comment 15 Marek Olšák 2014-01-23 11:03:02 UTC
UMS isn't supported anymore. Closing.