If someone else wants to implement the same functionality, it would only make sense that they use the same name. Creating a new name for the same thing creates confusion.
If they implement the same functionality but add more features, they should support the original extension and add a second, layered extension on top of the original, which they can call anything they want.
If they implement similar functionality but it is incompatible with the original extension (missing certain features), then they should just create a separate extension, or perhaps work to create an LCD (least common denominator) extension – though it should be noted that LCD extensions have problems of their own.
That would defeat the whole point of the naming scheme. “EXT” means multi-vendor. If we use EXT for the name of an extension that no one else has endorsed, we are lying.
Originally posted by mcraighead: That would defeat the whole point of the naming scheme. “EXT” means multi-vendor. If we use EXT for the name of an extension that no one else has endorsed, we are lying.
So, if EXT means multi-vendor, what is wrong with ATI renaming an NV extension to EXT. Nvidia supports it. ATI supports it. Sounds pretty multi-vendor to me.
Too bad the naming conventions cause this level of confusion.
@ Renaming an extension just adds to the already large number of extension strings that a vendor exposes. All of the renamed extensions just create clutter and difficulties for apps that were made using the original extension name (e.g. a program that checked for ATI_SOMETHING would miss EXT_SOMETHING or NV_SOMETHING until it was updated). Prepending an extension with the vendor name just organizes who created it. Promoting to EXT or ARB seems like a wasteful confusion, as in GL_SGIS_multitexture, GL_EXT_multitexture, & GL_ARB_multitexture.
Originally posted by DFrey: Maybe EXT is used when multiple vendors work together to develop the extension. Not simply implement it.
Correct. Renaming an extension without changing the functionality serves no rational purpose; in fact, it is harmful because it can lead to future SW incompatibility issues. It is silly to “promote” extensions from NV to EXT or ATI to EXT. It does make sense to seek another interested vendor before first releasing an extension, if you feel that the IP involved is not “too confidential”. This is what happened with ATIX_texture_env_dot3. “ATIX” meants ATI eXperimental, and so (in theory) an extension with that name should never actually ship (in fact, the ATIX extension used enumerants in the 0x6000-0x8000 range, which is reserved for use in non-shipping extensions only). We contacted ATI and offered to support it as an EXT extension. If we had not done so in time, it probably would have been renamed to ATI_texture_env_dot3 and we would have supported it under that name.
Promoting from vendor to ARB or EXT to ARB does make sense because it indicates that the ARB has officially blessed an extension as a first-class API feature (though an optional one).
Even if there are still things i think being “illogical”, with your help I now understand better how this extension system works.
The key sentence should be “don’t use experimental extensions as their name can change”
[This message has been edited by paddy (edited 01-27-2001).]
Maybe there should be a temporary standard in that the new extensions should be named TMP_whatever_extension_name, and then when ARB approves it, it gets renamed to ARB_whatever_extension_name. I don’t think ATI wants to have any NV_ named extensions, or S3_ or MT_ (Matrox).
I haven’t looked at the radeon specific extensions, but I assume they are ATI_something, and I am betting that the current nvidia hardware doesn’t support it, but NV20 may indeed support it, so I guess we will have to wait 4 months for the NV20 to ship before we can find out.
We all know it is just a name… but rarely do we see companies cooperate on behalf of the end-user.
In addition we are also working on Vertex and Pixel shading extensions as well as a Vertex buffer type extension, a render to texture extension, and a point sprites extension.
The pn_triangle seams to be a extension for n-patches, but I can’t find any documentation for it
There are some general information about n-patches and a plugin for 3d studio max available at ATi’s site, but there seams to be no info about how to use the extension.
WRT the PN Triangle extension, you can learn more about PN Triangles (called N-Patches in DX8) in our paper .
We will release the extension spec when we release hardware that supports these primitives. That said, the OpenGL extension is VERY easy for an application developer to write to. Be sure to pass in normals, set position interpolation order to linear or cubic, set normal interpolation order to linear or quadratic and set your LOD.
