On 2/27/06, Ian Romanick <[EMAIL PROTECTED]> wrote: > Nicholas Miell wrote: > > On Mon, 27 Feb 2006 15:25:03 -0800, Ian Romanick wrote: > > > >>After listening to a couple fairly vocal people squawk about the x86-64 > >>dispatch stubs, I spent some time investigating the raised issues. The > >>primary issue is that the TLS versions of the stubs contains an > >>unnecessary function call to get the dispatch pointer. > > > > I wasn't "squawking", I was complaining that your stated objections to the > > patch were based on erroneous facts. I would've been perfectly happy with > > "the advertised performance benefit isn't worth the effort involved" > > (although, there wasn't all that much effort). > > You also weren't the only one, just the most recent. :) I've received > e-mails from several people on this and closely related subjects. > Besides, I had to say *something* at least semi-inflamitory to make sure > I got people's attention. >:) > > >>The results are not impressive. The libGL.so with the modified dispatch > >>routines is 13KiB larger. > > > > That's odd. The dispatch routines are 16-byte aligned and the inlining > > doesn't grow the size of the routine above 16-bytes. Did actual .text size > > change, or just the library on-disk size? > > Disk size. I did 'strip -g libGL.so.1.2 ; ls -l libGL.so.1.2'. I can > check the .text size tomorrow. I don't have access to the x86-64 system > right now.
It's probably an increase in the size of the unwind info... except that the dispatch functions don't have unwind info (which is required by the ABI, btw, although I don't think it'll matter in practice unless something happens to crash in a dispatch function), so that can't be it. Odd. > > How does dynamically generated dispatch functions improve performance? Are > > the routines different depending on whether or not the app is threaded? > > This isn't an performance issue. It's a functionality issue. Right now > Mesa has no implementation (dispatch or otherwise) for some existing GL > extensions (e.g., GL_ARB_vertex_blend) or any yet-to-be-invented > extensions. Dynamic dispatch support is needed so that a loaded DRI > driver (e.g., fglx_dri.so) can request a new function (e.g., > glVertexBlendARB) be made available to applications. > > Even without considering binary drivers, it allows us to expose new > extensions in open drivers without requiring that the user update their > libGL. At some point in the future it will also allow us to *remove* > static dispatch stubs for functions that have never been implemeneted in > any DRI driver (e.g., glTexImage4DSGIX). Yeah this occurred to me after I sent the message. > > For that matter, why does Mesa have it's own reimplementation of dlsym() > > (or the equivalent for your platform of choice)? > > glXGetProcAddress is part of the GLX API. AFAIK, it was created > /before/ most platforms had dlsym. It's intended to be a cross-platform > way to probe for extension function addresses. It's there because it's > part of the API that we implement. Sorry, I wasn't clear. I was asking why glXGetProcAddress doesn't just call dlsym(RTLD_DEFAULT, "glFoo") instead of reimplementing all that machinery itself. Of course, drivers being able to extend the dispatch table ahead of Mesa throws a kink into that. (I think something could be worked up where the driver exports the new dispatch stubs itself so that dlsym can find them, but I'm not sure how that could be made to work with the dispatch table being changed at runtime -- I think the driver-supplied stubs would have to have their own separate dispatch table that they call through. Of course, this'd be a driver/Mesa ABI change and all the old GetProcAddress machinery would need to be kept around for fun platforms without a dlsym-workalike, so I'm sure it isn't worth the effort.) > > (Also, there doesn't seem to be anything Alpha-related in Mesa.) > > That's weird. I could have sworn that generate_entrypoint > (src/mesa/glapi/glapi.c) had support for Alpha. I guess I was mistaken. > I guess it doesn't matter at this point. For Mesa, ARM or MIPS is > probably a more relevant platform than Alpha. :( Yeah. Good bye, Alpha, we hardly knew you...
