|
Флудилка
|
|
|
|
|
Общаемся на различные темы!
|
|
|
|
|
Цитата Ghosteron (  ) А в Ш1 разве такая есть?
Есть, заменять пробовал - не взрывается (дошло до ковыряния в файлах mdl, не помогло).
Злой гений всего мод-комьюнити ВТВ (проклят и изгнан)
|
|
|
|
|
Цитата LVL90DRU1D ( ) Есть, заменять пробовал - не взрывается (дошло до ковыряния в файлах mdl, не помогло).
Поспрашивай тогда в беседе в ВК, я чет хз..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
А вот AVX инструкции себя не оправдали (((
Вот это прям облом дня. Уйма времени была убита на их поддержку, а в итоге разница не выразительна 
https://imgur.com/O2mN5AV
RunTime - это время обработки (в секундах).
Целый месяц в пустую. Обидно блин.
|
|
|
|
|
TonaTor, за то попробовал)))))))
|
|
|
|
|
Ghosteron, вод так и приходится, ради каждого незначительного улучшения пробовать несколько разных вариантов реализации. Ради каждого из которых нужно основательно перелопатить код.
А на выходе, такое...
|
|
|
|
|
|
|
|
С многопотоком тоже как-то не пошло.
Вроде само по себе всё работает
Но это происходит только при попытке выполнить код через два и более потоков,
т.е. omp_set_num_threads(1); работает, а omp_set_num_threads(2); и более - уже нет.
И кто подскажет, что делать?
|
|
|
|
|
Я просто сгорел. Перепробовал уже несколько технологий многоядерного многопотока (OpenMP, TBB, Thread), но все они просто несовместимы с моим основным компилятором, использующим устаревший стандарт C++03. Разработка затягивается.
Остаётся копать в сторону древних, хтоничных Win API... Но тефлоновое покрытие и углекислота исчерпаемы. Нужно доделать хотя бы к НГ.
|
|
|
|
|
Цитата TonaTor ( ) Я просто сгорел. Перепробовал уже несколько технологий многоядерного многопотока (OpenMP, TBB, Thread), но все они просто несовместимы с моим основным компилятором, использующим устаревший стандарт C++03. Разработка затягивается.
Остаётся копать в сторону древних, хтоничных Win API... Но тефлоновое покрытие и углекислота исчерпаемы. Нужно доделать хотя бы к НГ.
Я уже половину не понимаю что ты пишешь, серьёзно
это так сложно пиздеъц))))))))))
|
|
|
|
|
Ghosteron, мои идеи в принципе мало кто понимает с ходу.
Суть в том, что у меня есть какое-то изображение с альфа-каналом, альфа-канал настраивает "прозрачность" пикселя относительно поверхности на которой он расположен. На самом деле "прозрачность" пикселя - это смешение цветов (raster), исходя из его прозрачности (пикселя). В моём случае, "прозрачность" пикселя определяется его собственным, индивидуальным альфа-каналом.
Сам пиксель представляет собой структуру из 4 байт: ARGB - где A - альфа-канал, R - кол-во красного цвета, G - кол-во зелёного цвета, B - кол-во синего цвета. Все эти параметры могут иметь значения от 0 до 255.
Допустим у меня есть DDS файл из которого с помощью nVidia`вского декомпрессора прога вытащила 4K текстуру, т.е. текстуру с разрешением 4096x4096 пикселей. В буфере проги оказывается массив данных весом в 64МБ, которые надо распарсить и смешать с фоновым цветом по формуле: ресурсный растр = (ресурсный растр - фонвый растр) * альфа-канал / 255 + фонвый растр.
Этот расчет нужно сделать для каждого растра в пикселе т.е. 3 раза.
Плюс есть заморочки с нормализацией пикселя
Код
pixel = SWAP32(t); - это инвертирует все байты в пикселе. По принципу (было: 1234, стало 4321).
pixel = (pixel >> 8) | (pixel << 24); - это меняет местами первый и последний байт.
- от этого куска кода ещё только предстоит избавиться.
В результате получается, что для того чтобы отобразить одну 4K текстуру, нужно выполнить кучу действий для каждого из 16777216 пикселей. И все эти действия выполняются последовательно, пиксель за пикселем. И так-как
программный код изначально написан как однопоточный, то выполняется он в одном потоке (шаг за шагом) и на одном ядре процессора. А даже для моего разогнанного Core i5-6400 CPU 3,5GHz 16777216 пикселей - это слишком много.
В результате, рендер отдельных текстур, у меня занимает до 4 секунд. И при этом 3/4 мощности железа в это время просто простаивают. Это как-то не комильфо. Я искал и пробовал разные варианты решения этой проблемы: подменял инструкции (в место операции деления, использовал более лёгкие для проца, операции битового сдвига); пробовал предрассчитать все результаты деления на 255; даже пробовал использовать методы от самих Microsoft.
Но всё это было либо не эффективно, либо ещё и глючело (мой привет программистам из Microsoft).
Из-за этого я решил применить "тяжелую артиллерию" - многоядерный многопоток. Решение по своей сути ультимативное.
Суть в том, что формально пиксели можно рассчитывать в любой последовательности. А значит я могу разбить всё адресное пространство буфера на несколько областей. Для оптимизации по нагрузке на едро количество областей должно соответствовать кол-ву потоков (не физических ядер, а именно потоков. Т.к. у тех процов, у которых потоков больше чем ядер, есть дополнительный набор выходных регистров, который помогает снизить простой конвейера инструкций, вызванный задержками в памяти).
Поэтому в случае многоядерного многопотока (именно многоядерного, т.к. и на одном ядре можно организовать многопоток, но прироста он не даст, скорее даже чутка замедлит), туже 4K текстуру мой проц поделит на участки по 4194304 пикселей
и получется, что:
- первое ядро обрабатывает с 0 по 4194303 пиксель;
- второе ядро обрабатывает с 4194304 по 8388607 пиксель;
- третье ядро обрабатывает с 8388608 по 1258291 пиксель;
- четвертое ядро обрабатывает с 12582912 по 16777216 пиксель.
Получиться разительно быстрее чем сейчас.
Вот суть моей идеи на данный момент. ))))))
|
 | |  |
|
|
|
|
TonaTor, не кажется ли тебе что такая "оптимизация" очень нудная и сложная?
|
|
|
|
|
Ghosteron, ну, написание программ это в принципе нудно.
Однако если получится, то это сразу будет Гут.
К тому же, непонятным мне шаманством, удалось заставить работать одну из этих многопоточных технологий (OpenMP).
Мне буквально на слух удалось заставить работать OpenMP, с помощью MessageBeep )))))
Вот топорная функция подгрузки внешний DLL-ки и вызова из неё нужной функции.
Вот в DLL-ке столь же топорная функция расчета сферических коней в вакууме при при использовании многоядерного многопотока.
Результат пока странный, загрузка ядер по началу не полная. Но надеюсь, что и с этим разберусь.
В общем, разработка сложная но темпы сохранять удаётся)))
Ну а за весь этот многопоток и оптимизацию, я взялся чтоб прога не "вешалась" на слабых ПК.
Надеюсь затраты по времяни того стоят )))
|
|
|
|
|
TonaTor, ты такими темпами смотри не взломай чего нибудь)))))
|
|
|
|
|
|
|
|
Когда бабла не хватила на нормальную ПТ пушку 
|
|
|
|
|
|
|
|
|
|
|
Мда. Теперь у меня накрылся протокол вызова функций из библиотеки DLL.
Уже неделю пытаюсь починить.
|
|
|
|
|
Как я обожаю програмирование...
Одно идиотское, не согласованное соглашение о вызовах функций "__stdcall" - неделю канифолило мне мозги.
Это соглашение работает как стандартный "__cdecl", только требование к оформлению имён аргументов в стеке чуть другие.
Всё различие в символе '@'.
Fuck my brain... Я уже и сам не понимаю зачем мне оно надо.
|
|
|
|
|
|
|
|
АлисА “небо славян“ Брестская крепость
|
|
|
|
|
Цитата TonaTor ( ) АлисА “небо славян“ Брестская крепость
Воевал весь советский народ ;) А это не только славяне ....
|
|
|
|
|
|
|
|
UZSTALKER, весьма уместное замечание 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Желаю сказочного года
Без бед, болезней и помех!
Готовьтесь к новым поворотам
На неожиданный успех.
Пусть только радостные лица
Вас дома будут окружать
И давняя мечта свершится,
Не заставляя долго ждать!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... На работе дедлайн. Спать удаётся урывками по несколько часов в разное время дня. Ещё и простуду подхватил...
В общем "праздник к нам приходит; праздник к нам приходит"...
Так ещё и прожку к НГ написать не успею... 
|
|
|
|
|
|
|
|
UZSTALKER, и Вас, с наступающим...
|
|
|
|
|
|
|
|
UZSTALKER, тогда с двойным наступающим))))
|
|
|
|
|
А вот у меня опять печалька.
Вся та многопоточность, что я прекручивал к своей ДДС-смотрелке, дала лишь 5-10% прироста к скорости.
При этом ещё и работает крайне нестабильно. Почти сплошные неудачи за последние 2 месяца. Обидно...
|
|
|
|
|
|
|
|
После позорной и обидной неудачи с многопотоком OMP,
мне приходится с ещё большим позором и без СМС и регистрации погружаться в WinAPI.
Не знаю, что из этого получится, но надеюсь, что повезёт.
|
|
|
|
|
|
|
|
Таки и на WinAPI может получиться )))
|
|
|
|
|
У меня еще и скоро ДР 
)
