OpenGL ES v1.1 will add support for the ARB_matrix_palette of desktop OpenGL as part of its core functionality (enabling vertex skinning). Khronos is asking for feedback from OpenGL ES developers to define the minimum size of matrix palette (i.e total numbers of matrices) that an OpenGL ES application would want to define in the palette.
(In case you have been in a cave, OpenGL ES is OpenGL for embedded systems such as cell phones and handhelds - hardware acceleration is being added to the new line of cell phones coming out now, as well a gamepads, pdas, etc.)
Hmm… hasn’t this extension been pretty much deprecated on modern hardware? Isn’t it a mistake to introduce it to OpenGL|ES especially when footprint & complexity is an issue?
I’m not a member of the Khronos group, so I can’t say with any real authority. However, it seems that vertex blend & matrix palette are much easier to implement in restrict size hardware than full vertex programs. Not only that, with full vertex programs you need a vertex program compiler, which increases the software footprint. Supporting vertex blend & matrix palette gives a lot of useful functionality without bloating the hardware or the software too much.
Both of those extensions were DOA on desktop / workstation hardware because the software size issue of vertex programs did not exist. At the time when those extensions came out hardware underwent a couple process shrinks really quick and suddenly you could have chips with 80 million transistors without a problem. Can’t really do that (yet) in the embedded space.
Part of the reason this happened is because hardware TCL came to “game” hardware so late. Various companies had been implementing full hardware TCL in “workstation” hardware for years before GeForce or Radeon hit the market. If anyone in the CAD market cared about skinning, we probably would have seen vertex blend and matrix palette in core GL years ago. Embedded hardware is basically where workstation hardware was 8 or 10 years ago.
Regarding the need to have a vertex program compiler in the embedded implementation, this is not really an issue unless you want to have dynamic compilation. Otherwise just make a SDK offline tool which compiles the vp to byte code and define a new program format for glProgramStringARB (GL_PROGRAM_FORMAT_ASCII_ARB nowerdays), e.g. GL_PROGRAM_FORMAT_BYTE_CODE_ARB.
One could even make this byte code as a vendor specific extension, so that the byte code maps directly to the chips native microcode.
