[Mesa-dev] GLES1/2 and DRI drivers

[Kristian Høgsberg]

2010/4/13 Chia-I Wu <olvaffe at gmail.com>:
> 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.

That sounds good, I'll finish up the patches and post them for more
detailed review.  As for the dispatch table, I'll go with the big
static table we have now, but we definitely want something better for
a gles2 only driver.  I've been talking with Ian about different ideas
how to do this, and we're thinking that we can just do away with the
dispatch table alltogether and have the loader call get_proc for all
the entry points it needs.  We could use something like gperf perhaps
to make this fast enough.

>>  - 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?

Yeah, both the gallium and the DRI way of doing multiple drivers and
APIs have drawbacks.  I think that for gallium it can be pretty
optimal, if you use the gallium DRI state tracker and egl_dri2.  This
will let you use the small libGL, libGLESv2, libGLESv1_CM libraries to
load one catch-all GL state tracker which will then load the gallium
chipset driver.  For DRI, we'll still have a copy of the GL state
tracker in each driver, but that's nothing new.  I'm not sure how
libGLESv2 could work with both with egl_dri2 and egl/gallium, libGL
doesn't do that today.  Maybe it's possible, but I think it's fine if
we just leave that as a decision for the distro/system integrator.

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

Yeah, maybe that could work.  As a first step I'll just create the
DRI-loading libGLESv2 and libGLESv1_CM libraries and maybe we can add
EGL/Gallium compatibility.  But again, things will work just fine if
we use the EGL/DRI2 driver for loading classic and gallium drivers.

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

Yes, I definitely want to keep the FEATURE macro mechanism in place
and expand it so that we some day can build a minimal GLES2 state
tracker / driver.

Kristian