[Mesa-dev] [PATCH 12/14] mesa/vbo: Move src/mesa/vbo/vbo_exec_array.c -> src/mesa/main/draw.c
brianp at vmware.com
Wed Oct 31 22:20:55 UTC 2018
On 10/30/2018 11:48 PM, Mathias Fröhlich wrote:
> Hi Brian,
> On Tuesday, 30 October 2018 13:06:50 CET Brian Paul wrote:
>> The series looks great, Mathias.
>> Reviewed-by: Brian Paul <brianp at vmware.com>
> Thanks for that one!
>>> @@ -2072,7 +2073,7 @@ vbo_initialize_exec_dispatch(const struct gl_context *ctx,
>>> void GLAPIENTRY
>>> _mesa_DrawArrays(GLenum mode, GLint first, GLsizei count)
>>> - vbo_exec_DrawArrays(mode, first, count);
>>> + _mesa_exec_DrawArrays(mode, first, count);
>> It would be nice to avoid this pattern of simply calling another
>> function like this.
>> The complication, though, is that the _mesa_exec_Draw*() functions get
>> put into the dispatch table, but the _mesa_Draw*() functions are
>> decorated with GLAPIENTRY since they're Windows dll export functions.
>> We'd have to decorate some entries in the dispatch table with
>> GLAPIENTRY, but that could involve some messy python script work.
> Looking at that, at least both functions _mesa_DrawArrays and
> vbo_exec_DrawArrays/_mesa_exec_DrawArrays have the GLAPIENTRY.
> It's probably the pattern for all of these.
> May be I don't quite understand, but to me that looks just like a naming
> issue that got solved at one point by calling one function from an other?
> And don't all dispatch table functions have the GLAPIENTRY as well as
> the GLvertexformat functions?
>> What do you think?
> Now confused ...
Sorry, I think I was confused about how GLAPIENTRY works with the
dispatch table. :(
After your series lands, I think we can just remove the current
_mesa_DrawArrays() function and rename _mesa_exec_DrawArrays() ->
> I think it's just a level of indirection that was introduced for a reason
> that went away at one point in the past. May be the reason was just the naming
> that the vbo module used to have these vbo_ prefixes that are changed by this
More information about the mesa-dev