PDA

View Full Version : Official NVIDIA OpenGL 3.0 beta driver thread



barthold
08-14-2008, 11:07 AM
We've posted OpenGL 3.0 beta drivers here:

http://developer.nvidia.com/object/opengl_3_driver.html

Note that you'll also need nvemulate to turn on OpenGL 3.0:

http://developer.nvidia.com/object/nvemulate.html

This will run on G80 and up only, since OpenGL 3.0 requires G80 class hardware.

Use this thread to discuss driver specific issues only please. Make a new thread, or use an existing one, for general OpenGL 3.0 questions. Finally, a friendly request. Please leave any non-constructive comments out, it really is not going to help anything.

Thanks, and happy coding!

Barthold
With my NVIDIA hat on

weyrauch
08-14-2008, 01:44 PM
Any idea on when we can expect an Linux OpenGL 3.0 driver?

-rw

timmy79
08-14-2008, 04:15 PM
Thanks Nvidia for the quick release.

For any newbies wanting to play with GL 3 don't forgot to do something like this to get a GL 3 context:

int attribs[3];
attribs[0] = WGL_CONTEXT_MAJOR_VERSION_ARB;
attribs[1] = 3;
attribs[2] = 0; //terminate first pair

WGL_CONTEXT_MINOR_VERSION_ARB defaults to 0 anyway so no need to specify that one.

wglCreateContextAttribsARB(hdc,hglrc,attribs);

Happy coding.

ATI if you are reading, hurry up and stop shafting the GL community.

dpoon
08-14-2008, 05:31 PM
If you're running under Vista make sure you run the nvemulate tool as administrator.

Mars_999
08-14-2008, 09:06 PM
Will those drivers work with a mobile 9500GS card? My Asus laptop has a 9500GS, and I sold my desktop to get ready to build my new Intel i7 quad core desktop powerhouse!! ;)

timmy79
08-14-2008, 09:14 PM
They should work with a 9500gs according to NVidia.

3B
08-17-2008, 09:54 AM
Found 2 possible bugs with the 3.0 VAOs in the 177.89 drivers:

Main one is that calling glDisableVertexAttribArray(1); with no VAO bound breaks any existing VAOs that had attrib 1 active with a pointer set.

small test case, using glfw2.6 modified to use a gl3 context :


#include <stdio.h>
#include <GL/glfw.h>
#include "glext.h"

PFNGLGENBUFFERSPROC glGenBuffers = 0;
PFNGLBINDBUFFERPROC glBindBuffer = 0;
PFNGLBUFFERDATAPROC glBufferData = 0;
PFNGLGENVERTEXARRAYSAPPLEPROC glGenVertexArrays = 0;
PFNGLBINDVERTEXARRAYAPPLEPROC glBindVertexArray = 0;;
PFNGLDISABLEVERTEXATTRIBARRAYPROC glDisableVertexAttribArray = 0;
PFNGLENABLEVERTEXATTRIBARRAYPROC glEnableVertexAttribArray = 0;
PFNGLVERTEXATTRIBPOINTERPROC glVertexAttribPointer = 0;

PFNGLCREATEPROGRAMPROC glCreateProgram = 0;
PFNGLCREATESHADERPROC glCreateShader = 0;
PFNGLSHADERSOURCEPROC glShaderSource = 0;
PFNGLCOMPILESHADERPROC glCompileShader = 0;
PFNGLATTACHSHADERPROC glAttachShader = 0;
PFNGLBINDATTRIBLOCATIONPROC glBindAttribLocation = 0;
PFNGLLINKPROGRAMPROC glLinkProgram = 0;
PFNGLDELETESHADERPROC glDeleteShader = 0;
PFNGLUSEPROGRAMPROC glUseProgram = 0;

void init_extensions() {
glGenBuffers = glfwGetProcAddress("glGenBuffers");
glBindBuffer = glfwGetProcAddress("glBindBuffer");
glBufferData = glfwGetProcAddress("glBufferData");
glGenVertexArrays = glfwGetProcAddress("glGenVertexArrays");
glBindVertexArray = glfwGetProcAddress("glBindVertexArray");
glDisableVertexAttribArray = glfwGetProcAddress("glDisableVertexAttribArray");
glEnableVertexAttribArray = glfwGetProcAddress("glEnableVertexAttribArray");
glVertexAttribPointer = glfwGetProcAddress("glVertexAttribPointer");

glCreateProgram = glfwGetProcAddress("glCreateProgram");
glCreateShader = glfwGetProcAddress("glCreateShader");
glShaderSource = glfwGetProcAddress("glShaderSource");
glCompileShader = glfwGetProcAddress("glCompileShader");
glAttachShader = glfwGetProcAddress("glAttachShader");
glBindAttribLocation = glfwGetProcAddress("glBindAttribLocation");
glLinkProgram = glfwGetProcAddress("glLinkProgram");
glDeleteShader = glfwGetProcAddress("glDeleteShader");
glUseProgram = glfwGetProcAddress("glUseProgram");
}

const float cube[] = {-1.0, -1.0, -1.0,
-1.0, -1.0, 1.0,
-1.0, 1.0, -1.0,
-1.0, 1.0, 1.0,
1.0, -1.0, -1.0,
1.0, -1.0, 1.0,
1.0, 1.0, -1.0,
1.0, 1.0, 1.0, };

const int cubei[] = {0, 6, 4,
0, 2, 6,
0, 3, 2,
0, 1, 3,
2, 7, 6,
2, 3, 7,
4, 6, 7,
4, 7, 5,
0, 4, 5,
0, 5, 1,
1, 5, 7,
1, 7, 3,};

unsigned int vao = 0;
unsigned int program = 0;

// attrib indexes other than 1 don't trigger crash
#define ATTRIB 1

void fill_buffers() {
unsigned int i=0,v=0;

glGenBuffers(1, &amp;v);
glGenBuffers(1, &amp;i);

glBindBuffer(GL_ARRAY_BUFFER, v);
glBufferData(GL_ARRAY_BUFFER, 24*sizeof(float), cube, GL_STATIC_DRAW);

glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, 0);

glEnableVertexAttribArray( ATTRIB );
glVertexAttribPointer(ATTRIB, 3, GL_FLOAT, 0, 3*sizeof(float), 0);

glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, i);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, 36*sizeof(int), cubei, GL_STATIC_DRAW);
}


int main( void )
{
int width, height;

glfwInit();

glfwOpenWindow( 640, 480, 0,0,0,0, 0,0, GLFW_WINDOW );

init_extensions();

glfwGetWindowSize( &amp;width, &amp;height );
glViewport( 0, 0, width, height );

glGenVertexArrays(1, &amp;vao);
glBindVertexArray(vao);
fill_buffers();

//*** DrawElements below crashes if both of these lines are here :
glBindVertexArray(0); //***
glDisableVertexAttribArray( ATTRIB ); //***

glBindVertexArray(vao);
glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_INT, 0);

glfwSwapBuffers();

// crashes on exit if we leave vao bound
glBindVertexArray(0);

glfwTerminate();
return 0;
}

Only attrib 1 seems to be a problem, no crashes with any others.

Other possible bug is that the above code crashes if the vao is still bound when it exits.

-b-

jeffb
08-17-2008, 07:30 PM
Hi 3B,

Coincidentally, I found the same crash bug yesterday internally at NVIDIA. It'll be fixed in an upcoming release. I haven't been able to reproduce the crash at exit you mentioned. If you can provide a win32 executable that reproduces it, I'll give it a spin. Thanks.

HollanErno
08-18-2008, 04:20 AM
Will GL 3.0 driver support the 8600M GT? I tried to install under WinXP the driver on a Acer 5929g with the above mentioned card but the installation refused to continue.

Thanks

Chris Lux
08-18-2008, 05:57 AM
Will GL 3.0 driver support the 8600M GT? I tried to install under WinXP the driver on a Acer 5929g with the above mentioned card but the installation refused to continue.
mobile support is almost always missing from the drivers installer, but the driver itself does support the hardware. you just have to edit the nv4_disp.inf file of the driver setup to support your card/chip. look at the driver inf files at laptopvideo2go.com for the additional lines (PCI id etc.) but i recommend not using the infs from there as they modified to much in there making the drivers completely useless in some regards.

Hampel
08-18-2008, 06:21 AM
Would it also be possible to use this driver with and Apple MacBook Pro with an 8600M GT running Vista32 (with the inf-mod mentioned above)?

Zengar
08-18-2008, 06:46 AM
Would it also be possible to use this driver with and Apple MacBook Pro with an 8600M GT running Vista32 (with the inf-mod mentioned above)?

Why shouldn't it be possible?

3B
08-18-2008, 08:48 AM
I haven't been able to reproduce the crash at exit you mentioned. If you can provide a win32 executable that reproduces it, I'll give it a spin.

ok, http://www.3bb.cc/tmp/vao-exit-crash.zip is a binary of previous program chopped down to just the exiting with vao bound bit:


#include <stdio.h>
#include <GL/glfw.h>
#include "glext.h"

PFNGLGENVERTEXARRAYSAPPLEPROC glGenVertexArrays = 0;
PFNGLBINDVERTEXARRAYAPPLEPROC glBindVertexArray = 0;;

int main( int argc, char ** argv )
{
unsigned int width, height, vao;

glfwInit();

glfwOpenWindow( 640, 480, 0,0,0,0, 0,0, GLFW_WINDOW );

glGenVertexArrays = glfwGetProcAddress("glGenVertexArrays");
glBindVertexArray = glfwGetProcAddress("glBindVertexArray");

glfwGetWindowSize( &amp;width, &amp;height );
glViewport( 0, 0, width, height );

glGenVertexArrays(1, &amp;vao);
glBindVertexArray(vao);

if ( argc > 1 ) glBindVertexArray(0);

return 0;
}


compiled with gcc version "(GCC) 4.2.1-sjlj (mingw32-2)".

When run with an argument it binds VA 0 before exiting, and doesn't crash.
With no argument it leaves the VAO bound, and crashes.

jeffb
08-18-2008, 10:05 PM
Thanks 3B, I've reproduced the crash and will get it fixed for the next release.

Dark Photon
08-20-2008, 06:51 AM
Thanks 3B, I've reproduced the crash and will get it fixed for the next release.
Any word on when we'll have Linux drivers? I'd love to help beat on the GL3 support with our multinode NVidia systems, but without Linux support, not much I can do...

ultimA
08-23-2008, 09:17 AM
I have a 7600gs (driver ver. 177.89, xp sp3). VAO entry points can only be retreived using the "ARB" ending in their names. According to the extension specification issue #6, this is false and function names of this extension should not have the ARB ending.

Rosario Leonardi
08-23-2008, 08:55 PM
I have a 7600gs (driver ver. 177.89, xp sp3). VAO entry points can only be retreived using the "ARB" ending in their names.
Yep, same problem with GeForce8800gts (windows Xp 32)

ultimA
08-24-2008, 01:21 AM
I'm not sure if this is a bug since I've have found no trace of the GL_ARB_framebuffer_object extension specification. However, glGenerateMipmapEXT was part of GL_EXT_framebuffer_object, and since glGenerateMipmap is part of the OpenGL3.0 spec and is not deprecated, I assume there should be a glGenerateMipmap(ARB) entry point in the presence of GL_ARB_framebuffer_object. There is no such entrypoint with or without "ARB" ending.

7600gs, 177.89, xp sp3 32

Rob Barris
08-24-2008, 08:27 AM
ARB_fbo is still in the middle of its 30-day review period by the Khronos promoter companies. Assuming all goes well I would anticipate seeing it posted to the registry within a week or two.

elFarto
08-29-2008, 02:29 AM
Any word on when we will be getting a driver with EXT_direct_state_access?

Regards
elFarto

Brolingstanz
09-11-2008, 06:46 PM
Suppose I create a GL3 context with a GL2 context as the hShareContext. If this call succeeds, should I be able to use the programs previously created in the GL2 space with the new GL3 context?

Korval
09-11-2008, 07:44 PM
Suppose I create a GL3 context with a GL2 context as the hShareContext. If this call succeeds, should I be able to use the programs previously created in the GL2 space with the new GL3 context?

Yes, if the call succeeds, you should be able to use previously created objects in the new context.

Now, whether the call will succeed (especially in 3.1 if they remove the deprecated stuff)...

Brolingstanz
09-11-2008, 08:31 PM
The call succeeds but I'm getting an INVALID_VALUE the moment I try to bind one of the programs in the new context (glIsProgram returns false).

If I defer program creation to after the 3.0 context is created, all is right with the world (this seems like a good strategy).

Korval
09-11-2008, 08:43 PM
Well, it is a beta. File a bug on it.

Brolingstanz
09-14-2008, 01:58 PM
I'm getting an invalid enum on GetIntegerv with MAJOR_VERSION, but only the first time I make the call. In all cases the values returned for both major and minor seem random.

[8800 GTS, Vista x86 SP1]

3B
09-26-2008, 02:32 PM
Do newer drivers have any GL3 support?
I'm trying the 178.13 released yesterday, but not getting WGL_ARB_create_context in the WGL extension string or any other sign of it working, even with it enabled in nvemulate.

Korval
09-26-2008, 06:12 PM
Do newer drivers have any GL3 support?

If they did, I'm sure nVidia would have told you.

They currently have 3.0 beta drivers, and that's all.

Dark Photon
09-30-2008, 07:39 AM
Do newer drivers have any GL3 support?

If they did, I'm sure nVidia would have told you.

They currently have 3.0 beta drivers, and that's all.
And only for Windows (not Linux).

Looking for new ones on Linux both for GL3 and since the more recent ones have an alleged fix for the PBO 46MB upload stall.

3B
09-30-2008, 09:23 AM
Using 177.89 drivers in gl3 mode, glBindRenderbuffer seems to only accept renderbuffer names which have been returned from glGenFramebuffers instead of those returned from glGenRenderbuffers.

for example:


glGenRenderbuffers(1,&amp;rb);
glBindRenderbuffer(GL_RENDERBUFFER,rb);
gives GL_INVALID_OPERATION
but


glGenFramebuffers(1,&amp;rb);
glBindRenderbuffer(GL_RENDERBUFFER,rb);
runs with no errors.

Korval
09-30-2008, 11:49 AM
Sounds like a bug (hence the Beta). File a bug report on it.

barthold
10-24-2008, 04:20 PM
All,

Linux drivers are now available for download, as well as an update to the Windows drivers.

http://developer.nvidia.com/object/opengl_3_driver.html

New features:

* Linux support - OpenGL 3.0 and GLSL 1.30 functionality support between the Linux and Windows releases are identical.
* Now allows rendering to a FBO with mixed-size attachments
* VAO bug fixes and performance improvements
* EXT_texture_swizzle support
* Transform feedback missing functionality is implemented
* Various other bug fixes

Barthold
(with my NVIDIA hat on)

Jan
10-24-2008, 06:27 PM
What's EXT_texture_swizzle ? Never heard of it before (and google neither, apparently).

V-man
10-24-2008, 07:58 PM
The link is on the same page
http://developer.download.nvidia.com/opengl/specs/GL_EXT_texture_swizzle.txt

Timinator
10-28-2008, 08:11 AM
For those that are looking to run on mobile versions, I've used this with good success: http://www.driverheaven.net/nvmodtool.php

One thing to mention though is that in the past, the driver installation would put the temporary files into C:\NVIDIA\... making it easy to modify. With this new version, however, it appears they've moved the location of these files, and they get deleted if the drivers don't support your card (which is the case with most mobile devices). I did a bit of exploring and found that it places the driver files in a folder located in "C:\Documents and Settings\UserName\Local Settings\Temp\..." (In my case the folder was called "WZSE0.TMP", but I don't know if that would be the same for everyone).

To get this to work you have to start the installation, and when the "NVIDIA Setup Error" dialog box pops up saying you don't have supported hardware, don't click "OK", but go find the folder and copy it to some other location.

barthold
12-16-2008, 08:39 PM
The NVIDIA OpenGL 3 drivers are no longer in beta. Release drivers, with all OpenGL 3.0 features implemented, for both Windows and Linux, are here:

http://developer.nvidia.com/object/opengl_3_driver.html

Barthold
(with my NVIDIA hat on)

M/\dm/\n
12-17-2008, 02:48 PM
I noticed news about the new driver at techreport.com today. Great news!

I haven't been coding GL stuff for like 2 years, but I'm definitely going to try out the new features as soon as I can.

I also like the EXT_direct_state_access idea a lot. The old state management is a bloody mess. I hope this extension, or something like it, gets promoted to core real soon.

HellRaiZer
12-17-2008, 11:55 PM
Hi and sorry for posting in this thread, but since the new driver includes new extensions for GL 2.1, i thought it would be the appropriate place to ask.

Are there any plans on supporting GL_ARB_instanced_arrays (http://www.opengl.org/registry/specs/ARB/instanced_arrays.txt) on GL 2.1 hardware (SM3.0)?

Thanks. If this isn't the correct place to ask this, please say it i'll create a new thread.

HellRaiZer

Groovounet
12-18-2008, 04:24 AM
It's not the only OpenGL 3.0 feature missing ...
No map_buffer_range ... hummm It's still the time of the messy drivers that claim to be what they are not and make feature detection so scary and random. :p Anyway still I can rely on extensions strings that's ok but it would be so nice to just check the OpenGL version.

HellRaiZer
12-18-2008, 05:53 AM
If you mean this one (http://www.opengl.org/registry/specs/ARB/map_buffer_range.txt), then it is included in the latest (181.00) drivers even on my old 7950.

HellRaiZer

Groovounet
12-18-2008, 06:11 AM
Great! :)

I didn't see the entry point for glMapBufferRange in glView but this look like a bug I guest.

I pretty sure that GL_ARB_instanced_arrays will be implemented, Michael Gold worked on it, it would make sense ^_^

Timothy Farrar
12-24-2008, 12:49 PM
I'm currently using the 180.11.02 drivers for Linux-64 and it seems as if a lot of the GL3 stuff is missing from the header files? I tried downloading and installing the windows 180 driver on XP and it didn't seem to install GL3 headers either? I'm I all wet here, or where are the correct headers? Figured others might have this answer.

Stuff like the RG texture formats #defines are missing. Also glMapBufferRange() is missing. Is missing or I'm just being stupid somehow :) Filed nvdev bug report for this.

Writing to gl_FragDepth and user defined fragment outs (I'm using FP16 RGBA multiple render targets) at the same time is failing for me (get error message and bad shader output). Writing to user defined fragment outs alone works. Writing to gl_FragDepth and resorting to writing to gl_FragData[] solves the problem. Filed bug on this as well, but posted this here in case anyone else needs a workaround...

I've got workarounds for all the problems I've found, many of which are to just move back to older GL2+EXT code but still use the GL3 driver. So I'm happy to wait a little until proper fixes get into the core driver.

Brolingstanz
12-24-2008, 01:12 PM
Last I checked in glext.h MapBufferRange was missing a '*' on the void* return value...

Timothy Farrar
12-31-2008, 08:19 AM
Last I checked in glext.h MapBufferRange was missing a '*' on the void* return value...

Was this one of the Windows drivers? What about driver version?

Yesterday I went and re-downloaded the drivers, but this time picked up the latest OpenGL3 180 driver for Linux 32bit, FreeBSD along with the Linux 64bit driver.

Seems as if both the Linux drivers are missing OpenGL version 3.0 headers. However the FreeBSD driver clearly has OpenGL 3 headers (ie it has glMapBufferRange and more).

Thinking that perhaps just the GL3 header data was missing, I tried the FreeBSD defines for the GL3 texture formats and this didn't work on the Linux 64bit driver. Either the defines might be different on the two platforms or there is something not correct with the Linux drivers.

BTW, GLSL 1.30 stuff does work with the Linux driver, so parts of GL3 are definitely working...

martinsm
12-31-2008, 09:23 AM
glext.h is available here: http://www.opengl.org/registry/api/glext.h
It should include all the defines and entry points to OpenGL 3.0.


I tried downloading and installing the windows 180 driver on XP and it didn't seem to install GL3 headers either?
It has been always like that - no driver on Windows contains header and library files for newest core versions of OpenGL or newest extensions. You must define needed #define's yourself and load entry points with wglGetProcAddress function manually. Or alternatively you can use 3rd party library that will do everything for you: GLee (http://elf-stone.com/glee.php) or GLEW (http://glew.sourceforge.net/)