Тёмная тема
− Скрыть
Mirrel
> > попробуй более сложный пример
> попробую, если не забуду.
Откопал свой пример (фрагмент рейтрейсера):
https://gcc.godbolt.org/z/655rMeE61
Их хорошего - векторизует. Из плохого - умеет использовать ровно 2 (два) xmm регистра из 16 возможных, в результате постоянно дёргает стек. Не говоря уже о том, что ему вообще-то AVX указан, а получаем SSE. И корректность работы надо проверять, но сейчас уж лень.
В общем, это лучше, чем совсем никакой векторизации (как у Дельфи), но явно не дотягивает до Си, который может уложить те же вычисления в 5 FMA и 3 сложения:
https://gcc.godbolt.org/z/eKhn6rhzT
Проведя некоторые оптимизации удалось достичь почти невозможного - код стал быстрее в 2.32 раза! от изначальной скорости. Все еще ручная оптимизация(пока что без векторизации, но избавился даже от целочисленного деления)):
Думаю на этом и остановлюсь. Потом еще сделаю тест со сравнением скорости с алгоритмом от Mikle.
ArtProg
> Потом еще сделаю тест со сравнением скорости с алгоритмом от Mikle.
Там качественное масштабирование и двойной цикл для каждого пикселя. Обычно это делают в 2 прохода с одинарным циклом, но неважно - любой цикл медленнее, чем совсем без цикла.
invis, да, я в курсе о качестве. Сравнивал и на спрайтах с большим количеством деталей и на сетках. Оказывается, того же качества можно добиться в один проход тупо усредняя значение с тем, на котором остановилась скан линия, то есть по текущему пикселю. И каждый пиксель служит как бы аккумулятором для финального значения(можно даже математически это доказать, но мне что-то лень расписывать). Более того, приемлемое качество сохраняется, если оставить 2 if-а во внутреннем цикле(как в моем коде) с точным просчетом весовых коеффициентов для площадей и последующей записью в текущий и следующий пиксели, а в два нижних пикселя тупо записывать значение текущего пикселя исходного изображения вобще без усреднений. Ну а там, где качество начинает больше страдать при таких оптимизациях, то добавлены специальные ограничения на множители масштабирования и уже будут вызываться другие функции масштабирования(код выше сохраняет качество при множителе меньшем или равным 0.75, при большем множителе начинают проявляться небольшие рваные пиксели, поэтому масштабирование переключается на стандартное, без сглаживания).
ArtProg
> код выше сохраняет качество при множителе меньшем или равным 0.75
Ну это известный факт, что для ограниченных масштабов можно применять упрощённые алгоритмы.
В тех же видеокартах встроенное сглаживание - довольно примитивная билинейка по 4-м точкам, но всё-таки у неё допустимый диапазон побольше, увеличение произвольное, уменьшение до 0.5 (для меньших масштабов - мип-мэппинг, заранее уменьшенные в 2,4 и.т.д. раз картинки).
Я хотел сказать, что сравнивать скорость разных алгоритмов нет большого смысла, и так понятно, что упрощённый быстрее. Но не настолько быстрее, как мог бы быть написанный на Си.
invis
> уменьшение до 0.5 (для меньших масштабов - мип-мэппинг, заранее уменьшенные в
> 2,4 и.т.д. раз картинки).
Мип мапинг начинается как только идёт уменьшение менее 1.0 если не накрутить биас мипмапов. И единственный адексатный способ это мипмапы, а для 3д анизотропные ещё нужны.
Обычно как только люди понимают что делает видюха и как она это делает, перестают пытаться на цпу пиксели рисовать так как это чудовищно, нереально неэффективно, а производительность на цпу ещё много зачем понадобится. Фактически на цпу нужно считать линейный код, а на гпу параллельный. Тот-же парсинг текста на гпу не сделать нормально так как это задача для линейного прохода. А рисование треугольничков это параллельная задача(за исключением dd) и гпу с ней отлично справляется, из-за того что все пиксели треугольника можно запустить на отрендеривание параллельно.
samrrr, видюху будет еще чем нагрузить, главное фантазия). Вы ж надеюсь понимаете, что игра это не только рендер. Тот же AI например или физика.
ArtProg
> samrrr, видюху будет еще чем нагрузить, главное фантазия).
И чем ты видюху нагружаешь?
> Вы ж надеюсь понимаете, что игра это не только рендер. Тот же AI например или физика.
Вы ж надеюсь понимаете, что задача рендера ложится на видюху лучше всего. Даже лучше чем физика.
А AI ложится на видяху вообще паршиво. Из AI на видяху хорошо ложатся только нейронные сети, но как AI - это такое себе решение.
ArtProg
> Тот же AI например
Аи на шнйдерах? А я бы посмотрел на это)))
ArtProg
> физика
Физика сложнее кубиков на шейдерах? А такое бывает чтоли?)
MrShoor
> Вы ж надеюсь понимаете, что задача рендера ложится на видюху лучше всего.
Ну я то понимаю, а кое-кто похоже ни разу с видюхой не работал вообще.
samrrr
>Аи на шнйдерах? А я бы посмотрел на это)))
Я бы тоже). Есть парочка идей на этот счет, но это уже как-нибудь потом.
>Физика сложнее кубиков на шейдерах? А такое бывает чтоли?)
Частицы, в частности симуляция всяких жикостей. На процессоре считать такое наверное будет слишком затратно.
ArtProg
> Частицы, в частности симуляция всяких жикостей. На процессоре считать такое
> наверное будет слишком затратно.
А знаешь что еще выгодно считать на видеокарте, и что затратно на процессоре?
MrShoor, для 2D пока что с головой хватает. Тяжелые обьекты(типа трехмерных персонажей персонажей, как в ремейке Castlevania или The Darkest Tales, где окружение спрайтовое, кроме персов), если такие и будут, то да, будет присылать видеокарта.
ArtProg
> Частицы, в частности симуляция всяких жикостей.
Я же сказал сложнее, а не проще) Частицы то на гпу запросто делаются.
ArtProg
> для 2D пока что с головой хватает.
Вижу. Настолько хватает, что ты даже топик по оптимизации создал. :)
А делал бы на GPU - подобного топика не было бы, ибо там стократный запас производительности для 2д графики.
🍬x2