Войти
ПрограммированиеФорумГрафика

Тестирование софт рендера Quake. (17 стр)

Страницы: 116 17 18 1921 Следующая »
#240
15:52, 27 июля 2018

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

Только личный опыт. Пиши больше кода и экспериментируй.


#241
1:54, 28 июля 2018

Truthfinder
> http://flipcode.com/archives/Fast_log_Function.shtml
Вроде так лучше и скорость и точность:
http://rextester.com/YAYSP4490

> В q1 был z-fighting.
И всё-таки: z-тест вроде же не требует деления на пиксель (в z-буфер пишется как раз то самое zNDC)?
Или там что-то особое?

#242
8:40, 28 июля 2018

FordPerfect
> И всё-таки: z-тест вроде же не требует деления на пиксель (в z-буфер пишется
> как раз то самое zNDC)?
> Или там что-то особое?

A zNDC ты как получаешь? zNDC = z / w = z * rcp(w). Так понятно?

#243
13:40, 28 июля 2018

Truthfinder
> zNDC = z / w = z * rcp(w)
А ну это же можно per-vertex, там на скорость почти пофиг и деления не жалко.

#244
(Правка: 14:40) 14:29, 28 июля 2018

Чтобы конкретнее, я вот о чём:

+ Показать

#245
(Правка: 10:20) 10:19, 30 июля 2018

FordPerfect
> Чтобы конкретнее, я вот о чём:

Какая разница. Я просто раньше ВСЁ считал через rcp, потому что она быстрее div в несколько раз (~ 5-6). Пришлось местами вернуть div, вот и всё. Получилось примерно как у вас.

#246
11:53, 31 июля 2018

Truthfinder
> Я просто раньше ВСЁ считал через rcp
Ага, вот теперь понятно, спасибо.

#247
2:44, 5 сен. 2018

> http://blog.simonrodriguez.fr/articles/18-02-2017_writing_a_small_software_renderer.html
О, кстати https://drive.google.com/drive/folders/14yayBb9XiL16lmuhbYhhvea8mKUUK77W свободно выложили.

#248
15:16, 1 дек. 2018

Truthfinder
Ты рассказывал что отделял обработку пикселей от растеризации -- не для того ли чтобы параллелить обработку фрагментов внутри одного треугольника?
Расскажи плиз про опыт распараллеливания )

Я раньше делал по тайлам 64x64 но ускорения больше 2 раз в среднем не получал -- и это на виндовсе.
А на линуксе что-то совсем плохо.

#249
20:27, 1 дек. 2018

FROL
> Ты рассказывал что отделял обработку пикселей от растеризации -- не для того ли
> чтобы параллелить обработку фрагментов внутри одного треугольника?
> Расскажи плиз про опыт распараллеливания )

Я разные варианты пробовал. Решил остановиться на варианте деления экрана на горизонтальные блоки по числу ядер. Потому что чисто параллельная обработка, потоки работают параллельно и не имеют синхронизируемого доступа к данным, либо read-only, либо своя копия.

В управляющем потоке я делю треугольник на 2 горизонтальной линией от второй вершины. Считаю для треугольника основные константы барицентрические и константы для трассировки рёбер. Это контекст, который я передаю потокам рендеринга, которые уже каждый рисуют треугольник в своём участке окна.

> Я раньше делал по тайлам 64x64 но ускорения больше 2 раз в среднем не получал
> -- и это на виндовсе.

Я рисую по линиям. Так получилось. Сейчас в разработке варианты 4x2, 8x2. То есть пикселей по горизонтали по X берём столько, сколько влазит в регистр. 2 строки берём рядом и идём сразу обе строки. Получаем dFdy один раз и забываем. dFdx берём 1 на 2-4-8 пикселей. По желанию. Логарифм для мипмаппинга также считаем один на 2x2 и 4x2 блок. Или если очень надо, то обрабатываем например 4x2 блок за раз, при этом log считаем один на 2x2 блок.

Но при этом также бежим вдоль 2х линий параллельно. Чтобы cache-friendly.

#250
12:32, 3 дек. 2018

Спасибо!

#251
13:05, 3 дек. 2018

Сильно быстрее оригинального софт-рендера получилось?

#252
18:46, 3 дек. 2018

g-cont
> Сильно быстрее оригинального софт-рендера получилось?

Какого именно? Не понятно как тестить, увы.
Quake 1: timerefresh показывает погоду
Quake 2 1600x1200: мой - 27-30 fps, родной soft render - 74 fps, но родной не использует освещение в рендеринге.

#253
19:37, 3 дек. 2018

Truthfinder
> Quake 2 1600x1200: мой - 27-30 fps
однопоточный ? чёт медленновато :D

#254
(Правка: 20:03) 19:42, 3 дек. 2018

xma
> однопоточный ? чёт медленновато :D

Многопоточный. Как есть. Раз в 8-10 медленнее теоретически возможного. Однако ещё раз. Оригинальный выдаёт 74 без освещения. Не так уж и медленно. А по факту я считаю логарифм на пиксель сейчас. Также я использую GDI для передачи фрейма, а не DX. Что тоже производительности не добавляет. Q2 например использует DX.

И самое главное. У меня ограничение SSE3. Даже не SSSE3 (тем более нет SSE4.1/AVX). Почему так я уже писал. Я лишён удвоенных регистров(AVX), mullo_epi32(SSE4.1) и даже так нужного мне горизонтального целочисленного сложения (SSSE3).

Так что у меня ещё есть большой потенциал для дальнейшего развития. Дорабатывать просто некогда. А вы если сделали лучше, ну попробуйте с этими ограничениями. Тогда глядишь не факт, что у меня будет медленновато.

Страницы: 116 17 18 1921 Следующая »
ПрограммированиеФорумГрафика