[Mesa-dev] GLES1/2 and DRI drivers

[Chia-I Wu]

On Mon, Apr 12, 2010 at 12:37:10PM -0400, Kristian Høgsberg wrote:
> I've been looking into the GLES1/2 support in mesa and trying to
> figure out how to make it work for DRI drivers as well.  The current
> approach only works for gallium, and it works by compiling mesa core
> as different state trackers.  Each state tracker is just a thin filter
> on top of the public API and in the end, the result is essentially
> three copies of the mesa state tracker that all load the same gallium
> chipset driver to deal with the hardware.  As far as I understand it,
> anyway.
> I would like to propose that we structure the code a bit differently,
> specifically I would like to see a way where we can load one DRI
> driver which can implement multiple GL APIs.  I understand that
> gallium was designed to support mulitple APIs, however, in the case of
> gl/gles1/gles2, there is a big overlap, and we can support all three
> without different state trackers.
> Specifically, what I'm thinking of is
>  - the dri driver gets a new entry point that lets us create a context
> for a specified API (along these lines:
> http://cgit.freedesktop.org/~krh/mesa/commit/?h=gles2&id=707ad2057e5a2ab2e5fa36be77de373ed98967c5)
>  - mesa core becomes multi api aware, struct gl_context gets a new API field
>  - move the es entry points from src/mesa/es into src/mesa/main
These all look good to me.  Two bigger issues I can think of now is the
merge of GLAPI XMLs and get_gen.py.  I never have a chance to look at
gles version of get_gen.py, and I think it might require quite some time
of manual editing to merge.  GLAPI XMLs is less trouble if one is to
create a big dispatch table.  But it might be good to be able to create
a small GLES2 only dispatch table, if configured to.
>  - create src/gles1 and src/gles2 directories for compiling
> libGLESv1.so and libGLESv2.so; basically glapi-es2 as a shared object
> file.
In EGL/Gallium, there are three copies of libmesagallium.a, in libGL.so,
libGLESv1_CM.so, and libGLESv2.so respectively.  In EGL/DRI2, there is
one copy of libmesa.a in each DRI driver.  It is hard to say which is
better since both are not quite right.

It is never a sane idea to break DRI drivers, but I am wondering that,
is it possible to construct libGL*.so in a way that both EGL/Gallium and
EGL/DRI2 will work while you (or we) are at it?

For example, in this proposal, it seems libGLESv2.so will consist of
only glapi-es2.  Comparing it with src/state_trackers/es/, it misses a
symbol `st_module_OpenGL_ES2` whose sole purpose is to create an st_api.
If we can add this symbol and dynamically load a new library (consists
of libmesagallium.a) when requested to create an st_api, then both
EGL/Gallium and EGL/DRI2 would work with this libGLESv2.so.  This will
add a minimum amount of code to libGLESv2.so.  Plus, there will only be
a single copy of libmesagallium.a on the system since all libGL*.so will
load the same library.
> Obviously, we should keep the option to compile mesa state tracker as
> gles1 or gles2 only for example (to allow building a small gles2-only
> dri driver and to keep the current gallium setup working).
Yes, a small gles2-only dri driver/state tracker is preferable.  While
gl_context is made multiple API aware, we may still use FEATURE macros
to disable a good portion of mesa code at compile time, and disable the
creation of APIs that depend on the code.
> This is all still work in progress for me, but I'm curious what people
> think of this approach.

-- 
olv at LunarG.com