On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis <gsapount...@gmail.com> wrote: > > It turned out that there were two bugs in glapi. One with using > non-exec memory and the other with using an un-relocated function > template for entry-point generation. I put fixes at: > > Since we are already generating static dispatch stubs for all known > extensions, I guess we can add a few more static stubs and use them, > instead of generating on-the-fly. I put an example about this in the > getproc-debug branch, but I don't know if it's a good idea. >
I put a patch for using executable memory at: http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-execmem It just maps a single page with PROTO_EXEC and uses it as a backing store for generated entrypoints. Since there are many configure variables for glapi, please review and test. The variables are mostly: arch: x86, x86-64, sparc threading: tls, threads, no-threads I tested with tls on x86. Testing means comparing libGL from getproc-debug (based on master) vs. libGL from getproc-execmem-debug (based on getproc-execmem) and making sure new libGL either fixes or does not regress. To build libGL: configure ... make -C src/mesa/ libglapi.a make -C src/glx/ LD_PRELOAD=./lib/libGL.so.1.2 ./progs/demos/fbotexture regards, George. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
