NVIDIA releases OpenGL 4.0 drivers

[AlexN]

I didn't report this one, but it looks like 197.44 fixes a GLSL bug where breaking out of a for loop would increment the loop counter an additional time.

[oscarbg]

197.44 don't expose GL_ARB_gpu_shader_fp64 on a gtx 275..
Is Nvidia going in future to expose double precision extension GL_ARB_gpu_shader_fp64 on gtx 280 cards supporting doubles on CUDA?
Also forcing it I get:
0(5) : warning C7547: extension GL_ARB_gpu_shader_fp64 not supported in profile
gp4fp

[CrazyButcher]

sweet, any ETA for Cg support on NV_gpu_program5 and related?

[Prune]

Is EXT_direct_state_access orthogonal w.r.t. ARB_texture_multisample? I don't see a glTextureImage2DMultisampleEXT in glew...

[Alfonse Reinheart]

You can't expect the extension to be updated for every extension that comes out. Even though it has been updated to some since its initial release, but even that caused versioning problems with extension loaders.

In short, no. DSA does not have that function.

[Chris Lux]

Hi,
while reworking some of my texture binding functionality i noticed a bug in the latest OpenGL 3.3 and 4.0 beta drivers (197.44) with binding sampler objects.

When running on a last generation card (FX5800 in my case) and a OpenGL 3.3 context the following way to bind a sampler object fails with GL_INVALID_VALUE:

glBindSampler(0, _sampler_id);

This is the exact way to do it according to the spec. Doing it like with texture objects works fine:

glBindSampler(GL_TEXTURE0, _sampler_id);

However when running the same code on a GTX 480 with the same driver also on a 3.3 context works as expected and the second way correctly throws the invalid value error.

Regards
-chris

[Alfonse Reinheart]

Yeah, there's a thread about this. NVIDIA (and the ARB) is aware of the problem and will have a fix in their next driver revision.

[Chris Lux]

ok, i did not see that thread. i think the info that it works both ways in nvidia drivers depending on what hardware you run it is new .

[pbrown]

ok, i did not see that thread. i think the info that it works both ways in nvidia drivers depending on what hardware you run it is new .

There shouldn't be any difference in BindSampler behavior on NVIDIA GPUs between hardware versions, GeForce/Quadro, or OpenGL context versions. The first 3.3 driver did erroneously accept TEXTURE0 as described in the thread linked by Alphonse.

My guess is that your FX5800 was actually running with the older OpenGL 3.3-only driver (197.15?). Maybe something like the following happened?

* plug in GeForce GTX 480
* install 197.44
* everything works as expected
* replace with Quadro FX 5800
* after reboot, Windows plug-n-play ends up using the 197.15 driver, which accepts only TEXTURE0

I have seen something like this happen to me in the past, though I'm not sure how such a situation arises.

[Chris Lux]

There shouldn't be any difference in BindSampler behavior on NVIDIA GPUs between hardware versions, GeForce/Quadro, or OpenGL context versions. The first 3.3 driver did erroneously accept TEXTURE0 as described in the thread linked by Alphonse.

My guess is that your FX5800 was actually running with the older OpenGL 3.3-only driver (197.15?). Maybe something like the following happened?

* plug in GeForce GTX 480
* install 197.44
* everything works as expected
* replace with Quadro FX 5800
* after reboot, Windows plug-n-play ends up using the 197.15 driver, which accepts only TEXTURE0

I have seen something like this happen to me in the past, though I'm not sure how such a situation arises.

you are right, the machine i put the FX5800 in was actually running 197.15. it is not my main development machine so i did not catch that. thanks!