А какие языки можно оттранслировать в код для видеокарты?

Очевидно, что Ada и Objective C можно оттранслировать в Си. Поэтому, если Си можно оттранслировать в код GPU, то и Ada, и Objective C - тоже.

По этой логике, можно на Vala писать код для GPU?

Есть небольшая разница между «можно транслировать для GPU» и «можно писать для GPU» - второе подразумевает наличие готового тулчейна. А так да, трансляция Си дает возможность транслировать Vala.

Другое дело, что лично я не слышал о трансляторах Си для GPU.

То, что в Си, то и можно

CUDA Fortran. ©

В принципе любой можно. Разница исключительно в эффективности.

можно на Vala писать код для GPU?

why not? если компилятор научится генерировать код для gpu, то никаких проблем.
Нынешние видяхи сами по себе вполне могут работать, дело только в софте.

Xeon Phi за GPU считается?

D и Nim.

Все, что транслируется в LLVM IR.

OpenCL это НАДмножество C99.

Если да, то возникают закономерные вопросы: а звуковухой считается? устройством ввода? гражданином США? беспристрастным крокодилом? даром богов? высшим благом? соленым огурцом?

Любые, на которых тебе интересно писать без сисколлов?

а звуковухой считается?

Тут GPU обсуждаются в контексте GPGPU, числодробления, а не рисования графики. Xeon Phi это тоже числодробилка, без графического рудимента.

Я слышал, что когда-то были потуги использования DSP на звуковых картах для вычислений. Тогда процессоры были гораздо слабее, и эти хаки имели смысл. В те времена я бы задал вопрос: "... за звуковуху считается?"

http://fsharp.org/use/gpu/

Тут GPU обсуждаются в контексте GPGPU, числодробления, а не рисования графики. Xeon Phi это тоже числодробилка, без графического рудимента.

Складно речешь, только это не делает его видеокартой.

Ничего нельзя, все что ты можешь - это дергать api, предоставляемые тебе драйвером

А nvidia tesla считается?

Как ни странно, матричные преобразования можно эффективно запускать на GPU, программируя их с помощью Haskell: Accelerate

Любые, которые можно преобразовать в LLVM IR (или в С, а его в LLVM IR). Удобней, если в языке есть нечто, что похоже на #pragma в C, тогда можно ими код разметить на параллелизируемые блоки с помощью OpenACC, и работа с видеокартой сильно упрощается.

Другое дело, что лично я не слышал о трансляторах Си для GPU.

Сейчас есть полупропиетарный тулчейн от нвидии на основе OpenACC, он транслирует обычный код, размеченный дополнительно прагмами, в код, исполняемый на CPU и параллельные ядра для GPGPU с соответствующим управлением размещения данных в различных видах памяти (локальной CPU, локальной вычислительного блока GPU, синхронизируемой) и правильным переливанием из одной памяти в другую. В принципе LLVM умеет генерировать код из IR в машинный код видюхи, да и cuda по сути подмножество C. В gcc открытый вариант этого стека тоже потихоньку приходит, но пока там не всё есть, насколько я помню.

Только это по сути очень тупой и ограниченный DSL, генерящий код на C. Да ещё и довольно плохо написанный.

Хороший вопрос. Мое мнение таково: Tesla хоть в чем-то считается.

Ты видел нормальные транслятор Ады в С? Я всегда считал что Ада эту ступень благополучно минула.

Можно какие-то подробности?

Я вообще не видел трансляторов Ады. Никаких. Мне это не нужно на практике.

Только это по сути очень тупой и ограниченный DSL, генерящий код на C. Да ещё и довольно плохо написанный.

Тебе, конечно, как мега-специалисту виднее)

А весь ли OpenCL работает на GPU? И какой с этого профит, если брать только подмножество C99?

ТС, пиши вообще на шейдерах (геморройно конечно, особенно мало документации для новичков, но возможно). Возможно, будет производительнее и однозначно веселее, чем на CUDA или OpenCL.

Я не являюсь специалистом, просто когда-то хотелось использовать и немного расширить эту библиотеку. Это было непросто из-за хардкода и сильной связанности кода. Да и сами возможности кодогенератора были довольно ограничены: скалярных типов он поддерживал всего несколько.

Могу ошибаться, дело было пару лет назад. Вы, наверное используете эту библиотеку постоянно, и знаете, что всё изменилось с тех пор? Вообще, интересная была задумка. Не подскажете, пересборку бинарника на каждый вызов из хост-кода уже пофиксили? В скольких местах примерно нужно изменить код, чтобы добавить новую векторную операцию?

Впрочем, это оффтопик, т.к. accelerate является просто библиотекой векторизации. GPGPU умеет решать более общие задачи, невыразимые (эффективно) через эти абстракции. ОПа интересует не это, как я понимаю?

Не - на сейчас не вариант. Хотя - а можно ли с кода на шейдерах получить бинарник для ЦПУ? Я всегда считал что шейдеры это исключительно парафия ГПУ.

Я ХЗ. Я знаю про возможность считать на шейдерах в новом OpenGL, но детально не занимался этим.

Хотя - а можно ли с кода на шейдерах получить бинарник для ЦПУ?

Шейдеры в открытом стеке драйверов компилятся в LLVM IR, с него можно делать бинарник на любую поддерживаемую архитектуру, единственное что, в CPU потоков исполнения маловато, память медленная и всё это медленно и печально по сравнению с видюхой. Собственно, так при отсутствии поддержки ускорения видеокартой в месе и делается.

Весь. И я сказал НАДмножество (за вычетом рекурсии и указателей на функции, они идут расширениями)

Т.е. на видяхе выполняется 100% кода, включая всякие счетчики в циклах и т.д.? Прикольно.

Я об этой библиотеке только читал в книге, но все равно считаю, что чужой код называть «плохо написанным и тупым» не совсем корректно, потому что все люди разные, и со стороны не всегда понятно, что имел в виду автор, какие у него были планы, какие ставил цели.

Докину линк в тредик: https://developer.nvidia.com/openacc, там снизу курс, где всё чётко расписано, как они делают, только оно пока есть в проприетарном компиляторе от PGI полностью, и в gcc/llvm-стек приходит кусками как обычно. В llvm кодогенераторы из IR в машинный код большей части доступных параллельных вычислителей есть.