Hi, This RFC patch series tries to bring OpenGL ES support to master. It is based on the work of opengl-es branch. The patch series is too large to send to the list. It is available here
http://0xlab.org/~olv/mesa-es-rfc/ Or, gzipped, here http://0xlab.org/~olv/mesa-es-rfc.tar.gz It applies to master directly. Of all the patches, the important ones are patch 0004 ~ 0007. Most of the rests are taken from the opengl-es branch. I will give a summary of the important ones. To test out, one needs to $ cd $(TOP)/src/mesa/es $ make $ cd $(TOP)/src/gallium/state_trackers/es $ make There are some demos under progs. It needs libEGL and egl_softpipe to run. Patch 0004 makes the the generated glapi headers be included with a prefix. That is, #include "glapitable.h" becomes #include "glapi/glapitable.h" This is so that the real headers included can be changed by supplying suitable -I. 0005 adds -c option to some of the python scripts. When activated, it generates headers that is suitable for use with OpenGL ES overlay. Take ActiveTexture for example. In OpenGL, it is called ActiveTextureARB, and ActiveTexture is an alias. Mesa calls this function by CALL_ActiveTextureARB. And there is no CALL_ActiveTexture because it is an alias. However, in OpenGL ES, it is called ActiveTexture. To remedy this, ActiveTextureARB is added as an alias to ActiveTexture. When -c is given, gl_table.py would generate both CALL_ActiveTexture and CALL_ActiveTextureARB. 0006 adds the OpenGL ES XMLs. There are two scripts to help verify the correctness. gl_parse_header.py parses es gl.h or gl2.h from khronos and outputs the contents in XML form. gl_compare.py takes two XMLs and output their union/intersection/difference in XML form. I use them to compare the differences between, say, es1_API.xml with a generated es1 xml. 0007 adds the OpenGL ES overlay to src/mesa/es/. It is largely based on the work of opengl-es branch. It builds, with different sets of glapi headers, * libes1.a and libes2.a, from a subset of $(MESA_SOURCES) * libes1gallium.a and libes2gallium.a, from a subset of $(MESA_GALLIUM_SOURCES) * libes1api.a and libes2api.a, from a subset of $(GLAPI_SOURCES) They serve the same purpose as libmesa.a, libmesagallium.a, and libglapi.a do for OpenGL. The last patch is an example how the static libraries can be used to build libGLESv1_CM.so and libGLESv2.so. libes1.a and libes2.a are not used yet. I will work on getting the DRI drivers to build against them. It will then be possible to provide accelerated OpenGL ES. To fill the gap between OpenGL ES and OpenGL, all gl functions are dispatched to es functions first glColor4x ----> _es_Color4x ----> _vbo_Color4f The dispatch is done through glapi. _es_Color4x is generated from APIspec.txt and es_generator.py, modified from opengl-es branch. It is a passthrough function that converts GLfixed to GLfloat, and passes the converted values to _vbo_Color4f. I am still cleaning up the implementation. But I would like to know your ideas about OpenGL ES support, and the path I take. Thanks. -- Regards, olv ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
