Intel HD 5000 : glEnableVertexAttribArrayARB via GLEW does not work

[MSpar2]

I've just moved to the new Mac Air with HD 5000, and found the code I am developing in C++/OpenGL no longer renders normal mapped 3D geometry using pixel shaders.

It makes use of glEnableVertexAttribArrayARB to supply a tangent to the pixel shader pipeline. This process works perfectly well on nVidia and ATI graphic cards, and still works (as is) on my old Mac Air with nVidia 320M

The result is the model geometry is rendering as a corrupted model, in a spherical arrangement with a radius of 1.0

I can achieve the same results on the nVidia / ATI cards by using the same pixel shader, but by failing to provide the tangent data it expects - this results in the same corruption when rendering.

So - it seems on HD 5000, the driver is not honouring GLEW's glEnableVertexAttribArrayARB extension. Has it been remapped for the HD5000, or is there another way to bind to this functionality?

Note. I am not using OpenGL 4.0 - my code needs to support OpenGL 2.1, and has worked flawlessly so far on many other devices and GPU's. no

Thanks in advance!

[Kevin_M_Intel]

Hello Maksw,

Please note that based on an agreement between Apple and Intel, all the support, including warranty and information, will be provide by Apple only.

Due to this, I recommend you contacting Apple in order to get the support for your Mac unit.

[MSpar2]

Cheers for the prompt response kevin_intel.

I forgot to point out the incredibly important bit... this is on Windows 7, using the latest Windows 7 HD 5000 driver.

The HD driver supplied by Apple with their Boot Camp drivers showed this problem in Windows 7. I then updated the W7 driver using the Intel HD website to download and install, and still the problem exists.

I suspect the resolution is quite simple - either a software tweak on my side, or within GLEW for windows - but I'm hopeful if the HD driver needs adjusting then a future Windows update won't be out of the question?

I can help provide any diagnostics / testing to resolve the issue - I'm an experienced software engineer and games dev, and I'm used to chasing down issues like this when they occur. It's quite sad to move from the old mac air to a far more powerful graphics solution and see it crippled in this way (I've had to disable normal mapping in my engine for this machine) so I'm very keen to help with a resolution.

If it means waiting on Apple - then it will never happen - I have plenty of experience in dealing with them with major iOS related issues that sadly never get dealt with.

Fingers crossed!

[MSpar2]

Hi there - any progress on this? as to whether it's something that might be addressed in the W7 driver?

Right now all my models are rendering jet black, despite being lit and with normal mapping disabled... not really what I'd expected when purchasing this hardware...

Cheers,

Malc.

[Kevin_M_Intel]

Hello Maksw,

I am afraid to say that since you have a Mac computer, all the support on the unit is provided by the system manufacturer based on an agreement between Intel® and Apple. This also includes hardware and software besides the warranty on the unit.

At this point, you need to contact Apple to get the support for the unit.

[MSpar2]

Hi Kevin,

sorry to labour this point - but I'm a bit non-plussed and want to be ultra-sure on this.

You're saying Apple are responsible for providing technical support for Intel's own HD drivers for Windows 7? As downloaded directly from Intel's website?

[Kevin_M_Intel]

Hello Maksw,

1. Correct.

Based on an agreement between Apple and Intel, all the support needed on an Apple unit will be provided by Apple only.

[MSpar2]

Lawks - sorry to be so persistent Kevin - I'm just gobsmacked that this would affect the Intel drivers downloaded direct from your site. I can understand the one's which Apple provide via Boot Camp.

Thanks for being patient - I'll try Apple, but there's no chance of this getting sorted with them

Cheers anyway!

[Kevin_M_Intel]

Hello Maksw,

It is important to say that Apple is the one who provides support for their units based on an agreement between Intel® and Apple; however, we are very concerned on checking into this issue to see if it´s an universal driver problem.

Can you please post here the name of the application and the openGL Code you are trying? If you can post screenshots will be very useful.

[MSpar2]

That's good to hear Kevin - I can't send over the application itself as it's massive (a game in development).

Code wise will be tricky as it's deep inside my engine code. But the bolts of it is that doing this ;

given struct tv3 { float f[3] ; }given tv3* tangents ;// code to enable the array for OpenGL shaders to use ......glVertexAttribPointerARB(0, 3, GL_FLOAT, 0, sizeof(tv3), &tangents); glEnableVertexAttribArrayARB(0) ;...glDrawElements(GL_TRIANGLES, numVertices, GL_UNSIGNED_SHORT, &vertIndices) ;...//vertex GLSL shader...attribute vec3 vTangent;...

works fine on nvidia/ati - but on the HD5000, the call

glVertexAttribPointerARB(0, 3, GL_FLOAT, 0, sizeof(tv3), &tangents); glEnableVertexAttribArrayARB(0) ;

results in the GLSL vertex shader

attribute vec3 vTangent

being given garbage, or nothing - I can't tell which. This results in a 0.0 -> 1.0 "ball" of geometry instead of the actual model. I'll try and pin some screenshots up in a subsequent reply.

[Kevin_M_Intel]

Hi Maksw,

I am sorry for the delay on coming back to you. The issue has been identified and here are the corrections:

1. Corrections in the shader code:

51 vec4 diffuseMaterial = 0.0; should be vec4(0.0)

52 vec4 diffuseLight = 0.0; should be vec4(0.0)

…

70 diffuseMaterial = pow(texture2D (diffuseTexture, gl_TexCoord[0].st),2.0) should be vec4(2.0)

75 specularMaterial = pow(texture2D (specularTexture, gl_TexCoord[0].st),2.0); should be vec4(2.0)

1. tangentLoc was uninitialized (it refers to local not initialized mdObject member)

it should be initialized in load() function :

void md5Object::load() {

tangentLoc = Engine::engine->creatureShader->tangentLoc ;

1. Missing calls to set the default VBO and enable the vertex attribute array

glBindBufferARB(GL_ARRAY_BUFFER_ARB,0);

glEnableVertexAttribArrayARB(tangentLoc);

glDisableVertexAttribArrayARB(tangentLoc);

Let us know the result.

[MSpar2]

Thank you for taking the time to investigate this so thoroughly kevin_intel, it's appreciated.

Sadly, none of the suggestions apply to the original issue - all shader values are correct and initialised, as is the vertex attribute array. VBO's are not used.

I think the tutorial has probably sidetracked the issue instead of helping as I'd hoped. Although I actually do get the 'loss of diffuse' on HD5000 as well the tutorial, the primary problem is that with tangents being supplied by enabling vertex attribute arrays using glEnableVertexAttribArrayARB(...) the geometry just collapses on HD5000 only.

Here is what happens when enabling the tangents array using glEnableVertexAttribArrayARB(0)...

So there, it's actually placing all the vertices in the geometry onto the surface of a unit sphere of radius 1.0f

Now, with the exact same rendering code and shaders - but removing all calls to glEnableVertexAttribArrayARB(...)

The geometry is no longer affected - however, the same shaders no longer have the tangent space normals they need to provide normal mapping.

[Kevin_M_Intel]

Maksw thanks for the information but at this point, I recommend you contacting Apple for further support on your system.

[AXEL_M_Intel1]

What this looks like is that the GL is using the tangents as position.

This is probably be due to the historical aliasing of Vertex Attrib 0 and the Vertex Position (back when vertex attrib was introduced, and because of how the specification special-cased glVertex as provoking).

Try to bind the attribute to a different location with glBindAttribLocation to see if that is indeed what is happening.

[MSpar2]

AxelM - this resolved the corrupt geometry - fantastic pointer, thank you! I set the attrib location to 1 and the model renders as expected.

@Intel - for me this proves your driver is aliasing Vertex Attrib 0 as the vertex position as AxelM cites - whereas ATI and nVidia appear not. I'm not sure which is the correct behavior - but it's worth checking.

So - if this attrib location is arbitrary across GL drivers / hardware, how can one determine the right value to use at run-time given different driver support?

[HGree3]

Came here from Google, thought I'd post my own "intel ball" here as well

Running OS X Mavericks on Intel HD Graphics 3000. I get different kinds of garbage after switching different vertex attribs on and off, occasionally when leaving just the position attrib I get the correct geometry rendered. I will try to mess with glBindAttribLocation as per AxelM's suggestion to try and workaround this. Also not seeing anything wrong when running this code on an Nvidia GPU.