2010/4/25 Chia-I Wu <olva...@gmail.com>:
> 2010/4/25 Kristian Høgsberg <k...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
