Mesa3D

Hi,

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

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.

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.

-- 
Regards,
olv

On Thu, Oct 15, 2009 at 09:59:05AM -0700, Eric Anholt wrote:
> Not sure the impact on DRI ABI, but I like the idea.  In the automake
> work, I'd been thinking about conditionally compiling multiple copies of
> Mesa core with/without IN_DRI_DRIVER so that we could actually build
> more than one "driver" target at once.  Avoiding this entirely would be
> much nicer.
I have posted an RFC patch series.  It is (slightly) tested on x86 and
x86-64, with and without GLX_USE_TLS.  X server and unpatched libGL.so
seem to load the DRI drivers just fine.

A libmesa.a with remap table can be linked to by any of the drivers.
But there is an issue with libglapi.a.  When GLX_INDIRECT_RENDERING is
defined, glapitemp.h will eliminate some symbols.  It expects drivers to
provide them.  It is possible to modify gl_apitemp.py to generate the
stubs to help drivers.

-- 
Regards,
olv

-----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-----

On Mon, Oct 19, 2009 at 05:15:31PM -0700, Ian Romanick 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.
Thanks.  I have added/corrected the license and uploaded a new version
to

http://0xlab.org/~olv/mesa-remap-table-v2.tar.gz

There is no code change.
> > 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.
My way of doing it is to think of libmesa.a as a library of its own.  It
should not rely on symbols from applications (that is, drivers), and
SET/GET/CALL macros should work without special care because they are
part of libmesa.a API.
> > 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.
Yeah.  To minimize the changes needed, I am thinking re-organizing
glapitemp.h in a way that it can provide _only_ those symbols affected
by GLX_INDIRECT_RENDERING.  drivers/x11/ or gallium/winsys/xlib/ can
then include it to provide the missing symbols.

But it is still weird that libglapi.a has missing symbols, if one views
it as a library.  I would also like to change this while at it.

-- 
Regards,
olv

Hi,

I've updated the patch series again due to conflict with
614e8f220332d5876c787ea07300c6c8508219d5

http://0xlab.org/~olv/mesa-remap-table-v3/
http://0xlab.org/~olv/mesa-remap-table-v3.tar.gz

There is no real change.

This patch series brings "remappable" libmesa.a, which allows building
DRI/non-DRI drivers at the same time.  Patch 0002 enables the remap
table, and it brings some nice cleanups to the DRI drivers
 31 files changed, 66 insertions(+), 546 deletions(-)

A remaining issue is that the real GLX (src/glx/x11/) still cannot be
built at the same time, due to GLX_INDIRECT_RENDERING.  It is unsolved
in this patch series, because it is a separate issue, and is hard to
have a clean fix.

-- 
Regards,
olv

Chia-I Wu wrote:
> Hi,
> 
> I've updated the patch series again due to conflict with
> 614e8f220332d5876c787ea07300c6c8508219d5
> 
> http://0xlab.org/~olv/mesa-remap-table-v3/
> http://0xlab.org/~olv/mesa-remap-table-v3.tar.gz
> 
> There is no real change.
> 
> This patch series brings "remappable" libmesa.a, which allows building
> DRI/non-DRI drivers at the same time.  Patch 0002 enables the remap
> table, and it brings some nice cleanups to the DRI drivers
>  31 files changed, 66 insertions(+), 546 deletions(-)
> 
> A remaining issue is that the real GLX (src/glx/x11/) still cannot be
> built at the same time, due to GLX_INDIRECT_RENDERING.  It is unsolved
> in this patch series, because it is a separate issue, and is hard to
> have a clean fix.

Committed.  Thanks.

-Brian