On Thu, Sep 03, 2009 at 11:50:14AM -0700, Ian Romanick wrote: > > 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 have the same thing in mind too. What I want to do is, again use ActiveTextureARB as an example,
* rename ActiveTextureARB to ActiveTexture in sturct _glapi_table. Keep its offset. * define _gloffset_ActiveTexture and #define _gloffset_ActiveTextureARB _gloffset_ActiveTexture * define CALL_ActiveTexture and #define CALL_ActiveTextureARB CALL_ActiveTexture(disp, parameters) The idea is to always use "core" names, and define aliases using the core version. This is sort of the changes I made to the python scripts. The non-core versions are defined as a compability layer to avoid "s/ARB//" on each file. Actually, I am thinking removing <category> and make <dispatch>, <enum>, and <type> the top-level childen. Everything is tagged (by core verions or extensions), and an API is constructed from collecting all elements matching a specified set of tags. <dispatch> would look like <dispatch name="Foo" offset="xxx"> <function name="Bar" extensions="..."><!-- params, ...--></function> <function name="BarARB" extensions="..."><!-- params, ...--></function> </dispatch> where Bar is almost always equal to Foo. But this is another topic that worth a thread of its own :) > > 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. > > 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? GL_FIXED is handled when FEATURE_fixedpt is defined. Though, it is not quite complete. For example, it is not handled in _tnl_import_array. It is ok for this patch series because what it builds is a state tracker that does not go through the tnl. I think GL_HALF_FLOAT can be handled similarly. -- 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
