> предлагаю: унифицировать промежуточную VM для оных GPU, Уже была попытка, кстати. Называлось сие TGSI, см. http://people.freedesktop.org/~csimpson/gallium-docs/tgsi.html - и оно местами таки юзается. Но на общие вычисления не особо заточено, тому что сейчас в GPU не очень соответствует, и вообще имеет кучу грабель и все на это подзабили. К тому же еще парсить код шейдеров кто-то должен, в том числе и выислительный, а OpenCL уже достаточно приличный кусок от си. Собственно из каких-то таких соображений LLVM нынче и юзают нынче: парсер и генератор кода.
> то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция
> в код VM» делалось побольше всего.
Уже было и уже частично пострадало за свою специфичность, т.к. TGSI был слишком ориентирован на графику, а на GPGPU - как-то не особо. А тут до народа дошло что раз есть столько числокрушилок - хорошо бы на них не только графику считать :). Ну вот народ и возится теперь кто с чем.
В конечном итоге это нынче выглядит так: на вход дается сорц шейдера или вычислительного кернела а как оно там его перегонит сие в нативный код GPU - уже проблемы драйвера. При этом виртуальный набор команд не навязывается, там могут быть грабли еще и в том что этот набор менее фичаст чем свойства конкретного GPU который умеет больше нежели это. При компиляции из сорца такая проблема не возникает ессно. А вот внутрях там уже кто как делает. В открытых дровах интел пилит свою собственную реализацию opencl, амдшники поюзали некоторые части gallium и LLVM как генератор кода, etc. Что там у нуво - хрен их знает. Проприерасы IIRC целиком запилили с нуля свои реализации.
> но, конечно, наименее костыльный метод — это, я так понимаю, таскать с
> собой всю механику GCC (которая изначально не предназначена была для подобного
> использования). или монстра-переростка llvm.
Сдается мне что gcc не сильно меньше LLVM будет в этом плане. Ну и да, gcc на такое изначально никто вообще не рассчитывал, хотя то что его таки прикрутили и для этого, да еще довольно быстро - внушает. Яблочно-бздoтные фанаты бы оборались тут уже если б их фетиш с такой скоростью кто-то допиливал под разные задачи.
> и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit.
> это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со
> своим LuaJIT2.
LuaJIT это конечно круто и замечательно, но шейдеры пишутся на чем-то сиподобном, а OpenCL по сути специфичный диалект си. Так что да, кроме JIT надо бы еще и парсер этого самого си-подобного синтаксиса. Для OpenCL его целиком фигачить не вломак оказалось интелу, АМД заломало и они взяли из шланга. Почему не GCC? Ну... они уже 2 года долбутся с этим, 2 года назад сабжа не было :)
