I noticed: { "glDrawTransformFeedback", 43, -1 }, { "glDrawTransformFeedbackStream", 43, -1 }, which are from ARB_transform_feedback2 and 3 respectively are in GL 4.0 but the test says they must exist by 4.3. I started to fix this, but then noticed that we don't have lists for 4.0, 4.1, or 4.2, so the problem is probably much larger than just these two extensions. Maybe we should strip out all of the lines that say "Add to xml" and fix up the others. I also notice /* GL_ARB_internalformat_query */ { "glGetInternalformativ", 30, -1 }, but ARB_internalformat_query is part of 4.2 and not a required part of 3.0. I think there's some general confusion about what the version field is supposed to mean. IIRC, this is why Ian suggested having separate structs for each version, like how GL ES 2 and 3 are handled.
(In reply to comment #0) > I noticed: > > { "glDrawTransformFeedback", 43, -1 }, > { "glDrawTransformFeedbackStream", 43, -1 }, > > which are from ARB_transform_feedback2 and 3 respectively are in GL 4.0 but > the test says they must exist by 4.3. I believe that Jordan did that because Mesa already supports those extensions via the extensions. Any driver that supports OpenGL 4.0 will populate those dispatch pointers. > I started to fix this, but then noticed that we don't have lists for 4.0, > 4.1, or 4.2, so the problem is probably much larger than just these two > extensions. > > Maybe we should strip out all of the lines that say "Add to xml" and fix up > the others. > > I also notice > > /* GL_ARB_internalformat_query */ > { "glGetInternalformativ", 30, -1 }, > > but ARB_internalformat_query is part of 4.2 and not a required part of 3.0. > I think there's some general confusion about what the version field is > supposed to mean. However, every driver supports the extension, so the function is in the dispatch table. > IIRC, this is why Ian suggested having separate structs for each version, > like how GL ES 2 and 3 are handled. I'm not a huge fan of the version field in the dispatch sanity tests. :) But I don't think that will solve this particular problem. I think when we add the next big batch of functions (probably for ARB_geometry_shader4), we should refactor this test a bit.
Hi Matt, do you think we should just close this? Or do you still think the test should be re-factored?
(In reply to Timothy Arceri from comment #2) > Hi Matt, do you think we should just close this? Or do you still think the > test should be re-factored? meh :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.