On Sat, Aug 29, 2015 at 9:46 PM, Matt Turner <matts...@gmail.com> wrote: > On Sat, Aug 29, 2015 at 4:27 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> Why isn't this the default? IOW should this be incompatible with some >> other option and/or set based on some other option? > > Please don't top quote.
I usually don't, but there wasn't a nice logical place for me to ask my question, top seemed as good as any. > > If I understand correctly, this option partially disables an > optimization in the dispatch table, but the options are still > distinct. > > My understanding is that with the x86 assembly dispatch > implementation, either (or both...?) of > > glapi_entrypoint.c:init_glapi_relocs() > entry_x86_tls.h:entry_patch_public() > > patch .text to contain the TLS pointer, so that the expensive "movl > %gs:0x0, %eax" doesn't happen on each GL function call. But that of > course requires a writable .text section, which is frowned upon. > > So --enable-glx-rts (I'd be happy to change the name to something less > cryptic) inhibits that, and instead does the expensive TLS look-up > (see src/mapi/glapi/gen/gl_x86_asm.py) on each GL call, but still uses > the assembly implementation. > > The assembly implementation is able to jump directly to the _mesa_* > function implementation (that is, not a call instruction that pushes > more stuff on the stack), so I think even with --enable-glx-rts, the > assembly implementation is still better than the C implementation. > > We'll see if idr reads his mail and can confirm my understanding. I see. Perhaps a small bit of this commentary can end up in the configure option help? i.e. that it allows .text to be read-only at some performance cost? Basically when I run ./configure --help, it's nice to know what the various options do without being deeply involved in the package's functionality. I think things like "read only text segment" make sense, but then the question becomes why it's not just always on -- mentioning that there's a small performance penalty would be nice. I had actually assumed that this was more about rtasm stuff, but I guess that's all separate. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
