January 2015 - Wine-Devel - list.winehq.org

Re: loader: More generic pre_exec for Linux (try 2)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > Am 29.12.2014 um 23:03 schrieb André Hentschel: >> --- >> loader/main.c | 26 ++++++++++++++++++-------- >> 1 file changed, 18 insertions(+), 8 deletions(-) > > [After a small IRC discussion] > > My main goal is to also get the 2G/2G vmsplit warning on ARM, too. (and potential other platforms) > There are still many ARM kernels out there with a 2G split. > The problem is that Wine can't start on 2G/2G, it seems there are too much assumptions in the code for a 3G split. > e.g. for shared user data. We can't allocate 0x7ffe0000-0x7fff0000 on 2G split, most likely something else is already there, idk There are few such assumptions, and they could be fixed. The question is whether there are actual apps that depend on these addresses, like there are on i386. If not, it shouldn't be necessary to require a 3G split. -- Alexandre Julliard julliard(a)winehq.org

Jan. 5, 2015

Re: [PATCH 5/5] wined3d: Prefer the core glActiveTexture function.

by Matteo Bruni

2015-01-05 21:18 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 5 January 2015 at 21:01, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> previous approaches. Also, glShaderSource and glTexImage3D will >> additionally need a cast (for trivial reasons, but still...) so it's > > This is on a bit of a tangent, but the GLuint vs. GLhandleARB > difference may not be so trivial. I'm told that on MacOS X GLhandleARB > is typedef'ed as "void *", as opposed to "unsigned int" everywhere > else. Of course that wouldn't just be an issue for wined3d, but for > opengl32 as well. Fortunately 64-bit isn't ever going to work on OS X > anyway, I guess. That's all true, but that's actually not the issue here. We already have typedef unsigned int GLhandleARB; hardcoded in include/wine/wgl.h so 64-bit GL on OS X has already been broken for a long time (on top of 64-bit Wine on OS X being non-existent, obviously). Actually by going with this approach we avoid the GLhandleARB issue completely in wined3d if GL offers the core shader functions (which should be the case for any 2.0+ GL context).

Jan. 5, 2015

Re: [PATCH 2/5] winemac: Implement wglCreateContextAttribsARB.

by Matteo Bruni

2015-01-05 21:04 GMT+01:00 Ken Thomases <ken(a)codeweavers.com>: > On Jan 5, 2015, at 10:17 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > >> +#if !defined(MAC_OS_X_VERSION_10_7) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_7 >> + if (core) >> + { >> + WARN("OS X version >= 10.7 is required to be able to create core contexts\n", >> + err, CGLErrorString(err)); > > The "err, CGLErrorString(err)" arguments are superfluous. > >> + return FALSE; >> + } > > >> + if (core) >> + { >> + attribs[n++] = kCGLPFAOpenGLProfile; >> + attribs[n++] = (int)kCGLOGLPVersion_3_2_Core; >> + } > > These lines won't compile when the SDK is earlier than 10.7. So, they also need to be guarded with the appropriate #if. > > >> + case WGL_CONTEXT_PROFILE_MASK_ARB: >> + if ((value & ~VALID_PROFILE_BITS_MASK) || !value || >> + (value & VALID_PROFILE_BITS_MASK) == VALID_PROFILE_BITS_MASK) > > I think it would be better to simply do: > > if (value != WGL_CONTEXT_CORE_PROFILE_BIT_ARB && > value != WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB) > > Or did I miss something about the logic you used? No, you're totally right. By following the WGL spec to the letter I somehow lost sight of what I was actually doing... >> + { >> + WARN("WGL_CONTEXT_PROFILE_MASK_ARB bits %#x invalid\n", value); >> + SetLastError(ERROR_INVALID_PROFILE_ARB); >> + return NULL; >> + } >> + profile = value; >> + break; > > >> + register_extension("WGL_ARB_create_context"); >> + register_extension("WGL_ARB_create_context_profile"); >> + opengl_funcs.ext.p_wglCreateContextAttribsARB = macdrv_wglCreateContextAttribsARB; > > These should only be advertised when building against the 10.7 SDK or later. So, this should be guarded by the SDK #if directive. > > Also, given that it's possible to build against a 10.7+ SDK but target deployment back to 10.6, I'm tempted to say we should determine if core profiles are actually available and only advertise those extensions if so. Basically, call CGLChoosePixelFormat() with the simplest set of attributes that specify the core profile and see if it succeeds. Ah, I see. Sure I'll do that. > > -Ken > > >

Jan. 5, 2015

Re: [PATCH 5/5] wined3d: Prefer the core glActiveTexture function.

by Henri Verbeet

On 5 January 2015 at 21:01, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > previous approaches. Also, glShaderSource and glTexImage3D will > additionally need a cast (for trivial reasons, but still...) so it's This is on a bit of a tangent, but the GLuint vs. GLhandleARB difference may not be so trivial. I'm told that on MacOS X GLhandleARB is typedef'ed as "void *", as opposed to "unsigned int" everywhere else. Of course that wouldn't just be an issue for wined3d, but for opengl32 as well. Fortunately 64-bit isn't ever going to work on OS X anyway, I guess.

Jan. 5, 2015

Re: [PATCH 3/5] opengl32: Fix extension checks on OpenGL core profile contexts.

by Henri Verbeet

On 5 January 2015 at 20:19, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2015-01-05 18:33 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: >> If I'm reading this correctly, this effectively ignores >> DisabledExtensions for anything newer than GL 3.0. (And at least as >> far as wglGetProcAddress() is concerned it affects both compatibility >> and core contexts.) > > Hmm, it should still work via filter_extensions(). wglGetProcAddress() calls is_extension_supported(), which calls has_extension(NULL, ...) if major >= 3, so it doesn't go through filter_extensions(). Most applications probably won't care, but in principle applications can use wglGetProcAddress() to check if a function is supported. (As opposed to glXGetProcAddress() that's allowed to return non-NULL for unsupported functions.) >> As an aside, note that winex11.drv also uses >> "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo(). > > That should be fine, that's always a compatibility context created > with glXCreateContext(). Right, although in a way that's worse; extensions supported in compatibility contexts aren't necessarily also supported in core contexts. The only reason it will probably work in practice is because of the details of the extensions being checked against that list.

Jan. 5, 2015

Re: [PATCH 2/5] winemac: Implement wglCreateContextAttribsARB.

by Ken Thomases

On Jan 5, 2015, at 10:17 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +#if !defined(MAC_OS_X_VERSION_10_7) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_7 > + if (core) > + { > + WARN("OS X version >= 10.7 is required to be able to create core contexts\n", > + err, CGLErrorString(err)); The "err, CGLErrorString(err)" arguments are superfluous. > + return FALSE; > + } > + if (core) > + { > + attribs[n++] = kCGLPFAOpenGLProfile; > + attribs[n++] = (int)kCGLOGLPVersion_3_2_Core; > + } These lines won't compile when the SDK is earlier than 10.7. So, they also need to be guarded with the appropriate #if. > + case WGL_CONTEXT_PROFILE_MASK_ARB: > + if ((value & ~VALID_PROFILE_BITS_MASK) || !value || > + (value & VALID_PROFILE_BITS_MASK) == VALID_PROFILE_BITS_MASK) I think it would be better to simply do: if (value != WGL_CONTEXT_CORE_PROFILE_BIT_ARB && value != WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB) Or did I miss something about the logic you used? > + { > + WARN("WGL_CONTEXT_PROFILE_MASK_ARB bits %#x invalid\n", value); > + SetLastError(ERROR_INVALID_PROFILE_ARB); > + return NULL; > + } > + profile = value; > + break; > + register_extension("WGL_ARB_create_context"); > + register_extension("WGL_ARB_create_context_profile"); > + opengl_funcs.ext.p_wglCreateContextAttribsARB = macdrv_wglCreateContextAttribsARB; These should only be advertised when building against the 10.7 SDK or later. So, this should be guarded by the SDK #if directive. Also, given that it's possible to build against a 10.7+ SDK but target deployment back to 10.6, I'm tempted to say we should determine if core profiles are actually available and only advertise those extensions if so. Basically, call CGLChoosePixelFormat() with the simplest set of attributes that specify the core profile and see if it succeeds. -Ken

Jan. 5, 2015

Re: [PATCH 1/5] winemac: Make the implementation of clearToBlackIfNeeded compatible with core contexts.

by Ken Thomases

On Jan 5, 2015, at 10:17 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/winemac.drv/cocoa_opengl.m | 29 +++++++++++++++++++++++++++-- > 1 file changed, 27 insertions(+), 2 deletions(-) Looks OK to me. -Ken

Jan. 5, 2015

Re: [PATCH 5/5] wined3d: Prefer the core glActiveTexture function.

by Matteo Bruni

2015-01-05 18:32 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 5 January 2015 at 17:17, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> +#define MAP_GL_FUNCTION(core_func, ext_func) \ >> + { \ >> + if (!gl_info->gl_ops.ext.p_##core_func) \ >> + gl_info->gl_ops.ext.p_##core_func = gl_info->gl_ops.ext.p_##ext_func; \ >> + } >> + >> + MAP_GL_FUNCTION(glActiveTexture, glActiveTextureARB); >> +#undef MAP_GL_FUNCTION >> + > This kind of thing doesn't exactly fill me with joy, but I guess the > alternatives wouldn't be much better. Yeah, this is what I came up after a while and it looks better than my previous approaches. Also, glShaderSource and glTexImage3D will additionally need a cast (for trivial reasons, but still...) so it's going to get even funnier... > Any reason this can't be part of load_gl_funcs()? (And while we're > touching load_gl_funcs(), I don't see much of a reason we couldn't > just inline GL_EXT_FUNCS_GEN these days.) At this point, not really. I'm going to move it there and inline GL_EXT_FUNCS_GEN. >> + /* Newer core functions */ \ >> + USE_GL_FUNC(glActiveTexture) \ > It would probably be nice to note the exact GL version where the > function entered core GL. Good idea. I think I'm going to add a comment next to each line (while keeping this entire "core" section sorted alphabetically), as opposed to splitting the new section by version.

Jan. 5, 2015

Re: [PATCH 3/5] opengl32: Fix extension checks on OpenGL core profile contexts.

by Matteo Bruni

2015-01-05 18:33 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 5 January 2015 at 17:17, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> static BOOL has_extension( const char *list, const char *ext, size_t len ) >> { >> + if (!list) >> + { >> + const struct opengl_funcs *funcs = NtCurrentTeb()->glTable; >> + const char *gl_ext; >> + unsigned int i; >> + GLint extensions_count; >> + >> + glGetIntegerv(GL_NUM_EXTENSIONS, &extensions_count); >> + for (i = 0; i < extensions_count; ++i) >> + { >> + gl_ext = (const char *)funcs->ext.p_glGetStringi(GL_EXTENSIONS, i); >> + if (!strncmp(gl_ext, ext, len) && !gl_ext[len]) >> + return TRUE; >> + } >> + return FALSE; >> + } >> + > If I'm reading this correctly, this effectively ignores > DisabledExtensions for anything newer than GL 3.0. (And at least as > far as wglGetProcAddress() is concerned it affects both compatibility > and core contexts.) Hmm, it should still work via filter_extensions(). On the other hand we don't filter the extensions the application queries through glGetStringi(GL_EXTENSIONS, i), so yeah, that is missing and I should add that (maybe in a separate patch?) >> + gl_version = (const char *)glGetString(GL_VERSION); >> + sscanf(gl_version, "%u", &major); >> + if (major >= 3) >> + { > It seems tempting to just flag the context in > wglCreateContextAttribsARB() under the appropriate conditions, perhaps > in a similar way to wgl_handle_type. Not sure if it would really make > it better though. I'm going to give it a try and see how it looks. > As an aside, note that winex11.drv also uses > "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo(). That should be fine, that's always a compatibility context created with glXCreateContext().

Jan. 5, 2015

Re: dwrite: release_freetype() is unused so remove it.

by Nikolay Sivov

I'll send a patch to make it used.

Jan. 5, 2015