Jeśli dobrze liczę, to u nas to było 4 lata temu i 2 miesiące http://pclab.pl/art39671.html

Szerze powiedziawszy nihil novi.

Tech report już 3 lata temu zaczął się przyglądać czasom generowania klatek, ok, nie mieli wtedy FCATa, bo nie istniał, ale już wtedy było widać, że coś jest nie tak.

O ile w pojedynczych gpu różnica nie jest aż tak wielka, to jednak jest, nv po prostu, choć nie zawsze, ma niższe czasy klatki i wykres jest bardziej równomierny, co widać i w waszych wykresach, może podczas gry nikt tego nie odczuje, ale to pokazuje wyższość całego projektu gpu nv nad amd.

Tak w multi gpu to już AMD po prostu oszukuje perfidnie.

Tech report chyba od pół roku używał FCATa, byli jednymi z pierwszych, którzy nagłośnili sprawę multi gpu u AMD, wtedy wyszło wszystko na jaw, no przynajmniej dla fanbojów, bo każdy oczy miał i widział co się dzieje w crossfire kontra sli.

Od wtedy AMD się poci i najlepsze jest to, że tak jak pclab napisał nic nie zrobili, sprzedają bajeczki, przedłużają nadzieje, rok pracowali nad jakimś bublem, który coś tam daje, tyle, że bardzo mało, ze sli nie ma szans.

AMD po protu nie jest w stanie tego już poprawić, wiec zlewają na to, wolą czekać, aż ich starsze karty wymrą, a że robią tak, że i tak nic poniżej serii 7xxx od nich nie opłaca się kupić to im się to uda.

No, ale to multi gpu, dla mnie to zawsze i tak była nieciekawa opcja, ale to rzutuje na ich wiarygodność i profesjonalizm, skoro z tym sobie nie radzą, to i w single gpu mogą sobie z czymś nie radzić, abo ja wiem, a to stery biedne, a to może jakiś błąd w architekturze, a to rozwiązania na opak i potem z pięknych wykresów zostaje ciche przeklinanie marki pod nosem po zakupie.

Mantle to wspaniały pomysł i AMD ma ich wiele, ale coś po takich wpadkach tak na 100% trudno im zaufać.

A co do FCATa, co już wcześneij zauważyłem, trochę od rzeczy zaprojektowali ten soft, chodzi mi tu o źródło danych, którym chyba na teraz może być jedynie film z rozgrywki, co wymusza użycie drogiej karty do zapisu i kosmicznej konfiguracji dysków.

A przecież to by było zupełnie niepotrzebne, gdyby wypluwane obrazy od razu były analizowane, raz, FCAT nie potrzebuje całej klatki tylko ten kolorowy pasek, cała reszta obrazu jest mu zupełnie do niczego niepotrzebna.

Dwa, czemu akurat pasek ma 60 pikseli, przecież i tak nikt tego na oko nie analizuje, równe dobrze mógłby mieć 6, nie wiem czy w wydajności nakładania to by była różnica, ale do optymalizacji odczytu tych kolorów to zawsze lepiej, zresztą po co czytać całe 60 pikseli, skoro wystarczy odczytać pasek równy 1 pikselowi i wysokości klatki?

Tak więc wystarczyłoby, aby od razu wypluta klatka była skanowana pod kątem kolorków paska i w zwykłym pliku byłoby zapisywane kolejno, numer klatki, kolor i jego wysokość w pikselach, bo przecież tylko te dane wyciąga FCAT z filmu i jestem pewien, że zapis takiego pliku nie potrzebuje 350–550 MB/s ciągłego zapisu, ba, to sam tekst, równie dobrze można by całość trzymać w ramie, a po skończeniu zapisać na dysk.

Zresztą dokładnie bardzo podobny taki plik generuje FCAT Extractor w formie xls, to redakcja doskonale wie ile zajmuje ten plik, możecie podać?

Dodam, że sam Extractor to program napisany w .NET framework, także to żaden demon wydajności i nie musi być, jego zadaniem jest tylko przetworzenie kolorowych pasków na dane tekstowe do analizy przez skrypty perla, tak więc równie dobrze można by to przystosować do odczytu live z klatki, bez jej zapisu, bo po co, od razu zapisać plik tekstowy z odczytanymi danymi i tyle, a nawet pominąć extractora i zapisywać według algorytmu w nim zawartego gotowy plik xls.

Extractor nie jest nawet wielowątkowy, wiem to nie problem, ale że materiał jest nieskompresowany można wyciągać te dane na wszystkich rdzeniach szybciej, ile to teraz trwa?

Jeszcze posprawdzam to i tamto i zobaczę co da się zrobić, aby pozbyć się konieczności karty za 7 patoli i drugiego pc z masakrycznym ciągłym zapisem.

W sumie nie dziwię się NV, oni mieli dostarczyć metodę analizy, reszty nie optymalizowali, najważniejszy w FCAT jest ten soft co nakłada paski, overlay, bo cała reszta analiza i ekstrakcja danych dzieje się po wszystkim.

W takim razie mogę spokojnie założyć że odpowiedź nie jest Ci potrzebna.

Dla wszystkich pozostałych: wyjaśnię to nieco później (w wolnej chwili).

Super artykuł, przez Was spóźnię się do pracy

taka kultura
ja nie wiem czemu ale np. tutaj sporo http://pclab.pl/kom70228.html=718872 i tu http://pclab.pl/kom70228.html=718876
To czy dosjesz plusa czy minusa nie ma znaczenia, takiego by

redakcja przechodzi grę i szuka miejsc gdzie grafika ma dużo do robienia i jest intensywnie wykorzystywana, następnie przy każdej karcie graficznej daną czynność powtarza. Pewnie robi to człowiek, ale na to też są programy, które w 100% odtworzą kolejność naciskania klawiszy/myszki. Ważne jest, że procedura labowa jest w 100% powtarzalna.

Trwają jakieś atrakcyjne konkursy, czy tak na zapas się podlizujecie?

Czemu miałbym brać pod uwagę niereferencyjną? Czy niereferencyjna karta magicznie obniży pobór energii wydzielanej z mm^2?
Dalej 290x twin frozr będzie wciąż gorsze pod tym samym względem od produktów NV.

Jeśli dasz mi dwie karty AMD i NV z tym samym schładzaczem, wentylatory ustawione na ten sam RPM, która będzie wydajniejsza, chłodniejsza, większy zapas OC.

Brawo dla pclaba za dołącznie fcata ale ten artykuł już dawno czytałem na guru 3d http://www.guru3d.com/articles_pages/fcat_...g_review,1.html

@SunTzu - Nikt normalny nie kupuje referentow. Osoby co kupily 290 i 290X referenty zaczely je wymieniac jak tylko pojawily sie autorskie chlodzenia.
Fakt to wina AMD ze nie dostarczyli odpowiedniej ilosci chipow no ale powiedz mi szczerze, kupujac TERAZ karte, bralbys referenta? Ja nie znam takiej osoby.

Czemu uwaliło chłodzenie... 7970 nie był super głośny, a podobne masz tutaj. AMD uwaliło GPU, bo dało zegarki, które są spychane nawet 25% z powodu temperatury.
Idea testu nie jest zrobienie xyz pomiarów, które nie mają znaczenia. Zrobić takie, które mają znaczenie im większe tym lepiej. Robienie testu w takich warunkach przeczy rozsądkowi. Powinno się testować w standardowej obudowie może nawet mATX, bo po co większa obudowa/płyta główna?

I niech jeszcze ktoś narzeka na to, że PCLab jest pod skrzydłami Onet-u. Naprawdę od długiego czasu z zagranicznych serwisów czytam jedynie sporadycznie anandtech, bo wszystko inne nie dorasta wam do pięt. Poziom profesjonalizmu wzrasta w olbrzymim tempie, a ten artykuł to kolejny dowód. Brawo, za to że wam się chce i że wykonujecie taki ogrom pracy. A artykułem zamknęliście gęby niedowiarkom - brawo.

Oglądałem hobbita 48fps i jest kolosalna różnica

Moim zdaniem jest luka na rynku. Zamiast komputera-potwora do rejestracji obrazu ze złącza DVI wystarczyłoby proste urządzenie elektroniczne rejestrujące kolor tych pasków na kolejnych liniach każdej klatki obrazu. Być może nie wystarczyłoby to do diagnozowania usterek przez producentów kart graficznych, ale w zupełności wystarczyłoby do testów. Można by je wykonać za pomocą płytki prototypowej z układem FPGA i złączem wejścia HDMI, np. tą, za pomocą której można usunąć HDCP (jak się ją umie zaprogramować).
http://www.digilentinc.com/Products/Detail...&Prod=ATLYS

Podobnie hurra-optymistycznie opinie o tym narzędziu wyrażały redakcje zachodnie rok temu. W praktyce wychodzi, że żadna z redakcji nie porzuciła testowania FRAPS-like. Testowanie single GPU tym narzędziem dokłada jedynie pracy, bo w kwestii szukania różnic w płynności nie wiele się zobaczy (zresztą sam chaostheory napisał, że single GPU są praktycznie pozbawione problemu stutteringu). Jedynych różnic można się doszukiwać w działaniu rozwiązań mulit GPU. A kiedy już to zrobimy wychodzi na to, że SLI z kart opartych na Keplerze radzi sobie względnie dobrze. Zostaje więc do testowania właściwie jak działa CrossFire i to czasu aż AMD naprawi Frame Pacing. Zachodnie testy pokazują, że na Thaiti nie jest już źle (ale napewno gorzej niż na NV), natomiast na Hawaii z XDMA wykresy wyglądają podobnie jak na NV. Wychodzi z tego tyle, że FCAT pozostanie raczej ciekawostką, bo już nie ma gdzie szukać sensacji. Poza tym w moim odczuciu zamiast zarzucać czytelnika dziesiątkami wykresów wystarczyłoby pare zdań o tym jakie wrażenie w kwestii płynności ma recenzent na kartach obu producentów (tym bardziej, że chaosthoery ma wyczulone oko ), a dopiero w razie wątpliwości na poparcie tezy posiłkować się wynikami z FCAT.

BTW. Warto przeczytać: http://www.overclockers.com/nvidias-fcat-g...sting-pursuing/

Ale ja nie rozumiem o czym Ty mówisz. Naprawdę, nie musisz mi udowadniać kolejny raz że AMD spieprzyło referencyjne chłodzenie. Niereferenty wreszcie już są, można za pomocą referentów sprawdzić jak działają, nieco naginając rzeczywistość, a przede wszystkim to w ogóle nie o to chodzi. Chodzi o to, żeby sprawdzić, czy zmiany w sposobie działania CrossFire poszły w dobrym kierunku. Tyle.

Mam nadzieje, droga redakcjo, że konsolki też przetestujecie

Problem taki, że fraps nie mierzy wydajności kart graficznych, a czegoś innego co bardzo bardzo często pokrywa się wydajnością karty graficznej. Ale nie mierzy ilości klatek generowanych przez kartę graficzną.



Czemu nie testujemy więc radeonów w temperaturze -10 stopni?

A już myślałem, że tych od 'oko ludzkie widzi max xx fps' dawno już wymyło.