[Bug 6997] New: Execution of glDrawArrays (drawStridedFast) takes 1 second +

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=6997

Summary: Execution of glDrawArrays (drawStridedFast) takes 1
                    second +
           Product: Wine
           Version: 0.9.28.
          Platform: PC
               URL: http://www.download.com/Need-for-Speed-Most-Wanted-
                    demo/3000-7534_4-10459687.html
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wine-directx-d3d
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Need for Speed: Most Wanted Demo, earliest wine version tested: 0.9.19 (but only
with GLSL, ARB can't handle some opcodes yet with 0.9.19)

The game is incredibly slow right at startup, i.e. also the loading screen, if
video options are not set to the lowest possible, with both GLSL and ARB shaders.

Debug output reveals that the call to glDrawArrays (for 4 vertices) in
drawStridedFast sometimes takes more than a second to return, I measured this
with RDTSC, sometimes its fast, sometimes it's just stuck for a while and
glGetError gives 0x502 (GL_INVALID_OPERATION) (The error is not reported when
using GLSL, it's still slow, though).

Further, glTexEnvf(GL_POINT_SPRITE, GL_COORD_REPLACE, FALSE) (state_pointsprite)
also gives error 0x502 several times, continuously. (both GLSL and ARB).

ARB shaders give an error:
err:d3d_shader:shader_hw_sample Unexpected texture type 0
fixme:d3d_shader:IWineD3DPixelShaderImpl_GenerateShader HW PixelShader Error at
position 474: "line 24, column 26:  error: invalid texture target type\n"
GLSL shaders don't report any errors.

Apparently, shader_get_registers_used doesn't set the respective
reg_maps->samplers variable for the sampler, it would do so if I added a
(WINED3DSIO_TEXREG2AR == curOpcode->opcode) condition to the part of the
function where it checks other TEX* opcodes ... but, since I'm not so familiar
with the code and shader assembly etc. doing this might as well be nonsense, and
it doesn't actually resolve the slowness bug.

In GLSL, removing the texture2D calls in the pixelshaders does away with the
slowness so might it have something to do with texture access, samplers?

I'll attach a debug log (WINEDEBUG="wine_d3d,d3d,d3d_shader,d3d_draw") ... have
fun :-)