|
»
move dri remap table to mesa core?
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
move dri remap table to mesa core?
by Chia-I Wu-2
::
Rate this Message:
As I frequently need to make sure my changes to EGL core do not break
any of the various EGL drivers, I found that I have to change the configs between DRI and non-DRI ones, and re-build everything. It is a little time consuming, and I think it can be solved by moving the dri remap table to mesa core. I've done some experiments and it seems to work great. The remap table in core is made a feature in mfeatures.h #ifdef IN_DRI_DRIVER #define FEATURE_remap_table 1 #else #define FEATURE_remap_table 0 #endif It has zero impact on the performance of non-DRI drivers because IN_DRI_DRIVER is not defined. But when IN_DRI_DRIVER is defined, the same libmesa.a can be linked to by DRI drivers and non-DRI drivers. Another direct benefit of the change is the separation of function remapping and extension initialization. In every hw dri driver, driInitExtensions is called twice to solve the chicken-egg problem: functions need to be remapped before a context can be initialized, and a context need to be initialized before extensions can be enabled. This problem is automatically solved when functions are remapped in mesa core. There is also no need for the DRI drivers to list an extension only because the mesa core implements some functions in terms of functions in the extension (See the comments in drivers/dri/common/utils.c). How does it sound? I can refine my experiments and post an RFC patch series if it sounds a good idea. -- Regards, olv ------------------------------------------------------------------------------ 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@... https://lists.sourceforge.net/lists/listinfo/mesa3d-dev |
|
|
|
|
|
|
|
|
Re: [PATCH-RFC] move dri remap table to mesa core
by Ian Romanick-4
::
Rate this Message:
-----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@... https://lists.sourceforge.net/lists/listinfo/mesa3d-dev |
|
|
Re: [PATCH-RFC] move dri remap table to mesa core
by Chia-I Wu-2
::
Rate this Message:
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. 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 ------------------------------------------------------------------------------ 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@... https://lists.sourceforge.net/lists/listinfo/mesa3d-dev |
|
|
[PATCHv3] move dri remap table to mesa core
by Chia-I Wu-2
::
Rate this Message:
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 ------------------------------------------------------------------------------ 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@... https://lists.sourceforge.net/lists/listinfo/mesa3d-dev |
|
|
Re: [PATCHv3] move dri remap table to mesa core
by Brian Paul-3
::
Rate this Message:
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 ------------------------------------------------------------------------------ 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@... https://lists.sourceforge.net/lists/listinfo/mesa3d-dev |
| Free embeddable forum powered by Nabble | Forum Help |
