Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chia-I Wu wrote: > >> 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 > > I'll try to look at these patches soon, especially the changes to the > Python. In the meantime, I have a couple questions / comments below.
I haven't had time to review the patches either. I'll be off for the next four days too. >> 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. > > Eric and I were just talking about this the other day. I think it might > be better to just switch core Mesa to the "core" names. There are a lot > of extensions that have been incorporated into the core that are still > accessed within Mesa using the ARB or EXT names. I'm OK with removing the ARB/EXT suffixes where we can, but we have to be careful. For example, glVertexPointer() and glVertexPointerEXT() take a different number of parameters. glBindVertexArray() and glBindVertexArrayAPPLE() have different semantics. There are other cases of differences between the ARB/EXT/core variations of functions. >> 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 > > This sounds like the right approach. That's for libGLES, not regular libGL, right? I wouldn't want to introduce more API function call overhead for libGL. >> 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. > > How are arrays of GL_FIXED handled? Can this implementation easily be > extended to handle GL_HALF_FLOAT? Core Mesa has support for GL_FIXED arrays. See "FEATURE_fixedpt" -Brian ------------------------------------------------------------------------------ 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
