LINUX.ORG.RU

Раздвоение личности std::string под minGW (сборка openCV)

 


0

3

Собственно openCV в итоге собрать удалось, но вот дальше началось непонятное. При сборке тестового проекта (стандартная шняга с открытием картинки) вылетает куча undefined reference. Опытным путём было обнаружено, что у всех функций, которые параметром имеют std::string (алиас cv::String) не совпадает сигнатура и линкёр их не видит. Поиск навёл на подобную проблему со сборкой под мак clang-ом. Там, вроде как, 2 версии разных библиотек с реализацийе std::*, причём сигнатуры как раз совпадают с моими. Вот только никакой информации о подобном раздвоении у minGW не нашлось. При сборке openCV, вроде, никаких подозрительных флагов не нашел и почему такая разница - непонятно. Может кто в курсе, где копать?

Ответ на: комментарий от Iron_Bug

Ты почитай исходники OpenCV! Я и сам подумывал было это говно использовать, но как глянул, что там внутри за быдлокод, понял, что лучше самому с нуля писать! Там вообще никакой оптимизацией и не пахнет. И CUDA они никак не осилят...

anonymous
()
Ответ на: комментарий от anonymous

Да мне пофиг на оптимизации. Если она осилит задачу - я могу хоть на ночь считать оставить. Ещё раз говорю - мне нужно проверить идею, для этого годится что угодно. Хоть китаец, который вручную будет попиксельно обрабатывать. Китаец даже лучше справится :)

TripleGluk
() автор топика
Ответ на: комментарий от TripleGluk

Тогда тебе octave за глаза хватит.

anonymous
()
Ответ на: комментарий от anonymous

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

но вообще, нет там ничего сверхсложного с точки зрения алгоритмов. всё это хорошо оптимизируется через параллельность, но надо грамотно это делать. странно, что они это не осилили.

несколько лет назад мне была интересна возможность использования GPU в вычислениях, чтобы не простаивал зря. например, через OpenCL. но если они хотят для этого проприетарщину втаскивать, то я против. нафиг мне GPU с проприетарщиной? задача сразу теряет смысл. поэтому я это дело забросила.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

использования GPU в вычислениях, чтобы не простаивал зря. например, через OpenCL. но если они хотят для этого проприетарщину втаскивать, то я против. нафиг мне GPU с проприетарщиной?

Как писал выше - кое-какие вычисления вполне можно на шейдерах делать. В OpenGL например. Правда остаются проприетарные драйвера, куда же без них.

TripleGluk
() автор топика
Ответ на: комментарий от TripleGluk

вот именно проприетарщина и не даёт их использовать. я читала, что на открытых AMD-шных дровах OpenCL вроде как наладили. но там ограниченное количество поддерживаемых карт и они довольно слабые. просто не будет профита от таких GPU. а невидия не хочет открывать спецификации. у меня на ноуте она отключена, потому что nouveau данную модель не поддерживает, а проприетарщину я не поставлю. сижу на встроенной карте, мне хватает за глаза.

Iron_Bug ★★★★★
()
Ответ на: комментарий от TripleGluk

кое-какие вычисления вполне можно на шейдерах делать. В OpenGL например

Любые шейдеры это и есть вычисления на GPU, что в программе напишешь, то она считать и будет. Но все типы кроме compute shader являются частью графического пайплайна, в котором не все стадии можно программировать, а compute shader просто запускается и считает

annulen ★★★★★
()
Ответ на: комментарий от annulen

Любые шейдеры это и есть вычисления на GPU, что в программе напишешь, то она считать и будет.

Это как-то расходится с моими словами? Просто вариант обойтись без openCL. Без драйверов, увы, не обойтись.

Стадии не нужно программироватью На шейдерах втупую вполне можно считать на фрагментных. Одна/несколько текстур на входе, одна/несколько текстур на выходе. Некоторые вещи вполне неплохо считает. Правда иногда требуется алгоритм немного вывернуть, чтобы адаптировать под такой формат.

TripleGluk
() автор топика
Ответ на: комментарий от Iron_Bug

А ты без проприетарщины на GPU ничего и не сделаешь, потому что кроме CUDA нормальных средств нет. А OpenCL наркоманы какие-то писали. Один и тот же код на CUDA и OpenCL по размеру в несколько раз отличается, потому что на CUDA раз-два и готово, а на OpenCL гемор сплошной.

Это как некоторые наркоманы мне тут советовали в OpenGL для элементарных вещей вместо GLUT использовать шейдеры. Упоротые товарищи...

anonymous
()
Ответ на: комментарий от anonymous

Эмм... А вместо чего в глют можно шейдеры? Glut - это обёртка над окошками (кривая довольно). Ну простые фигуры и текст выводить ещё умеет. Собсно больше там ничего нет.

TripleGluk
() автор топика
Ответ на: комментарий от TripleGluk

Дык, мне opengl нужен лишь для того, чтобы картинку показать (статика или видео), крестики там нарисовать, да график какой. Тут шейдеры не нужны. В дальнейшем, возможно, придется еще GUI делать — кнопочки всякие добавить...

anonymous
()
Ответ на: комментарий от anonymous

Тогда да, глюта достаточно. Но рекомендую glfw. Те же яйца, только в профиль. Но сильно лучше. Перешел на него когда глют окончательно задолбал и вполне доволен. С ним отлично стыкуется imgui - кнопочки в всякое прочее.

TripleGluk
() автор топика
Ответ на: комментарий от TripleGluk

Пока что я сторонюсь GUI как сифилиса. Но если прижмет, придется заразиться по-полной...

anonymous
()
Ответ на: комментарий от anonymous

imgui крайне простой. он только отрисовывает его. Ну в общем моё дело предложить...

TripleGluk
() автор топика
Ответ на: комментарий от anonymous

на CUDA раз-два и готово, а на OpenCL гемор сплошной.

ну так если на проце общего назначения делать то, к чему он по дизайну не приспособлен, то понятно, что будет медленно.

без проприетарщины в GPU можно кое-что делать. радеоновский драйвер OpenCL поддерживает, хотя и частично. но таких карт немного и они слабые. так что я отказалась от этой идеи. других готовых решений для параллельных вычислений я не знаю. у меня есть всякие тестовые платы с FPGA. можно их приспособить. но это не типовое решение будет.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Хз что у интела с дровами, но на встроенной интеловской видяхе шейдеры тоже вполне крутятся. И по скорости на подходящих задачах рвут ЦП в клочья.

TripleGluk
() автор топика
Ответ на: комментарий от TripleGluk

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Уже писал выше. CL для этого не обязателен. У моей видяхи вообще OpenGL 2.2 потолок, CL с такими не работает. Используется это немного через задницу. Просто через OpenGL рендеришь на экран квад нужного размера, В качестве вычислителя цепляешь ему фрагментный шейдар, а данные передаются через юниформ текстуры на входе и текстуры, в которые он рендерит на выходе.

Можно на shadertoy.com глянуть примеры всяческих симуляций, вроде Навье-Стокса и т.д. которые хорошо на сетку ложатся.

TripleGluk
() автор топика
Ответ на: комментарий от TripleGluk

кхе-кхе... это и взаправду малость через одно место. придумали, как натянуть проприетарщиков :) но это всё равно не управление шейдерами, а только частное решение. хотя соглашусь, что тоже рабочий вариант, если других решений нет.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

А что есть управление? Там до 32х текстур *4 флоата (1, 2х или 3х мерных) на входе и столько же на выходе вроде (на самом деле меньше, зависит от реализации) и сколько угодно проходов скольких угодно шейдеров. Любые расчёты от одномерных до сколько угодно-мерных (2х-мерными слоями). Это не так мало...

TripleGluk
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.