Rico Schüller kgbricola@web.de writes:
dlls/opengl32/make_opengl | 316 +++++++++++++++++++--------------------------- dlls/winemac.drv/opengl.c | 8 +- dlls/winex11.drv/opengl.c | 8 +- 3 Dateien geändert, 136 Zeilen hinzugefügt(+), 196 Zeilen entfernt(-)
It's not generating quite the same thing as the previous version, and some of the differences look wrong, for instance:
-static void WINAPI glBindAttribLocation( GLuint program, GLuint index, const GLchar* name ) { +static void WINAPI glBindAttribLocation( GLhandleARB programObj, GLuint index, const GLcharARB* name ) {
On 29.10.2013 13:10, Alexandre Julliard wrote:
Rico Schüller kgbricola@web.de writes:
dlls/opengl32/make_opengl | 316 +++++++++++++++++++--------------------------- dlls/winemac.drv/opengl.c | 8 +- dlls/winex11.drv/opengl.c | 8 +- 3 Dateien geändert, 136 Zeilen hinzugefügt(+), 196 Zeilen entfernt(-)
It's not generating quite the same thing as the previous version, and some of the differences look wrong, for instance:
-static void WINAPI glBindAttribLocation( GLuint program, GLuint index, const GLchar* name ) { +static void WINAPI glBindAttribLocation( GLhandleARB programObj, GLuint index, const GLcharARB* name ) {
Yes, they look wrong. Apparently the alias did this. It's fine, when the alias is ignored. I missed this, sorry. This could be fixed.
I found some other issues and now I think the xml seems not use able for us in the state it is now. Sorry for the noise.
E.g. glColorSubTable is listed in the extension GL_ARB_imaging, but not as GL 1.2 requirement. All linux drivers support at least 1.2 (and thus don't expose GL_ARB_imaging), so there is no way to tell if we should support that function or not. We would need a separate list for that ...
Imho this works for glBlendColor which is in GL_ARB_imaging and GL_VERSION_1_4, but this seems also wrong as it should be in GL 1.2.
Did I miss anything?
Maybe we should provide a list which extension is part of which opengl version?
Cheers Rico
On 31 October 2013 11:16, Rico Schüller kgbricola@web.de wrote:
I found some other issues and now I think the xml seems not use able for us in the state it is now. Sorry for the noise.
E.g. glColorSubTable is listed in the extension GL_ARB_imaging, but not as GL 1.2 requirement. All linux drivers support at least 1.2 (and thus don't expose GL_ARB_imaging), so there is no way to tell if we should support that function or not. We would need a separate list for that ...
Imho this works for glBlendColor which is in GL_ARB_imaging and GL_VERSION_1_4, but this seems also wrong as it should be in GL 1.2.
Did I miss anything?
If this is just for functions in GL_ARB_imaging, I think this is correct / intentional. The GL "imaging subset" has always been a bit special, and not many drivers implement it, although IIRC at least NVIDIA does. For all the details see section 3.6.2 of the GL 1.2.1 spec, but the bottom line is that it's not actually available unless you have GL_ARB_imaging in the extension string, despite being described in the GL 1.2.1 spec.
On 31.10.2013 11:37, Henri Verbeet wrote:
On 31 October 2013 11:16, Rico Schüller kgbricola@web.de wrote:
I found some other issues and now I think the xml seems not use able for us in the state it is now. Sorry for the noise.
E.g. glColorSubTable is listed in the extension GL_ARB_imaging, but not as GL 1.2 requirement. All linux drivers support at least 1.2 (and thus don't expose GL_ARB_imaging), so there is no way to tell if we should support that function or not. We would need a separate list for that ...
Imho this works for glBlendColor which is in GL_ARB_imaging and GL_VERSION_1_4, but this seems also wrong as it should be in GL 1.2.
Did I miss anything?
If this is just for functions in GL_ARB_imaging, I think this is correct / intentional. The GL "imaging subset" has always been a bit special, and not many drivers implement it, although IIRC at least NVIDIA does. For all the details see section 3.6.2 of the GL 1.2.1 spec, but the bottom line is that it's not actually available unless you have GL_ARB_imaging in the extension string, despite being described in the GL 1.2.1 spec.
Yeah, should be mostly for GL_ARB_imaging... so basically using GL_ARB_imaging is fine then and the previous GL_VERSION_1_2 was wrong.
Well there are some other issues like e.g. glVertexAttrib4ubvARB which is added by both extensions (GL_ARB_vertex_shader and GL_ARB_vertex_program) and I'm not sure there is one preferred over the other. Also, there are functions which are added in two ways, e.g. glVertexP2ui (GL_ARB_vertex_type_2_10_10_10_rev and GL_VERSION_3_3).
The attached patch would fix both (and the parser needs to add list all versions and extensions). I think, it is fine, if we would have support til here, as that is what's working with the gl.spec file as of now. I'll update the complete series, if there are no other concerns.
How do we handle glNamedFramebufferParameteriEXT? It basically needs two extensions (GL_ARB_framebuffer_no_attachments and GL_EXT_direct_state_access), but only a comment in the gl.xml mentions that. Do we need to take care of that case or do most drivers support both extensions anyway together?
Cheers Rico
-
Alexandre Julliard -
Henri Verbeet -
Rico Schüller