Proposed fix for recent opengl.org registry updates
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
Proposed fix for recent opengl.org registry updates
by Nigel Stewart-2
::
Rate this Message:
There are some OpenGL entries that conflict
with GL_ARB_uniform_buffer_object: glBindBufferBase glBindBufferRange glGetIntegeri_v Otherwise, we could just remove them from core/GL_VERSION_3_0 - Nigel -------------- Index: auto/bin/update_ext.sh =================================================================== --- auto/bin/update_ext.sh (revision 548) +++ auto/bin/update_ext.sh (working copy) @@ -203,6 +203,14 @@ grep -v "glGetIntegerIndexedvEXT" $1/GL_NV_explicit_multisample > tmp mv tmp $1/GL_NV_explicit_multisample +# remove OpenGL 3.0 entries from GL_ARB_uniform_buffer_object + grep -v "glBindBufferBase" $1/GL_ARB_uniform_buffer_object > tmp + mv tmp $1/GL_ARB_uniform_buffer_object + grep -v "glBindBufferRange" $1/GL_ARB_uniform_buffer_object > tmp + mv tmp $1/GL_ARB_uniform_buffer_object + grep -v "glGetIntegeri_v" $1/GL_ARB_uniform_buffer_object > tmp + mv tmp $1/GL_ARB_uniform_buffer_object + # fix bugs in GL_ARB_vertex_shader grep -v "GL_FLOAT" $1/GL_ARB_vertex_shader > tmp mv tmp $1/GL_ARB_vertex_shader ----------------------------------------------------------------------------------- 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. ----------------------------------------------------------------------------------- ------------------------------------------------------------------------------ _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: Proposed fix for recent opengl.org registry updates
by tom fogal-3
::
Rate this Message:
Nigel Stewart <nstewart@...> writes:
> There are some OpenGL entries that conflict > with GL_ARB_uniform_buffer_object: > > glBindBufferBase > glBindBufferRange > glGetIntegeri_v > > Otherwise, we could just remove them from > core/GL_VERSION_3_0 *laugh*, I was just about to email the list with a patch blacklisting the extension. Good thing I checked my old mails first. > Index: auto/bin/update_ext.sh > =================================================================== > --- auto/bin/update_ext.sh (revision 548) > +++ auto/bin/update_ext.sh (working copy) > @@ -203,6 +203,14 @@ > grep -v "glGetIntegerIndexedvEXT" $1/GL_NV_explicit_multisample > tmp > mv tmp $1/GL_NV_explicit_multisample > > +# remove OpenGL 3.0 entries from GL_ARB_uniform_buffer_object > + grep -v "glBindBufferBase" $1/GL_ARB_uniform_buffer_object > tmp > + mv tmp $1/GL_ARB_uniform_buffer_object I like this solution better; I haven't checked but I'd guess the blacklist approach disables buffer objects for almost everyone (those who don't have 3.0-capable drivers), which is obviously a terrible idea. Would this solution also prevent use of buffer objects for 2.x-but-not-3.x capable drivers? If so, I'd vote for removing them from GL_VERSION_3_0 for now. Those with 3.x drivers can still access them through the extension, then. Regardless of which place it should be removed, +1 from me. Thanks, -tom ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: Proposed fix for recent opengl.org registry updates
by Nigel Stewart-2
::
Rate this Message:
> I'd vote for removing them from GL_VERSION_3_0 for now.
> Those with 3.x drivers can still access them through the extension, then. I agree with your line of reasoning Tom, but I can also see the opposite argument that an OpenGL3 implementation shouldn't need the extension to resolve those symbols. And that's why I was reluctant to put a change in, one way or the other.... - 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. ----------------------------------------------------------------------------------- ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
|
|
Re: Proposed fix for recent opengl.org registry updates
by tom fogal-3
::
Rate this Message:
Nigel Stewart <nstewart@...> writes:
> > I'd vote for removing them from GL_VERSION_3_0 for now. > > Those with 3.x drivers can still access them through the extension, then. > > I agree with your line of reasoning Tom, but I can > also see the opposite argument that an OpenGL3 implementation > shouldn't need the extension to resolve those symbols. Well, yes.. but the opposite reasoning would break existing applications, whereas removing them from 3.x-core would only impact software that developers are currently writing. Further, I think it would be difficult to find an app which is only targeting 3.0+, refusing to fall back on the older extensions. The extension was essentially accepted wholesale, yes? Perhaps the correct approach is to remove one of them and simply map the removed one to the existing one. In that case, I think the logic would be simplest if we removed the OpenGL 3.x one and mapped it to the ARB extension (otherwise we'd have to handle the case that the card has the extension, but the driver doesn't report 3.0+). This approach would cause applications using either approach to silently `just work', I'd guess. Or we could just print a message to the terminal -- ``you're trying to use the bindbuffer 3.0 function, but I've disabled it in favor of the extension! See <x> thread on glew-coders''. Then a lost developer would at least know where to go for further information, and we could tell them how to hack around it for their app. -tom ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ glew-coders mailing list glew-coders@... https://lists.sourceforge.net/lists/listinfo/glew-coders |
| Free embeddable forum powered by Nabble | Forum Help |
