[Mesa-dev] [RFC PATCH 1/6] st_api: Remove st_module

[Kristian Høgsberg]

2010/4/25 Chia-I Wu <olvaffe at gmail.com>:
> 2010/4/25 Kristian Høgsberg <krh at bitplanet.net>:
>> On Sat, Apr 24, 2010 at 10:25 AM, Jakob Bornecrantz
>>> -PUBLIC const struct st_module st_module_OpenGL_ES1 = {
>>> -   .api = ST_API_OPENGL_ES1,
>>> -   .create_api = st_manager_create_api
>>> -};
>>> +PUBLIC struct st_api *
>>> +st_api_create_OpenGL_ES1()
>>> +{
>>> +   return st_gl_api_create();
>> Can we make st_gl_api_create() take an enum (like ST_API_OPENGL_ES1)
>> to indicate which GL API we want to create?  I have a patch series on
>> the way to make core mesa multi-API aware and mesa_create_context()
>> will take a similar enum from mtypes.h.  If we add that argument to
>> st_gl_api_create(), one gallium GL state tracker will be able to
>> implement the three API in one driver.
> This sounds good to me.  But we need a way to know which GL APIs are
> supported, in case we have an OpenGL-only or ES2-only core mesa,
> without really creating the context.  So that we can advertise them in
> EGLConfigs.  It also implies that st/egl can no longer use the
> existence of certain symbols to decide which APIs are available.

Yes, I'll need the same thing in the DRI interface.  A way to query
the bitmask of supported APIs before creating a context.

Btw, the patch series is over here:

  http://cgit.freedesktop.org/~krh/mesa/log/?h=gles2

It's up to 19 patches, and that just moving the GLES stuff into
src/main.  I just need to move the drawtex functionality into mesa and
that should be all done, then I need to add the DRI driver interface
to create a context for a given API and add support to EGL/DRI2.

Kristian