Войти
ФлеймФорумПрограммирование

Общие вопросы по программированию графония. (2 стр)

Страницы: 1 2 3 419 Следующая »
#15
21:24, 13 янв. 2020

nes
> Задолбаюсь прикручивать D3D.
а надо наоборот, прикручивать bullet к тому что у тебя уже есть.


#16
(Правка: 5:22) 5:21, 14 янв. 2020

nes
> Раньше в гапях можно было по отдельности ставить рендер стейты,
> было удобно, было логично.
> Потом, по каким-то странным причинам решили их группировать
> в пачки и теперь их нужно еще и аллоцировать.
рендерстейты в современных гапи группируются согласно тому, как они, ожидаемо, группируются драйвером при общении с самой GPU. например, если для самой видюхи эффективнее аккумулировать полный бленд-стейт и его сабмитить одним пакетом, то вместо того, чтобы делать неявное аккумулирование этого состояния под капотом (как делалалось в d3d9 и opengl), в самом GAPI просто даётся возможность сабмитить сразу всё состояние, а при необходимости аккумулирование этого состояния реализовывать во внешнем коде. это гораздо лучше, потому что даёт возможность как писать максимально эффективный, близкий к железу код без аккумулирования, так и максимально юзерфрендли код с аккумулированием состояний.

#17
7:12, 14 янв. 2020

nes
> Задолбаюсь прикручивать D3D.
Я всегда думал, что единственная связь между физдвижком и рендерером - это

Matrix4 m = phys->GetBodyPosition(this->physBody);
render->SetMeshPosition(this->mesh, m);
Что ещё между ними может вообще происходить?
#18
8:12, 14 янв. 2020

Suslik
Неужели передача нескольких жалких байт стейта в гупу может столь фатально убить производительность?
Это же не мегабайты текстурных данных передавать.

Delfigamer
Лево-Правосторонность СК.

#19
8:43, 14 янв. 2020

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

#20
8:49, 14 янв. 2020

Mikle
> Дело не в байтах, а в количестве вызовов.

да ладно

#21
8:51, 14 янв. 2020

Mikle
Что мешало сделать сраные лох/анлох?

gupaLoh();
gupaSetBlendState(...);
gupaSetDepthState(...);
gupaSetStencilState(...);
gupaSetTexture(...);
gupaSetSampler(...);
...
gupaUnloh();
#22
9:10, 14 янв. 2020

Suslik
> рендерстейты в современных гапи группируются согласно тому, как они, ожидаемо,
> группируются драйвером при общении с самой GPU. например, если для самой видюхи
> эффективнее аккумулировать полный бленд-стейт и его сабмитить одним пакетом, то
> вместо того, чтобы делать неявное аккумулирование этого состояния под капотом
> (как делалалось в d3d9 и opengl)

в современных апи есть PSO, например у nvidia blend входит в сам PS

#23
(Правка: 9:35) 9:33, 14 янв. 2020

nes
> Неужели передача нескольких жалких байт стейта в гупу может столь фатально
> убить производительность?
> Это же не мегабайты текстурных данных передавать.
считай, что каждая передача данных на GPU — это как отправка корабля-сухогруза. ему по большому счёту всё равно, что именно перевозить: 10 тонн груза (полную текстуру) или одного плюшевого медведя. бОльшая часть времени уйдёт на то, чтобы этот сухогруз отправить и доехать. поэтому перевести 10 плюшевых медведей по одному оказывается гораздо дороже, чем отправить 10 тонн плюшевых медведей одной пачкой.

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

#24
9:38, 14 янв. 2020

Suslik
Между Lock/Unlock мы как раз и пакуем судно,
т.е. ололоцировать то ничего уже и не нужно,
нам остается только указать когда отправлять груз.

#25
9:46, 14 янв. 2020

nes
> Между Lock/Unlock мы как раз и пакуем судно,
> т.е. ололоцировать то ничего уже и не нужно,
> нам остается только указать когда отправлять груз.
ну так реализуй, если тебе так хочется, не мешает ведь никто. фишка в том, чтобы делать меньше уровней абстракции в самом GAPI и делать его как можно ближе к тому, как реально происходит общение драйвера с видюхой, а весь синтаксический сахар тогда возлагается на движкописателей и это хорошо, потому что им же этот сахар и использовать в результате, поэтому пусть пишут, что им вздумается.

#26
9:48, 14 янв. 2020

Suslik
Ну так надо было тогда вывалить программисту на руки голые регистры и пусть хозяйничает.

#27
9:55, 14 янв. 2020

nes

ты хоть понимаешь что железки могут быть сильно разные?
кончай страдать ерундой - пиши код лучше - технотролляка

#28
(Правка: 10:01) 10:00, 14 янв. 2020

nes
> Delfigamer
> Лево-Правосторонность СК.
Вообще не в тему.
Даже если ты за каким-то бодуном при отправке тел в физдвиг вывернул им базис, то при выгрузке можно без проблем вывернуть его обратно последующим домножением Matrix4 m на выворатор Matrix4 gPhysToRenderTransform.
При этом непосредственно связь гапи с физухой в конечно итоге всё равно сводится к одной операции - ты берёшь матрицу слева и передаёшь её направо.

#29
10:03, 14 янв. 2020

innuendo
Регистровый эйпи может быть сильно абстрактным,
в том числе и от железки.

Delfigamer
>Вообще не в тему.
Вообще в самую тему, ибо я хз какая там в буллетах СК,
у меня она левосторонняя.

>при выгрузке можно без проблем вывернуть его обратно последующим домножением Matrix4 m на выворатор Matrix4 gPhysToRenderTransform.
И получить переголову.

Страницы: 1 2 3 419 Следующая »
ФлеймФорумПрограммирование