[Mesa-dev] GLES1/2 and DRI drivers

[Brian Paul]

Kristian Høgsberg wrote:
> 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.

Still catching up on email but just thought I'd say that this sounds 
good in general.

I think there's lots of opportunity for clean-up and unification of 
core Mesa and the ES1/2 state tracker code.

-Brian