[Mesa-dev] GLES1/2 and DRI drivers
olvaffe at gmail.com
Tue Apr 13 03:05:34 PDT 2010
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.
> - 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?
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
More information about the mesa-dev