On Sat, Aug 29, 2015 at 6:57 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > 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.
Indeed, that's a good plan. Hopefully someone can confirm what I said so I'm not just spreading rumours via ./configure --help :) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
