Created attachment 22970 [details]
Correct rendering of level 1

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.

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);

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.

Created attachment 23422 [details]
Source code execution list.

(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.

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.

(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...

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.

I have just installed the latest version of Mesa from git, and yes I do still see this problem.

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

I just looked at the texCombine test and it is for an extension that this game is not using, so ignore my previous comment.

(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.

jsado_sc3@comcast.net,
Please attach full dmesg and output of lspci -vv
Please check the status of your issue.

UMS isn't supported anymore. Closing.