-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chia-I Wu wrote:

> I've managed to clean up the code and created a patch series.  As it
> touches glapi, the file size exceeds the limit the list easily.  I have
> to upload it to somewhere else

I looked over the patches, and they look good to me.  It's hard to give
a thorough review due to the volume of changes.  I only noticed a couple
minor issues.

 - remap.c has no license.
 - remap.h has an incorrect license.  At least the Mesa version should
be changed.

> http://0xlab.org/~olv/mesa-remap-table/ or
> http://0xlab.org/~olv/mesa-remap-table.tar.gz
> 
> There are five patches.  The first patch adds remap.c and helper
> scripts/headers to mesa core.  This is the in core remap table.
> 
> The second patch switches the use of dri remap table and
> extension_helper.h to the in core remap table and remap_helper.h.  As
> the helper headers provide the same source level API, the switch here is
> simple.  driInitExtensions is also updated to call the in core
> functions.
> 
> It also solves the chicken-egg problem that can be seen in all hw dri
> drivers.  The remap table is now automatically initialized in
> one_time_init().  I think this is an important change, and it is good.

I agree.  This was the one thing that always bothered me about the remap
stuff.  I wanted to do it differently, but I didn't see a good way.

> The third patch removes extensions_helper.h.
> 
> The seemingly huge fourth patch does one simple thing.  It moves the
> SET/GET/CALL macros from dispatch.h to glapidispatch.h, in preparation
> for the last patch.  The last patch makes libglapi.a always be built.
> While libglapi.a has nothing to do with IN_DRI_DRIVER, one might notice
> that libglapi.a cannot be built with IN_DRI_DRIVER defined.  This should
> be solved by the last two patches.
> 
> The difference with these patches applied is... no difference, when
> IN_DRI_DRIVER is not defined.  The remap table is simply gone.
> 
> But when IN_DRI_DRIVER is defined, it will give a "remappable"
> libmesa.a.  DRI drivers are linked to it, and they should function the
> same way except for slightly reduced startup time and file size
> (remap_helper.h is more compact than extension_helper.h).
> 
> Non-DRI drivers can also link to it.  They will function, but will be,
> just like DRI drivers, slightly slower when any of the SET/GET/CALL
> macros are used.
> 
> As for libglapi.a, there will be some missing symbols, like
> glGenTexturesEXT, when GLX_INDIRECT_RENDERING is defined.  It is
> possible to modify gl_apitemp.py to generate the stubs.  But it is
> skipped in this patch series.

The issue here was that we want some functions to alias (such as
glGenTexturesEXT and glGenTextures), but they have different GLX protocol.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrdASIACgkQX1gOwKyEAw8eUwCeOojpE8uCEPShDocyO5jD1nir
GAcAn3/3s1LGPt8lRLw5Xe4u/QrwUGY9
=WBcr
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to