Barrapunto

Hay varios errores en tu argumentación. El más obvio: CUDA y OpenACC se parecen lo que un huevo a una castaña, no tienen absolutamente nada que ver el uno con el otro. El segundo, NVIDIA lleva idea de cargarse CUDA en favor de OpenCL, en cuyo desarrollo participa a través del Chronos Group, es una generalización de CUDA y es a lo que tiende CUDA versión a versión.

Por otro lado, para sacarle partido a CUDA no hace falta, pero ni muchísimo menos, una GPU de 1000€. Incluso en las de gama baja, que tienen menos SMPs, se puede sacar bastante ventaja de CUDA.

¿Qué es lo que probablemente veamos con este movimiento? Seguramente que se extienda el soporte de OpenACC (PGI tenía la exclusiva) y, mucho más importante, que mejore sustancialmente el rendimiento.

OpenACC no está pensado para sustituir cosas tipo CUDA/OpenCL, está pensado para ofrecer facilidades tipo OpenMP para programar aceleradoras. Ni la programación multi-thread manual ha sustituido a OpenMP ni OpenCL sustituirá a OpenACC. Si algo lleva a OpenACC a la extinción, será precisamente OpenMP.

De pm tengo acciones en NVidia.

Creo que querías decir ni OpenMP ha sustituido a la programación multithread manual, ni OpenACC sustituirá a OpenCL. En lo de que si algo lleva a la extinción de OpenACC (del que no sólo PGI tenía la exclusiva, ya que CAPS Compilers también lo implementa, así como el compilador experimental accULL, de la Universidad de La Laguna) será, precisamente, OpenMP, estoy de acuerdo. Y veremos qué pasa con OpenHMPP, por el cual apuesta fuerte PathScale. A mí, como usuario, la verdad es que me gustaría verlo todo bajo un estándar único. OpenMP, ni más ni menos. Y veremos también si NVIDIA acaba ofreciendo los compiladores de PGI como freeware para proyectos no comerciales, como hacen Intel y Oracle.

Pues en tu argumentación hay unos cuantos errores más.

Cómo va a querer NVIDA cargarse CUDA? OpenCL se arrastra detrás de CUDA, versión a versión. Dynamic parallelism? Acceso remoto a otras memorias? Punteros? Soporte de C++?

OpenCL no lo usa ni el tato por tres sencillas razones:
1- Es demasiado low-level para desarrollar aplicaciones. Detectar plataformas y dispositivos, crear contextos y colas de comandos, compilar el código en runtime, hacer una llamada para cada parámetro que se pasa al kernel... Guardar el código en un string! Estamos locos?
2- Es demasiado high-level para desarrollar runtimes. No tiene soporte para manejo de memoria. La memoria está asociada a un contexto que, a su vez, puede estar asociado a unos cuantos dispositivos. La alocatacón de memoria se realiza de forma lazy por el runtime. El rendimiento de las copias de memoria varía para cada runtime; algunos prefieren clEnqueue{Read/Write}Buffer, otros clEnque{Map/Unmap}
3- En teoría es un lenguaje de programación universal, pero para tener un rendimiento razonable hay que escribir una versión para cada dispositivo.

Por otro lado CUDA está orientado a programadores finales.