Citiraj:
Autor Bubba
Ako je "multihrading" zapravo multithreading, onda nam objasni kako to "znas", jer je to sto si rekao poprilicna neistina; tim konceptom se bavi compiler i/ili OS, a ne programer (aplikacije koje nisu eksplicitno pisane za visenitne/visejezgrene sustave imaju ogromna ubrzanja uz odgovarajuci operativni sustav). Problem postoji kod izvrsavanje vise paralelnih procesa na istom racunalu, no takvo nesto je tesko uzeti kao kamen spoticanja u napretku programiranja, pogotovo uz MPI i razna druga cuda te namjene.
|
Ono sto je on reko ima smisla, samo ti ocito neznas o cem pricas... Kod se mora dizajnirat da bude paralelan tj. da koristi vise threadova da bi paralelno procesirao odredjene podatke... To je prilicno tesko jer moras napravit optimalan sustav u kojem se threadovi sinkroniziraju a nesmiju provest previse vremena cekajuci jedan na drugog i nesmiju ostat u "deadlocku", debagirat takve situacije je jako tesko za programere i slicno.
Neznam stvarno koi OS ili kompajler ti to omogucava da kod koi nije pisan za MT iskoristava sve jezgre al volio bi ga vidit...
Citiraj:
|
Problem postoji kod izvrsavanje vise paralelnih procesa na istom racunalu no takvo nesto je tesko uzeti kao kamen spoticanja u napretku programiranja, pogotovo uz MPI i razna druga cuda te namjene.
|
na sta mislis sa
MPI ?
Ko sto reko MT je kompleksno podrucje gdje je debugiranje gotovo "nemoguce" pogotovo kad ti kod mora radit na nekonstantnom broju procesora/jezgri... (znaci "standardan" komp moze imat 2, 4 pa 8 i onda jos dodaj HT sto ti je teoretski 16 threadova, svaka ta kombinacija moze donjet neki bug koi si previdio sa dizajnom ili implementacijom ...)
Citiraj:
Autor Bubba
Nema tu kruha. Iza grafike leze teske teksture i lagana matematika . I to je lose lose situation. Optimizaciju danas koriste oni koji to rade zbog znanosti, ili iz fore. I jedni i drugi u tom slucaju ne zive od toga.
|
Ovo ti je osnova 3D matematike u renderiranju i moze imat vise efekta na izgled modela nego tekstura. Neznam, ja se dosta zezam s time i zabavno je al nikad nebi reko da je "lagana matematika", pogotovo ne kompleksnija/realna implementacija istoga (subsurface scatering, specular reflekcije ... ), a jos u real-timeu ...
On topic ...
Raytracing je losa metoda renderiranja za real-time jer iako ima prednost sto su reflekcije ugradjene po defaultu jako puna ray-eva se mora "poslat" u scenu da bi to izgledalo kako treba... Standardni raster je mnogo optimalniji samo sto je neke fenomene (reflekcije, refrakcije i slicno) potrebno malo "drugacije" implementirat (reflekcijske mape, cube mape ...)
Vodeci programeri u Gamedev industriji (
ovo mi je prvi link koi sam naso mogu nac jos ako treba) rekli da sumnjaju u "standardni" raytracing kao dominantnu metodu renderiranja, ako nekog zanima nek procita (inace za one koi neznaju on je taj koi je napiso orginalni engine za QW-ET), postoje price o hibridnim tehnikama koje bi "mogle" postat optimalne al daleko su od implementacije koliko sam informiran ...