[Mesa-dev] GLES1/2 and DRI drivers
brianp at vmware.com
Wed Apr 14 13:44:54 PDT 2010
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,
>>> 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:
>>> - 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
>> 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.
More information about the mesa-dev