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. -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
