Mesh fusion generuje porzadna geometrie, slozona z quadow i trisow, zapewnie tez kontrole na chamferami. Jakbys obejrzal tutoriale na vimeo to bys sie przekonał (;.

Sproboj w mayi albo w maxie uzyskac czysty boolean kuli w kuli. Have fun (;. O bardziej skompikowanych rzeczach nawet nie mowie. Wkoncu jebnie. I bedzie to szybciej niz wczesniej.

@up
No true, majce trzeba ręcznie to wszystko robić, trochę zabawy Nie zauważyłem racja. Hrr jak zwykle trzeba się przekonać do softu... jak zwykle wychodzę z założenia, że maya ma wszystko Ale widać czasem trzeba więcej roboty.

Dzięki, w wakcje będzie trzeba spróbować w modo.

Nie wiem jak można jaśniej to wytłumaczyć jak to zrobił Skoti ? Ilość cykli jaką musiał poświecić CPU na wygenerowanie jednej klatki jest taka sama. Przy vsync off czy on to się nie zmienia.
Jedyne co ulega zmianie to interwał czasowy pomiędzy klatkami. Jeżeli masz włączony vsync to jeżeli CPU wygeneruje klatkę resztę cykli poświęca innym zadaniom lub 'jest wolny'.
To ten czas widzisz jako mniejsze użycie procesora. Jednak ilość cykli cpu poświęconych na wygenerowanie pojedynczej klatki animacji nie spadł. To takie ciężkie to chwycenia ?
Skoti jest programistą. Sama wiedza z art. ile co ma MHz, ile klatek co kręci, jaki ma zegar etc. to za mało aby toczyć rozmowę na takim poziomie. Ja ze swojej strony wielkie TNX za czas i ilość fachowych rzeczy jakie mogłem przeczytać od Skotiego w tej dyskusji.

@up
Powiedz mi jeszcze jak zmierzysz obciążenie procesora w danym cyklu, bo sideband nie pisał o cyklach, a obciążeniu.
CPU będzie obciążony w 75% przez 6cykli vs 100% w 5 cyklach, gdzie obciążenie jest większe?

Obciążenie CPU generowaniem pojedynczej klatki to ilość cykli/czasu jakie na to poświęca. Jest ono takie same jak przy vsync off i on. Spada jedynie ilość czasu jaką CPU zajmuje się w danym interwale generowaniem grafiki przez to że generuje ich mniej.
Prawdziwe zmniejszenie obciążenia CPU to spadek cykli jakie zużywa na wygenerowanie pojedynczej ramki.

Przeczytaj jeszcze raz co napisałem. Nawet jak zajmiesz procesor ciągłą robotą to nie obciążysz go w 100%, a jedynie sprawisz, że zajmiesz x cykli procesor robotą, dlatego jest inny pobór energii renderując cinebenchem, a inny w OCCT, a jeszcze inny w Prime

Nie dlatego ,że w danej jednostce czasu mniej cykli procesor pracował. Pracował tu i tu, ale z innym obciążeniem

]
a cos takiego w ogole jest mozliwe?
w danym cyklu albo wykonujesz prace, albo nie. nie mozesz pracowac przez 75% cyklu.
procesor moze za to wykonywac prace w 75% lub 100% cykli przypadajacych na dana jednostke czasu...

Cały czas myślisz o czasie...
Nie może pracować przez 75% cyklu, ale może pracować 75% procesora w danym cyklu.

Inaczej nie miał byś tak dużych różnic w poborze energii wykonując nawet to samo zadanie-> rendering.

a dobra, teraz już rozumiem o co Ci chodziło.
Natomiast wcześniej to nie ze mną prowadziłeś dyskusję

Sam przeczytaj dokładnie co pisał Skoti.
No więc wyszła Ci bzdura ponieważ CPU zużyje na generowanie jednej ramki obrazu zawsze tyle samo samo % z vsync czy bez vsync.
Czarów nie ma. Jedynie przez uproszczenie/optymalizację kodu lub zmniejszenia obciążenia przez sam sterownik karty uzyskasz coś co nazwiesz - mniejsze zużycie procesora.

Przeczytaj co pisał sideband i na co odpowiadał. Nie pisał o ilości cykli/klatkę, nie pisał też o obciążeniu na klatkę, to wymyślił skoti.
To co pisał skoti można sprawdzić tylko mając narzędzia developerskie, poczęści. A obciążenia i tak nie sprawdzisz, a tego tyczył się pierwotnie temat czyli obciążenie DX/Mantle.

Jak mi porównasz obciążenie DX/Mantle winszuję. Ma to praktyczne znadzenie, np. na platformie z niskim zegarem i bardzo dużym turbo uzależnionym od poboru energii. Gdzie mantle może teoretycznie więcej zyskać.

Ale jak podałem przykład A->15% CPU robi rzecz 5 cykli vs B-> 100% CPU w 4 cyklach... na teście z OC laba będzie rozwiązanie B będzie znacznie szybsze, a np. na platformie ultrabooku będzie rozwiązanie A szybsze.

Nie wiem czy mnie przeczytałeś ? Ja napisałem o obu rzeczach, zmniejszeniu czasu w jakim jest używany CPU do generowania grafiki przez obcięcie ilości generowanych ramek, oraz o tym że nie ma to znaczenia przy prawdziwej zmianie obciążenia cpu przy generowaniu pojedynczej.
To co pisał Side to chyba oczywista oczywistość. Ale jeżeli podchodzisz to czegoś takiego jak 'obciążenie cpu' to takie uproszczenie jest nie poprawne i wymaga rozbicia i wyjaśnienia pojęcia do końca.

@up
Tak samo nie porównasz mi tu obciążenia DX/Mantle jak to skoti mocno dociekał. Jedyna poprawna forma tutaj to ilość cykli potrzebnych na wygenerowania klatki teoretycznie będzie taka sama z i bez limitu FPSów->
^ to też nie jest prawda.

Nadzieja prysła

@eagle
Obciążenie procesora na taką samą klatkę winien być identyczny, tak podpowiada logika, z drugiej strony ile takich samych klatek mamy podczas rozgrywki?

Jeśli chodzi o obciążenie procesora, to z jednej strony nie ma za bardzo jak sprawdzić ilość nudzących się tranzystorów w trakcie trwania cyklu, z drugiej natomiast takie rzeczy można na oko sprawdzić porównując i5 z i7 o tym samym zegarze... Przyśpieszenie powinno być adekwatne do 'leniwych' jednostek w procesorze.

Obciążenie ogólne jest istotne z tego względu, że mamy już pobieżny wynik który podzespół może być odpowiedzialny za niesatysfakcjonującą wydajność. Dlatego przydatny dla nas byłby program do sprawdzania jaki wątek jaki czas procesora nam zabiera, z racji tego że na silnik gry już nie możemy wpłynąć.

Nie ma to jak dawać przykład gry wydanej Valve, która po latach została zoptymalizowana ponownie w związku z wydaniem Steama na Ubuntu i konieczności przystosowania jej do nowego środowiska.
No i nie można zapominać o bólu tyłka założyciela Valve, który nienawidzi Windows 8 i M$...
Nie wiem, póki co i tak największe tytuły nie goszczą na Linuxie, ale porównanie byłoby ciekawe i wiarygodne pod warunkiem, że gra zostałaby wydana w jednym momencie na obie platformy...

z tym Left 4 Dead nie jest tak fajnie jak na filmiku w rzeczywistości łazi porównywalnie z dx ale miewa dziwne spadki klatek
a testy chyba na pentium 1 było ta gra niema żadnych wymagań sprzętowych dziwne te 44 fps no i filmi staryyyyyyyyyyyyy klatki

Zetniesz fps spadnie pobór mocy i temperatury cpu , samo obciążenia może nie spaść , ale procesor przelicza mniej w danej jednostce czasu i to można przełożyć na realne niższe obciążenie cpu. Pobór mocy i temp to także realny wskażnik wykorzystania cpu , skoro spadają to procesor jest wykorzytywany w mniejszym stopniu.

Pisząc spadło obciążenie cpu nie robi się błędu , ale ciebie takie sformułowanie może drażnić.

Takie same mało dokładne dane podaje monitoring z nvapi i nikt nie płacze.

jakby nie było widać tutaj postęp szczególnie przy średnich prockach, może by tak zrobili coś z tym DirectX żeby to usprawnić. Czy ktoś może mi odpowiedzieć czy na Intel 3770 Radeon r9 290x z Mantle pokona geforce 780 ti ? widzę tu 780 ale ti nie widzę

Możesz sprawdzić debuggerem DX i zobaczyć, ze zmiana rozdzielczości czy dodanie interwału nic nie zmienia czasu spędzonego na renderowaniu klatki.


Nawet nie w swoim silniku możesz zobaczyć dokładnie na performance counterach faktyczne obciążenie procesora.



Nie jest to prawdą jeśli aktualizacja jest co 15ms counterka (tak na przykład, bo raczej 500ms ;p (pół sekundy)) w systemie to mantle pokaże 17%... jeśli co 7,5ms to pokaże w jednym przedziale 33%, a w kolejnym 0% (a w DX w obu 15%)


Jeśli weźmiesz pod uwagę jednostkę czasu tak - czas procesora przy generowaniu klatki się nie zmieni, ale będzie sztucznie wytworzona przerwa w działaniu, jednak tu nie ma zupełnie żadnej analogii względem zmniejszenia rozdzielczości... jest wręcz przeciwnie proporcjonalna (im niższa rozdzielczość tym łączny czas generowania klatki jest mniejszy, i w jednosce czasu CPU więcej klatek musi obliczyć (jednak na klatkę robi zawsze tą samą pracę)).

O rozdzielczości nic nie pisałem w tej chwili , cały czas rozpatrujesz obciążenie cpu z poziomu aplikacji i tutaj nic się nie zmieni , ale skoro wydłuża się przerwa w działaniu cpu to logiczne jest , że cpu jest mniej zajęty i to co pokazuje menedżer zadań nie jest głupotą.

Albo udajesz idiotę albo mnie masz za idiotę.