15bd8deadSopenharmony_ci<html> 25bd8deadSopenharmony_ci 35bd8deadSopenharmony_ci<head> 45bd8deadSopenharmony_ci<title>Promoting OpenGL Extensions</title> 55bd8deadSopenharmony_ci</head> 65bd8deadSopenharmony_ci 75bd8deadSopenharmony_ci<body> 85bd8deadSopenharmony_ci<h1>Promoting OpenGL Extensions</h1> 95bd8deadSopenharmony_ci 105bd8deadSopenharmony_ci<p> <i>Promoting</i> an extension refers to moving it from single-vendor 115bd8deadSopenharmony_cito multi-vendor or ARB-approved status, usually by changing the vendor 125bd8deadSopenharmony_citag attached to the extension name string, enumerants and API entry 135bd8deadSopenharmony_cipoints. This is sometimes done when an extension is successful and more 145bd8deadSopenharmony_cilicensees want to support it. This document describes the steps to 155bd8deadSopenharmony_cifollow when promoting an extension. 165bd8deadSopenharmony_ci 175bd8deadSopenharmony_ci<h3>Is Promotion Required?</h3> 185bd8deadSopenharmony_ci 195bd8deadSopenharmony_ci<p> Changing the names creates a significant burden for ISVs supporting 205bd8deadSopenharmony_cithe existing extension. It should not be done gratuitously; if the 215bd8deadSopenharmony_ciexisting interface is sufficient, there's no inherent reason an 225bd8deadSopenharmony_ciimplementation shipped by one vendor cannot advertise and support an 235bd8deadSopenharmony_ciextension using another vendor's prefix. 245bd8deadSopenharmony_ci 255bd8deadSopenharmony_ci<p> If you do this, make <b>certain</b> that the original vendor agrees 265bd8deadSopenharmony_cito freeze the definition of the extension, and that what you ship is 275bd8deadSopenharmony_ciidentical in behavior to what the original vendor is shipping. Shipping 285bd8deadSopenharmony_ciwhat appears to be the "same" extension while implementing different 295bd8deadSopenharmony_cibehavior on multiple platforms is a great disservice to ISVs trying to 305bd8deadSopenharmony_ciuse extensions, and to OpenGL in general. 315bd8deadSopenharmony_ci 325bd8deadSopenharmony_ci<p> <b>Do not</b>, under any circumstances, ship an extension defined by 335bd8deadSopenharmony_cianother vendor without first clearing it with that vendor. 345bd8deadSopenharmony_ci 355bd8deadSopenharmony_ci 365bd8deadSopenharmony_ci<h3>Promoting Without Changes in Behavior</h3> 375bd8deadSopenharmony_ci 385bd8deadSopenharmony_ci<p> If you nevertheless want to promote an extension from 395bd8deadSopenharmony_civendor-specific to e.g. <tt>EXT</tt> status, without changing the 405bd8deadSopenharmony_cibehavior or definition of that extension, then advertise and export 415bd8deadSopenharmony_ci<b>both</b> the old and the new forms of the extension for maximum 425bd8deadSopenharmony_cibackwards compatibility. This means that: 435bd8deadSopenharmony_ci 445bd8deadSopenharmony_ci<ul> 455bd8deadSopenharmony_ci <li>Both extensions strings should be included in the 465bd8deadSopenharmony_ci <tt>GL_EXTENSIONS</tt> string query (or the corresponding 475bd8deadSopenharmony_ci WGL/GLX query, if it extends those APIs). 485bd8deadSopenharmony_ci <li>All enumerants should exist in both 495bd8deadSopenharmony_ci <tt>GL_<i>VENDOR</i>_ENUM_NAME</tt> and 505bd8deadSopenharmony_ci <tt>GL_EXT_ENUM_NAME</tt> forms, with the same values. 515bd8deadSopenharmony_ci <li>All entry points should exist in both 525bd8deadSopenharmony_ci <b>glExtensionName<i>Vendor</i></b> and 535bd8deadSopenharmony_ci <b>glExtensionNameEXT</b> forms, resolving to the same code. 545bd8deadSopenharmony_ci <li>For an extension supported under GLX, the same GLX protocol 555bd8deadSopenharmony_ci should be generated no matter whether the vendor or <tt>EXT</tt> 565bd8deadSopenharmony_ci version of the extension is called. 575bd8deadSopenharmony_ci</ul> 585bd8deadSopenharmony_ci 595bd8deadSopenharmony_ci 605bd8deadSopenharmony_ci<h3>Promoting With Changes in Behavior</h3> 615bd8deadSopenharmony_ci 625bd8deadSopenharmony_ci<p> If you are promoting an extension while changing its definition or 635bd8deadSopenharmony_cibehavior, <b>do not</b> treat it as identical to the old extension. This 645bd8deadSopenharmony_cimeans that: 655bd8deadSopenharmony_ci 665bd8deadSopenharmony_ci<ul> 675bd8deadSopenharmony_ci <li>Any new <tt>EXT</tt> enumerants which differ in definition from 685bd8deadSopenharmony_ci the original <tt><i>VENDOR</i></tt> enumerants should be assigned new 695bd8deadSopenharmony_ci values, and those values registered with SGI. 705bd8deadSopenharmony_ci <li>All new <b>EXT</b> entry points should resolve to different code 715bd8deadSopenharmony_ci in the GL client library than the original <b><i>Vendor</i></b> 725bd8deadSopenharmony_ci extension entry points. 735bd8deadSopenharmony_ci <li>For an extension supported under GLX, different GLX protocol 745bd8deadSopenharmony_ci requests should be generated for the two extensions, so 755bd8deadSopenharmony_ci they can be distinguished on the server side. 765bd8deadSopenharmony_ci</ul> 775bd8deadSopenharmony_ci 785bd8deadSopenharmony_ci<p> None of this should be taken to indicate that code cannot be shared 795bd8deadSopenharmony_cibetween implementations of the old and new extensions; simply that the 805bd8deadSopenharmony_ciimplementation must be able to distinguish whether the old or new form 815bd8deadSopenharmony_ciis being called, since they are de facto different extensions despite 825bd8deadSopenharmony_cisharing similar purposes. 835bd8deadSopenharmony_ci 845bd8deadSopenharmony_ci<hr> 855bd8deadSopenharmony_ci 865bd8deadSopenharmony_ci<p> Last modified April 5, 1999 Jon Leech 875bd8deadSopenharmony_ci</body> 885bd8deadSopenharmony_ci</html> 89