DirectX 10 срещу OpenGL

Всичко свързано с Microsoft DirectX. Въпроси относно HLSL.
Потребителски аватар
YE
Power User
Power User
Мнения: 1554
Регистриран на: 01 дек 2003 21:08
Местоположение: Outer Qwghlm
Контакти:

Мнение от YE » 28 юни 2007 14:13

Zemedelec написа:Мда - вече и OGL драйверите ще са нещо чудовищно, както става с DirectX.
Wellcome обектния модел!
(вместо да разрешат писане на command/push-buffer-и...)
Навремето Кармак като се прочу с една дълга и сочна псувня на ДХ5, точно command buffers псуваше. Сигурен съм, че и тия дето пишат CAD-ове много ще се зарадват на идеята.

Пък и какви ще са тия хардуерно независими command/push-buffers?

GeLeTo
Power User
Power User
Мнения: 285
Регистриран на: 16 дек 2003 17:02

Мнение от GeLeTo » 28 юни 2007 14:37

Zemedelec написа:Wellcome обектния модел!(вместо да разрешат писане на command/push-buffer-и...)
Нямах впредвит от гледна точка на съвместимост.
А от гледна точка на абстракция, която се отдалечава все повече от хардуера.
Предвид че никога няма да има един общ command buffer формат - няма как да се мине без абстракция. Стария state-based модел на пръв поглед изглежда по-добре да пасва с command буферите. Авторите на новата спецификация твърдят че положението е обратното - една от причините е че при създаването на обекта можеш да го смелиш в подходящия за хардуера вид. От друга страна пък не казват как ще сравняват какви state changes са необходими спрямо предишния state object... Дано не ни баламосват :-)

pdimov
gosu
gosu
Мнения: 871
Регистриран на: 02 дек 2003 01:04

Мнение от pdimov » 28 юни 2007 16:09

Доколкото ми е известно, OpenGL драйверите винаги са си били чудовищни, както и абстрактни и отдалечаващи клиента от хардуера. То всъщност това е била целта на OpenGL. Абстракцията де, не чудовищността. DirectX започна като съвсем ниско ниво (хората много обичат да са близо до метала), после постепенно се извиси и той до абстракция (понеже когато металите са десетина, всеки с по няколко изотопа, им идва нанагорно).

PS, Кармак псуваше DX3 execute buffers, в DX5 махнаха глупостите и сложиха DrawPrimitive. Оттогава нивото на абстракция в DX не е спряло да върви нагоре, както и трябва да е, според мен.

Потребителски аватар
Zemedelec
Power User
Power User
Мнения: 782
Регистриран на: 08 дек 2003 15:45
Контакти:

Мнение от Zemedelec » 28 юни 2007 22:02

Command buffera е дело на runtime, като така е една идея по-абстрактен от push-buffer-а. Обаче премахва цели слоеве, ненужни (в по-голямата част от времето) проверки, копиране на памет и т.н.

OGL действительно е бил чудовищен, в смисъл на някои неща, като 'прозрачен' device lost хандлер и някои други неща.
За абстракцията не съм съгласен - най-отдолу слоя върху хардуера трябва да е максимално тънък, пък който иска да си надстройва отгоре (или да ползва готов) слой за обектен поглед на не-обектния хардуер.
В DX10 се опитват да направят такъв модел. Олекотиха DIP-а, супер. Ама има още какво да се желае. FX например не струва, трябва нещо по-тънко...

Потребителски аватар
haho
Power User
Power User
Мнения: 999
Регистриран на: 07 дек 2003 21:52
Местоположение: България
Контакти:

Мнение от haho » 28 юни 2007 22:56

FX например не струва, трябва нещо по-тънко...
Какво точно не ти харесва? Имаш ли идея как би станал по-добре? Питам защото този проект не плозваме Fx framework интензивно но за бъдещ смятам сериозно да се използва.

Потребителски аватар
warjo
Power User
Power User
Мнения: 197
Регистриран на: 21 юли 2005 12:54
Местоположение: Derby, UK

Мнение от warjo » 28 юни 2007 23:19

Без да влизаме в много подробности...
Какво точно не ти харесва?
Липса на крос платформена поддръжка. Ако това не е достатъчно, като правиш engine най-добре сам да си контролираш мета датата директно а не да оставяш на framework дето е правена за експерименти и демота. Ако се прави и data driven shader систгема като граф едитор (ала U3) това става задължително.
Имаш ли идея как би станал по-добре?
ахам...
Питам защото този проект не плозваме Fx framework интензивно но за бъдещ смятам сериозно да се използва.
Всички тези врели некипели дето ти ги приказвам имат смисъл само ако шравиш корс платформен shader центриран engine с който искаш tech художниците да правят ефекти/shaders без да те викат за всяка промяна която им трябва. Ако смятате да си контролирате програмно shader-ите и да не правите крос платформ може с каквото искаш да действаш :)

pdimov
gosu
gosu
Мнения: 871
Регистриран на: 02 дек 2003 01:04

Мнение от pdimov » 29 юни 2007 01:50

Zemedelec написа:За абстракцията не съм съгласен - най-отдолу слоя върху хардуера трябва да е максимално тънък, пък който иска да си надстройва отгоре (или да ползва готов) слой за обектен поглед на не-обектния хардуер.
Ако имаш предвид близост до хардуера както писането на x86 асемблер е близо до модерните процесори, може би. Ако наистина искаш тънък слой, той ще е закачен за текущата генерация хардуер.

Аз отдавна не следя развитието на DirectX особено внимателно де. Напълно е възможно вече да може да се приеме хардуера за достатъчно статичен, че да си измислиш нещо, което да се заблуждаваш, че е тънък слой.

Не съм сигурен за какво обектно става дума, но така или иначе ти си говориш с драйвера, не с хардуера. Ако модела на драйвера е по-удобно да е обектен, лошо няма. Нищо няма да спечелиш от необектния интерфейс, който драйвера после трябва да си транслира обратно в нещо, което на него му е удобно.

Потребителски аватар
Zemedelec
Power User
Power User
Мнения: 782
Регистриран на: 08 дек 2003 15:45
Контакти:

Мнение от Zemedelec » 29 юни 2007 10:19

pdimov написа:Ако имаш предвид близост до хардуера както писането на x86 асемблер е близо до модерните процесори, може би. Ако наистина искаш тънък слой, той ще е закачен за текущата генерация хардуер.
Ако ще да е закачен поотделно към всяка генерация - никой не пречи отгоре да има същия абстрактен слой, както е сега.
Обаче като поискам, да мога да сетъпвам константи и да DIP-вам както си зная, а не да минавам през 2 филтъра, един-2-3 кеша, проверки, глупости всякакви дето поддържат COM върху параметрите.
Искам да рисувам геометрия по екрана бързо, а не да поддържат ref counted текстури... :)
За аналогията с x86 - тя тук е доста далечна, на GPU-то it all about states, а не толкова асемблер. Асемблер вече не се пише на PC.
pdimov написа: Напълно е възможно вече да може да се приеме хардуера за достатъчно статичен, че да си измислиш нещо, което да се заблуждаваш, че е тънък слой.
Не става дума за генерализация - а за проверки, валидации и т.н. При все статичен хардуер.
pdimov написа: Ако модела на драйвера е по-удобно да е обектен, лошо няма. Нищо няма да спечелиш от необектния интерфейс, който драйвера после трябва да си транслира обратно в нещо, което на него му е удобно.
Не знам какво точно разбираш под обектно в дадения случай - в хардуера действительно има обекти, в смисъл на парчета памет, които или идват като указатели или директно за да се натъпчат в push-buffer-а. Обаче начина по който работи от хардуера, е скрит от драйвера и рантайма (и от липсата на документи), и отгоре нещата изглеждат по друг начин. Хората дори се мъчат да разберат как работи GPU-то и отгоре да подават така параметрите, че да се получи по-бързо, докато в API-то и намек няма как трябва да се прави.

haho написа:...
FX си е FX. Става. Ползваме го. SetPixelConstant/SetVertexConstant обаче не е най-доброто, с което може да се сетъпват константи, а се оказва че често там е ботълнека. И незнаеш какво прави отдолу цялата тази работа, въпреки въведеното CommitChanges.

Потребителски аватар
haho
Power User
Power User
Мнения: 999
Регистриран на: 07 дек 2003 21:52
Местоположение: България
Контакти:

Мнение от haho » 29 юни 2007 10:29

Zemedelec написа:FX си е FX. Става. Ползваме го. SetPixelConstant/SetVertexConstant обаче не е най-доброто, с което може да се сетъпват константи, а се оказва че често там е ботълнека. И незнаеш какво прави отдолу цялата тази работа, въпреки въведеното CommitChanges.
Как предлагаш да се сетват константи? Как ще ти е най-удобно и как ще е най-бързо за хардуера?

Потребителски аватар
Zemedelec
Power User
Power User
Мнения: 782
Регистриран на: 08 дек 2003 15:45
Контакти:

Мнение от Zemedelec » 29 юни 2007 10:46

constant buffers + custom разпределяне на параметрите по тези буфери в зависимост от това какво рендваме и колко често сетъпваме дадени параметри.
Има ги в DX10, може да се симулират донякъде в DX9.

pdimov
gosu
gosu
Мнения: 871
Регистриран на: 02 дек 2003 01:04

Мнение от pdimov » 29 юни 2007 16:43

Zemedelec написа:Обаче като поискам, да мога да сетъпвам константи и да DIP-вам както си зная, а не да минавам през 2 филтъра, един-2-3 кеша, проверки, глупости всякакви дето поддържат COM върху параметрите.
Искам да рисувам геометрия по екрана бързо, а не да поддържат ref counted текстури... :)
Е, какво ти пречат refcounted текстурите (и ресурсите като цяло). Все някакъв lifetime management трябва да има. Или искаш да може да закачиш render target, да го освободиш, след което да пуснеш render там, а който е имал късмета да алокира на негово място, да гори като факла? :-) Все пак вече уж повече от една програма ползва хардуера.

Потребителски аватар
Zemedelec
Power User
Power User
Мнения: 782
Регистриран на: 08 дек 2003 15:45
Контакти:

Мнение от Zemedelec » 29 юни 2007 17:04

pdimov написа:Е, какво ти пречат refcounted текстурите (и ресурсите като цяло). Все някакъв lifetime management трябва да има. Или искаш да може да закачиш render target, да го освободиш, след което да пуснеш render там, а който е имал късмета да алокира на негово място, да гори като факла? :-) Все пак вече уж повече от една програма ползва хардуера.
Реф каунтед lifetime management е едно от най-лошите неща които могат да се случат на една система, imho. Никой нищо не знае за никакви паттерни, къде отива паметта и т.н., но пък се надяваме че работи... :)

Е, няма нужда, дето се вика. Аз ще се погрижа и сам, без API-то да се прави на много умно. Ако имам нужда - ще го имплементна отгоре, а не да се чудя какво да го правя без да имам възможност да го махна.
В DX10 най накрая го няма.

А за многото програми - ресурси така или иначе логически не се шерват между процессите - т.е. моя процесс не знае за тях. Ако аз вътрешно се прецакам - това няма отношение към другите процесси.

gemicha
Site Admin
Site Admin
Мнения: 2930
Регистриран на: 20 ное 2003 22:20
Местоположение: USA

Мнение от gemicha » 29 юни 2007 19:54

Zemedelec написа:В DX10 най накрая го няма.
В Dx10 цялата видео памет е виртуализирана. Нищо не е така както изглежда.

pdimov
gosu
gosu
Мнения: 871
Регистриран на: 02 дек 2003 01:04

Мнение от pdimov » 29 юни 2007 20:00

Доколкото четох аз някакви странички за DX10, пак си го има, само че като закачиш ресурс нейде по device, не му се увеличава refcount-а. Но има някаква weak pointer магия, която позволява на device-а да се усети ако ресурса е починал и да не се пробва да го чете/пише. За да се случва това, отдолу трябва да има някакъв tracking; дори и да не ти извадят refcount отгоре, за да си мислиш, че няма, то пак ще си има. Ти просто ще сложиш още един.

Ресурсите логически може и да не се споделят между процеси, но физически мястото им в паметта се - не мисля, че видеопаметта има memory protection. Дадат ли ти възможност да накараш хардуера да пише където си пожелаеш, другите процеси ще бъдат доста изненадани. Нали Xbox360 така го бяха откъртили, през шейдърите. То там за допълнителна екстра видеохардуера може(ше?) да пише навсякъде, дори и по kernel-а.

Потребителски аватар
Zemedelec
Power User
Power User
Мнения: 782
Регистриран на: 08 дек 2003 15:45
Контакти:

Мнение от Zemedelec » 29 юни 2007 20:14

gemicha написа:В Dx10 цялата видео памет е виртуализирана. Нищо не е така както изглежда.
Това в каква връзка...? :)

Отговори

Кой е на линия

Потребители, разглеждащи този форум: Няма регистрирани потребители и 1 гост