Created attachment 6951 [details]
Example of "missing bits" with GL_ARB_vertex_program

In this example, Warcraft is running in OpenGL mode with GL_ARB_vertex_program
enabled and GL_ARB_vertex_buffer_object disabled. I have rebuilt r200_dri.so to
include the changes to r200_vertprog.c, r200_texstate.c and r200_state.c from
September 13th 2006, to no effect.

How are you disabling GL_ARB_vertex_program now that the option for "software"
vp has been removed from driconf?

I'm not doubting your theory. I think I've seen a related problem in Warcraft 3,
but I haven't yet pinpointed the problem. I've always been thinking it's related
to tcl.

I'm disabling GL_ARB_vertex_program via Wine, which has a registry key for
listing OpenGL extensions that you don't want to be used:

http://appdb.winehq.org/appimage.php?iId=3746

Ok. Tried and obviously made no difference in this case. I don't think that war3
even uses vertex program. But the issue does look oddly similar. 

Please see wine bug 6502
http://bugs.winehq.org/show_bug.cgi?id=6502
And try the workaround patch. I'm just trying to make sure whether this is the
same problem or not.

(In reply to comment #5)
> Please see wine bug 6502
> http://bugs.winehq.org/show_bug.cgi?id=6502
> And try the workaround patch. I'm just trying to make sure whether this is the
> same problem or not.

I can now absolutely confirm that this is nothing at all to do with wine bug 6502.

Does World of Warcraft have any option related to particles? In Warcraft 3,
there is a "Particles" option. I fixed my problem by setting particles from High
to Medium and restarting the game.

FWIW, the r200 driver now should support generic vertex attribs. You may want to
try that out, though no guarantees it won't lockup or crash :-). The driver now
should support everything related to vertex programs in hw with the only
fallbacks left either because a limit is violated (too many temps (could need
optimizer there), attribs, instructions) or writes to back facing colors (looks
like r200 can't handle that in vp mode).

(In reply to comment #8)
> FWIW, the r200 driver now should support generic vertex attribs.

Ooo, my hero ;-)! I assume we're talking CVS Mesa here, though. What else will I
need to update to use that, given that I am running the 2.6.18.1 kernel and the
DRM module out of the old CVS repository (+ patch for an integer overflow bug in
the radeon code)?

BTW, I am also running the Xorg packages from FC6, albeit recompiled for FC5.

(In reply to comment #9)
> Ooo, my hero ;-)! I assume we're talking CVS Mesa here, though. What else will I
> need to update to use that, given that I am running the 2.6.18.1 kernel and the
> DRM module out of the old CVS repository (+ patch for an integer overflow bug in
> the radeon code)?
You don't need a newer drm kernel module (in fact 2.6.18 should be just as
recent as the one from the old cvs repo), however you may need a new libdrm to
get it to compile.

(In reply to comment #10)
> You don't need a newer drm kernel module (in fact 2.6.18 should be just as
> recent as the one from the old cvs repo), however you may need a new libdrm to
> get it to compile.

It compiled just fine using libdrm-2.2.0, but refused to run because of a
missing drmCloseOnce() symbol. Something somewhere must be out of sync.

(In reply to comment #11)
> (In reply to comment #10)
> > You don't need a newer drm kernel module (in fact 2.6.18 should be just as
> > recent as the one from the old cvs repo), however you may need a new libdrm to
> > get it to compile.
> 
> It compiled just fine using libdrm-2.2.0, but refused to run because of a
> missing drmCloseOnce() symbol. Something somewhere must be out of sync.
Actually I was hit by that too. Didn't realize it then, but it should work if
you use a new libGL.so (i.e. the one which is built as the same time as the driver).

I did try running it, but I was stuck at 800x600 resolution and it locked up
when I tried switching to a virtual console. (My DFL monitor's refresh frequency
was reported as some ridiculous negative number in the screen resolution
preferences, as well.) Do I need to recompile anything else against the new libGL?

For reference, I installed the libdrm-2.2.0 package, and did a "make install" in
the Mesa/ directory, so should have been using the new libGL:

# Installation directories (for make install)
INSTALL_DIR = /usr
DRI_DRIVER_INSTALL_DIR = /usr/lib/dri

BTW, here I am seeing no difference with War3 and latest CVS. So I'll be
interested what Roland's latest patch does for you, because I believe he removed
some of the fallbacks?

(In reply to comment #14)
> BTW, here I am seeing no difference with War3 and latest CVS. So I'll be
> interested what Roland's latest patch does for you, because I believe he removed
> some of the fallbacks?
Considering War3 was designed to run well on TNT's and similar old cards, I
doubt it uses vertex programs. Since only some fallbacks for vertex programs
were removed, you obviously won't see a difference.

(In reply to comment #13)
> I did try running it, but I was stuck at 800x600 resolution and it locked up
> when I tried switching to a virtual console. (My DFL monitor's refresh frequency
> was reported as some ridiculous negative number in the screen resolution
> preferences, as well.) Do I need to recompile anything else against the new libGL?
That's strange. Are you sure it really picked up the right libraries? For
testing, you could always just set LIBGL_DRIVERS_PATH to the path where the
*_dri.so driver is (this won't work for libgl though, you could try
LD_LIBRARY_PATH for that). I can't see any reason why it would make a difference
wrt resoluton selection or something similar.

(In reply to comment #16)
> That's strange. Are you sure it really picked up the right libraries? For
> testing, you could always just set LIBGL_DRIVERS_PATH to the path where the
> *_dri.so driver is (this won't work for libgl though, you could try
> LD_LIBRARY_PATH for that). I can't see any reason why it would make a
> difference wrt resoluton selection or something similar.

I know I was using the new r200_dri.so module because of the drmCloseOnce symbol
issue. And I must have been using libdrm-2.2.0 because I created an RPM for it
and upgraded from the existing libdrm-2.0.2 package.

I suppose I could try uninstalling all my original Mesa RPMs before installing
CVS over the top. Failing that, can you think of anything other than Mesa that
links against libdrm?

(In reply to comment #17)
> I know I was using the new r200_dri.so module because of the drmCloseOnce symbol
> issue. And I must have been using libdrm-2.2.0 because I created an RPM for it
> and upgraded from the existing libdrm-2.0.2 package.
> 
> I suppose I could try uninstalling all my original Mesa RPMs before installing
> CVS over the top. Failing that, can you think of anything other than Mesa that
> links against libdrm?
not sure, but I think only the dri drivers use it. Not sure where you're
problems are coming from.

I installed "by hand" this time, and my resolution problem has gone away. Here
is my new glxinfo:

name of display: :0.0
libGL warning: 3D driver claims to not support visual 0x4b
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
    GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read,
    GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 20060602 AGP 8x x86/MMX/SSE2 TCL
OpenGL version string: 1.3 Mesa 6.5.2
OpenGL extensions:
    GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture,
    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_texture_border_clamp,
    GL_ARB_texture_compression, GL_ARB_texture_cube_map,
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
    GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle,
    GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
    GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra,
    GL_EXT_blend_color, GL_EXT_blend_equation_separate,
    GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution,
    GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord,
    GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_point_parameters,
    GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color,
    GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture,
    GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc,
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
    GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
    GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3,
    GL_ATI_texture_mirror_once, GL_ATI_fragment_shader, GL_IBM_rasterpos_clip,
    GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
    GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos,
    GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle,
    GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix,
    GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_S3_s3tc
OpenGL limits:
    GL_MAX_ATTRIB_STACK_DEPTH = 16
    GL_MAX_CLIENT_ATTRIB_STACK_DEPTH = 16
    GL_MAX_CLIP_PLANES = 6
    GL_MAX_COLOR_MATRIX_STACK_DEPTH = 4
    GL_MAX_ELEMENTS_VERTICES = 3000
    GL_MAX_ELEMENTS_INDICES = 3000
    GL_MAX_EVAL_ORDER = 30
    GL_MAX_LIGHTS = 8
    GL_MAX_LIST_NESTING = 64
    GL_MAX_MODELVIEW_STACK_DEPTH = 32
    GL_MAX_NAME_STACK_DEPTH = 64
    GL_MAX_PIXEL_MAP_TABLE = 256
    GL_MAX_PROJECTION_STACK_DEPTH = 32
    GL_MAX_TEXTURE_STACK_DEPTH = 10
    GL_MAX_TEXTURE_SIZE = 2048
    GL_MAX_3D_TEXTURE_SIZE = 128
    GL_MAX_VIEWPORT_DIMS = 4096, 4096
    GL_ALIASED_LINE_WIDTH_RANGE = 1, 10
    GL_SMOOTH_LINE_WIDTH_RANGE = 1, 10
    GL_ALIASED_POINT_SIZE_RANGE = 1, 2047
    GL_SMOOTH_POINT_SIZE_RANGE = 1, 1
    GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 1024
    GL_NUM_COMPRESSED_TEXTURE_FORMATS_ARB = 7
    GL_MAX_TEXTURE_UNITS_ARB = 6
    GL_MAX_TEXTURE_LOD_BIAS_EXT = 11
    GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT = 16
    GL_MAX_CONVOLUTION_WIDTH/HEIGHT = 9, 9
    GL_VERTEX_PROGRAM_ARB:
        GL_MAX_PROGRAM_INSTRUCTIONS_ARB = 128
        GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB = 128
        GL_MAX_PROGRAM_TEMPORARIES_ARB = 12
        GL_MAX_PROGRAM_NATIVE_TEMPORARIES_ARB = 12
        GL_MAX_PROGRAM_PARAMETERS_ARB = 128
        GL_MAX_PROGRAM_NATIVE_PARAMETERS_ARB = 192
        GL_MAX_PROGRAM_ATTRIBS_ARB = 16
        GL_MAX_PROGRAM_NATIVE_ATTRIBS_ARB = 12
        GL_MAX_PROGRAM_ADDRESS_REGISTERS_ARB = 1
        GL_MAX_PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB = 1
        GL_MAX_PROGRAM_LOCAL_PARAMETERS_ARB = 128
        GL_MAX_PROGRAM_ENV_PARAMETERS_ARB = 128
        GL_MAX_PROGRAM_ALU_INSTRUCTIONS_ARB = 128
        GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB = 128
        GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB = 128
        GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB = 128
        GL_MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB = 128
        GL_MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB = 128

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x24 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x25 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x26 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x27 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x28 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x29 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x2a 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x2b 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x2c 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x2d 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x2e 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x2f 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x30 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x31 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x32 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x4b 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 Ncon

Unfortunately, the new GL_ARB_vertex_program code is locking up both celestia
and Warcraft. Warcraft doesn't even manage to bring up the login screen, and so
it's a good bet that one of those four vertex programs that I posted for an
earlier bug is breaking. Celestia is locking up during the start-up demo.

However, Warcraft runs fine once I tell wine to ignore GL_ARB_vertex_program
again. The GL_ARB_point_sprite / point_parameters code must therefore be working
(I think)...

(In reply to comment #19)
> Unfortunately, the new GL_ARB_vertex_program code is locking up both celestia
> and Warcraft. Warcraft doesn't even manage to bring up the login screen, and so
> it's a good bet that one of those four vertex programs that I posted for an
> earlier bug is breaking. Celestia is locking up during the start-up demo.
That's strange, afaik celestia doesn't even use generic attribs and shouldn't be
affected at all. Are you still using the old cvs drm? I think I was wrong in
telling it should work, it lacks the lockup fix when enabling/disabling vertex
programs. drm from 2.6.18 has it however, otherwise you could try re-enabling
the workaround code in r200_state.c.

(In reply to comment #20)
> Are you still using the old cvs drm?

Yes, but with an "integer overflow" patch against radeon_state.c which I need,
but that 2.6.18.x does not have. (I'm hoping that 2.6.19 will, though.) I'll try
applying my patch to 2.6.18 and rebuilding the kernel module.

(In reply to comment #20)
> Are you still using the old cvs drm? I think I was wrong in
> telling it should work, it lacks the lockup fix when enabling/disabling vertex
> programs.

Do you mean "r200_vap_state_flush.diff"? It turns out that I have applied this
fix already.

(In reply to comment #22)
> Do you mean "r200_vap_state_flush.diff"? It turns out that I have applied this
> fix already.
Yes. Turns out though this wasn't (at least not the only) issue, I could
reproduce the lockups. I didn't see them before due to experimental changes in
my local tree for optimizing color input 0 away in fixed function mode (which
wasn't really a performance gain btw).
Should be fixed now, though I won't be able to look into any further issues for
a week.

(In reply to comment #23)
> Yes. Turns out though this wasn't (at least not the only) issue, I could
> reproduce the lockups. I didn't see them before due to experimental changes in
> my local tree for optimizing color input 0 away in fixed function mode (which
> wasn't really a performance gain btw).

OK, I'll test this tomorrow. I think the existing code does show a minor
increase in FPS. Which is to say that a location where it normally drops to 8-10
FPS stayed at around 14 this time. And the colour palette was a lot richer this
time.

Created attachment 7676 [details]
Screenshot of WoW with new R200 vertex programs.

At least the lock-up is fixed ;-). Celestia works fine now, too.

Created attachment 7677 [details]
xscreensaver 4.24, "hypertorus -solid -transp"

I'm not sure if this is related to the vertex program problem, but I'm sure
that those triangular artifacts shouldn't be there.

(In reply to comment #26)
> Created an attachment (id=7677) [edit]
> xscreensaver 4.24, "hypertorus -solid -transp"
> 
> I'm not sure if this is related to the vertex program problem, but I'm sure
> that those triangular artifacts shouldn't be there.
Are you sure direct rendering worked for xscreensaver? I get exactly the same
problem, but only with indirect rendering. In any case, I doubt it's related.

(In reply to comment #27)
> Are you sure direct rendering worked for xscreensaver? I get exactly the same
> problem, but only with indirect rendering. In any case, I doubt it's related.

Well, I can't think why xscreensaver wouldn't be using direct rendering. But if
you think it's a separate issue then fair enough.

(In reply to comment #28)
> (In reply to comment #27)
> > Are you sure direct rendering worked for xscreensaver? I get exactly the same
> > problem, but only with indirect rendering. In any case, I doubt it's related.
> 
> Well, I can't think why xscreensaver wouldn't be using direct rendering. But if
> you think it's a separate issue then fair enough.
Well, I've got some trouble sometimes with xscreensaver not getting direct
rendering (where all other apps work). However, I can reproduce it with direct
rendering, if I set tcl_mode to 0 or 1. So there definitely is a problem here,
it certainly should look the same regardless of tcl mode. It could be related to
warcraft problems, though that's difficult to say.

(In reply to comment #29)
> Well, I've got some trouble sometimes with xscreensaver not getting direct
> rendering (where all other apps work). However, I can reproduce it with direct
> rendering, if I set tcl_mode to 0 or 1. So there definitely is a problem here,
> it certainly should look the same regardless of tcl mode.

I am running with tcl_mode = 1.

> It could be related to warcraft problems, though that's difficult to say.

Naturally, if you don't have a Warcraft account ;-). However, the current
problems are visible at the login screen and so no account would be needed. All
you would need would be the trial client.

(In reply to comment #30)
> > it certainly should look the same regardless of tcl mode.
> 
> I am running with tcl_mode = 1.
FWIW, this is fixed (see #9062). Unlikely to be related, however.

> Naturally, if you don't have a Warcraft account ;-). However, the current
> problems are visible at the login screen and so no account would be needed. All
> you would need would be the trial client.
I've finally downloaded WoW (and warcraft 3), will try later with new distro
(couldn't get newer wine versions to run at all with old distro, segfaulted even
before reaching gdb...)

Hmm ok so it looks like there is something wrong with emitting the upper 3
instructions of the 67 instruction length vertex program (those that do not fit
into the first 64 instruction memory area). The driver seems to cycle between
emitting different values of garbage, and all zeros for these...
Should be a fairly obvious bug to find, though I failed so far :-(

(In reply to comment #32)
> Hmm ok so it looks like there is something wrong with emitting the upper 3
> instructions of the 67 instruction length vertex program (those that do not fit
> into the first 64 instruction memory area). The driver seems to cycle between
> emitting different values of garbage, and all zeros for these...
> Should be a fairly obvious bug to find, though I failed so far :-(
Meh. That was just bogus debug output in the sanity code...
No idea what's really wrong.

Ok, the problem is that the component order is wrong if you use mixed generic
and non-generic arrays (somehow I knew I should have tested this more thoroughly
than with the extremely simple mesa test...), in this case colors and texture
coordinates get mixed up completely. I should be able to fix that...

ordering problem is fixed & WoW intro screen looks much better. I'm afraid
though this probably won't help with the missing avatars...

(In reply to comment #35)
> ordering problem is fixed & WoW intro screen looks much better. I'm afraid
> though this probably won't help with the missing avatars...

Hi, thanks for doing that. I've just tried with the new r200_dri.so module (Do I
need the updated libGL, libGLU etc as well?) and the login screen now works with
vertex programs enabled. However, my avatars now look like Ringwraiths from the
Lord of the Rings, in that they're completely invisible except for their eyes
and a few features such as weapons, buckles etc.

When I enter the game, the screen goes crazy again, and when I return to the
login screen it looks like the vertex programs aren't enabled again.

Created attachment 7919 [details]
Having just logged into Warcraft, at the "character selection" screen.

As well as my avatar becoming a RingWraith, there are also random flickering
triangular artifacts.

Created attachment 7920 [details]
Have selected character and have entered the game proper.

You can see some detail beneath the blue, and also a sprinkling of curious
dots. The blank white circle (the mini-map) is a different bug (I think).

Created attachment 7921 [details]
Have returned to the login screen, after logging out again.

This is much as the login screen used to look like when vertex programs were
not being compiled at all.

There are the new vertex programs that are compiled for the character selection
screen, after successfully logging in:

!!ARBvp1.0
PARAM c0 = { 255.002, 3, 0, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c17[11] = { program.env  [17..27] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R0.z, R2, R1, R0;
        MUL R1.w, R0.z, c0.y;
        ARL A0.x, R1.w;
        DP4 R1.x, c31[A0.x], v16;
        DP4 R1.y, c31[A0.x + 1], v16;
        DP4 R1.z, c31[A0.x + 2], v16;
        MOV result.fogcoord.x, R1.z;
        MOV R0.xyz, R1.xyzz;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        DP3 R0.y, c31[A0.x].xyzx, v18.xyzx;
        DP3 R0.z, c31[A0.x + 1].xyzx, v18.xyzx;
        DP3 R0.w, c31[A0.x + 2].xyzx, v18.xyzx;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R0.xyz, R0.x, R0.yzwy;
        ADD R1.xyz, c17[4].xyzx, -R1.xyzx;
        DP3 R0.w, R1.xyzx, R0.xyzx;
        DP3 R1.z, R1.xyzx, R1.xyzx;
        RSQ R1.y, R1.z;
        MUL R0.w, R0.w, R1.y;
        MAX R1.x, R0.w, c0.z;
        MUL R0.w, R1.z, R1.y;
        MUL R0.w, R0.w, c17[9].x;
        MAD R0.w, R1.z, c17[10].x, R0.w;
        ADD R0.w, R0.w, c17[8].x;
        RCP R0.w, R0.w;
        MUL R3.w, R1.x, R0.w;
        MUL R1, R0.xyzz, R0.yzzx;
        DP4 R3.x, c10[3], R1;
        DP4 R3.y, c10[4], R1;
        DP4 R3.z, c10[5], R1;
        MOV R2.xyz, R0.xyzz;
        MOV R2.w, c0.w;
        DP4 R1.x, c10[0], R2;
        DP4 R1.y, c10[1], R2;
        DP4 R1.z, c10[2], R2;
        ADD R1.xyz, R1.xyzx, R3.xyzx;
        MUL R0.w, R0.y, R0.y;
        MAD R0.x, R0.x, R0.x, -R0.w;
        MAD R0.xyz, c10[6].xyzx, R0.x, R1.xyzx;
        MAD R0.xyz, c17[0].xyzx, R3.w, R0.xyzx;
        MIN R0.xyz, c0.w, R0.xyzx;
        MAX R1.xyz, c0.z, R0.xyzx;
        MOV R1.w, c0.w;
        MOV R0, c28[0];
        MAD result.color.front.primary, R0, R1, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3, R4;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c17[11] = { program.env  [17..27] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R1.zw, R2.xxyz, R1.xxyz, R0.xxyz;
        MUL R1.y, R1.z, c0.z;
        ARL A0.x, R1.y;
        MUL R0, c31[A0.x], v17.y;
        MUL R1.x, R1.w, c0.z;
        ARL A0.x, R1.x;
        MAD R4, c31[A0.x], v17.x, R0;
        DP4 R3.x, R4, v16;
        ARL A0.x, R1.y;
        MUL R0, c31[A0.x + 1], v17.y;
        ARL A0.x, R1.x;
        MAD R2, c31[A0.x + 1], v17.x, R0;
        DP4 R3.y, R2, v16;
        ARL A0.x, R1.y;
        MUL R0, c31[A0.x + 2], v17.y;
        ARL A0.x, R1.x;
        MAD R1, c31[A0.x + 2], v17.x, R0;
        DP4 R3.z, R1, v16;
        MOV result.fogcoord.x, R3.z;
        MOV R0.xyz, R3.xyzz;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        DP3 R0.y, R4.xyzx, v18.xyzx;
        DP3 R0.z, R2.xyzx, v18.xyzx;
        DP3 R0.w, R1.xyzx, v18.xyzx;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R0.xyz, R0.x, R0.yzwy;
        ADD R1.xyz, c17[4].xyzx, -R3.xyzx;
        DP3 R0.w, R1.xyzx, R0.xyzx;
        DP3 R1.z, R1.xyzx, R1.xyzx;
        RSQ R1.y, R1.z;
        MUL R0.w, R0.w, R1.y;
        MAX R1.x, R0.w, c0.y;
        MUL R0.w, R1.z, R1.y;
        MUL R0.w, R0.w, c17[9].x;
        MAD R0.w, R1.z, c17[10].x, R0.w;
        ADD R0.w, R0.w, c17[8].x;
        RCP R0.w, R0.w;
        MUL R3.w, R1.x, R0.w;
        MUL R1, R0.xyzz, R0.yzzx;
        DP4 R3.x, c10[3], R1;
        DP4 R3.y, c10[4], R1;
        DP4 R3.z, c10[5], R1;
        MOV R2.xyz, R0.xyzz;
        MOV R2.w, c0.w;
        DP4 R1.x, c10[0], R2;
        DP4 R1.y, c10[1], R2;
        DP4 R1.z, c10[2], R2;
        ADD R1.xyz, R1.xyzx, R3.xyzx;
        MUL R0.w, R0.y, R0.y;
        MAD R0.x, R0.x, R0.x, -R0.w;
        MAD R0.xyz, c10[6].xyzx, R0.x, R1.xyzx;
        MAD R0.xyz, c17[0].xyzx, R3.w, R0.xyzx;
        MIN R0.xyz, c0.w, R0.xyzx;
        MAX R1.xyz, c0.y, R0.xyzx;
        MOV R1.w, c0.w;
        MOV R0, c28[0];
        MAD result.color.front.primary, R0, R1, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 3, 0, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R0.z, R2, R1, R0;
        MUL R1.x, R0.z, c0.y;
        ARL A0.x, R1.x;
        DP4 R0.x, c31[A0.x], v16;
        DP4 R0.y, c31[A0.x + 1], v16;
        DP4 R0.z, c31[A0.x + 2], v16;
        MOV result.fogcoord.x, R0.z;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        DP3 R0.y, c31[A0.x].xyzx, v18.xyzx;
        DP3 R0.z, c31[A0.x + 1].xyzx, v18.xyzx;
        DP3 R0.w, c31[A0.x + 2].xyzx, v18.xyzx;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R3.xyz, R0.x, R0.yzwy;
        MUL R0, R3.xyzz, R3.yzzx;
        DP4 R2.x, c10[3], R0;
        DP4 R2.y, c10[4], R0;
        DP4 R2.z, c10[5], R0;
        MOV R1.xyz, R3.xyzz;
        MOV R1.w, c0.w;
        DP4 R0.x, c10[0], R1;
        DP4 R0.y, c10[1], R1;
        DP4 R0.z, c10[2], R1;
        ADD R0.yzw, R0.xxyz, R2.xxyz;
        MUL R0.x, R3.y, R3.y;
        MAD R0.x, R3.x, R3.x, -R0.x;
        MAD R1.xyz, c10[6].xyzx, R0.x, R0.yzwy;
        MOV R1.w, c0.w;
        MOV R0, c28[0];
        MAD result.color.front.primary, R0, R1, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3, R4;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R2.xyz, R2, R1, R0;
        MUL R1.z, R2.y, c0.z;
        ARL A0.x, R1.z;
        MUL R0, c31[A0.x], v17.y;
        MUL R1.y, R2.z, c0.z;
        ARL A0.x, R1.y;
        MAD R0, c31[A0.x], v17.x, R0;
        MUL R1.x, R2.x, c0.z;
        ARL A0.x, R1.x;
        MAD R4, c31[A0.x], v17.z, R0;
        DP4 R3.x, R4, v16;
        ARL A0.x, R1.z;
        MUL R0, c31[A0.x + 1], v17.y;
        ARL A0.x, R1.y;
        MAD R0, c31[A0.x + 1], v17.x, R0;
        ARL A0.x, R1.x;
        MAD R2, c31[A0.x + 1], v17.z, R0;
        DP4 R3.y, R2, v16;
        ARL A0.x, R1.z;
        MUL R0, c31[A0.x + 2], v17.y;
        ARL A0.x, R1.y;
        MAD R0, c31[A0.x + 2], v17.x, R0;
        ARL A0.x, R1.x;
        MAD R1, c31[A0.x + 2], v17.z, R0;
        DP4 R3.z, R1, v16;
        MOV result.fogcoord.x, R3.z;
        MOV R3.w, c0.w;
        DP4 result.position.x, c2[0], R3;
        DP4 result.position.y, c2[1], R3;
        DP4 result.position.z, c2[2], R3;
        DP4 result.position.w, c2[3], R3;
        DP3 R0.y, R4.xyzx, v18.xyzx;
        DP3 R0.z, R2.xyzx, v18.xyzx;
        DP3 R0.w, R1.xyzx, v18.xyzx;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R3.xyz, R0.x, R0.yzwy;
        MUL R0, R3.xyzz, R3.yzzx;
        DP4 R2.x, c10[3], R0;
        DP4 R2.y, c10[4], R0;
        DP4 R2.z, c10[5], R0;
        MOV R1.xyz, R3.xyzz;
        MOV R1.w, c0.w;
        DP4 R0.x, c10[0], R1;
        DP4 R0.y, c10[1], R1;
        DP4 R0.z, c10[2], R1;
        ADD R0.yzw, R0.xxyz, R2.xxyz;
        MUL R0.x, R3.y, R3.y;
        MAD R0.x, R3.x, R3.x, -R0.x;
        MAD R1.xyz, c10[6].xyzx, R0.x, R0.yzwy;
        MOV R1.w, c0.w;
        MOV R0, c28[0];
        MAD result.color.front.primary, R0, R1, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3, R4;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R1, R2, R1, R0;
        MUL R2.w, R1.y, c0.z;
        ARL A0.x, R2.w;
        MUL R0, c31[A0.x], v17.y;
        MUL R2.z, R1.z, c0.z;
        ARL A0.x, R2.z;
        MAD R0, c31[A0.x], v17.x, R0;
        MUL R2.y, R1.x, c0.z;
        ARL A0.x, R2.y;
        MAD R0, c31[A0.x], v17.z, R0;
        MUL R2.x, R1.w, c0.z;
        ARL A0.x, R2.x;
        MAD R1, c31[A0.x], v17.w, R0;
        DP4 R0.x, R1, v16;
        ARL A0.x, R2.w;
        MUL R3, c31[A0.x + 1], v17.y;
        ARL A0.x, R2.z;
        MAD R3, c31[A0.x + 1], v17.x, R3;
        ARL A0.x, R2.y;
        MAD R3, c31[A0.x + 1], v17.z, R3;
        ARL A0.x, R2.x;
        MAD R4, c31[A0.x + 1], v17.w, R3;
        DP4 R0.y, R4, v16;
        ARL A0.x, R2.w;
        MUL R3, c31[A0.x + 2], v17.y;
        ARL A0.x, R2.z;
        MAD R3, c31[A0.x + 2], v17.x, R3;
        ARL A0.x, R2.y;
        MAD R3, c31[A0.x + 2], v17.z, R3;
        ARL A0.x, R2.x;
        MAD R2, c31[A0.x + 2], v17.w, R3;
        DP4 R0.z, R2, v16;
        MOV result.fogcoord.x, R0.z;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        DP3 R0.y, R1.xyzx, v18.xyzx;
        DP3 R0.z, R4.xyzx, v18.xyzx;
        DP3 R0.w, R2.xyzx, v18.xyzx;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R3.xyz, R0.x, R0.yzwy;
        MUL R0, R3.xyzz, R3.yzzx;
        DP4 R2.x, c10[3], R0;
        DP4 R2.y, c10[4], R0;
        DP4 R2.z, c10[5], R0;
        MOV R1.xyz, R3.xyzz;
        MOV R1.w, c0.w;
        DP4 R0.x, c10[0], R1;
        DP4 R0.y, c10[1], R1;
        DP4 R0.z, c10[2], R1;
        ADD R0.yzw, R0.xxyz, R2.xxyz;
        MUL R0.x, R3.y, R3.y;
        MAD R0.x, R3.x, R3.x, -R0.x;
        MAD R1.xyz, c10[6].xyzx, R0.x, R0.yzwy;
        MOV R1.w, c0.w;
        MOV R0, c28[0];
        MAD result.color.front.primary, R0, R1, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3, R4;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R1.zw, R2.xxyz, R1.xxyz, R0.xxyz;
        MUL R1.y, R1.z, c0.z;
        ARL A0.x, R1.y;
        MUL R0, c31[A0.x], v17.y;
        MUL R1.x, R1.w, c0.z;
        ARL A0.x, R1.x;
        MAD R4, c31[A0.x], v17.x, R0;
        DP4 R3.x, R4, v16;
        ARL A0.x, R1.y;
        MUL R0, c31[A0.x + 1], v17.y;
        ARL A0.x, R1.x;
        MAD R2, c31[A0.x + 1], v17.x, R0;
        DP4 R3.y, R2, v16;
        ARL A0.x, R1.y;
        MUL R0, c31[A0.x + 2], v17.y;
        ARL A0.x, R1.x;
        MAD R1, c31[A0.x + 2], v17.x, R0;
        DP4 R3.z, R1, v16;
        MOV result.fogcoord.x, R3.z;
        MOV R3.w, c0.w;
        DP4 result.position.x, c2[0], R3;
        DP4 result.position.y, c2[1], R3;
        DP4 result.position.z, c2[2], R3;
        DP4 result.position.w, c2[3], R3;
        DP3 R0.y, R4.xyzx, v18.xyzx;
        DP3 R0.z, R2.xyzx, v18.xyzx;
        DP3 R0.w, R1.xyzx, v18.xyzx;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R3.xyz, R0.x, R0.yzwy;
        MUL R0, R3.xyzz, R3.yzzx;
        DP4 R2.x, c10[3], R0;
        DP4 R2.y, c10[4], R0;
        DP4 R2.z, c10[5], R0;
        MOV R1.xyz, R3.xyzz;
        MOV R1.w, c0.w;
        DP4 R0.x, c10[0], R1;
        DP4 R0.y, c10[1], R1;
        DP4 R0.z, c10[2], R1;
        ADD R0.yzw, R0.xxyz, R2.xxyz;
        MUL R0.x, R3.y, R3.y;
        MAD R0.x, R3.x, R3.x, -R0.x;
        MAD R1.xyz, c10[6].xyzx, R0.x, R0.yzwy;
        MOV R1.w, c0.w;
        MOV R0, c28[0];
        MAD result.color.front.primary, R0, R1, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 3, 0, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0.5, 0, 0 };
TEMP R0, R1, R2, R3, R4;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R0.z, R2, R1, R0;
        MUL R1.w, R0.z, c0.y;
        ARL A0.x, R1.w;
        DP4 R1.x, c31[A0.x], v16;
        DP4 R1.y, c31[A0.x + 1], v16;
        DP4 R1.z, c31[A0.x + 2], v16;
        MOV result.fogcoord.x, R1.z;
        MOV R0.xyz, R1.xyzz;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        DP3 R0.y, c31[A0.x].xyzx, v18.xyzx;
        DP3 R0.z, c31[A0.x + 1].xyzx, v18.xyzx;
        DP3 R0.w, c31[A0.x + 2].xyzx, v18.xyzx;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R0.xyz, R0.x, R0.yzwy;
        MUL R2, R0.xyzz, R0.yzzx;
        DP4 R4.x, c10[3], R2;
        DP4 R4.y, c10[4], R2;
        DP4 R4.z, c10[5], R2;
        MOV R3.xyz, R0.xyzz;
        MOV R3.w, c0.w;
        DP4 R2.x, c10[0], R3;
        DP4 R2.y, c10[1], R3;
        DP4 R2.z, c10[2], R3;
        ADD R2.xyz, R2.xyzx, R4.xyzx;
        MUL R0.w, R0.y, R0.y;
        MAD R0.w, R0.x, R0.x, -R0.w;
        MAD R3.xyz, c10[6].xyzx, R0.w, R2.xyzx;
        MOV R3.w, c0.w;
        MOV R2, c28[0];
        MAD result.color.front.primary, R2, R3, c28[1];
        DP3 R0.w, R1.xyzx, R0.xyzx;
        MUL R0.w, c1.x, R0.w;
        MAD R0.yzw, -R0.w, R0.xxyz, R1.xxyz;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R0.xy, R0.x, R0.yzwy;
        MAD result.texcoord[0].xy, R0.xyxx, c1.y, c1.y;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

I'm guessing that at least one of these has turned my character into a Ringwraith.

These are the additional vertex programs that are run when leaving the character
selection screen, and entering the game proper:

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MOV result.fogcoord.x, c0.y;
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R2, R2, R1, R0;
        MUL R1.w, R2.y, c0.z;
        ARL A0.x, R1.w;
        MUL R0, c31[A0.x], v17.y;
        MUL R1.z, R2.z, c0.z;
        ARL A0.x, R1.z;
        MAD R0, c31[A0.x], v17.x, R0;
        MUL R1.y, R2.x, c0.z;
        ARL A0.x, R1.y;
        MAD R0, c31[A0.x], v17.z, R0;
        MUL R1.x, R2.w, c0.z;
        ARL A0.x, R1.x;
        MAD R0, c31[A0.x], v17.w, R0;
        DP4 R0.x, R0, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 1], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 1], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 1], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R2, c31[A0.x + 1], v17.w, R2;
        DP4 R0.y, R2, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 2], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 2], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 2], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R1, c31[A0.x + 2], v17.w, R2;
        DP4 R0.z, R1, v16;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        MOV R0, c28[0];
        ADD result.color.front.primary, R0, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END


!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R2, R2, R1, R0;
        MUL R1.w, R2.y, c0.z;
        ARL A0.x, R1.w;
        MUL R0, c31[A0.x], v17.y;
        MUL R1.z, R2.z, c0.z;
        ARL A0.x, R1.z;
        MAD R0, c31[A0.x], v17.x, R0;
        MUL R1.y, R2.x, c0.z;
        ARL A0.x, R1.y;
        MAD R0, c31[A0.x], v17.z, R0;
        MUL R1.x, R2.w, c0.z;
        ARL A0.x, R1.x;
        MAD R0, c31[A0.x], v17.w, R0;
        DP4 R0.x, R0, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 1], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 1], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 1], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R2, c31[A0.x + 1], v17.w, R2;
        DP4 R0.y, R2, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 2], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 2], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 2], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R1, c31[A0.x + 2], v17.w, R2;
        DP4 R0.z, R1, v16;
        MOV result.fogcoord.x, R0.z;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        MOV R0, c28[0];
        ADD result.color.front.primary, R0, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END


!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0.5, 0, 0 };
TEMP R0, R1, R2, R3, R4;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R1, R2, R1, R0;
        MUL R3.z, R1.y, c0.z;
        ARL A0.x, R3.z;
        MUL R0, c31[A0.x], v17.y;
        MUL R3.y, R1.z, c0.z;
        ARL A0.x, R3.y;
        MAD R0, c31[A0.x], v17.x, R0;
        MUL R3.x, R1.x, c0.z;
        ARL A0.x, R3.x;
        MAD R0, c31[A0.x], v17.z, R0;
        MUL R1.w, R1.w, c0.z;
        ARL A0.x, R1.w;
        MAD R2, c31[A0.x], v17.w, R0;
        DP4 R1.x, R2, v16;
        ARL A0.x, R3.z;
        MUL R0, c31[A0.x + 1], v17.y;
        ARL A0.x, R3.y;
        MAD R0, c31[A0.x + 1], v17.x, R0;
        ARL A0.x, R3.x;
        MAD R0, c31[A0.x + 1], v17.z, R0;
        ARL A0.x, R1.w;
        MAD R0, c31[A0.x + 1], v17.w, R0;
        DP4 R1.y, R0, v16;
        ARL A0.x, R3.z;
        MUL R4, c31[A0.x + 2], v17.y;
        ARL A0.x, R3.y;
        MAD R4, c31[A0.x + 2], v17.x, R4;
        ARL A0.x, R3.x;
        MAD R3, c31[A0.x + 2], v17.z, R4;
        ARL A0.x, R1.w;
        MAD R4, c31[A0.x + 2], v17.w, R3;
        DP4 R1.z, R4, v16;
        MOV result.fogcoord.x, R1.z;
        MOV R3.xyz, R1.xyzz;
        MOV R3.w, c0.w;
        DP4 result.position.x, c2[0], R3;
        DP4 result.position.y, c2[1], R3;
        DP4 result.position.z, c2[2], R3;
        DP4 result.position.w, c2[3], R3;
        DP3 R2.x, R2.xyzx, v18.xyzx;
        DP3 R2.y, R0.xyzx, v18.xyzx;
        DP3 R2.z, R4.xyzx, v18.xyzx;
        DP3 R0.x, R2.xyzx, R2.xyzx;
        RSQ R0.x, R0.x;
        MUL R0.xyz, R0.x, R2.xyzx;
        MUL R2, R0.xyzz, R0.yzzx;
        DP4 R4.x, c10[3], R2;
        DP4 R4.y, c10[4], R2;
        DP4 R4.z, c10[5], R2;
        MOV R3.xyz, R0.xyzz;
        MOV R3.w, c0.w;
        DP4 R2.x, c10[0], R3;
        DP4 R2.y, c10[1], R3;
        DP4 R2.z, c10[2], R3;
        ADD R2.xyz, R2.xyzx, R4.xyzx;
        MUL R0.w, R0.y, R0.y;
        MAD R0.w, R0.x, R0.x, -R0.w;
        MAD R3.xyz, c10[6].xyzx, R0.w, R2.xyzx;
        MOV R3.w, c0.w;
        MOV R2, c28[0];
        MAD result.color.front.primary, R2, R3, c28[1];
        DP3 R0.w, R1.xyzx, R0.xyzx;
        MUL R0.w, c1.x, R0.w;
        MAD R0.yzw, -R0.w, R0.xxyz, R1.xxyz;
        DP3 R0.x, R0.yzwy, R0.yzwy;
        RSQ R0.x, R0.x;
        MUL R0.xy, R0.x, R0.yzwy;
        MAD result.texcoord[0].xy, R0.xyxx, c1.y, c1.y;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

(In reply to comment #40)
Not sure about the return to login screen, this looks like a different bug than
the rest to me.
However, those vertex programs will not work.
ATTRIB v17 = vertex.weight;
MUL R0, c31[A0.x], v17.y;
They not only declare vertex.weight input (which is illegal and we now ignore)
but they also use that input - not sure what software mesa tnl does, but the
r200 driver never submits that array to the hardware. I could change that but I
don't think that mesa's tnl module actually imports those values. Or does this
work with software tcl?
<rant>WoW looks particularly stupid here. It uses mostly conventional attribs,
which is fine, and generic attrib 7, which is nice too as it never aliases a
conventional attrib. But instead of just using attrib 6 (which never aliases
neither) it uses that weight attribute belonging to a stupid extension noone
supports.</rant>
In an ideal world, you'd just go complain to blizzard, they should fix their code.

(In reply to comment #42)
> Not sure about the return to login screen, this looks like a different bug
> than the rest to me.

The login screen only fails again if I enter the game. I can go back from the
character selection screen without difficulty.

> However, those vertex programs will not work.
> ATTRIB v17 = vertex.weight;
> MUL R0, c31[A0.x], v17.y;
> They not only declare vertex.weight input (which is illegal and we now ignore)
> but they also use that input - not sure what software mesa tnl does, but the
> r200 driver never submits that array to the hardware.

I'm not sure what the ATI driver does with these programs, then...??! Is there
anything else I can try with this? (Does the NVIDIA driver support ARB vertex
programs?) I thought Mac users ran WoW in OpenGL mode, so if these vertex
programs are broken then they would all see these problems too?!

Can we patch the programs "on the fly"? Even if only to see what would happen?

(In reply to comment #42)
> Or does this work with software tcl?

With software TCL, I get the original "missing bits" bug back again. However,
there's still *sonething* missing from the login screen when I logout, although
it's not quite as empty as with the hardware TCL.

(In reply to comment #43)
> > but they also use that input - not sure what software mesa tnl does, but the
> > r200 driver never submits that array to the hardware.
> 
> I'm not sure what the ATI driver does with these programs, then...??! Is there
> anything else I can try with this? (Does the NVIDIA driver support ARB vertex
> programs?) I thought Mac users ran WoW in OpenGL mode, so if these vertex
> programs are broken then they would all see these problems too?!
Actually, those weight extensions are not that uncommon. It seems with mac os
ARB_vertex_blend is always supported. With pcs, ati supports it with fglrx, and
on some other os ati supports it on every card since rage128... Nvidia instead
support EXT_vertex_weighting since TNT's... So those vertex programs are indeed
legal with these drivers.
> Can we patch the programs "on the fly"? Even if only to see what would happen?
The programs itself aren't that much of a problem, but there are just some bits
missing in mesa when an app tries to use vertex weight array - there isn't even
a pointer available to access it in the vb struct (though the attrib pointer
should do), and it's completely missing from the array cache code. Not sure what
opinions others have to add code that can't be legally used...

Warcraft released a patch today (697 MB patch to bridge the gap between Warcraft
and Blizzard's new "The Burning Crusade" add-on), and so I tried reenabling
GL_ARB_vertex_program to see what would happen. Basically, the login screen is
broken again:

!!ARBvp1.0
PARAM c2 = { 2, 1, 3, 6.28319 };
PARAM c4 = { 0, 0.5, 1, 0 };
PARAM c5 = { 0.25, -9, 0.75, 0.159155 };
PARAM c6 = { 24.9808, -24.9808, -60.1458, 60.1458 };
PARAM c7 = { 85.4538, -85.4538, -64.9394, 64.9394 };
PARAM c8 = { 19.7392, -19.7392, -1, 1 };
PARAM c9 = { 0.00195313, 0.00260417, 0, 0 };
PARAM c3 = { 0, 0, 0, 0 };
TEMP R0, R1, R2, R3, R4, R5;
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v19 = vertex.color;
ATTRIB v16 = vertex.position;
PARAM c1 = program.local[1];
PARAM c0 = program.local[0];
        MOV result.position.xy, v16.xyyy;
        MOV result.position.z, c3.x;
        MOV R2, c2;
        MOV result.position.w, R2.y;
        ADD R1, v24.xyxx, -c9.xyxx;
        MOV result.texcoord[0].xy, R1;
        MAD R0.x, v19.x, R2.x, -R2.y;
        MAD R0.y, R0.x, R2.z, c0.x;
        RCP R0.x, R2.w;
        MUL R0.x, R0.y, R0.x;
        MAX R0.x, R0.x, -R0.x;
        FRC R0.x, R0.x;
        MUL R0.z, R0.x, R2.w;
        SLT R0.y, R0.y, c3.x;
        ADD R0.x, R2.y, -R0.y;
        MUL R0.x, R0.x, R0.z;
        MAD R0.x, R0.y, -R0.z, R0.x;
        MUL R4, c5.w, R0.x;
        FRC R0.w, R4.x;
        ADD R0.xyz, c4.xyzx, -R0.w;
        MUL R0.xyz, R0.xyzx, R0.xyzx;
        SLT R3.x, R0.w, c5.x;
        SGE R2.xyw, R0.w, c5.yzyy;
        MOV R3.yz, R2.xxyw;
        DP3 R3.y, R3.xyzx, c8.zwzz;
        MAD R2.xyz, c6.xyxx, R0.xyzx, c6.zwzz;
        MAD R2.xyz, R2.xyzx, R0.xyzx, c7.xyxx;
        MAD R2.xyz, R2.xyzx, R0.xyzx, c7.zwzz;
        MAD R2.xyz, R2.xyzx, R0.xyzx, c8.xyxx;
        MAD R2.xyz, R2.xyzx, R0.xyzx, c8.zwzz;
        DP3 R0.x, R2.xyzx, -R3.xyzx;
        ADD R5.xy, R4.x, -c5.x;
        FRC R5.y, R5.x;
        ADD R2.xyz, c4.xyzx, -R5.y;
        MUL R4.xyz, R2.xyzx, R2.xyzx;
        SLT R3.x, R5.y, c5.x;
        SGE R2.xyw, R5.y, c5.yzyy;
        MOV R3.yz, R2.xxyw;
        DP3 R3.y, R3.xyzx, c8.zwzz;
        MAD R2.xyz, c6.xyxx, R4.xyzx, c6.zwzz;
        MAD R2.xyz, R2.xyzx, R4.xyzx, c7.xyxx;
        MAD R2.xyz, R2.xyzx, R4.xyzx, c7.zwzz;
        MAD R2.xyz, R2.xyzx, R4.xyzx, c8.xyxx;
        MAD R2.xyz, R2.xyzx, R4.xyzx, c8.zwzz;
        DP3 R4.x, R2.xyzx, -R3.xyzx;
        MOV R0.y, R4.x;
        MUL R2.xy, R0.xyxx, c1.x;
        ADD R0, R1.xyxx, R2.xyxx;
        MOV result.texcoord[1].xy, R0;
        ADD R0, R0.xyxx, R2.xyxx;
        MOV result.texcoord[2].xy, R0;
        ADD result.texcoord[3].xy, R0.xyxx, R2.xyxx;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MOV result.fogcoord.x, c0.y;
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R2, R2, R1, R0;
        MUL R1.w, R2.y, c0.z;
        ARL A0.x, R1.w;
        MUL R0, c31[A0.x], v17.y;
        MUL R1.z, R2.z, c0.z;
        ARL A0.x, R1.z;
        MAD R0, c31[A0.x], v17.x, R0;
        MUL R1.y, R2.x, c0.z;
        ARL A0.x, R1.y;
        MAD R0, c31[A0.x], v17.z, R0;
        MUL R1.x, R2.w, c0.z;
        ARL A0.x, R1.x;
        MAD R0, c31[A0.x], v17.w, R0;
        DP4 R0.x, R0, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 1], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 1], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 1], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R2, c31[A0.x + 1], v17.w, R2;
        DP4 R0.y, R2, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 2], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 2], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 2], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R1, c31[A0.x + 2], v17.w, R2;
        DP4 R0.z, R1, v16;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        MOV R0, c28[0];
        ADD result.color.front.primary, R0, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R2, R2, R1, R0;
        MUL R1.w, R2.y, c0.z;
        ARL A0.x, R1.w;
        MUL R0, c31[A0.x], v17.y;
        MUL R1.z, R2.z, c0.z;
        ARL A0.x, R1.z;
        MAD R0, c31[A0.x], v17.x, R0;
        MUL R1.y, R2.x, c0.z;
        ARL A0.x, R1.y;
        MAD R0, c31[A0.x], v17.z, R0;
        MUL R1.x, R2.w, c0.z;
        ARL A0.x, R1.x;
        MAD R0, c31[A0.x], v17.w, R0;
        DP4 R0.x, R0, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 1], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 1], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 1], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R2, c31[A0.x + 1], v17.w, R2;
        DP4 R0.y, R2, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 2], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 2], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 2], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R1, c31[A0.x + 2], v17.w, R2;
        DP4 R0.z, R1, v16;
        MOV result.fogcoord.x, R0.z;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        MOV R0, c28[0];
        ADD result.color.front.primary, R0, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3, R4, R5, R6;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c28[2] = { program.env  [28..29] };
PARAM c17[11] = { program.env  [17..27] };
PARAM c10[7] = { program.env  [10..16] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R2, R2, R1, R0;
        MUL R0.w, R2.y, c0.z;
        ARL A0.x, R0.w;
        MUL R1, c31[A0.x], v17.y;
        MUL R0.z, R2.z, c0.z;
        ARL A0.x, R0.z;
        MAD R1, c31[A0.x], v17.x, R1;
        MUL R0.y, R2.x, c0.z;
        ARL A0.x, R0.y;
        MAD R1, c31[A0.x], v17.z, R1;
        MUL R0.x, R2.w, c0.z;
        ARL A0.x, R0.x;
        MAD R5, c31[A0.x], v17.w, R1;
        DP4 R1.x, R5, v16;
        ARL A0.x, R0.w;
        MUL R2, c31[A0.x + 1], v17.y;
        ARL A0.x, R0.z;
        MAD R2, c31[A0.x + 1], v17.x, R2;
        ARL A0.x, R0.y;
        MAD R2, c31[A0.x + 1], v17.z, R2;
        ARL A0.x, R0.x;
        MAD R4, c31[A0.x + 1], v17.w, R2;
        DP4 R1.y, R4, v16;
        ARL A0.x, R0.w;
        MUL R2, c31[A0.x + 2], v17.y;
        ARL A0.x, R0.z;
        MAD R2, c31[A0.x + 2], v17.x, R2;
        ARL A0.x, R0.y;
        MAD R2, c31[A0.x + 2], v17.z, R2;
        ARL A0.x, R0.x;
        MAD R0, c31[A0.x + 2], v17.w, R2;
        DP4 R1.z, R0, v16;
        MOV result.fogcoord.x, R1.z;
        MOV R2.xyz, R1.xyzz;
        MOV R2.w, c0.w;
        DP4 result.position.x, c2[0], R2;
        DP4 result.position.y, c2[1], R2;
        DP4 result.position.z, c2[2], R2;
        DP4 result.position.w, c2[3], R2;
        ADD R3.xyz, c17[4].xyzx, -R1.xyzx;
        DP3 R6.x, R3.xyzx, R3.xyzx;
        ADD R2.xyz, c17[5].xyzx, -R1.xyzx;
        DP3 R6.y, R2.xyzx, R2.xyzx;
        RSQ R1.z, R6.x;
        RSQ R1.w, R6.y;
        MUL R1.xy, R6.xyxx, R1.zwzz;
        MUL R1.xy, R1.xyxx, c17[9].xyxx;
        MAD R1.xy, R6.xyxx, c17[10].xyxx, R1.xyxx;
        ADD R6.xy, R1.xyxx, c17[8].xyxx;
        RCP R1.x, R6.x;
        RCP R1.y, R6.y;
        DP3 R5.x, R5.xyzx, v18.xyzx;
        DP3 R5.y, R4.xyzx, v18.xyzx;
        DP3 R5.z, R0.xyzx, v18.xyzx;
        DP3 R0.x, R5.xyzx, R5.xyzx;
        RSQ R0.x, R0.x;
        MUL R0.xyz, R0.x, R5.xyzx;
        DP3 R3.x, R3.xyzx, R0.xyzx;
        DP3 R3.y, R2.xyzx, R0.xyzx;
        MUL R1.zw, R3.xxxy, R1.zzzw;
        MAX R1.zw, R1.zzzw, c0.y;
        MUL R4.xy, R1.zwzz, R1.xyxx;
        MUL R1, R0.xyzz, R0.yzzx;
        DP4 R3.x, c10[3], R1;
        DP4 R3.y, c10[4], R1;
        DP4 R3.z, c10[5], R1;
        MOV R2.xyz, R0.xyzz;
        MOV R2.w, c0.w;
        DP4 R1.x, c10[0], R2;
        DP4 R1.y, c10[1], R2;
        DP4 R1.z, c10[2], R2;
        ADD R1.xyz, R1.xyzx, R3.xyzx;
        MUL R0.w, R0.y, R0.y;
        MAD R0.x, R0.x, R0.x, -R0.w;
        MAD R0.xyz, c10[6].xyzx, R0.x, R1.xyzx;
        MAD R0.xyz, c17[0].xyzx, R4.x, R0.xyzx;
        MAD R0.xyz, c17[1].xyzx, R4.y, R0.xyzx;
        MIN R0.xyz, c0.w, R0.xyzx;
        MAX R1.xyz, c0.y, R0.xyzx;
        MOV R1.w, c0.w;
        MOV R0, c28[0];
        MAD result.color.front.primary, R0, R1, c28[1];
        MOV result.texcoord[0].xy, v24.xyxx;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

!!ARBvp1.0
PARAM c0 = { 255.002, 0, 3, 1 };
PARAM c94 = { 0, 1, 0, 0 };
PARAM c1 = { 2, 0, 0, 0 };
TEMP R0, R1, R2, R3;
ADDRESS A0;
ATTRIB v25 = vertex.texcoord[1];
ATTRIB v24 = vertex.texcoord[0];
ATTRIB v7 = vertex.attrib[7];
ATTRIB v17 = vertex.weight;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;
PARAM c6[4] = { program.env  [6..9] };
PARAM c28[2] = { program.env  [28..29] };
PARAM c2[4] = { program.env  [2..5] };
PARAM c31[65]={program.env[31..95]};
        MOV result.fogcoord.x, c0.y;
        MUL R3, v7.zyxw, c0.x;
        FRC R0, R3;
        SLT R2, -R0, R0;
        SLT R1, R3, -R3;
        ADD R0, -R0, R3;
        MAD R2, R2, R1, R0;
        MUL R1.w, R2.y, c0.z;
        ARL A0.x, R1.w;
        MUL R0, c31[A0.x], v17.y;
        MUL R1.z, R2.z, c0.z;
        ARL A0.x, R1.z;
        MAD R0, c31[A0.x], v17.x, R0;
        MUL R1.y, R2.x, c0.z;
        ARL A0.x, R1.y;
        MAD R0, c31[A0.x], v17.z, R0;
        MUL R1.x, R2.w, c0.z;
        ARL A0.x, R1.x;
        MAD R0, c31[A0.x], v17.w, R0;
        DP4 R0.x, R0, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 1], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 1], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 1], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R2, c31[A0.x + 1], v17.w, R2;
        DP4 R0.y, R2, v16;
        ARL A0.x, R1.w;
        MUL R2, c31[A0.x + 2], v17.y;
        ARL A0.x, R1.z;
        MAD R2, c31[A0.x + 2], v17.x, R2;
        ARL A0.x, R1.y;
        MAD R2, c31[A0.x + 2], v17.z, R2;
        ARL A0.x, R1.x;
        MAD R1, c31[A0.x + 2], v17.w, R2;
        DP4 R0.z, R1, v16;
        MOV R0.w, c0.w;
        DP4 result.position.x, c2[0], R0;
        DP4 result.position.y, c2[1], R0;
        DP4 result.position.z, c2[2], R0;
        DP4 result.position.w, c2[3], R0;
        MOV R0, c28[0];
        ADD result.color.front.primary, R0, c28[1];
        DP4 result.texcoord[0].x, c6[0], v24;
        DP4 result.texcoord[0].y, c6[1], v24;
        MOV result.texcoord[0].zw, c94.xyxy;
        MOV result.texcoord[1].xy, v25.xyxx;
        MOV result.texcoord[1].zw, c94.xyxy;
END

I'm guessing that it's because now they are using vertex.weight here too, yes?

(In reply to comment #46)
> Warcraft released a patch today (697 MB patch to bridge the gap between Warcraft
> and Blizzard's new "The Burning Crusade" add-on), and so I tried reenabling
> GL_ARB_vertex_program to see what would happen. Basically, the login screen is
> broken again:
> I'm guessing that it's because now they are using vertex.weight here too, yes?
Yes, I guess so. I can try fixing that if noone objects putting code into mesa
which is essentially just bloat as it can't be legally used - shouldn't be that
difficult, just make sure the arrays get imported and pointers correctly
assigned I'd hope. A pity they didn't fix it in the patch...

(In reply to comment #47)
> A pity they didn't fix it in the patch...

But it's like you said - everyone else's drivers support GL_ARB_vertex_blend
anyway (or an equivalent) and so the programs are only illegal on Linux or *BSD.
And Blizzard doesn't officially support any of these platforms.

I just don't see Blizzard falling over itself to change working (if not
technically correct) code just for the sake of "better OpenGL conformance".

The patches that went in may be causing issues on the Radeon 7500:
http://forums.gentoo.org/viewtopic-t-521622-highlight-.html

(In reply to comment #49)
> The patches that went in may be causing issues on the Radeon 7500:
> http://forums.gentoo.org/viewtopic-t-521622-highlight-.html
Are you talking about the WoW patch now? There weren't any patches in mesa for
making WoW work better which would affect radeon 7500. It's hard to tell without
knowing what mesa version he previously used. Could be a problem with textures
(some fix went in some months ago for fixing GL_ALPHA and GL_LUMINANCE textures
in rare cases, though that shouldn't have broken anything, maybe dxtc trouble),
could be bogus texture coordinates, alpha blend, ...

Oh ok. I already asked him what his mesa version was, and I asked him to do a
git bisect. I just thought what he was experiencing was maybe a recent change.
So I'll wait for further info.

Well, Dizzutch upgraded to cvs I think as of Nov 22, which had the problem in
the screen shots. And he just tried 6.5.2 which fixed the problem. Not sure if
it was totally unrelated, but it is actually working now.
http://appdb.winehq.org/commentview.php?iAppId=1922&iVersionId=5606&iThreadId=16575

(In reply to comment #48)
> I just don't see Blizzard falling over itself to change working (if not
> technically correct) code just for the sake of "better OpenGL conformance".
That's not quite the only reason why it would be helpful. Should any new graphic
card companies bring out new cards, I can't really see them implementing "old
crap" in a new driver.
Anyway, I've looked at it a bit and after adding lots of copy & paste code (for
array import etc.), I stopped when I realized we'd also need new entries in the
dispatch table. I'm not going to mess with that just for the sake of some broken
app, even if it might be popular.

(In reply to comment #53)
> Should any new graphic card companies bring out new cards, I can't really see
> them implementing "old crap" in a new driver.

Oh, I can. Over 7 million Blizzard customers, all itching to boost their FPS
with the latest liquid-nitrogen-cooled global-warming graphics hardware (or
whatever). I doubt Blizzard is the only company with sloppy vertex code, either.
Any driver upgrade that broke someone's games would probably not go down well,
so I suspect that any hope that these extensions will just vanish one day will
be in vain.

Actually, I really don't see the problem with supporting GL_ARB_vertex_blend.
Everyone *is* still using it implicitly today. Needlessly, erroneously perhaps.
But using it, nonetheless. Maybe if other examples came to light...

> I'm not going to mess with [the dispatch table] just for the sake of some
> broken app, even if it might be popular.

OK, better put that in future Mesa release notes then. It will save people time
(as well as forcing them to use fglrx). In fact, this applies to *all* Mesa
drivers now doesn't it, not just the ATI ones?

(In reply to comment #54)
> Any driver upgrade that broke someone's games would probably not go down well,
> so I suspect that any hope that these extensions will just vanish one day will
> be in vain.
> 

Actually, I can see something like what Roland said happening in the future.
Right now it seems both Nvidia and ATI are both pushing to remove old "legacy"
code from their "unified" drivers for "legacy" cards. Even ATI is removing R200.
It may be possible that with a new card or driver release that it will
disappear. I believe blizzard would conform when a driver causes breakage.
Actually, I think ATI or NVidia would notify them before a release would occur.

It is obviously true, that convincing blizzard to do anything about it without a
driver breaking on a supported platform is slim.

(In reply to comment #55)
> Right now it seems both Nvidia and ATI are both pushing to remove old "legacy"
> code from their "unified" drivers for "legacy" cards. Even ATI is removing
> R200.

Yes, ATI removed support for legacy *cards*. But that's a different issue from
removing legacy OpenGL extensions, particularly since it means that for R200
owners there is now only one driver choice - Mesa.

> It may be possible that with a new card or driver release that it will
> disappear. I believe blizzard would conform when a driver causes breakage.
> Actually, I think ATI or NVidia would notify them before a release would
> occur.

I don't claim to understand the exact relationship between games companies and
hardware companies, but there are more games companies that graphics companies
and all the games companies would need to stop using something before it could
be removed from a driver.

> It is obviously true, that convincing blizzard to do anything about it without 
> a driver breaking on a supported platform is slim.

Yes, so now I have the following choices:
- Buy an entirely new graphics card that fglrx supports (e.g. X1650 AGPx8?). But
that would be a "loss" for Free Software.
- Wait for Blizzard to do something - although its last patch made things worse,
not better, and so I'm not expecting anything to happen any time soon.
- Scan the WoW executable / data files for the slim chance that the vertex
programs are in clear-text, and then hack them myself somehow - which might just
break Blizzard's EULA.
- Run without GL_ARB_vertex_program enabled (which is what I do now),
effectively downgrading my R200 to an R100 or something.

I happen to have a Radeon 9550 card lying around, but even if Mesa did support
this card as well as the Radeon 9200 series, the r300_dri.so would surely choke
on the vertex programs as badly as the r200_dri.so driver does. And similarly
for any i965-based hardware too.

(In reply to comment #56)
> - Wait for Blizzard to do something - although its last patch made things worse,
> not better, and so I'm not expecting anything to happen any time soon.
> - Scan the WoW executable / data files for the slim chance that the vertex
> programs are in clear-text, and then hack them myself somehow - which might just
> break Blizzard's EULA.
It's not the vertex programs as such which really make problems, so it wouldn't
work. And I'd bet they'd have some anti-cheat code in there anyway.

> - Run without GL_ARB_vertex_program enabled (which is what I do now),
> effectively downgrading my R200 to an R100 or something.
> 
> I happen to have a Radeon 9550 card lying around, but even if Mesa did support
> this card as well as the Radeon 9200 series, the r300_dri.so would surely choke
> on the vertex programs as badly as the r200_dri.so driver does. And similarly
> for any i965-based hardware too.
Indeed. To give some background why it's problematic to fix up, the vertex
programs really aren't all that hard to fix. We already have that small hack to
just ignore the error if a vertex program tries to use the weight input. That's
basically all that's needed, the drivers just need to make sure this input gets
routed correctly. But the trouble really is with how the data gets into mesa. To
make use of that vertex weight, the application _has to_ now call one of the
vertex blend functions to supply the data (either glWeight or more likely
glWeightPointerARB). Mesa simply doesn't have any code to deal with those, there
are not even entries in the dispatch table.
Oh, and I'm not sure how this works on other hw. ARB_vertex_blend seems to be
implemented _only_ by ATI (at least announced only by ATI drivers), Nvidia
implements EXT_vertex_weighting, but unless I missed some other extensions it
can't be used since the VertexWeight functions accept only 1 value, and the
vertex programs show it's using 4 components. Intel has no support for either
extension. No idea what the heck WoW is doing there, I hope for them they don't
use different code solely based on renderer string...

(In reply to comment #57)
> Oh, and I'm not sure how this works on other hw. ARB_vertex_blend seems to be
> implemented _only_ by ATI (at least announced only by ATI drivers), Nvidia
> implements EXT_vertex_weighting, but unless I missed some other extensions it
> can't be used since the VertexWeight functions accept only 1 value, and the
> vertex programs show it's using 4 components.

I'm guessing that WoW will use GL_NV_vertex_program over GL_ARB_vertex_program,
if it detects it, and that WoW uses different vertex programs for each
extension. Can Mesa hardware-accelerate NV vertex programs using ATI hardware?
I'm thinking that these two vertex program languages have different syntaxes,
but do basically the same things.

> Intel has no support for either [ARB_vertex_blend or EXT_vertex_weighting]
> extension.

And ironically, that is a hopeful sign. Has the i965 made its way into Macs yet?
I'm assuming that this chipset supports GL_ARB_vertex_program at the very least,
and Mac *is* a supported platform.

(In reply to comment #58)
> I'm guessing that WoW will use GL_NV_vertex_program over GL_ARB_vertex_program,
> if it detects it, and that WoW uses different vertex programs for each
> extension. Can Mesa hardware-accelerate NV vertex programs using ATI hardware?
> I'm thinking that these two vertex program languages have different syntaxes,
> but do basically the same things.
They have the same syntax, just some subtle differences. You can enable the
extension with driconf, and just remove the test for IsNVProgram in
r200_vertprog.c (of course it's there for a reason, depending what the vertex
program does this may or may not work correctly).
I can't really see a reason why WoW would prefer NV_vp over ARB_vp though. It is
possible it uses NV_vp only when it detects nvidia hardware (by whatever means),
or if other nv specific extensions (for instance for fragment shading) are
detected. Again, I can't see a reason why it would do this however.

> > Intel has no support for either [ARB_vertex_blend or EXT_vertex_weighting]
> > extension.
> 
> And ironically, that is a hopeful sign. Has the i965 made its way into Macs yet?
> I'm assuming that this chipset supports GL_ARB_vertex_program at the very least,
> and Mac *is* a supported platform.
As said, it seems on Macs ARB_vertex_blend is a required extension, so no help
from there...

(In reply to comment #59)
> I can't really see a reason why WoW would prefer NV_vp over ARB_vp though.
> It is possible it uses NV_vp only when it detects nvidia hardware (by whatever
> means),

I'm thinking that any NV_vp code might not use vertex.weight, thus explaining
why EXT_vertex_weighting doesn't need to provide the 4 inputs for NVIDIA cards
that would be required for the given ARB_vp samples.

But NVIDIA hardware would probably be no more complicated than detecting
NV_vertex_program, wouldn't it? Does ATI's fglrx driver support
NV_vertex_program? WoW is obviously oblivious to Mesa...

> As said, it seems on Macs ARB_vertex_blend is a required extension, so no help
> from there...

Oh, so Intel would need to implement ARB_vertex_blend for any i965 driver for
the Mac anyway? Nuts.

(In reply to comment #59)
> As said, it seems on Macs ARB_vertex_blend is a required extension, so no help
> from there...

Do you mean that everyone writing OpenGL games for the Mac *must* support
ARB_vertex_blend? Doesn't this mean that Apple *requires* that this extension
not become obsolete, then? Because if this is the case, ATI couldn't drop it
even if it desperately wanted to.

On the Mac, Quartz Extreme is used for almost everything.  This is "hardware
accelerated" OpenGL.

Every OS-level window is an OpenGL texture.

(In reply to comment #56)
> (In reply to comment #55)
> > Right now it seems both Nvidia and ATI are both pushing to remove old "legacy"
> > code from their "unified" drivers for "legacy" cards. Even ATI is removing
> > R200.
> 
> Yes, ATI removed support for legacy *cards*. But that's a different issue from
> removing legacy OpenGL extensions, particularly since it means that for R200
> owners there is now only one driver choice - Mesa.
> 

Yes, but I've seen Nvidia remove extensions before. If ARB_vertex_blend makes no
sense for the current cards, they can remove it completely. Obviously what is
going on the Mac platform is critical. How can we be sure that Mac OS X uses the
extension in the GUI?

Can someone check to see if WoW actually calls glWeight or glWeightPointerARB?
Maybe someone could check what would happen if ARB_vertex_blend or
EXT_vertex_weighting is disabled too. Also, can someone spoof the OpenGL
versions strings to make WoW think there is an Nvidia card?

(In reply to comment #63)
> Yes, but I've seen Nvidia remove extensions before. If ARB_vertex_blend makes no
> sense for the current cards, they can remove it completely.

Except that ARB_vertex_blend is currently implemented for ATI cards, not NVIDIA
ones.

FWIW, I've checked the missing bits to the r200 driver for submitting vertex
weights. At least for the login screen, WoW only appears to use immediate mode
glWeight, so it actually just works without further mesa changes. If it tries to
use glWeightPointerARB later on, I'm not quite sure what would happen, it would
probably segfault. I'm not quite sure what the login screen should look like
exactly, but it appears r200 hw renderer is now more correct than sw tnl, there
seems to be a bug there.

(In reply to comment #65)
> FWIW, I've checked the missing bits to the r200 driver for submitting vertex
> weights.

Thanks for doing that.

> I'm not quite sure what the login screen should look like exactly, but it
> appears r200 hw renderer is now more correct than sw tnl, there seems to be
> a bug there.

I attached two more screenshots. It's an improvement and nothing seg-faults, but
there are still artifacts and pieces missing.

Created attachment 8096 [details]
Login screen with GL_ARB_vertex_program enabled

There are three small artifacts (that I can see) here: two yellow blobs on
either side of the archway, and a harder-to-spot purple blob above the yellow
blob on the left. (Just above the left pillar, on the lintel.)

Created attachment 8097 [details]
Character selection screen, ARB_vertex_program enabled

My character seems to have at least partly exited the Ringwraiths' shadow
realm.

Here are all the "ARB" references that the strings program can find in the WoW
executable:

$ strings WoW.exe | grep ARB
wglQueryPbufferARB
wglDestroyPbufferARB
wglReleasePbufferDCARB
wglGetPbufferDCARB
wglCreatePbufferARB
WGL_ARB_pbuffer
wglChoosePixelFormatARB
wglGetPixelFormatAttribivARB
WGL_ARB_pixel_format
wglGetExtensionsStringARB
CGxDeviceOpenGl::CreatePoolAPI(): glGenBuffersARB() failed!
GL_ARB_point_sprite
glPointParameterfvARB
glPointParameterfARB
GL_ARB_point_parameters
glGetQueryObjectuivARB
glGetQueryObjectivARB
glGetQueryivARB
glEndQueryARB
glBeginQueryARB
glDeleteQueriesARB
glGenQueriesARB
GL_ARB_occlusion_query
GL_ARB_texture_rectangle
GL_ARB_multisample
GL_ARB_texture_cube_map
glProgramEnvParameter4fvARB
glDisableVertexAttribArrayARB
glEnableVertexAttribArrayARB
glVertexAttribPointerARB
GL_ARB_vertex_program
glGetProgramivARB
glIsProgramARB
glGenProgramsARB
glDeleteProgramsARB
glProgramLocalParameter4fvARB
glBindProgramARB
glProgramStringARB
GL_ARB_fragment_program
GL_ARB_texture_env_combine
glUnmapBufferARB
glMapBufferARB
glBufferSubDataARB
glBufferDataARB
glGenBuffersARB
glDeleteBuffersARB
glBindBufferARB
GL_ARB_vertex_buffer_object
glCompressedTexSubImage2DARB
glCompressedTexImage2DARB
GL_ARB_texture_compression
glClientActiveTextureARB
glActiveTextureARB
GL_ARB_multitexture
OPTION ARB_fog_exp2;
OPTION ARB_fog_exp;
OPTION ARB_fog_linear;
!!ARBfp1.0

And here are all the "Weight" references:

$ strings WoW.exe | grep Weight
WeightVector
Weight

So no (obvious) reference to either glWeight or glWeightPointerARB. Is there
another way of filling this array?

Created attachment 8098 [details]
Actually, the character screen looks like this now!

Oops! I had left GL_NV_vertex_program enabled when I attached those last two
screen shots showing the login artifacts and the partially rendered character.
The character selection screen actually looks like this now! (Seems perfect to
me :-).)

I can't progress to the game proper yet because of a Wine bug, but will keep
you posted...

(In reply to comment #70)
> (Seems perfect to me :-).)

On closer study, it's not *quite* perfect. Other characters are showing curious
gaps at their elbows and waist, giving them the appearance of having
free-floating forearms etc. The software-rendered versions still look fine, though.

(In reply to comment #69)
> So no (obvious) reference to either glWeight or glWeightPointerARB. Is there
> another way of filling this array?
Yes there is. In fact it's impossible that WoW could use either glWeight or
glWeightPointer, I didn't really look because I just thought that's how it
works. It does not.
WoW uses glVertexAttribPointerARB to set the weight vertex array! Now as far as
I can tell according to the aliasing rules, this is wrong, implementations MAY
alias generic and conventional attributes, but this is not required and the spec
states that setting generic attributes will leave the corresponding conventional
attribute undefined. In fact, aliasing is _forbidden_ if a driver also
implements ARB_vertex_shader. Mesa in fact does not alias, but it seems to work
because it assigns the same AttribPtr to the undefined conventional arrays as to
the corresponding generic arrays (in _tnl_constant_attrib).

Created attachment 8204 [details]
Floating forearms with hardware vertex programs?

This image shows the only remaining issue that I have found so far with the
hardware vertex programs. Basically, there is a gap at each elbow on the
character here. Other characters have different gaps in the rendering, and
these gaps don't appear if I disable GL_ARB_vertex_program.

I have now experienced a few GPU lock-ups with hardware vertex programs enabled,
although I can't think of any way to narrow the problem down.

Hi,

I see that there have been some exciting changes in the R200 DRI driver. I'd go grab them and try them out, except... I have been building a lot of XOrg servers recently, and have discovered that they use the Mesa sources to build correctly! So can you tell me how XOrg and Mesa are related, please? Is it "safe" to be running an X server that has been built against (say) Mesa 6.5.1, and then go install the git versions of r200_dri.so, libGL.so, libGLU.so etc?

Cheers,
Chris

(In reply to comment #75)
> I see that there have been some exciting changes in the R200 DRI driver. I'd go
> grab them and try them out, except... I have been building a lot of XOrg
> servers recently, and have discovered that they use the Mesa sources to build
> correctly! So can you tell me how XOrg and Mesa are related, please? Is it
> "safe" to be running an X server that has been built against (say) Mesa 6.5.1,
> and then go install the git versions of r200_dri.so, libGL.so, libGLU.so etc?
This is safe in general, with very few exceptions, the interfaces rarely change in incompatible ways. One such change would have been the glx protocol number change of the tfp extension, but even then this only affected aiglx. The built-in mesa version in the xserver doesn't really matter for direct rendering. You typically can update the dri driver alone, but if you don't have a recent enough libGL it will not work correctly, but apart from that you don't need to update any other libs for just getting a new dri driver (not that it should hurt either).
Note the vbo changes could speed up WoW, but YMMV. The title screen looked ok for me at least...

(In reply to comment #76)
> This is safe in general, with very few exceptions, the interfaces rarely
> change in incompatible ways.

> The built-in mesa version in the xserver doesn't really matter for direct
> rendering.

I guess the part which worries me the most is this:

# lsof /usr/lib/dri/r200_dri.so
COMMAND  PID USER  FD   TYPE DEVICE     SIZE    NODE NAME
Xorg    2991 root mem    REG    3,3 14277710 5657877 /usr/lib/dri/r200_dri.so

It makes me worry whether the new r200_dri.so would be compatiable with the X-server.

*Sigh*, I can't test the latest Mesa any more. I tried replacing r200_dri.so, libGL.so.1.2 and libGLU.so.1 with the latest versions but even glxinfo crashed the X-server immediately. So it looks like even FC6's version of XOrg isn't new enough any more. Maybe I'll have better luck when I upgrade to FC7...?

As an aside, how much more hardware acceleration is left to be squeezed out of the R200? I'm getting about 10-15 fps in WoW without either VPs or VBOs right now, and it's very playable. Enabling VPs with my current r200_dri.so makes the game feel sluggish - I don't know why. I was wondering if this might be fixed by the recent "don't calculate fog for everything" patch I saw go sailing past. There are also gaps in the rendering on the character selection screen, but maybe a recent patch has fixed that too?

The WoW forum for Wine users recommends that fglrx users turn GL_ARB_vertex_buffer_object off "for performance reasons". A comment on Blizzard's OpenGL code, I believe... ;-).

(In reply to comment #78)
> *Sigh*, I can't test the latest Mesa any more. I tried replacing r200_dri.so,
> libGL.so.1.2 and libGLU.so.1 with the latest versions but even glxinfo crashed
> the X-server immediately. So it looks like even FC6's version of XOrg isn't new
> enough any more. Maybe I'll have better luck when I upgrade to FC7...?
Not sure why it wouldn't work. Make sure that both the new libGL and dri driver are picked up, the default location may have changed. That r200_dri.so is shown in-use by Xorg must be because of aiglx btw.

> As an aside, how much more hardware acceleration is left to be squeezed out of
> the R200? I'm getting about 10-15 fps in WoW without either VPs or VBOs right
> now, and it's very playable. Enabling VPs with my current r200_dri.so makes the
> game feel sluggish - I don't know why. I was wondering if this might be fixed
> by the recent "don't calculate fog for everything" patch I saw go sailing past.
There are no driver-specific fixes which would really improve performance. But the vbo code IME really can make a difference. In theory, fixed function tnl and vertex programs should likely have similar performance on a r200-based chip, as long as the application doesn't use more complicated rendering (since the execution units are after all the same on the chip I would guess).

> There are also gaps in the rendering on the character selection screen, but
> maybe a recent patch has fixed that too?
Unless it was some bug with vertex submission (not very likely), I don't think so.

> The WoW forum for Wine users recommends that fglrx users turn
> GL_ARB_vertex_buffer_object off "for performance reasons". A comment on
> Blizzard's OpenGL code, I believe... ;-).
There is likely not that much of a performance difference with the r200 driver. I'm surprised that it would be faster without it with fglrx though, unless those comments relate to older fglrx drivers which were known to have problems with that. It would also be possible the game does not make good use of ARB_vbo (e.g. something like only use every buffer once for drawing) but that would be a bit surprising.

(In reply to comment #79)
> Not sure why it wouldn't work. Make sure that both the new libGL and
> dri driver are picked up, the default location may have changed.
/usr/lib/dri/ ?

> That r200_dri.so is shown in-use by Xorg must be because of aiglx btw.
Yes, I believe that it is.

Do you have any theories about why these rendering gaps are appearing at the elbows, please?
https://bugs.freedesktop.org/attachment.cgi?id=8204

> There are no driver-specific fixes which would really improve performance.
So no more GL_... extensions just waiting to be backed up with hardware support? Cool. Does that mean that Mesa's R200 support is now complete? I have never successfully used this card with fglrx, so have no basis of comparison.

Too bad the XvMC support is a non-starter ;-).

(In reply to comment #80)
> (In reply to comment #79)
> > Not sure why it wouldn't work. Make sure that both the new libGL and
> > dri driver are picked up, the default location may have changed.
> /usr/lib/dri/ ?
Not sure. In any case, you could always use LIBGL_DRIVERS_PATH to override.

> > That r200_dri.so is shown in-use by Xorg must be because of aiglx btw.
> Yes, I believe that it is.
It might be possible this causes problems (especially if a different dri driver is picked up by aiglx and direct rendering), you could try disabling it.

> Do you have any theories about why these rendering gaps are appearing at the
> elbows, please?
> https://bugs.freedesktop.org/attachment.cgi?id=8204
Unfortunately no. It's not impossible this changes with the vbo code (just unlikely probably...)

> > There are no driver-specific fixes which would really improve performance.
> So no more GL_... extensions just waiting to be backed up with hardware
> support? Cool. Does that mean that Mesa's R200 support is now complete? I have
> never successfully used this card with fglrx, so have no basis of comparison.
Well, in terms of extensions it is pretty complete. If you look at extensions which made it into core opengl 1.4 and 1.5, EXT_multi_draw_arrays is missing. I'm pretty sure you could just enable it and it will work (might not have been the case with the now-removed vtxfmt code), though I don't think it's used very often. Another one missing is ARB_occlusion_query (for all r100/r200/r300 drivers), which is annoying to implement. That's basically it, the others the chip can't do (depth textures / shadow). Well OTOH the driver supports even some rare OGL 2.0 features (point sprites, separate blend equations). What it could do (and should help performance at least in some cases) is implement its own draw_prims function alongside real ARB_vbo support. Support of ARB_pbo is in theory also possible.

> Too bad the XvMC support is a non-starter ;-).
Well, as long as Xv is working this is usually quite useable.

I have discovered that the reason that X was crashing when I upgraded Mesa was that the Xserver wanted a different version of r200_dri.so than the client. So I have kept the server's version in /usr/lib/dri and forced the client to pick up its version from /usr/X11R6/lib/modules/dri via the environment variable.

And suddenly, my Warcraft avatars are being rendered without gaps :-) !! The frustrating thing about this is that enabling GL_ARB_vertex_program *costs* me about 4 FPS, so I'm still better off without it...! And I can't enable GL_ARB_vertex_buffer_object either because this triggers a bug in WoW with the text-rendering, although it does give me about 1 FPS back.

I'll play with GL_ARB_vertex_program enabled for a while to see if the crashes reoccur, but I'm hoping that we can soon close this bug. Then I'll just have to hope Blizzard optimizes its OpenGL code...

> The frustrating thing about this is that enabling GL_ARB_vertex_program *costs*
> me about 4 FPS, so I'm still better off without it...!

4 FPS is cheap considering that ATI has not released enough documentation to accelerate it . AFAIK GL_ARB_vertex_program is still done in software on r200.

(In reply to comment #83)
> 4 FPS is cheap considering that ATI has not released enough documentation to
> accelerate it . AFAIK GL_ARB_vertex_program is still done in software on r200.

Hmm, that wasn't my understanding. I thought that recent Mesa *was* accelerating vertex programs via the R200 hardware.

(In reply to comment #84)
> (In reply to comment #83)
> > 4 FPS is cheap considering that ATI has not released enough documentation to
> > accelerate it . AFAIK GL_ARB_vertex_program is still done in software on r200.
> 
> Hmm, that wasn't my understanding. I thought that recent Mesa *was*
> accelerating vertex programs via the R200 hardware.
That's certainly correct (unless you're using back facing colors or exceed the hw limits in one way or another). It is possible that WoW indeed does more complicated rendering when using ARB_vp, even if it doesn't really seem to look much different. There could be other reasons why it's a bit slower (for instance there's no optimizer for r200 vertex programs, and too many parameter uploads might be triggered, though I've no idea how much you could gain by improving that).

(In reply to comment #85)
>> That's certainly correct (unless you're using back facing colors or exceed the
> hw limits in one way or another).

I don't suppose the driver has a way of telling you if it exceeds one of these limits?

> there's no optimizer for r200 vertex programs

Would this optimizer be part of the hardware and not supported by Mesa, or do you mean that the R200 hardware has no optimizer, period?

(In reply to comment #86)
> (In reply to comment #85)
> >> That's certainly correct (unless you're using back facing colors or exceed the
> > hw limits in one way or another).
> 
> I don't suppose the driver has a way of telling you if it exceeds one of these
> limits?
It should if you use R200_DEBUG=fall (it's not very likely to hit a fallback in real life I guess).

> > there's no optimizer for r200 vertex programs
> 
> Would this optimizer be part of the hardware and not supported by Mesa, or do
> you mean that the R200 hardware has no optimizer, period?
No I meant that the driver does not optimize the programs. For example rescheduling instructions might be necessary (so an instruction reading a temp does not follow immidiately the one writing that temp) to get optimal performance, or things like eliminating swizzle instructions (since the hw can do that for free) could be useful. Other optimizations like analyses of live/dead registers would be nice too (that one could take place outside the hw specific driver), to avoid fallbacks due to not enough temps (AFAIK there's no direct performance hit though for using more temp registers than necessary, as long as you still have enough, unlike on some hw from another vendor).
Usually games tend to be performance limited somewhere in the pixel stage rather than vertex transform though (just increase/decrease the resolution and look if performance scales (near) linearly).

(In reply to comment #82)
> I have discovered that the reason that X was crashing when I upgraded Mesa was
> that the Xserver wanted a different version of r200_dri.so than the client. So
> I have kept the server's version in /usr/lib/dri and forced the client to pick
> up its version from /usr/X11R6/lib/modules/dri via the environment variable.

If you had to change the version used by the X server, this may indicate that indirect rendering is being used. Make sure the performance critical apps are using direct rendering.

(In reply to comment #88)
> If you had to change the version used by the X server, this may indicate that
> indirect rendering is being used. Make sure the performance critical apps are
> using direct rendering.

The Xorg.0.log file suggests that the problem is the AIGLX support in the X server, which I believe is accelerated indirect rendering. So I've left the X-server's r200_dri.so in /usr/lib/dri and have set the LIBGL_DRIVERS_PATH environment variable to point elsewhere for my user account.

My machine rebooted itself while playing WoW with GL_ARB_vertex_program enabled the other night. However, I can't say for certain that the graphics driver was responsible yet. (My 2.6.20.1 kernel has scheduling issues, there was a memory leak in the VBO code and possibly memory corruption in the /sys reference counting too.)

$ git bisect log
git-bisect start
# bad: [61ec23cc63a040a2edf1bc466917e85362514c89] fix for bug#10196
git-bisect bad 61ec23cc63a040a2edf1bc466917e85362514c89
# good: [d85667950f6797f63fa0863e6882390c2adaaf2b] remove a if-statement
git-bisect good d85667950f6797f63fa0863e6882390c2adaaf2b
# good: [d2b06403c6f06ee37f46c2a504983884382c8abc] i915tex: Fix performance regression with new vbo code and latest drm.
git-bisect good d2b06403c6f06ee37f46c2a504983884382c8abc
# good: [d2b06403c6f06ee37f46c2a504983884382c8abc] i915tex: Fix performance regression with new vbo code and latest drm.
git-bisect good d2b06403c6f06ee37f46c2a504983884382c8abc

Using git-reset to go back to the last revision that builds successfully doesn't help me refine the search any further.

D*mm*t!!!! That last comment should have been for #10265!

I updated Mesa from december's git to as of last weekend. My problem with Warcraft III looks like it has been fixed sometime in the last 3 months. I can no longer reproduce it. Chris are you still having issues?

(In reply to comment #92)
> I updated Mesa from december's git to as of last weekend. My problem with
> Warcraft III looks like it has been fixed sometime in the last 3 months. I can
> no longer reproduce it. Chris are you still having issues?

Heh, I was thinking about this bug too. WoW now appears to render correctly with GL_ARB_vertex_program enabled, so I guess this bug is now fixed.

Mass version move, cvs -> git