> Ну тогда не шейдеры, а opencl/cuda скорее нужен,

Ну просто шейдеры уже сейчас есть, а opencl пока в процессе допиловки. Вот и юзанули то что уже работает. В конечном итоге - ну, считает же.

> хотя я видел только декодер дирака для куды.

В принципе что на шейдерах что на opencl можно считать что угодно. Вопрос в желающих это наапрограммить, не более.

> А с h264 есть затыки какие-то с распараллеливанием некоторых операций,

Есть. Например при зависимости кадров друг от друга не получится декодировать несколько кадров впараллель. Из-за зависимости от других кадров. Но в целом наверное вышло бы неплохо. Плюс всякий там постпроцессинг типа деблокинга параллелится на ура.

> вон, было несколько кодировщиков h264 на куду под винду, но они не сильно
> быстры и дают унылое качество на выходе. И даже то ли амд, то ли нвидия
> собиралась запихнуть DSP, делающий аппаратное кодирование.

Собственно блоки декодирования вроде у обоих есть. И своих грабель с ними есть. Как то - разборчивы к формату и малейшим косякам кодеков. Чуть что не так - и оно будучи дубовым вместо картинки сгенерит полный крап. Софтварные кодеки обладают повышенной терпимостю к неидеальным ситуациям, вплоть до воркэраунда чужих глюков если о них известно.

> него поддержку в драйверах будет в разы проще, нежели переписывать x264
> на glsl или даже на opencl.

Не будет. За отсутствием на UVD (и что там у нвидии вместо него) документации на данный момент. А реверсить такую штуку - ну, идите и разреверсите. Если реверсилка не отвалится. А шейдеры - вот они, уже готовые. Считаются. Понятно по крайней мере куда копать.