GLEW supported types Question
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
GLEW supported types Question
by chire
::
Rate this Message:
Hello,
i am running a Glew "Hello World" type aplication that only does this [Code] #include <stdio.h> #include <stdlib.h> #include <GL/glew.h> #include <GL/glut.h> void main(int argc, char **argv) { glutInit(&argc, argv); glewInit(); if (glewIsSupported("GL_VERSION_2_0")){ printf("Ready for OpenGL 2.0\n"); system("PAUSE"); } else { printf("OpenGL 2.0 not supported\n"); system("PAUSE"); exit(1); } //setShaders(); glutMainLoop(); } [/Code] it returns "OpenGL 2.0 not supported" and return that message to wahtever version of Opengl y ask for, also throws not supported for all Extensions. BUT, if i run the glewinfo.exe i get [Code] --------------------------- GLEW Extension Info --------------------------- GLEW version 1.5.1 Reporting capabilities of pixelformat 1 Running on a GeForce 9800 GTX+/PCI/SSE2 from NVIDIA Corporation OpenGL version 3.0.0 is supported GL_VERSION_1_1: OK --------------- GL_VERSION_1_2: OK --------------- glCopyTexSubImage3D: OK glDrawRangeElements: OK glTexImage3D: OK glTexSubImage3D: OK GL_VERSION_1_3: OK --------------- glActiveTexture: OK glClientActiveTexture: OK glCompressedTexImage1D: OK glCompressedTexImage2D: OK glCompressedTexImage3D: OK glCompressedTexSubImage1D: OK glCompressedTexSubImage2D: OK glCompressedTexSubImage3D: OK glGetCompressedTexImage: OK glLoadTransposeMatrixd: OK glLoadTransposeMatrixf: OK glMultTransposeMatrixd: OK glMultTransposeMatrixf: OK glMultiTexCoord1d: OK glMultiTexCoord1dv: OK glMultiTexCoord1f: OK glMultiTexCoord1fv: OK glMultiTexCoord1i: OK glMultiTexCoord1iv: OK glMultiTexCoord1s: OK glMultiTexCoord1sv: OK glMultiTexCoord2d: OK glMultiTexCoord2dv: OK glMultiTexCoord2f: OK glMultiTexCoord2fv: OK glMultiTexCoord2i: OK glMultiTexCoord2iv: OK glMultiTexCoord2s: OK glMultiTexCoord2sv: OK glMultiTexCoord3d: OK glMultiTexCoord3dv: OK glMultiTexCoord3f: OK glMultiTexCoord3fv: OK glMultiTexCoord3i: OK glMultiTexCoord3iv: OK glMultiTexCoord3s: OK glMultiTexCoord3sv: OK glMultiTexCoord4d: OK glMultiTexCoord4dv: OK glMultiTexCoord4f: OK glMultiTexCoord4fv: OK glMultiTexCoord4i: OK glMultiTexCoord4iv: OK glMultiTexCoord4s: OK glMultiTexCoord4sv: OK glSampleCoverage: OK GL_VERSION_1_4: OK --------------- glBlendColor: OK glBlendEquation: OK glBlendFuncSeparate: OK glFogCoordPointer: OK glFogCoordd: OK glFogCoorddv: OK glFogCoordf: OK glFogCoordfv: OK glMultiDrawArrays: OK glMultiDrawElements: OK glPointParameterf: OK glPointParameterfv: OK glPointParameteri: OK glPointParameteriv: OK glSecondaryColor3b: OK glSecondaryColor3bv: OK glSecondaryColor3d: OK glSecondaryColor3dv: OK glSecondaryColor3f: OK glSecondaryColor3fv: OK glSecondaryColor3i: OK glSecondaryColor3iv: OK glSecondaryColor3s: OK glSecondaryColor3sv: OK glSecondaryColor3ub: OK glSecondaryColor3ubv: OK glSecondaryColor3ui: OK glSecondaryColor3uiv: OK glSecondaryColor3us: OK glSecondaryColor3usv: OK glSecondaryColorPointer: OK glWindowPos2d: OK glWindowPos2dv: OK glWindowPos2f: OK glWindowPos2fv: OK glWindowPos2i: OK glWindowPos2iv: OK glWindowPos2s: OK glWindowPos2sv: OK glWindowPos3d: OK glWindowPos3dv: OK glWindowPos3f: OK glWindowPos3fv: OK glWindowPos3i: OK glWindowPos3iv: OK glWindowPos3s: OK glWindowPos3sv: OK GL_VERSION_1_5: OK --------------- glBeginQuery: OK glBindBuffer: OK glBufferData: OK glBufferSubData: OK glDeleteBuffers: OK glDeleteQueries: OK glEndQuery: OK glGenBuffers: OK glGenQueries: OK glGetBufferParameteriv: OK glGetBufferPointerv: OK glGetBufferSubData: OK glGetQueryObjectiv: OK glGetQueryObjectuiv: OK glGetQueryiv: OK glIsBuffer: OK glIsQuery: OK glMapBuffer: OK glUnmapBuffer: OK GL_VERSION_2_0: OK --------------- glAttachShader: OK glBindAttribLocation: OK glBlendEquationSeparate: OK glCompileShader: OK glCreateProgram: OK glCreateShader: OK glDeleteProgram: OK glDeleteShader: OK glDetachShader: OK glDisableVertexAttribArray: OK glDrawBuffers: OK glEnableVertexAttribArray: OK glGetActiveAttrib: OK glGetActiveUniform: OK glGetAttachedShaders: OK glGetAttribLocation: OK glGetProgramInfoLog: OK glGetProgramiv: OK glGetShaderInfoLog: OK glGetShaderSource: OK glGetShaderiv: OK glGetUniformLocation: OK glGetUniformfv: OK glGetUniformiv: OK glGetVertexAttribPointerv: OK glGetVertexAttribdv: OK glGetVertexAttribfv: OK glGetVertexAttribiv: OK glIsProgram: OK glIsShader: OK glLinkProgram: OK glShaderSource: OK glStencilFuncSeparate: OK glStencilMaskSeparate: OK glStencilOpSeparate: OK glUniform1f: OK glUniform1fv: OK glUniform1i: OK glUniform1iv: OK glUniform2f: OK glUniform2fv: OK glUniform2i: OK glUniform2iv: OK glUniform3f: OK glUniform3fv: OK glUniform3i: OK glUniform3iv: OK glUniform4f: OK glUniform4fv: OK glUniform4i: OK glUniform4iv: OK glUniformMatrix2fv: OK glUniformMatrix3fv: OK glUniformMatrix4fv: OK glUseProgram: OK glValidateProgram: OK glVertexAttrib1d: OK glVertexAttrib1dv: OK glVertexAttrib1f: OK glVertexAttrib1fv: OK glVertexAttrib1s: OK glVertexAttrib1sv: OK glVertexAttrib2d: OK glVertexAttrib2dv: OK glVertexAttrib2f: OK glVertexAttrib2fv: OK glVertexAttrib2s: OK glVertexAttrib2sv: OK glVertexAttrib3d: OK glVertexAttrib3dv: OK glVertexAttrib3f: OK glVertexAttrib3fv: OK glVertexAttrib3s: OK glVertexAttrib3sv: OK glVertexAttrib4Nbv: OK glVertexAttrib4Niv: OK glVertexAttrib4Nsv: OK glVertexAttrib4Nub: OK glVertexAttrib4Nubv: OK glVertexAttrib4Nuiv: OK glVertexAttrib4Nusv: OK glVertexAttrib4bv: OK glVertexAttrib4d: OK glVertexAttrib4dv: OK glVertexAttrib4f: OK glVertexAttrib4fv: OK glVertexAttrib4iv: OK glVertexAttrib4s: OK glVertexAttrib4sv: OK glVertexAttrib4ubv: OK glVertexAttrib4uiv: OK glVertexAttrib4usv: OK glVertexAttribPointer: OK GL_VERSION_2_1: OK --------------- glUniformMatrix2x3fv: OK glUniformMatrix2x4fv: OK glUniformMatrix3x2fv: OK glUniformMatrix3x4fv: OK glUniformMatrix4x2fv: OK glUniformMatrix4x3fv: OK GL_VERSION_3_0: OK --------------- glBeginConditionalRender: OK glBeginTransformFeedback: OK glBindBufferBase: OK glBindBufferRange: OK glBindFragDataLocation: OK glClampColor: OK glClearBufferfi: OK glClearBufferfv: OK glClearBufferiv: OK glClearBufferuiv: OK glColorMaski: OK glDisablei: OK glEnablei: OK glEndConditionalRender: OK glEndTransformFeedback: OK glGetBooleani_v: OK glGetFragDataLocation: OK glGetIntegeri_v: OK glGetStringi: OK glGetTexParameterIiv: OK glGetTexParameterIuiv: OK glGetTransformFeedbackVarying: OK glGetUniformuiv: OK glGetVertexAttribIiv: OK glGetVertexAttribIuiv: OK glIsEnabledi: OK glTexParameterIiv: OK glTexParameterIuiv: OK glTransformFeedbackVaryings: OK glUniform1ui: OK glUniform1uiv: OK glUniform2ui: OK glUniform2uiv: OK glUniform3ui: OK glUniform3uiv: OK glUniform4ui: OK glUniform4uiv: OK glVertexAttribI1i: OK glVertexAttribI1iv: OK glVertexAttribI1ui: OK glVertexAttribI1uiv: OK glVertexAttribI2i: OK glVertexAttribI2iv: OK glVertexAttribI2ui: OK glVertexAttribI2uiv: OK glVertexAttribI3i: OK glVertexAttribI3iv: OK glVertexAttribI3ui: OK glVertexAttribI3uiv: OK glVertexAttribI4bv: OK glVertexAttribI4i: OK glVertexAttribI4iv: OK glVertexAttribI4sv: OK glVertexAttribI4ubv: OK glVertexAttribI4ui: OK glVertexAttribI4uiv: OK glVertexAttribI4usv: OK glVertexAttribIPointer: OK [/Code] so actually my card+driver does support opengl even up to 3.0 (i got Nvidia 9800gtx+ 512mb ) im runnning it on Windows 7 Beta with latest Nvidia driver released for windows 7 any help? how could the glewinfo.exe detect the supported types, is the glewIsSupported("GL_VERSION_2_0") a wrong way to check support? PD: also tried with glewExperimental = GL_TRUE before glewInit() and same problem.... |
|
|
Re: GLEW supported types Question
by Nigel Stewart-2
::
Rate this Message:
> if (glewIsSupported("GL_VERSION_2_0")){ > printf("Ready for OpenGL 2.0\n"); > system("PAUSE"); > } > else { > printf("OpenGL 2.0 not supported\n"); > system("PAUSE"); > exit(1); > } > > it returns "OpenGL 2.0 not supported" and return that message to wahtever > version of Opengl y ask for, also throws not supported for all Extensions. There is a known bug in GLEW 1.5.1 due to the OpenGL version being mishandled for OpenGL 3. See bug 2636621 in the Sourceforge bug tracker: http://sourceforge.net/tracker/?atid=523274&group_id=67586&func=browse Two options for you: 1. Get the latest GLEW from CVS and regenerate GLEW from the extensions registry. http://sourceforge.net/scm/?type=cvs&group_id=67586 2. Get Cg Toolkit 2.2 April, which includes GLEW sourcecode with a fix. http://developer.nvidia.com/object/cg_download.html - Nigel ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ glew-users mailing list glew-users@... https://lists.sourceforge.net/lists/listinfo/glew-users |
|
|
detecting GLSL shader model
by Travis Heppe
::
Rate this Message:
the interface to detect which GLSL shader model you're dealing with is pretty convoluted. See http://www.opengl.org/wiki/ Shading_languages:_How_to_detect_shader_model%3F This seems like a problem that GLEW ought to provide a solution for. It references an interface in glh, but that implementation has a pretty major flaw in that it is not easily extensible as new pipeline stages become programmable. How would everyone feel about adding a mechanism in GLEW to directly query shader model? -Travis ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ glew-users mailing list glew-users@... https://lists.sourceforge.net/lists/listinfo/glew-users |
|
|
Re: detecting GLSL shader model
by tom fogal-3
::
Rate this Message:
Travis Heppe <heppe@...> writes:
> the interface to detect which GLSL shader model you're dealing with > is pretty convoluted. See > http://www.opengl.org/wiki/ > Shading_languages:_How_to_detect_shader_model%3F > > This seems like a problem that GLEW ought to provide a solution for. I'm not really sure how this fits into GLEW. `Shader Model' is a DirectX concept; OpenGL 3.1 at least doesn't define any kind of `model'. The solution given in the linked to website is ad hoc at best. They're essentially outlining a database approach: a mapping of DX SM versions to exported OpenGL extensions. I don't think this is a good model to follow for the long term. The natural complaint is `but I need to know which operations will be done in HW'. I sympathize, this hits us as well, but the solution should come in OpenGL, because anywhere downstream can only give doomed-to-be-poor approximations. > How would everyone feel about adding a mechanism in GLEW to directly > query shader model? I disagree with it. I think a library which encodes a similar card database would be useful, and I'd love to have time to make such a library, but I don't feel this kind of approach should make it into GLEW. -tom ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ glew-users mailing list glew-users@... https://lists.sourceforge.net/lists/listinfo/glew-users |
|
|
Re: detecting GLSL shader model
by Travis Heppe
::
Rate this Message:
tom fogal wrote:
> I'm not really sure how this fits into GLEW. `Shader Model' is a > DirectX concept; OpenGL 3.1 at least doesn't define any kind of > `model'. > that's not strictly true. Perhaps not explicitly, but each successive generation of hardware has added capabilities that inform what may be put into the GLSL contents. Three examples dFdx/dFdy gl_FrontFacing as fragment shader input instruction limit ...and there are many more. AMD's ShaderAnalyzer asks the user to specify a GFX board before it will tell you what shader assembly GLSL code resolves to and will report that you have errors if you specify a target that is too old. > The solution given in the linked to website is ad hoc at best. They're > essentially outlining a database approach: a mapping of DX SM versions > to exported OpenGL extensions. I don't think this is a good model to > follow for the long term. > > The natural complaint is `but I need to know which operations will be > done in HW'. I sympathize, this hits us as well, but the solution > should come in OpenGL, because anywhere downstream can only give > doomed-to-be-poor approximations. > OpenGL were making it easy to address its extensions, GLEW wouldn't have any need exist. In any case, waiting for OpenGL to resolve these things internally is probably going to take longer than I care to wait. It's not always a matter of whether the GLSL code will be accepted at all by the compiler. Our experience is that older parts will fail at either shader compile or shader link time, and we'd like a better way than trial&error to decide what version of our GLSL code to feed it. That's even assuming that the compiler tells us. Successful compilation resulting in software emulation is even worse. -Travis ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ glew-users mailing list glew-users@... https://lists.sourceforge.net/lists/listinfo/glew-users |
|
|
Re: detecting GLSL shader model
by tom fogal-3
::
Rate this Message:
Travis Heppe <heppe@...> writes:
> tom fogal wrote: > > I'm not really sure how this fits into GLEW. `Shader Model' is a > > DirectX concept; OpenGL 3.1 at least doesn't define any kind of > > `model'. > > that's not strictly true. Perhaps not explicitly, but each > successive generation of hardware has added capabilities that inform > what may be put into the GLSL contents. That's exactly my point: this is not an issue with loading an OpenGL extension, but rather an issue that occurs because OpenGL vendors routinely break the OpenGL abstraction. > Three examples > dFdx/dFdy > gl_FrontFacing as fragment shader input > instruction limit > ...and there are many more. I don't see anything in GLSL 1.20 which allows an implementation to *not* implement dFdx. Nor can I find anything about shader length limits in the 3.1 OGL spec. I don't have the 1.10 document to compare with, but assuming they're not there, you can use `#version 120' or #ifdef's on __VERSION__ to verify your shader runs in a 1.20 supporting environment. Anyway, if you've got a 1.20-compliant shader, which you declare requires 1.20, and a driver does not compile it ... that's a bug in the driver. Or AMD's ShaderAnalyzer program, whatever. Ditto for a shader being too long for the hardware. While these are very real problems that occur all too often (and as application developers we *need* to provide workarounds), I still do not feel that GLEW is the appropriate place for such a workaround. > AMD's ShaderAnalyzer asks the user to specify a GFX board before it > will tell you what shader assembly GLSL code resolves to and will > report that you have errors if you specify a target that is too old. Again, this is only resolvable correctly with a per-card database of some kind. I'd bet AMD's program is essentially doing that under the hood. > > The natural complaint is `but I need to know which operations > > will be done in HW'. I sympathize, this hits us as well, but the > > solution should come in OpenGL, because anywhere downstream can > > only give doomed-to-be-poor approximations. > > I agree that a solution inside of OpenGL would be prefereable, but if > OpenGL were making it easy to address its extensions, GLEW wouldn't > have any need exist. I think we might just disagree on what GLEW is for. I happen to think OpenGL extension management is done very well; it's a necessarily hard problem. Further, GLEW abstracts it fairly well. That's where GLEW fits: I view it as a simple way to dlsym() (basically) all the OpenGL symbols I care about (and nothing more). > In any case, waiting for OpenGL to resolve these things internally is > probably going to take longer than I care to wait. It sounds like you want a library that fixes/abstracts some of the more difficult problems in developing OpenGL applications. I think it would be very useful, but I don't think this library should be GLEW, and I certainly don't think GLEW should ever contain any sort of card-specific logic (other than loading vendor-specific extensions). > It's not always a matter of whether the GLSL code will be accepted at > all by the compiler. Our experience is that older parts will fail > at either shader compile or shader link time [. . .] Yeah, we hit this as well, and it sucks. If you develop a library of workarounds, perhaps on top of GLEW, I'd like to see it licensed however GLEW (BSD, I think?) is. I imagine we'd make use of it around here. -tom ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ glew-users mailing list glew-users@... https://lists.sourceforge.net/lists/listinfo/glew-users |
|
|
Re: detecting GLSL shader model
by Nigel Stewart-2
::
Rate this Message:
> That's exactly my point: this is not an issue with loading an OpenGL
> extension, but rather an issue that occurs because OpenGL vendors > routinely break the OpenGL abstraction. It's not an issue with vendors, it's an issue with customers that are always demanding new features. :-) - Nigel ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ glew-users mailing list glew-users@... https://lists.sourceforge.net/lists/listinfo/glew-users |
|
|
Re: detecting GLSL shader model
by tom fogal-3
::
Rate this Message:
Nigel Stewart <nstewart@...> writes:
> > That's exactly my point: this is not an issue with loading an OpenGL > > extension, but rather an issue that occurs because OpenGL vendors > > routinely break the OpenGL abstraction. > > It's not an issue with vendors, it's an issue with > customers that are always demanding new features. :-) <g>, okay, you might more accurately say that it's an issue due to the slow pace of OpenGL standardization -- vendor develops Y, BigHitGameOfSeason needs something like Y, vendor creates glYARB(), and the rest of us are left with the mess ;) It's a bad situation, but I don't really see a way of fixing it. I think the main problem is the lack of incentive for either BigHitGameOfSeason developer or vendor to properly get something in core, especially when an extension is so much easier. *shrug*. I do think OpenGL is broken w.r.t. it's abstraction though. Feels like they try to hard to maintain this abstract graphics library, but there really needs to be some (at least vague) performance specifications in the standard. I'm starting to ramble now.. -tom ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ glew-users mailing list glew-users@... https://lists.sourceforge.net/lists/listinfo/glew-users |
| Free embeddable forum powered by Nabble | Forum Help |
