Добрый день

Неожиданно получил еще один заказ перевести программу на Linux. Задача небольшая но использует OGL. Подскажите как его на Линукс (RedHat) ставить. Конечно гуглю но ничего конкретного пока не нашел.

Спасибо

Ясно, запускается bundle/package. Так откуда же возьмутся аргументы командной строки если их никто не давал? Ну и будет argv[0] имя самой программы (не bundle) - и все.

Не увлекайтесь всякими "умными библиотеками" да как чего подключить и.т.п. - это все фуфло. Выучите 2 вещи: скалярное и векторное произведение. Твердо и капитально. Сделайте свой прикладной класс чтобы работать в векторах а не месить все время x, y, z. Для начала все. Вот пара задачек, если Вы сможете записать решения в 1 строку кода - Вы и нормали построите

1) Треугольник задан 3-мя точками (p0, p1, p2). Найти его площадь

2) Есть точка P (хотя для решения она не нужна). В этой точке есть вектор нормали к поверхности N и есть направление на источник света  L (от точки к источнику). Найти отраженный вектор света V (угол падения = углу отражения)

Там же, из argv[1] (2 и.т.п). Если пусто - то это проблемы запускающего который не подал аргументы командной строки

Хммм... ну вообще-то 3/4 работы по построению модели - это именно вычисление вертексных нормалей (в различных вариантах) и только 1/4 (часто меньше) - сама геометрия 
На практике используются 3 способа вычисления нормалей:

1) Аналитический. Напр. для сферы нормаль к вертексу = (vertex_position - center).normalize()

2) Градиентный (называется по-разному, но всегда применяется когда нужно пересчитать существующие нормали напр. при деформации исходной модели)

3) Через осреднение всех (или некоторых) нормалей к полигонам в которые данный вертекс входит. Это дает нормали худшего качества чем 1, зато метод универсальный.

Не существует какого-то "легкого удобного" способа, ну разве что если это стандартная модель строится ф-цией библиотеки - но на этом далеко не уехать

Если используется GL_SMOOTH, то надо обеспечить/задать нормали к вертексам (напр. с помощью glNormal..). В Вашем тексте я этого не увидел

Хммм... а не много ли Вы хотите? То есть QTextEdit в который можно вставлять картинки, они будут обтекаться текстом в различных вариациях - довольно близко к профессиональной программе верстки, типа PageMaker

"В общем случае" - ни с чего, забыть как неосуществимую мечту. Потому что классов/инструментов таких нет - значит нельзя А "в частном случае" - сделать конкретную разметку конкретной страницы и повставлять текст кусочками, свой контрол для каждого. И вообще, поубавить притязания

Все файлы грузятся полностью и читаются всего 1 раз. Но не для всех распакованное содержимое держится в памяти, для многих оно хранится постранично. Если памяти достаточно - все будет в памяти, нет - будет подкачиваться с диска.

Не имею цели подколоть, но не знаю что такое кластер (здесь), правда Ну например, выходной имедж имеет 1000 строк. Пользователь может задать число полос, напр 4. Значит будут запущены 4 копии. Первая получит задачу сделать первые 250 строк, вторая - вторые 250 и.т.п. Возможно какая-то копия не рассчитает ни одного пикселя - нечего считать, но результат (черный пустой имедж) все равно будет. То есть разбивается "тупо", по числу строк. Но эта задача давно решена и успешно эксплуатируется.

Да кто ж его знает где этот корень?  Очень может быть я выбрал не лучший путь но в данном случае любой имеет трудности.

niXman, мы весьма отвлеклись от темы, давайте переключаться в личку, с удовольствием отвечу на любые Ваши вопросы.

Подавляющее большинство исходных данных общие и "только чтение" (хотя они и требуют блокировок для подгрузки с диска). Проблема в том что нет четкой "мишени" - в начале расчетов неизвестно какие пиксели и как считать, это выясняется по ходу дела. Сетевой вариант задачи живет долго и вполне счастливо, он разбивает результат(изображение) на N полос (или кадров) и запускает свою копию для каждой части. При этом однако дублируются все исходные данные. Склеивание полос, передача исходных данных по сети и результатов обратно - все это в сумме не так уж дешево. Часть данных строится динамически и это будет тоже повторено N раз. Уязвимое место - относительно короткие расчеты (особенно превью), тогда запуск сетевой бандуры не окупает себя.  В общем пришли к банальной истине: задача должна иметь как сетевой вариант, так и поддержку multi-threading 

При таком шикарном MAX_K (100000000) пройдет все что угодно - вот только где ж мне его взять если по задаче это от 50 до 5000 

OpenMP 
В данном конкретном случае под "синхронизацией" понимается "старт и финиш" задачи для которой привлекаются все нитки. Это расчет одного пикселя который может состоять из N (100, 200, 400 в тестах) подрасчетов (распределяемых между нитками). Каждый подрасчет может быть более или менее трудоемким (зависит от многих исходных данных). Проблемы возникают из-за того что время расчета пикселя достаточно мало (меньше миллисекунды).

Понятно что заманчиво давать ниткам расчеты целых пикселей (а не "подрасчеты"). Но при этом мне надо гораздо больше распараллелить, появляется очень много массивов (где была 1 переменная), появляются конструкции указателей *** (понимаемые самим автором с трудом). Также резко нарастает число блокировок и их вес. Не берусь предсказать будет ли "более высокоуровневый подход" более эффективным, но что усилий и времени он съест много - это точно.

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

Это радует! И все встало нормально? Как ходят старые проекты под 64? Есть ли проблемы с расчетной частью и использованием сторонних библиотек?

Заранее спасибо

Особенный или нет - не знаю, потому что сравнить не могу (Qt стоит только на Mac). А бесполезный - моя личная точка зрения, не хочу чтобы кто-то мне чего-то наколбасил а я потом разбирайся, лучше я сам все сделаю как мне удобно. А если нужны формы - для этого есть designer (с дальнейшей загрузкой из ресурсов).

И еще просьба: давайте не будем забивать тему, для обсуждения creator'а можно создать новую (если есть желание).

Проверил с компилятором Intel
Результаты для 4 ниток, 2 процессора Intel Xeon по 2 ядра
В таблице время в секундах, колонка соответствует 1 тесту, напр. 2_200 значит: тест 2, выполняется 200 вычислений на точку. Сами тесты (1 и 2) отличаются трудоемкостью единичного вычисления.

Придется использовать Intel хотя забот с ним более чем достаточно и компилирует он совсем не быстро. Досадно что GCC проигрывает с таким разгромным счетом, но надо заметить что это OSX, т.е. POSIX. Судя по исходникам GCC 4.4, для POSIX используется простая реализация семафора (mutex + pthread_cond_wait). Для Linux используется гораздо более изощренная техника фьютексов (futex) так что там результат может быть совсем иным.

Я пока на 10.5 (леопард без снега  ), так что извините если посоветую невпопад

1) Не спешите все сразу вставить. Зачистите все и поставьте SDK, просто инсталлером ничего не прописывая. После этого у Вас должны ходить все examples и Вы сможете создавать Xcode проекты с помощью 

qmake -spec macx-xcode example1.pro

2) Ставьте Creator (вещь красивая но бесполезная), он тоже должен пойти

3) Распакуйте исходники куда-нибудь - просто чтобы подсмотреть там что-то. Как собирать "статически" - не знаю и терять время не хочу, все равно скоро надо переходить на 10.6 а в недалеком будущем на Cocoa