----- Original Message ----- > On 03/10/2014 02:52 PM, Jose Fonseca wrote: > > > > > > ----- Original Message ----- > >> On 03/10/2014 03:09 PM, Ian Romanick wrote: > >>> On 03/10/2014 02:06 PM, Ian Romanick wrote: > >>>> No way. This will break existing applications on Linux. > >> > >> How so? Before, for example, we had glCompileShaderARB(GLhandleARB) and > >> glCompileShader(GLuint) libGL entrypoints and GLhandleARB=GLuint. After > >> these changes it's the same story. No change. > >> > >> > >>> This also breaks the libGL <-> DRI driver ABI. These function entry > >>> points have been aliased for... a decade? I can't understand why we'd > >>> break our own ABI because of something silly that Apple did. This feels > >>> like madness. > >> > >> Hmm, I forgot about the libGL / DRI ABI. Crap. I guess it's the case > >> of using a new libGL with an old DRI driver that would break. Have we > >> even been testing ABI interoperability lately? I'm not sure how > >> libglapi factors into this either. > > > > I'm not sure how the libGL<->DRI ABI is preserved with > > src/mapi/glapi/gen/gl_API.xml edits. If it's a matter of not touching > > earlier entrypoints, then the solution should be to move the new > > entrypoints (e.g., ShaderSourceARB) to the bottom of the gl_API.xml with a > > high offset, so that it gets added to the end of the table. > > The problem is that drivers are built expecting that glCompileShader and > glCompileShaerARB are the same function. As a result, the driver only > asks libGL the offset of one of those functions in the dispatch table, > and it only sets one pointer in the dispatch table. Then an application > tries to call the "other" function, gets a NULL dispatch pointer, and > explodes. > > The inverse problem exists with an old libGL and a new built driver. In > that case the driver will ask for two different offsets, but libGL will > only give it one.
I see. BTW, this means that aliasing in the dispatch API was a design mistake, as it is irreversible in face of this bi-directional backward compatibility requirement -- once two functions are aliased, they need to be aliased for eternity. Even if turns out there was a bad interpretation of the spec, or a new extension comes along and adds conflicting semantics to one of the aliased functions. It would had been better for entrypoint to have a separate entry in the dispatch table, even if two entries end up pointing to the same function. And we should consider correcting that if/when we need to break compatability for some other reason. And this happened precisely with ARB_framebuffer_object and EXT_framebuffer_object, change 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
