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

[Henri Verbeet]

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.

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.)
> +    /* Newer core functions */ \
> +    USE_GL_FUNC(glActiveTexture) \
> It would probably be nice to note the exact GL version where the
> function entered core GL.

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

[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.

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

[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.

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

[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).