Q: "OpenGL на CPU"?

Преамбула

Несмотря на долбанутость OpenGL-ного API (и, как следствие, огромное количество глупых ньюбских ошибок, которые я допустил), сам OpenGL мне очень понравился.

Вот, к примеру, код в RawDigger, который занимается визуализацией, это 500+ строк довольно нетривиального кода которые делают:

  • Raw Composite
  • Поканальный показ
  • Overexposure/Underexposure
На OpenGL шейдер, который делает ровно то же самое (ну, да, немножко поменьше, в RD есть всякие режимы 2x2 pixels) - это 11 строк кода, несколько строк определения переменных, ну и, да, еще строк 10 для формирования матриц-векторов на которые мы множим и с которыми сравниваем. Ну и работает "немножко" побыстрее.

К сожалению, выяснилось что полноценный OpenGL есть не везде и в новом проекте таки придется делать софтверный рендеринг.

Амбула

Вопрос, собственно, такой: а есть какой-то code generator, который питался бы чем-то вроде кода OpenGL шейдеров и порождал бы код на SSE+треды. И был бы заточен именно под Imaging.

Ну если быть точным, то я знаю уже про

  • ISPC, который я нежно люблю, но он все-таки не про Imaging (4 рядом лежащих компонента пикселя), а больше про скалярное. С пикселями там приходится чудовищно извращаться.
  • Halide - ровно про это, вот прямо таки заточен, но мне очень не хочется таскать с собой llvm runtime, а хотелось бы генерировать статический код при сборке проекта. Кроме того: Windows support is technically feasible, but we have not yet built or tested on Windows, а мне оно нужно исключительно под Винду, у маков и так все хорошо (даже софтверный рендеринг в виртуальной машине - работает и быстро).
  • llvmpipe - даже совсем OpenGL, но есть серия но:
    • Очень не хочется таскать с собой здоровенный llvm runtime
    • Судя по обсуждению в багзилле мозиллы, прикручивание llvmpipe в качестве software renderer есть процесс весьма сексуальный.
Вопрос мой: может быть есть, все-таки, какие-то оффлайновые кодогенераторы, которые сочетали бы оффлайновость ISPC и пикселе-заточенность Halide/Mesa3D?

Comments

нету. ну, вернее не было несколько лет назад, но вряд ли ты хочешь такой код not mature enough

Если речь о Windows и стандартных драйверах, в которых нет поддержки OpenGL вменяемой, то можно пойти по пути Qt5. Они долго думали как бы им выкрутится из похожей ситуации, в итоге они используют OpenGL ES2 и библиотеку для трансляции оной в DX9 под Windows: https://blog.qt.digia.com/blog/2012/10/24/graphics-on-windows-from-a-dif...

Да, и именно по этой причине новый проект я делаю на Qt5

Но выяснилось неприятное - на "старых чипсетных" интелах нет поддержки float-текстур (ни fp16, ни fp32), а 8-битной точности для моих целей недостаточно.

Так опять же вопрос, в OpenGL ES2 в теории есть fp16 текстуры (может и fp32). Qt5 для обеспечения совместимости использует библиотеку ANGLE для трансляции OpenGL в DX9. Может она и в этом случаи подойдет?

Правда писать придется не на OpenGL а не OpenGL ES.

Ну так вот родил тест с fp16/fp32 (именно Qt5+ANGLE), раздал людям, выяснил что
Intel H55 - OpenGL поломан (2.0 есть, но падает), плавучка есть, DX9 работает
Intel G45 - OpenGL 1.4, плавучки нет.

1) G45 умеет OpenGL 2.0.
2) Насколько я понимаю, использовать просто Qt5 недостаточно. Нужно в конкретном месте использовать ANGLE явно.
3) OpenGL 2.0 != OpenGL ES2, там некоторые Extension'ы отличаются по имени.

Да, я использую Angle явно. Или, наоборот, явно его не имею.

И имею следующий результат:

-opengl desktop:
NVidia 480GTX (ну к примеру) - работает
Intel H55 - падает в интеловых драйверах (все extensions есть)
Intel G45 - нет нужных extensions

-opengl es (т.е. через Angle)
NVidia 480GTX - работает (т.е. все текстурные форматы и т.п. нормально транслируются в dx9)
Intel H55 - работает
Intel G45 - не работает.

Т.к. у меня машин на H55 и G45 нету, провести более глубокие исследования не имею возможности.

Можно воспроизвести искуственным образом. Драйвера на nvidia, скаченные с сайта Windows Updates должны идти без OpenGL, т.е. в качестве драйвера будет использована эмуляция через Microsoft'овский драйвер (OpenGL 1.1). Можно вычистить на какой-нибудь машине с нвидией драйвера, поставить их через Windows Update и посмотреть что получится. Как раз от таких ситуаций и должен спасать Angle.

Они идут с OpenGL. Это ровно те же драйвера, что берутся с nvidia.com

Но даже на машине с OpenGL-драйверами - при работе через Angle оно работает именно через Angle. Я туда отладчиком ходил и доходил до DX9-вызовов.

Одна с Qt + Angle проблема, если так соберешь то даже если на машине будет нормальный OpenGL ты им не сможешь воспользоваться c Qt. Angle все равно все через DX гонять будет

не вижу в этом проблемы никакой. Ну, для моих целей.

llvm runtime умеет влинковываться (там патч в две строчки будет -- к мейкфайлу, его динамическим сделали недавно по многочисленным просьбам зрителей)

В юниксе для включения софтрендерера достаточно выставить пару переменных

Софт рендеринг есть в Mesa, правда я не уверен что там всё SSE и multi-thread.