dokturpotfor

Czolem, Na E3 był nowy materiał z Rage'a: http://www.gametrailers.com/video/e3-2010-rage/700653

http://boingboing.net/2010/05/08/star-wars-trilogy-re.html tu jest fabuła klasycznej trylogii.

Ja polecam ostatnio tego NEC'a: http://www.necdisplaysolutions.pl/?c=15&l=1&id=1689&tab=main Jest tani (tj. w porównaniu do Eizo czy pro NEC'ów), a oferuje znakomitą jakość obrazu. Porównaj sobie z Dell'em w jakimś sklepie i napisz co myślisz. PS: hmm, zdziwiła mnie trochę ta cena, 1799 PLN vs. 2900 na dell.pl, to nie jakiś wałek: leżak z magazynu, zwrot, etc... ? Cena wygląda na niezłą. Aż się przejdę do ich krakowskiego salonu.

hmm... czyli starkiller "2" to klon bohatera pierwszej części? Chyba nie będą zmieniać kanonowego zakończenia force unleashed 1. Btw. z trailera zapowiada się troche brutalniejszy klimat niż w jedynce, może wreszcie uwzględnią nieodłączny element walki na miecze świetlne czyli: obcinanie kończyn :)

Śmiało możesz podnieść złożoność geometrii, nie ma co tak skąpić :), karty graficzne dziś potrafią sobie z tym radzić. Druga sprawa spróbuj włączyć shadery, które wyciągną fakturę (np. paralax mapping). Jakie tam jest włączone oświetlenie? Normale/bump nie będzie widoczny bez dobrze określonego źródła/źródeł światła, czy tam w ogóle jest włączone per pixel lighting jakieś?

Czolem, re: Pawel Lipka Jakoś wszyscy którzy cię krytykują, nie zrozumieli o co ci chodzi. Może to być problem z nami (po prostu jesteśmy wtórnymi analfabetami :) ), albo z tobą - i piszesz wierutne, lecz nie przecze wylewne, bzdury. Nie twierdze, iż nie można pisać bzdur, sam czasem się na tym łapię i jest mi wtedy bardzo głupio, ale podstawą cywilizowanej dyskusji jest pewien rodzaj intelektualnej pokory. edit: nie ma sensu tego ciągnąć :)

Wal smiało w radeona HD5750, używam HD5870 od 7 miesięcy jakoś i nie ma najmniejszych problemów (3ds max, Corel, CS4 regularnie).

re: Paweł Lipka Wybacz stary, ale to co piszesz to są jakieś pseudointelektualne wypierdzenia licealisty, albo jeśli potraktować cię łagodniej czyste trollowanie człowieka z wszystkiego niezadowolonego. Walczący mężczyźni? Naśladujące kobiety niezadowolone ze swojego życia? Kuba Wojewódzki nie potrafiący rozmawiać o swoich uczuciach? Intymność erogenna a nie uczuciowa? Puste gry wypierające resztki ludzkiej natury ? - wyraże się językiem mojego pokolenia: WTF ???? Co to za bełkot, pusty zlepek bezsensownych zdań. Pod cienkim płaszczykiem niosą one tyle treści co byle elukubracja z emo-bloga. Co to w ogóle wnosi do dyskusji o tym filmie, grze, grach jako takich poza tym, iż pokazujesz jaki to jesteś przejęty walką kultury masowej z wysoką? Jak ktoś już wcześniej skomentował: facepalm

re: up Z tego co pamiętam to Deus Ex'y to był akurat przykład przerostu: "treści nad formą" a nie na odwrót. Mało znam gier, które lepiej wpisywały się w klimat takiego oldschoolowego cyberpunka (a'la William Gibson, czy niektóre P.K. Dick'i). Co do samej stylizacji filmiku to powiedziałbym, iż fotorealizm to raczej skutek uboczny niż zamierzeni. Scenografia - ok, ale postacie bardziej mi przypominają japońska animację, albo jakiś komiks: mocne pociągłe rysy twarzy (jak np u Petera Chunga), ciepły rim light, spłaszczone "shadery". A jeśli "dążenie do władzy i kontroli", które jest lejtmotivem niezliczonych arcydzieł naszej kultury nie jest odpowiednim tematem na filmik / grę, to ja już nie wiem co miałoby być... :)

Ten filmik demo na którym gość z Chaos Group pokazuje Vraya RT Gpu był przygotowany na 3 x GTX480.

Jeśli używasz Unity z DirectX to zainstaluj DirectX SDK. Tam jest takie narzędzie jak PIX (to debugger wywołań API DirectX). Przy pomocy PIX'a możesz np. wykonywać zrzuty informacji o tym co w danej klatce twój program robi z kartą graficzną za pośrednictwem API (PIX ma porządnego helpa, poradzisz sobie). Co do wpływu na to w jaki sposób Unity zarządza renderowaniem to jeśli twórcy explicite nie dali narzędzi do obsługi tego aspektu (jakieś kolejki, warstwy, instancjonowanie itd...) to raczej bez wersji źródłowej się nie obejdzie. re: liczenie drawcalli... heh, to nie takie proste... wiele świateł może być realizowane przez kilka passów, może być realizowane przez deferred shading, może być realizowane przez kilka wersji shaderów które przyjmują różne parametry kilku świateł na raz. Zmiany tekstur na chłopski rozum to jest wywołanie API, ale np jeśli unity ma streamowane tekstury (virtual texture) to może to być jedynie zmiana zmiennych shadera (która jest stosunkowo tania i może być ukryta przy innych zmianach), a nie przepięcie zupełnie nowej tekstury. Bez źródeł ciężko zgadywać, jak znajdę chwilę to spróbuje zdebugować Unity. A oni nie opisali 'polityki' renderowania w jakichś manualach? na chłopski rozum, ilość drawcalli ci rośnie liniowo z ilością postaci, jeśli masz światła realizowane przez multipass to 'razy' ilość świateł, jeśli przez deferred shading to 'plus' ilość świateł (ale deferred shading ma pewien narzut niezależny od ilości świateł i obiektów), jeśli masz shadow mapping włączony dla świateł to dodaj koszt wyrenderowania głębokości obiektów dla każdego światła (niezależnie czy deferred czy zwykły). Ale przy 20 meshach i 3 światłach nie powinieneś mieć problemu z cpu - ilość rzędu 1000-2000 wywołań API na klatke (przy DX) jest spoko. Jeśli możesz przejdź z DX9 na 10, API jest szybsze. Jeśli robisz na mac'a / OpenGL to nie wiem jak to tam do końca wygląda. Aha, co chciałbym podkreślić, tu jest cały czas mowa o cpu, API i sterownikach, czyli to jest jedna strona medalu, bo nawet jeśli cpu wyrobi to może okazać się że gpu ograniczy wydajność.

chodzi ci o multipass? Problem jest w tym ile potrzebujesz mieć geometrii w scenie, jak jesteś w stanie podzielić scenkę na mniejsze w których nie ma (albo da się oszukać) zależności między obiektami pomiędzy passami (np obiekty z jednego nie odbijają się w drugim) to na pewno to pomoże. Ciekaw jestem jaki jest narzut pamięciowy przy przeniesieniu scenki z cpu na gpu przy Vray'u RT.

yo, 1) gpu nie ma dostępu do pamięci cpu, który pozwalałby na sensowną interaktywną pracę (tzn tak aby podczas wykonywania shadera gpu mogło sięgnąć do pamięci cpu a nie własnej) bez stukrotnego spowolnienia. 2) trójkanałowy i7 z ddr3-1600 to około 20 GB/s przepustowości pamięci radeon hd5870 to 160 GB/s, GTX480 to 173GB/s... mały zgrzyt 3) w kartach graficznych gddr5 jest 32 bitowy, kości 1 giga_bit_ są drogie kości 2 giga_bity_ są bardzo drogie. Kość 1 gigabit = 128 mega, radeony maja 128 do 256 bitową architekturę kontrolera pamięci = 4-8 kostek = max 1 lub 2 GB. Fermii ma od 256 do 384 bitowy kontroler pamięci czyli 8-12 kostek, max 2GB - 3GB. Zwiększenie szyny danych to bardzo duży problem technologiczny (komplikacja układu, komplikacja płytki PCB, ciepło...). Jest jeszcze tryb clamshell czyli parowanie dwóch kości pamięci na jednym kontrolerze ale to też niesie pewne ograniczenia, trzeba czekać na kolejną generację kart :) edit: clamshell

'Draw call' to wywołanie API które wysyła na kartę graficzną geometrię do zrasterowania (w uproszczeniu). Wszystkie zmiany stanu karty graficznej: ustawienie innego shadera, ustawienie tekstur, ustawienie parametrów shaderów, ustawienie parametrów samplerów, ustawienie rendertargeta itd, to operacje realizowane przez software po stronie cpu (api programistyczne i driver karty graficznej. Im więcej geometrii która wymaga zmian stanu karty graficznej (np. rózne tekstury, shadery, vertex buffery itd) tym większe obciążenie cpu. Zbyt frywolne rozdrobnienie sceny (bez instancjonowania) - podział na malutkie obiekty z których każdy musi być osobno 'wysłany' do wyświetlenia działa podobnie. Zła kolejność wyświetlania obiektów (psująca grupowanie zmian stanu) to kolejny problem. W ogólności dużo 'draw calli' i zmian stanu powoduje, że oprogramowanie jest ograniczone przez cpu a gpu się marnuje.

x6 = 6rdzeni = i7 980x = 999$ = ~4000 PLN w Polsce

re: up O jakiejś prehistorii mówisz... albo o intelu gma9xx :) ale dla pewności sprawdziłem hd4200 i poszło 1080p bez problemu, zużycie procesora poniżej 10%, głównie na obsługę windowsowego DRM'a

btw, jeśli się nie mylę to na Polskę po premierze było przewidzianych 40 sztuk GTX480, więc się pośpiesz lepiej. Poza tym wydaje mi się że 1.5 kW to trochę za mało jak na ten sprzęt. A te dyski twarde to śmiech na sali, wziął byś choć ze dwa SSD w RAID-zie.

1352 to proc dla systemów jednoprocesorowych, potrzebujesz serię 2xxx.

Sons of Anarchy, cool, nie wiedzialem ze ktos to oglada...

Weź sobie jakiś podkład z Nine Inch Nails. Od kilku albumów Trent Reznor rozpowszechnia muzykę jako CC attribution, non-commercial. A wiele kawałków jak ulał pasuje do dynamicznego demo. btw. autorskie pisze się przez u niezależnie od tego jak ł śmiesznie wygląda

czolem, niezaleznie od tego czy faktura byla wystawiona na firme czy na osobe prywatna, to z tego co wiem nie da sie tego wliczyc w koszty moja dziewczyna dostala w listopadzie dotacje i razem z moja ksiegowa obczajalismy jak to rozgryzc. po zasiegnieciu informacji w paru urzedach to co udalo sie dowiedziec: pieniadze z dotacji nie podlegaja opodatkowaniu wiec na poczatek powiedzieli nam ze nie mozna dostac 'zwrotu podatku' skoro sie go nie zaplacilo. Zaczelismy dalej drazyc, bo przepisy o kwalifikowalnosci kosztow w cale nie mowia o tym czy kasa pochodzi ze srodkow zwolnionych z podatku czy nie. no to znalezli nam kolejny przepis ze: odpisy amortyzacyjne na srodki trwale (kupowalismy laptopa) i na wartosci niematerialne (soft) sa proporcjonalne do realnego poniesionego przez podatnika kosztu (a poniewaz kasa pochodzila z dotacji to interpretacja jest taka ze podatnik nie poniosl kosztow i tego sie urzedy trzymaja). Inaczej jest z wyposazeniem i materialami (czyli nie srodkami trwalymi ani nie wartosciami niematerialnymi i prawnymi), je mozna zaliczyc w koszty, nawet jesli sa finansowane przez dotacje. Z vatem jest tak: z jednej strony vat mozna odliczyc jedynie od rzeczy ktore sa zaliczone w poczet kwalifikowanych kosztow, ale na szczescie tej reguly nie stosuje sie do... tada "srodkow trwalych i wartosci niematerialnych i prawnych". Suma summarum, koszty = tylko materialy i wyposazenie, VAT - wyglada na to ze wszystko (ale na razie dziewczyna nie jest vatowcem wiec nas to nie obchodzilo)

hehe... ja tez chyba sie skusze na ten konkurs z jakims Orwellowskim klimatem... :)

od CES'a dostepne sa biale papiery fermii: http://www.nvidia.com/content/PDF/fermi_white_papers/NVIDIA_Fermi_Compute_Architecture_Whitepaper.pdf no tak, ale rzadko kiedy mamy doczynienia z idealnymi lustrami :) materialy maja dosc dowolne parametry: odbic specular, zalaman, odbic diffuse, dodaj do tego glossa, dodaj sss... w ogolnosci BSDF... lustra i szklanki (oraz im podobne) ktore niezle zachowuja po odbiciu spojnosc przestrzenna to bardzo waski wycinek. a z kazdym odbiciem rozrzut sie powieksza. edit: btw. zauwazyles ze ulubionym tematem dem gpu raytracing sa blyszczace lustrzane samochody ? :) wiele przejsc algorytmu to oczywiscie jakies rozwiazanie, ale... sortowanie, grupowanie promieni kolejnych poziomow jest, kosztowne: bo generuje sie ich ogromna ilosc, a po drugie... nie wiadomo jak tego dokonac... a priori nie mamy wiedzy ktore promienie ida w to samo miejsce, gdybysmy mieli to po co w ogole je tracowac? wystarczy znalezc 'przedstawiciela' takiej grupki (w uproszczeniu) policzyc gdzie trafi, a pozniej z duza dokladnoscia okreslic gdzie trafia sasiedzi. pozostaja heurezy, mozna podzielic promienie na 'kubelki' wg. punktu startowego i kierunku i takimi paczkami sobie dalej dzialac. Jasne bedzie szybciej... ale to nie jakosciowa zmiana. zastanowmy sie nad ta sztuczka z puszczaniem 16 probek w to samo miejsce (albo bardzo blisko), to dobrze dziala na gpu, bo te probki ida ta sama sciezka kodu i nie wykonuja nadmiarowych instrukcji na branchujacy kod. trafiaja w jeden trojkat z malutkim rozrzutem i jakos tam sie rozrzucaja dalej (i dla dobra dyskusji powiedzmy ze tam dalej to juz jest gorzej bo leca w roznych kierunkach). fan raytracingu na gpu powie: no tak, ale pierwsze 16 primary rayow zalatwilismy od tak *pstryk* moca gpu... a fan cpu powie: no tak ale tylko dlatego ze gpu nie moze sobie z jednego promienia wyspawnowac 16 (co sie dzieje w monte carlo na cpu bardzo czesto) bo by zdechlo, wiec musi na poczatku wykonac 16 razy wiecej praktycznie takich samych obliczen zeby pierwsze promienie dotarly do pierwszego zdarzenia. a trzeba pamietac ze branch nie zdarza sie tylko na 'trafieniu' i shaderach opisujacych material... wystarczy drobny rozrzut i promienie lecace z nieodleglych punktów w podobnych kierunkach zaczna bladzic roznymi sciezkami w drzewkach. ps: coraz bardziej mi sie wydaje ze na obecnej klasie sprzetu droga ktora da lepsze wyniki bedzie radiance transfer... zbudowac siatke opisujaca przeplyw swiatla (chocby grid, a moze inne cudo - losowy podzial? podzial delaunaya ), naladowac punkty startowe od zrodel swiatla, a pozniej zapuscic rownanie Poissona i iterowac, iterowac...

to w jaki niby sposob mam tej pamieci uzywac do budowania stosu (od czego zaczela sie w ogole dyskusja o pamieci global i hosta) ? o hoscie zapomnijmy bo to nie tedy droga. pamiec global jest waskim gardlem wielu aplikacji na gpu. pamiec globalna ma przykre wlasciwosci na gpu, slabo dziala przy nieregularnym dostepie (cashy nie ma w ogole, lub sa kosmicznie male jak na ilosc watkow ktore walcza o pamiec), wymaga lokalnosci operacji (nie wiem jak lepiej nazwac coalescent access) i jako pamiec 'random access' narzuca rzad jesli nie dwa wielkosci wolniejszy dostep. glowna zasada pisania wydajnego kodu: "keep ALU:TEX high!" to nie bierze sie z nikad. rozumiem budowanie stosu w pamieci shared, ale do tej pory bylo jej tez smiesznie malo 16kb, a w fermii kiedy sie wreszcie ukaze bedziemy mieli dostep do 48kilo _na wszystkie te watki dzialajace na jednym SM_ A co do SIMD/MIMD nie przekonam cie zapewne samym opowiadaniem, zacytuje, papiery fermi: " Hardware Execution CUDA’s hierarchy of threads maps to a hierarchy of processors on the GPU; a GPU executes one or more kernel grids; a streaming multiprocessor (SM) executes one or more thread blocks; and CUDA cores and other execution units in the SM execute threads. The SM executes threads in groups of 32 threads called a warp. While programmers can generally ignore warp execution for functional correctness and think of programming one thread, they can greatly improve performance by having threads in a warp execute the same code path and access memory in nearby addresses. " " Dual Warp Scheduler The SM schedules threads in groups of 32 parallel threads called warps. Each SM features two warp schedulers and two instruction dispatch units, allowing two warps to be issued and executed concurrently. Fermi’s dual warp scheduler selects two warps, and issues one instruction from each warp to a group of sixteen cores, sixteen load/store units, or four SFUs. Because warps execute independently, Fermi’s scheduler does not need to check for dependencies from within the instruction stream. Using this elegant model of dual-issue, Fermi achieves near peak hardware performance. " to nie jest MIMD, granulacja na poziomie kernela to 16/32 watki wykonywane jako SIMD, oczywiscie techniki jak Out of order execution, czy rownolegle wykonywanie ALU, TEX, SFU pozwalaja _calymi warpami_ wykonywac kilka instrukcji na raz. na poziomie jednego kernela/shadera gpu dziala jedynie jako calkiem szerokie SIMD. na poziomie kilku kerneli rozne SM moga wykonywac rozne kernele - to jest jedyne MIMD na fermi. jeden SM moze tez miec kilka warpow ktore aktualnie obsluguje i np jesli jeden warp jedzie po ALU, to drugi moze rownolegle meczyc TEX, albo SFU. Ale znow to nie jest MIMD, to zwykly pipeline / vliw tak, tak, hlsl :) brain fart... btw... wyobrazasz sobie chip ktory mialby 512 fetchy i dekoderow? jeszcze pare tekstow: " Divergent Branches. The PTX machine model defines a divergent branch as a branch instruction where some threads within the same warp branch while others fall through. In this study, we report the branch divergence of an application as the ratio of divergent branches to total branches. As control flow divergence results in two separate sets of threads whose execution must be serialized, the location of the synchronization point has a profound impact on thread activity and the number of dynamic instructions executed. In [19], Fung et al. show that the earliest (ideal) location of thread reconvergence is the immediate post dominator of the branch instruction - that is, the nearest successor basic block that must be executed if the branch instruction is executed regardless of control path taken. We also investigated an alternative method in which divergent threads are not reconverged until explicit synchronization barriers are encountered by ignoring compiler inserted reconverge points. " " At every instruction issue time, the SIMT unit selects a warp that is ready to execute and issues the next instruction to the active threads of the warp. A warp executes one common instruction at a time, so full efficiency is realized when all threads of a warp agree on their execution path. If threads of a warp diverge via a data-dependent conditional branch, the warp __serially__ executes each branch path taken, disabling threads that are not on that path, and when all paths complete, the threads converge back to the same execution path. Branch divergence occurs only within a warp; different warps execute independently regardless of whether they are executing common or disjointed code paths. " " SIMT architecture is akin to SIMD (Single Instruction, Multiple Data) vector organizations in that a single instruction controls multiple processing elements. A key difference is that SIMD vector organizations expose the SIMD width to the software, whereas SIMT instructions specify the execution and branching behavior of a single thread. In contrast with SIMD vector machines, SIMT enables programmers to write thread-level parallel code for independent, scalar threads, as well as data-parallel code for coordinated threads. For the purposes of correctness, the programmer can essentially ignore the SIMT behavior; however, substantial performance improvements can be realized by taking care that the code seldom requires threads in a warp to diverge. " fermi nic tu nie zmieni... fermi to nadal 16 procesorow SIMD o szerokosci 16/32 watki, model obliczen jest taki sam, oczywiscie dodano udogodnienia w stylu jednoczesne wykonywanie kilku kerneli, cache przed kazda pamiecia, wydajniejsze ale to nie zmienia modelu. wyobraz sobie raytracing na gpu w ktorym 16/32 promienie ida w jednej paczce przez jakas strukture danych (octree, kdtree, cokolwiek), trafiaja w koncu na jakas gemetrie. To byla przestrzennie spojna paczka promieni (kilka sasiednich pixeli np) zalozmy ze trafily w jeden trojkat (to sie zdarza dla primary rays calkiem czesto), a teraz co? jeden sie odbije w jedna strone, drugi w druga, trzeci bedzie mial sss, czwarty przeniknie... na pierwszym bouncu moze jeszcze pojawia sie 'peczki' promieni, mozna temu nawet pomoc i puszczac od razu promienie zmultiplikowane (po prostu duzo probek), ale to nie zmienia faktu ze z kazdym poziomem tej pseudo-rekursji wykladniczo rosnie zlozonosc branchowania. majac 16/32 watki na warpa szybko zauwazysz ze liczac np gi, kazdy jest w innej odnodze sterowania - co czyni kod seryjnym (czyli nie mozemy pominac zadnych instrukcji). oczywiscie swiat sie kreci i powstaja hybrydowe rozwiazania, ale wg mnie SIMD nadaje sie do rasteryzacji, nadaje sie do numeryki, ale do raytracingu to jest tak jak powiedzialem: "oranie pola czolgiem", dlatego tak zaciekawilo mnie larrabee (racja ze rodzi sie w bolach, ale moze sie doczekamy) - egzemplarz 48 way MIMD z 512 bitowymi operacjami wektorowymi @ 2ghz chetnie bym ogladnal. mam nalecialosci akademickie (caly czas probuje sie w koncu zdoktoryzowac), ale w tym roku stuknie mi 10 lat pracy zawodowej, na wielu architekturach nisko i wysokopoziomowych. ostatnie 2 lata to tylko DX, wczesniej openGL. ale jedynym powodem mojej dociekliwosci jest wlasnie proba wycisniecia ze sprzetu tyle ile sie da... a nie da sie tego zrobic nie wiedzac jak on dziala. re: tweety smiej sie smiej a my tu prawimy co sie w twoim rendererze dzieje... :P

Dobra, odpowiedzialem w nowym watku: "Fakty, mity i CUDA" http://www.max3d.pl/forum/showthread.php?p=890564