Barrapunto

Tampoco es que se haya dicho que OpenGL esté formado por extensiones. La última versión, la 4.1, es el equivalente a Direct3D 11 y no está copada de extensiones para tener la funcionalidad requerida.

Pero vaya, si tuviera más extensiones tampoco pasaría nada. Quizá no se me ha entendido bien, pero con el tema de que estuviera formado por extensiones me refería a que fueran parte del estándar. Por ejemplo, si AMD añade a OpenGL una extensión para permitir el uso de memoria virtual unificada en gráficos, es posible que lo haga de una forma que sea más genérica. A estas alturas no creo que sean tan estúpidos como para hacer una extensión completamente propietaria que luego lleve un gran trabajo adicional portarla a otros sistemas. Vale, la gente ha aceptado atarse a CUDA, pero si programas en OpenCL esperas que tu código se pueda ejecutar tanto en NVIDIA como en AMD y por tanto necesites comprobar un "feature flag" para saber si hay memoria virtual disponible o no y se entiende que ambos fabricantes harán una implementación compatible, aunque por parte de NVIDIA al estar tan centrada en CUDA sus adaptaciones a OpenCL pueden dejar que desear. Si incluso limita artificialmente el rendimiento en coma flotante de precisión doble en las tarjetas de consumo para vender más Teslas.

Unos ejemplos de lo que me vengo a referir serían las API que hay en GNU/Linux para la aceleración por hardware de la reproducción de vídeo: VDPAU, XvBA, VA-API.
VA-API es la librería agnóstica para acelerar reproducción de vídeo. VDPAU es de NVIDIA y XvBA es de AMD.
NVIDIA dejó en VDPAU explicaciones para que otros fabricantes añadieran soporte para sus gráficas (es código abierto), como por ejemplo Intel que lo estaba considerando o S3 que añadió soporte VDPAU a una gama de sus tarjetas. AMD sin embargo prefirió crear XvBA para competir con VDPAU.
A pesar de todo esto, tanto XvBA como VDPAU son utilizables a través de VA API, por lo que cualquiera que soporte VA API tendrá aceleración hardware con VPDAU o XvBA sin necesidad de soportar independientemente cada librería. Digamos que lo que es acelerado es bastante directo de traducir/suplantar. Ahora, esto tiene sus inconvenientes ya que VA API no implementa todas las fases de decodificación de vídeo y por tanto sólo accede a un subconjunto de VDPAU. XvBA es más básico que VDPAU (llega hasta el UVD2 de las AMD, faltaría el UVD3) y por tanto sería 100% útil bajo VA API.

En OpenGL/CL se podría hacer algo similar. Aunque en un principio cada fabricante lance sus extensiones para hacer uso de la capacidad de memoria virtual de su hardware es de esperar que hagan una implementación oficial que sea usable en ambos o que una de las extensiones sirva como oficial.

Ah, y mi ejemplo de VA-API tiene como contraposición la situación de Windows donde se han doblegado ante el DXVA de Microsoft sin pelearse de forma absurda entre sí. En este caso digo que se han doblegado porque en GNU/Linux claramente aunque han añadido soporte para VA-API cada uno sigue mejorando y añadiendo funcionalidad a su librería en vez de mejorar VA-API.