Catalyst 9.1 is out

[blabub]

Well, it'll work for the current EVE Premium client. I just tried the Apocrypha client and it failed to compile one of the shaders.

Where I can get the beta? Google is not willing to tell it me.


The normal client runs now perfect! Thanks so much!

[poofyyoda]

No such luck here on Command and Conquer 3, HD4650 - catalyst 9.1, wine 1.1.15

gazillions of these:

fixme:d3d_shader:shader_glsl_select >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUseProgramObjectARB @ glsl_shader.c / 3584
fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawElements @ drawprim.c / 276

I turn shader detail up, then the in-game lags severely and shader-applied objects disappear.

[poofyyoda]

Also tried the Crysis demo (a bit optimistic maybe)

insane corruption of course and:

fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1130: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supported "
fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1135: "Fragment shader was successfully compiled to run on hardware.\nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supporte"
fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1133: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supportedWARNING: built-in varying gl_TexCoord [5] has mismatched access semantics between the vertex and fragment shader\nWARNING: built-in varying gl_TexCoord [5] has mismatched access semanti"...

lots of stuff like this with the shader # increasing through the log.


glxinfo claims that GL_ARB_draw_buffers is a supported OpenGL extension however...
I think AMD should look at GL_ARB_draw_buffers, and their GLSL support in the driver.

[hpestilence]

http://www.eveonline.com/ingameboard...hreadID=998390 How to install

http://www.eveonline.com/ingameboard...readID=1001885
Is the patch for the Singularity copy your Program Files/CCP/EVE installation to EVE2. The patch will ask which directory to install in. Copy the RTP file elsewhere or the patcher will delete it if it errors out then copy back to try again. I've went through GB's of bandwidth because the new patcher doesn't work as nice as the old one.



fixme:d3d_shaderrint_glsl_info_log Error received from GLSL shader #1130: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supported " is just a warning whenever the extension is called into the shader seems to work though.

The easiest way to debug shader issues is to run a game with:
WINEDEBUG="d3d_shader" wine game.exe &> gameshaders.log

It creates some big log files though so make sure you have space for them. For eve-online I get about 100 - 200 MB logs. Then searching for "INVALID" should bring you to the first opengl error and scrolling up from that look for shaders that weren't successfully compiled or linked.

Looks like the shaders for Crysis are compiled and linked successfully since there isn't any GL_INVALID_OPERATION. Not sure what's with the corruption though.

[hpestilence]

So I worked around that shader compile error (I put in a value of 512 to be safe, a 8800gts can do 1024 and my card outperforms a 8800gtx) for the Apocrypha client and still didn't get any models the only error I seem to get is the same as the crysis one.

fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supportedWARNING: built-in varying gl_TexCoord [5] has mismatched access semantics between the vertex and fragment shader\nWARNING: built-in varying gl_TexCoord [5] has mismatched access semanti"...

For some reason wine is getting that I support only this

trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_SHADER float constants: 128
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_SHADER float constants: 128

If you subtract the few that wine uses it comes to 107.

while a 8800gts reports it can do this

trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_SHADER float constants: 1024
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_SHADER float constants: 512

PS: I'm suspecting that these values are wrong or something, the 2147483647 value doesn't make sense and a 8800gts has higher values.

trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM float constants: 256  <-- this might be correct
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM native temporaries: 256  <-- 8800gts supports 4096
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM native instructions: 2147483647  <-- 8800gts supports 8192
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM float constants: 256  <-- this might be correct
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM native temporaries: 256  <--  8800gts supports 4096
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM native instructions: 2147483647 <-- 8800gts supports 8192
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_SHADER float constants: 128  <-- 8800gts supports 1024 and this is the cause of the shader failing to compile
trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_SHADER float constants: 128  <-- 8800gts supports 512

[tarzan]

Does anyone use fglrx with a Radeon 3450 in a Lenovo T400? This driver acts strange... Once i use an external monitor i am unable to switch back to LVDS only. Console switching also does not work.

[Henri]

At first glance the Apocrypha issue looks like an error in the shader source code. This line :

trace:d3d_shader:shader_addline GL HW (2, 13) : uniform vec4 VC[107];

... defines the VC array with 107 elements, yet :

trace:d3d_shader:shader_addline GL HW (23, 513) : gl_Position.x = (dot(R1.xyzw, VC[224].xyzw));
trace:d3d_shader:shader_addline GL HW (24, 559) : gl_Position.y = (dot(R1.xyzw, VC[225].xyzw));
trace:d3d_shader:shader_addline GL HW (25, 605) : gl_Position.z = (dot(R1.xyzw, VC[226].xyzw));
trace:d3d_shader:shader_addline GL HW (26, 651) : gl_Position.w = (dot(R1.xyzw, VC[227].xyzw));

... seem to use the 224th through 227th elements of that array, and then :

trace:d3d_shader:shader_addline GL HW (36, 1156) : R0.xyz = (-R1.xyz + VC[223].xyz);

accesses the 223rd element. Those are the 5 lines rejected by the shader compiler, but they *do* seem like they should be rejected. Anyone more familiar with GLSL want to jump in here ?

The size of the VC array is based on the amount of available uniforms. Ie, on a card with 512 uniforms (= 128 vec4's) available, we subtract 4 for posFixup, 16 for bool constants, and 4*16 for integer constants to end up with 428 uniforms for floating point constants, which gives 107 vec4's.

We could potentially skip subtracting the integer and bool constants if the shader doesn't use them, but that won't help much here. It looks like the shader simply expects 256 float constants to be available (which is not unreasonable for a SM3.0 shader, vs_3_0 requires 256 float constants). Iow, you'd require about 1024 uniforms to run this shader.

I wouldn't be surprised if the number of reported uniforms is simply wrong and the driver reports the number of available vec4's rather than the number of available uniforms. The number for ARB_VERTEX_PROGRAM being larger than the one for ARB_VERTEX_SHADER is a pretty strong hint this is the case.