Неэффективный "графический анализ"

Всем доброго времени суток!
Прошу консультации уважаемых экспертов в области графического анализа с использованием OpenGL.

Я постараюсь описать задачу абстрактно, поэтому могут иметь место некоторые недосказанности. Также я буду отсылаться к картинке, которую приложу.
Итак, задача. Имеется некоторое плоское поле, ограниченное минимальными и максимальными координатами X и Y. В пределах этого поля заключена некоторая "непрерывная информация". В том же пространстве, но не обязательно только в пределах поля, рассчитывается сложная траектория (кривая Безье) по некоторым опорным точкам. Необходимо (быстро) выяснить, какую "информацию" обрабатывать нужно, а какую - нет. Что за "ифномрация" требует обработки - не суть - но необходимо сказать, что "аналитическая" обработка этой информации по отношению к новопостроенной кривой - смэрть с точки зрения необходимого времени (или вычислительных ресурсов). К тому же, слоёв это "непрерывной информации" может быть много, и они несовместимы по смыслу; "информаиця" меняется чрезвычайно редко или не меняется вообще (относительно требуемого времени анализа).
Точность в рамках этой задачи вторична - выяснение тенденций гораздо важнее, поэтому вот что мной было придумано для решения задачи:
1. растеризация поступившей "информации" - она может быть легко представлена в графическом виде, и особенно, с точки зрения слоёв (получается эдакая 3D-текстура);
2. использование конвейера OpenGL для рисования нужных кривых прямо поверх созданной 3D-текстуры с целью "прямого анализа" - на вход вершинного шейдера поступают все данные о текущей кривой, геометрический шейдер её рассчитывает и передаёт дальше получившуюся ломаную, а фрагментный шейдер смотрит, какие пиксели участвуют в расчёте, сразу вызывает нужную информацию из всех слоёв 3D-текстуры, обрабатывает её, и распихивает по SSBO, из которых я буду производить чтение результатов.
В целом, всё описанное выше изображено слева на картинке (зелёным - группа кривых Безье).
На первый взгляд кажется, что всё просто и быстро - бери, да делай. Но, разумеется, есть нюансы. Чтобы я мог проворачивать вышеописанную схему, необходимо, чтобы OpenGL растеризовал кривую на буфере (FBO) такого же размера, что и 3D-текстура. Растеризованная "информация" может быть огромных размеров - на картинке, в качестве примера, я привожу размеры в 108554 на 91210 пикселей - это средний случай. FBO же, в свою очередь, не может быть больше, чем 32768 пикселей по любому из измерений. Выход - резать 3D-текстуру на "слоёные блоки" одинакового размера, но не более 32768. (Также OpenGL не любит нечётные размеры текстур.) Для приведённого на картинке случая, "крупное" изображение поделено на 12 равных частей, и FBO, на стадии создания шейдерной программы, получит именно такой размер.
Теперь я могу полностью написать программу, делающую то, что мне нужно; и я написал. И работала она плоховастенько - в диспетчере задач я видел долгие простои GPU между пиками нагрузки и какие-то скачки на 12 Гб в ОЗУ в те же моменты времени. Я почитал документацию OpenGL и понял, что резервировать память под все слои "части изображения" при помощи в конструкторе, и делать на каждом вызове расчётного метода (итеративно - для каждой "части изображения" до вызова ) это, конечно, идея рабочая, но бесполезная - куча простоев и какое-то постоянное выделение памяти в ОЗУ подо что-то непонятное.
Я перешёл на PBO и создал кольцевой буфер на 2 звена (а также сопутствующие объекты синхронизации и прочее, прочее). Это привело к тому, что GPU теперь практически никогда не простаивает, но! Если я искусственно сделаю так, что я смогу загрузить всю "информацию" в память GPU за один раз - на этапе инициализации - и в расчётном цикле просто её использовать, не подгружая и не анализируя "по частям", то PBO-реализация работает медленнее (в разы), чем упомянутая ранее "первая реализация", даже если вся "информация" весит 250 Мб. Ну не может копирование занимать столько времени - следовательно, проблема в управлении.
Кроме того, всё это дело ещё любит падать либо на этапе синхронизации:
Либо на этапе считывания SSBO-буфера:
Если же я попытаюсь поставить до места падения, то падать программа начинает на . Происходят падения случайно - бывает, при большом объёме посылаемых мной данных, а бывает и при весьма скромных.

Я понимаю, что весьма сумбурно описал ситуацию, но я и не рассчитываю, что кто-то решит проблему за меня - я хотел бы, чтобы кто-нибудь смог направить меня в нужную сторону, подсказав какие-то общие принципы, которых необходимо придерживаться при реализации подобного механизма. Очевидно, я как-то неправильно работаю с памятью, но а как правильно-то? В спецификациях пишут общие правила, то и дело упоминая полуопасный функционал, который "должен чётко контролироваться разработчиком" (там было что-то про буферы, за которыми перестаёт следить драйвер по требованию программиста, потокоые буферы и ручную синхронизацию).
Я буду невероятно благодарен за любую помощь, советы и подсказки! Спасибо!

P.S. Я вообще не против заморочиться и сделать предельно эффективно - но я правда не понимаю, куда двигаться. Программа то падает, то работает при условиях, в которых падала всегда без исключений, то шлёт неверные данные, хотя раньше такого не было, то монитор отрубается до перезагрузки после запуска теста (а компьютер продолжает себе работать - то есть, я руками поломал что-то в памяти GPU).

Миниатюры

 

0

Сообщение от Ромуальд_7 Я вообще не против заморочиться и сделать предельно эффективно - но я правда не понимаю, куда двигаться.

Мне кажется, что ошибка была совершена 5 лет назад - при формулировке стартовых задач и их способов решения. Имею в виду Ваши темы 2020г про минимальный эллипс, огибающий все точки окружности, и про решение систем нелинейных неравенств. Вот оттуда до сих пор и берутся/тянутся переходы из непрерывного в дискретное (и, м.б., затем обратно - для результатов) и попытки решать проверками условий - в т.ч. и потому, что промежуточные объекты/результаты (после которых Вы делаете следующий шаг / берёте новую задачу/подзадачу) выходят неоптимальными/"плохими".

Сообщение от Ромуальд_7 В пределах этого поля заключена некоторая "непрерывная информация". В том же пространстве, но не обязательно только в пределах поля, рассчитывается сложная траектория (кривая Безье) по некоторым опорным точкам. Необходимо (быстро) выяснить, какую "информацию" обрабатывать нужно, а какую - нет. Что за "ифномрация" требует обработки - не суть - но необходимо сказать, что "аналитическая" обработка этой информации по отношению к новопостроенной кривой - смэрть с точки зрения необходимого времени (или вычислительных ресурсов).

Как возможность/идея - не сидеть в рамках логики постановки и решения ТОЛЬКО прямых задач.
"Информацию", думаю, вполне можно менять (хотя-бы "рабочую копию" некоторого исходного массива этой информации). В сторону дискретизации ПО ЕЁ ЗНАЧЕНИЯМ, т.е. изменять каждое исходное значение в сторону приближения к одному или другому заранее вводимому "порогу". А далее, после некоторого числа шагов итерирования некоторой общей (на всём многомерном "поле информации") "функции потерь", кидаем каждый пиксел, в соответствии с его изменённым значением, в один или другой набор (требующий или не требующий дальнейшей обработки).
И работать тут (менять значения данных на входе модели) - градиентной оптимизацией. Аналитика не нужна - нужна только возможность быстро вычислить градиент некоторой "функции потерь" по входам модели (и, м.б., учесть и прочие ограничения). А на этом принципе (быстрое = максимально параллельное вычисление градиента сложной функции) уже 40 лет как основываются современные нейросетки. Там вычисление каждой отдельной производной - не по отдельной заранее и явно выписанной формуле делается (и не численно - не конечными разностями).
Ещё возможная фишка - вместе с изменением/коррекцией входных данных оптимизировать ещё и саму модель (значения каких-то коэффициентов в ней). Т.е. уже смешанная задача (прямая+обратная сразу).
Ну и "я не тактик - я стратег" (С) анекдот. В смысле - я предложил просто идею, не привязываясь ни к какому способу софтовой или аппаратной реализации. Т.е. про ОпенЖЛ я тут даже и не думал ни капли.

0

Сообщение от Ромуальд_7 и распихивает по SSBO

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

Надеюсь понимаю как не нужно вываливать все подробности/специфику задачи до которых, в общем, никому нет дела. "Это мое дело что/как я считаю" - нормальный подход. Но тогда не вполне ясно что Вы хотите обсудить. Предлагаю считать "как организовать/хранить (массивные) 3D данные в объеме". Если нет - поправьте

Мое личное мнение: 3D текстура - дело гиблое. Вы всегда будете в соплях и с зависшей машиной, ужасными свопами и.т.д. Сама идея прямолинейно хранить объем порочна. Нужно искать др подходы. Посмотрите OpenVDB, может подойдет

1

Сообщение от VTsaregorodtsev Мне кажется, что ошибка была совершена 5 лет назад

Не-не-не, та задача, слава Богу и этому форуму, успешно решена, применена, и закрыта. Как, впрочем, и все, о которых я ранее спрашивал
Это довольно новая (для меня) задача, которая, вообще говоря, решена, но есть проблемы, о которых я и пишу.

По поводу следующих четырёх абзацев - я понимаю, о чём Вы говорите, но моя текущая задача связана с применением генетического алгоритма (далее - ГА), в котором для каждой итерации необходимо решить прямую задачу по "оценке" ткущего получаемого решения, чтобы знать, куда двигаться дальше.
Если Вам бы хотелось, чтобы я накинул конкретики, то я могу. Какое-то время тому назад я писал, в другую ветку форума, про задачу о пересечении ортодромии и ортодромического полигона - там требовалось найти точную дистанцию их пересечения. Тогда было высянено, что функции быстрее, чем то, что я делал, создать невозможно; на этом я и успокоился - функция и правда работает быстро - десятки микросекунд на один вызов (в самом "простом" случае).
Так вот. Моя новейшая реализация ГА предусматривает, чтобы, в наименее нагруженном случае, за одну итерацию я исследовал пересечение не менее ста тысяч ортодромий с не менее, чем 1000 ортодромических полигонов. Если использовать ту "аналитическую" реализацию (возьмём 70 мкс на вызов в среднем), то в лучшем случая одна итерация, совершённая на каком-нибудь R9 9950X (на всех ядрах), потребует ~438 секунд, и это кошмар.
Теперь мы можем вернуться к теме этого вопроса
Я подумал: "у меня есть ортодромические полигоны, но ведь у меня может быть нечто получше - РИСУНОК ортодромических полигонов". Получить такой рисунок довольно легко - это и есть "информация". Дальше я создал реализацию алгоритма Брезенхема, чтобы с её помощью просто рисовать ортодромии прямо на рисунке полигонов, превращая пиксели в дистанцию пересечения. Такой подход не только ускоряет процесс в десятки раз, но и позволяет контролировать точность вычислений через размер изображения полигонов.
Естественно, ~20 секунд на одну итерацию это гораздо лучше, чем 438, но это и самый ненагруженный случай. В самом нагруженном и здесь получается от 300 секунд. Очевидный выход - использовать аппаратную растеризацию - на вход шейдерной программы я подаю кучу ортодромий (каждая - пара точек) и загружаю текстуру с полигонами, и оно там через атомарный счётчик заполняет SSBO, вычисляя "пиксельную дистанцию" внутри фрагментного шейдера (а пара точек превращается в ломаную в геометрическом шейдере). А в общем, всё так, как я и писал в начале.
Таким образом, здесь нет сценария, о котором Вы писали.
И не было бы печали, если бы не описанные мной проблемы со стабильностью программы и не отсутствующие оптимизации по использованию памяти

Добавлено через 17 минут

Сообщение от Igor3D легкость/безмятежность с которой повышаются требования к железу

Ну, смотрите. В ответе выше я более подробно описал задачу, и, опираясь на эту информацию, скажу, что требования могут быть совсем невелики - точность расчёта строго подконтрольна - и я вижу необоснованные падения даже тогда, когда общий объём памяти, занимаемый программой на GPU составляет не более 500 Мб. Я планирую сделать так, чтобы программа могла работать даже на встроенных GPU, что вполне реалистично с современными 880m, 8060S и IrisXe. Объём SSBO же даже для 5 млн ортодромий (я рассматриваю это значение как теоретический потолок) составит 20 Мб на 1 слой информационных изображений (поскольку заполнение SSBO происходит атомарно, при переходе между "частями крупнопланового изображения" шейдер видит другие числа, но продолжает писать всё в те же ячейки SSBO, ведь одна и та же ортодромия может пересекать границы плиток). То есть, требования-то тут очень даже мягкие.

Сообщение от Igor3D Но тогда не вполне ясно что Вы хотите обсудить.

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

Сообщение от Igor3D 3D текстура - дело гиблое. Вы всегда будете в соплях и с зависшей машиной, ужасными свопами и.т.д.

О как, а почему? Я ознакомился с очень большим числом источников, но нигде не было ни слова о том, что такое поведение это "нормальная практика". Вас не затруднит рассказать поподробнее, или сослаться на источник? И не лучше ли с этим в Vulkan'е? Если так, то пора туда наведаться, как думаете? Повторюсь - я готов потратить время на сложные вещи.

Сообщение от Igor3D Сама идея прямолинейно хранить объем порочна.

Не могли бы Вы и здесь немного развернуть мысль?

Сообщение от Igor3D Посмотрите OpenVDB

Спасибо, пока почитаю - выбора всё-равно нет

0

Сообщение от Ромуальд_7 требования-то тут очень даже мягкие.

Ну как сказать.. Напр я пролетаю со своим OpenGL 4.1

По поводу 3D текстуры. Делал аж одну задачу Но впечатления самые неприятные. При каком-то разумном объеме данных рез-т очень бедный, смотреть не на что. А при попытке использовать больший объем быстро получал по рогам, начинается пыхтение и натужность. И еще: современные рендеры работают с объемом, но 3D текстуры там совсем не популярны.

Сообщение от Ромуальд_7 ортодромического полигона

Вот такие вещи прекрасно отбивают желание отвечать Полигон - это планарный N-угольник, на практике часто 3 или 4-х угольник (больше напрямую не рендерят), а иногда упрощается до пошлого "только треугольники!". Полигон обычно задается индексами в массиве вертексов/атрибутов (значения в углах должны быть известны). Также не утверждается, но обычно подразумевается что полигоны образуют некую поверхность, каждое "ребро" шарится 2-мя полигонами. И вот Вы вылазите со своей "ортодромией", и это вызывает смятение. Верно ли я понимаю базовую сущность "полигон" в данном случае/контексте? А может "ортодромический" - это уже совсем иное? Та ну его, лучше с этим не связываться.

Сообщение от Ромуальд_7 Я подумал: "у меня есть ортодромические полигоны, но ведь у меня может быть нечто получше - РИСУНОК ортодромических полигонов". Получить такой рисунок довольно легко - это и есть "информация". Дальше я создал реализацию алгоритма Брезенхема, чтобы с её помощью просто рисовать ортодромии прямо на рисунке полигонов, превращая пиксели в дистанцию пересечения. Такой подход не только ускоряет процесс в десятки раз, но и позволяет контролировать точность вычислений через размер изображения полигонов.

Вот есть 3D модель, нужно нарисовать какую-то линию на ее поверхности. Писал подобное не раз, никаких трудностей не испытал. На GPU правда не делал, но полагаю что вполне возможно. Не верю что для этого нужно привлекать пиксели, фрагментный шейдер, Брезенхема и др. Нужно просто "шагать по полигонам" (каждый знает соседей).

И наконец совершенно непонятно за каким <T> привлекается такая мутная вещь как 3D текстура? Полигоны в несколько слоев? Что вообще с вертексами? Они на поверхности сферы или как?

0

Сообщение от Igor3D современные рендеры работают с объемом, но 3D текстуры там совсем не популярны

А какими сущностями тогда описывается объём? Передают трёхмерные матрицы чисел типа <uint8>?

Сообщение от Igor3D Верно ли я понимаю базовую сущность "полигон" в данном случае/контексте?

Нет-нет, всё верно понимаете. Если взять наш геоид и развернуть на плоскость так, чтобы по оси X были долготы (от -180 до +180), а по Y - широты (от -90 до +90), то получится простейшая проекция. На ней можно нарисовать треугольный полигон "втупую" (рис. 1), а можно - ортодромически-корректно (рис. 2) ("сферический треугольник"). Формально, это всё тот же "обычный" полигон, только вершин теперь не три, а столько, сколько нужно для достижения требуемой точности. И вот численный анализ такой штуковины занимает очень много времени (и быстрее - никак).

Сообщение от Igor3D Вот есть 3D модель, нужно нарисовать какую-то линию на ее поверхности. Писал подобное не раз, никаких трудностей не испытал.

Да нет, в этом действительно нет никаких трудностей. Вопрос мой про анализ получающегося, а точнее, про работу с памятью, по сути, ведь когда я просто один раз гружу текстуру (GL_TEXTURE_2D) и просто анализирую по ней ортодромии получается предельно эффективно, но когда я перехожу к GL_TEXTURE_2D_ARRAY где-то что-то "ломается". Я, вот, и хотел бы понять, что я делаю не так и как вообще умные люди-то делают.

Сообщение от Igor3D И наконец совершенно непонятно за каким <T> привлекается такая мутная вещь как 3D текстура?

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

Сообщение от Igor3D Что вообще с вертексами? Они на поверхности сферы или как?

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

Миниатюры

 

0

Сообщение от Igor3D Ну как сказать.. Напр я пролетаю со своим OpenGL 4.1

Версия 4.6 вышла в 2017 году (середине), хотя там нововведений почти нету, только шейдеры от вулкана можно использовать (со своими недостатками, ограничениями больше, например в вулкане нету юниформ). А так отличий от версии 4.5 нету, а она вышла в 2014 году, ей аж 11 лет будет в августе. В пролете только маки, но там вообще эта технология в виде deprecated и живого мертвеца, могут внезапно удалить. Хотя я считаю что на маке использовать OpenGL как и вообще С/С++ не очень затея, у них свой очень не плохой апи Метал (который не сложнее opengl и при этом можно занизить до уровня вулкана, хотя это вроде устарело но точно не разбирался, может другие способы есть не устаревшие, мне лезть так низко не интересно) да и на плюсах даже окно не создать так как апи ос на objc/swift (второй на голову удобней первого и даже с++).

Сообщение от Igor3D Полигон - это планарный N-угольник, на практике часто 3 или 4-х угольник (больше напрямую не рендерят), а иногда упрощается до пошлого "только треугольники!".

4 угольники есть только в фиксированном конвейере (glBegin/glEnd) в виде GL_QUADS, который потом был удален. Так что на современном апи больше 3 никак.

0

Сообщение от alecss131 хотя там нововведений почти нету

А я, кстати, нашёл одно существенное (для меня) отличие от 4.3-4.5. До 4.6 атомарное сложение в шейдерах могло производиться только над целыми числами, или с расширением, поддерживаемым только GPU NVidia. В версии 4.6 же обязательной к реализации стала операция atomicAdd над типом float. Жаль только, что Qt не даёт создать контекст версии >4.5, так что боремся с переполнением int'а как можем

0

Сообщение от alecss131 В пролете только маки, но там вообще эта технология в виде deprecated и живого мертвеца, могут внезапно удалить.

Пока не удаляют. Я имел ввиду что SSBO требует 4.3

Сообщение от alecss131 4 угольники есть только в фиксированном конвейере (glBegin/glEnd) в виде GL_QUADS, который потом был удален. Так что на современном апи больше 3 никак.

- Папа, тебе урезали зарплату, значит ты будешь меньше пить? - Нет, сынок, это ты будешь меньше кушать

Из того что OpenGL изменил команду рисования вовсе не следует что теперь модели должны быть только из треугольников (как полагают малограмотные люди ). Придется приложить больше усилий чтобы рисовать квадранглы, не меняя при этом базовые данные. Приходится заряжать геометрические шейдеры что принимают 4 вертекса (lines_adjacency) и выдают 2 triangle (phong) или 4 lines (wireframe).

Кстати/к слову. GL_QUADS тупо рисовал квадрангл как 2 треугольника, это было хорошо заметно при цвете вертексов. Поэтому такой вопросик

Есть 4-угольник ABCD. Каким образом лучше разбить его на 2 треугольника? Др словами какую диагональ лучше провести: BD или AC ?

Я не утверждаю что OpenGL это делал

Добавлено через 1 час 37 минут

Сообщение от Ромуальд_7 Да, вот, есть несколько слоёв таких полигонов, и они несовместимы между собой (информационно).

Тогда получается что Вы используете 3D текстуру "не по назначению", ведь она интерполирует данные слоев, а Вы хотите просто "контейнер текстур".

Сообщение от Ромуальд_7 Нет-нет, всё верно понимаете. Если взять наш геоид и развернуть на плоскость так, чтобы по оси X были долготы (от -180 до +180), а по Y - широты (от -90 до +90), то получится простейшая проекция. На ней можно нарисовать треугольный полигон "втупую" (рис. 1), а можно - ортодромически-корректно (рис. 2) ("сферический треугольник"). Формально, это всё тот же "обычный" полигон, только вершин теперь не три, а столько, сколько нужно для достижения требуемой точности. И вот численный анализ такой штуковины занимает очень много времени (и быстрее - никак).

Насколько помню, задача одного расчета

найти (последовательно) все полигоны пересекаемые данной дугой

И я не верю что здесь вообще нужны какие-то текстуры, геометрический шейдер и.т.п. Это должно решаться аналитически (пересечение дуг и все такое), причем не слишком сложно. Напр тупенько привести это к обычной 3D модели (если все вертексы на сфере), и учесть ортодромию для расстояния по дуге.

В общем, у меня стойкое впечатление что не должно оно быть так сложно, развесисто. Перемудрили

0

Сообщение от Igor3D Тогда получается что Вы используете 3D текстуру "не по назначению"

Ну, формально ведь я и не использую 3D-текстуру - я беру GL_TEXTURE_2D_ARRAY, что, как я понял, невполне 3D-текстура.

Сообщение от Igor3D Это должно решаться аналитически (пересечение дуг и все такое)

Так да - я же об этом и написал. Расчёт несложный - до 100 микросекунд на 1 дугу по 1 полигону; то ли дело, когда дуг становится миллион, а полигонов - тысячи. Да - оптимизация, отбрасывание лишних расчётов проверками - это всё полумеры, неспособные (как оказалось) даже приблизить по скорости аналитический расчёт к графическому (даже не оптимизированному). Да, графически ошибка может достигать (тесты) 13%, однако средняя-то ошибка выходит равной <0.3%, а выигрыш по скорости - в сотни раз.
Мудрю, согласен полностью, но всё это не из спортивного любопытства. Да и, де-факто, не такая уж и сложная машинерия выходит.

0

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

0

Сообщение от Igor3D Почему не просто

Да ну я же говорю - это действительно просто, но если умножить "просто" на 1 млрд, то получится "долго". Чтобы избежать "долго" я придумал "сложно".
В конце концов, вопрос-то мой в другом был

0

Сообщение от Ромуальд_7 В конце концов, вопрос-то мой в другом был

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

По поводу Ваших вылетов/падений. Я бы отключил весь код SSBO, падает ли на таком "холостом ходу"? Если собака порылась там, то один из возможных путей: скачать примеры (OpenGL Examples), найти/собрать пример с SSBO и погонять его. Дальше видно будет

0

Сообщение от Igor3D Хотя, возможно, это удачный момент переосмыслить задачу и обойтись без текстур и шейдеров вообще.

Возможно, Вы правы, но вчерашние тесты показывают, что (в случае, когда GPU правильно работает) задачу, на которую 12-ядерному CPU нужен час, GPU решает за 7 секунд Я правда не вижу иного выхода.

Сообщение от Igor3D По поводу Ваших вылетов/падений.

Кстати, есть обновление, да. Я заметил, что у GPU есть какое-то "время релаксации" - если прошлый запуск завершился аварийно (или досрочно по требованию пользователя), то видеокарте нужно либо некоторое время, чтобы вновь заработать нормально (минут 10, как я заметил), либо можно позапускать программу пару-тройку раз (которые завершатся ошибкой), после чего всё вновь починится само. Отмечу, что на Linux (mint) падений не происходит - просто иногда возвращается нулевой указатель при попытке мапить SSBO. Драйвер во главе угла, получается.
Также я нашёл источник регулярных падений - оказывается (уже дежурное слово у меня) GPU не нравится, когда размер фреймбуфера (или загружаемой текстуры - я не понял) не делится на "4", то есть, "не выровнен"; пришлось находить и применять _glFuncs->glPixelStorei(GL_UNPACK_ALIGNMENT, 1); - регулярные падения прекратились полностью.
Однако я нашёл одну вещь, природу которой понять не могу - (пример) - если я работаю с изображением с размерами 26760*27000, то всё идёт "по плану" (выходят какие-тозначения, отличающиеся от истинных на разумный %), но если я меняю размеры на 26750*27000 (-10 пикселей по ширине), то из SSBO я считываю какую-то шляпу - значения начинают отличаться от истинных в 67 раз! В этом тесте я передаю лишь одну ортодромию и одно изображение (и то - при инициализации), поэтому влияние "гонки данных" и прочего устранено. Если же во фрагментном шейдере я настрою атомарный счётчик на выяснение числа обработанных пикселей, то окажется, что их число меняется сообразно изменениям размеров изображения (+/- 5 пикселей).
Вы, случайно, не сталкивались с таким?

0

Сообщение от Ромуальд_7 задачу, на которую 12-ядерному CPU нужен час, GPU решает за 7 секунд Я правда не вижу иного выхода.

Я не предлагал обойтись без GPU. Но почему текстуры, шейдеры и.т.п.? Это действительно самый быстрый способ считать пересечения дуг, используя растеризацию ? Как-то не верится. Напрашивается культурный "computing shader", или вообще OpenCL

Сообщение от Ромуальд_7 Вы, случайно, не сталкивались с таким?

Нет, с OpenGL 4.1 мне такие радости недоступны.
Добавлено через 1 минуту

1

Сообщение от Igor3D культурный "computing shader"

О, а вот это я пробовал около года назад. Оказалось, что драйверы GPU (у AMD помягче, у NVidia пожёстче) не видят применения вычислительных шейдеров отдельно от пайплана рисования чего-либо (например, плащ бэтмена из "Arkham Knight"), поэтому через +/- 1.4 секунды убивает процесс, запустивший выч. шейдер (glDispatchCompute()), который, "почему-то работает ТАК долго". Узнав это, я, конечно же попробовал

Сообщение от Igor3D или вообще OpenCL

и дело действительно пошло бодрее, но я столкнулся с жёсткой необходимостью использовать точность double в аналитических методах, а GPU этого не любят, как тогда я и выяснил. Как результат - около 100 секунд на NVidia A100 - да, это не час, как на CPU, однако ну что это такое? И это формулы для "Земли-шара", где расчётов, де-факто, не так уж и много.

Сообщение от Igor3D последующие расчеты опять потребуют GPU. Об этом стоит подумать/позаботиться

Полагаю, что Вы правы.

Сообщение от Igor3D Я бы не думая равнялся на 16

Я, наверное, так и сделаю, выровняв все текстурные объекты под "квадраты" 8/16/32 * 1024; спасибо

0

0