Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 02-08-04, 01:31 PM   #1
regnnick
Registered User
 
Join Date: Feb 2004
Posts: 3
Default problems with opengl header

I've updated my nvidia drivers to the latest ia32 version (aka 1.0-5336) including the opengl headears. And now, any C++ program complain about broken glu.h/glext.h (I didn't try C programs). I have the following error messages:
/usr/include/GL/glext.h:3178: type specifier omitted for parameter `boolean'
/usr/include/GL/glext.h:3178: parse error before `*' token

/usr/X11R6/include/GL/glu.h:261: parse error before `*' token
/usr/X11R6/include/GL/glu.h:263: syntax error before `void'
/usr/X11R6/include/GL/glu.h:264: syntax error before `void'
/usr/X11R6/include/GL/glu.h:265: syntax error before `void'
/usr/X11R6/include/GL/glu.h:266: syntax error before `void'
...


The same programs compile fine with the previous drivers and on my opteron computer (with amd64 drivers 1.0-5332)

Any idea why this error occurs?
regnnick is offline   Reply With Quote
Old 02-08-04, 09:56 PM   #2
nvnothing
Registered User
 
Join Date: Feb 2004
Posts: 3
Default Nvidia error

NVidia just made a typo.

/usr/include/GL/glext.h:3178: type specifier omitted for parameter `boolean'
/usr/include/GL/glext.h:3178: parse error before `*' token

FIX:
Change boolean to GLboolean:

extern GLboolean glAreProgramsResidentNV(GLsizei n, const GLuint *ids, boolean *residences);

becomes:

extern GLboolean glAreProgramsResidentNV(GLsizei n, const GLuint *ids, GLboolean *residences);


I just found this too with 5336. Probably it crept through because VC++ defines a boolean type for C, whereas gcc doesn't. But that's just a guess. If so, this could cause problems as GLboolean is unsigned char while VC++ boolean might be an int, so the library would have it as 1 unsigned byte while the program would be expecting 4 bytes, signed.

Anyhow 5336 is 20% slower on my Ti4200 than 4496, so I am only using its headers. Mysterious performance problems make me wish for driver source code, not to mention all the headaches poor VIA chipset folks have.

On my system the 3xxx drivers couldn't do TwinView except for Clone -- right and left monitors caused a lockup.

4xxx is slower but works for TwinView, but is prone to occasional lockups. 5xxx is slower still, so I didn't wait around to check its stability.
nvnothing is offline   Reply With Quote
Old 02-09-04, 02:04 PM   #3
regnnick
Registered User
 
Join Date: Feb 2004
Posts: 3
Default Re: Nvidia error

Quote:
Originally posted by nvnothing
NVidia just made a typo.

FIX:
Change boolean to GLboolean:

extern GLboolean glAreProgramsResidentNV(GLsizei n, const GLuint *ids, boolean *residences);

becomes:

extern GLboolean glAreProgramsResidentNV(GLsizei n, const GLuint *ids, GLboolean *residences);
In fact, I've already done this change, but thanks . But I still have a problem with the glu.h which is more tricky. I had to suppress the GLAPI and GLAPIENTRY (like in the mesa glu.h) and now it seems to work.


Quote:
I just found this too with 5336. Probably it crept through because VC++ defines a boolean type for C, whereas gcc doesn't. But that's just a guess. If so, this could cause problems as GLboolean is unsigned char while VC++ boolean might be an int, so the library would have it as 1 unsigned byte while the program would be expecting 4 bytes, signed.

Anyhow 5336 is 20% slower on my Ti4200 than 4496, so I am only using its headers. Mysterious performance problems make me wish for driver source code, not to mention all the headaches poor VIA chipset folks have.
It would be easier for the linux community if these drivers were released under a free licence. I never really understand why it is not possible to open part of the code which is not patent protected and let the rest in a binary file...
regnnick is offline   Reply With Quote
Old 02-09-04, 04:43 PM   #4
nvnothing
Registered User
 
Join Date: Feb 2004
Posts: 3
Default GLU

Perhaps you could quote the problem lines from your GLU file.

My line 261 says:

extern void gluBeginSurface (GLUnurbs* nurb);

Earlier, GLUnurbs is declared as:

#ifdef __cplusplus
class GLUnurbs;
class GLUquadric;
class GLUtesselator;
#else
typedef struct GLUnurbs GLUnurbs;
typedef struct GLUquadric GLUquadric;
typedef struct GLUtesselator GLUtesselator;
#endif

glu.h is not included in the NV driver, so mine is from SGI: "This software was created using the OpenGL(R) version 1.2.1 Sample Implementation published by SGI", according to the comments.


Quote:
It would be easier for the linux community if these drivers were released under a free licence. I never really understand why it is not possible to open part of the code which is not patent protected and let the rest in a binary file...
Now that ATI has equalled or surpassed NVidia in many ways, I don't see how opening their drivers could cause them to lose their performance edge, as it's already gone.

The other day I was checking out Mesa and they have all the extensions, vertex programs, you name it. We just need an FPGA Mesa board.
nvnothing is offline   Reply With Quote
Old 02-10-04, 02:04 PM   #5
regnnick
Registered User
 
Join Date: Feb 2004
Posts: 3
Default Re: GLU

Quote:
Perhaps you could quote the problem lines from your GLU file.
Here it is

typedef void (GLAPIENTRY *_GLUfuncptr)();

As I said in my previous post, the errors arise from the GLAPI and GLAPIENTRY.


Quote:
glu.h is not included in the NV driver, so mine is from SGI: "This software was created using the OpenGL(R) version 1.2.1 Sample Implementation published by SGI", according to the comments.
You're right. I don't have the previous gl.h anymore. Do you know if the GLAPI and GLAPIENTRY were defined there?

Big thanks for your help

Quote:
Now that ATI has equalled or surpassed NVidia in many ways, I don't see how opening their drivers could cause them to lose their performance edge, as it's already gone.

The other day I was checking out Mesa and they have all the extensions, vertex programs, you name it. We just need an FPGA Mesa board.
I agree but I thought the reason why they didn't want to open the code was because of the patent problems.
regnnick is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenGL book Airstrip1 Software Development 2 08-12-12 09:55 AM
Unity 5.12 Fixes Ubuntu OpenGL Performance Problems News Archived News Items 0 06-11-12 02:20 PM
Major WineX prob... I think it has to do with the vidcard... Linewbie NVIDIA Linux 20 10-09-02 10:58 PM
OpenGL SDK compilation problems gib bogle NVIDIA Linux 2 09-18-02 10:15 AM
Slow OpenGL on 7.3 kl899 NVIDIA Linux 1 08-04-02 08:58 PM

All times are GMT -5. The time now is 01:37 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.