October 2013 - Wine-Devel - list.winehq.org

Re: [PATCH 3/3] opengl32: Use opengl xml registry files.

by Rico Schüller

On 31.10.2013 11:37, Henri Verbeet wrote: > On 31 October 2013 11:16, Rico Schüller <kgbricola(a)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

Oct. 31, 2013

Re: [PATCH 3/3] opengl32: Use opengl xml registry files.

by Henri Verbeet

On 31 October 2013 11:16, Rico Schüller <kgbricola(a)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.

Oct. 31, 2013

Re: [PATCH 3/3] opengl32: Use opengl xml registry files.

by Rico Schüller

On 29.10.2013 13:10, Alexandre Julliard wrote: > Rico Schüller <kgbricola(a)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

Oct. 31, 2013

Re: [PATCH 3/5] ddraw/tests: Use explicit A calls.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3136 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7.c:3055: Test failed: SetDisplayMode failed, hr 0x80004001. === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w8 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w864 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w864 (32 bit visual) === visual.c:2616: Test failed: unexpected colortable on offscreen surface

Oct. 31, 2013

Re: [PATCH 1/5] d3d9/tests: Use color_match() in more places.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3134 Your paranoid android. === w8 (32 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000. === w864 (32 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000. === w864 (64 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000.

Oct. 31, 2013

Re: server: Make it possible for WaitCommEvent to detect recursive requests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3133 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1500) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1550: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1517: Changing CommMask on the fly for handle 000000F8 after timeout 500

Oct. 31, 2013

Re: shell32: Check number of bytes returned by ReadFile.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > What is the reason for setting state of this patch as 'pending'? Think a bit more about how to properly handle errors in that code. -- Alexandre Julliard julliard(a)winehq.org

Oct. 31, 2013

Re: shell32: Check number of bytes returned by ReadFile.

by Dmitry Timoshkov

What is the reason for setting state of this patch as 'pending'? -- Dmitry.

Oct. 31, 2013

Re: [PATCH 2/3] winmm/tests: Use the explicit mciSendCommandA() version.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3126 Your paranoid android. === w7pro64 (32 bit mci) === mci.c:988: Test failed: 394ms is not in the expected 400-600ms range mci.c:995: Test failed: 394ms is not even in the expected 400-1000ms range

Oct. 31, 2013

Re: [PATCH 1/3] winmm/tests: Avoid duplicating the tested call in the ok() message.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3125 Your paranoid android. === wvista (32 bit mci) === mci.c:987: Test failed: 398ms is not in the expected 400-600ms range mci.c:994: Test failed: 398ms is not even in the expected 400-1000ms range === w864 (32 bit mci) === mci.c:987: Test failed: 398ms is not in the expected 400-600ms range mci.c:994: Test failed: 398ms is not even in the expected 400-1000ms range === w7pro64 (64 bit mci) === mci.c:856: Test failed: mci status mode: playing after play from 0 to 0

Oct. 31, 2013