Dziwne z tymi filtrami i postprocesingiem. Nie da się tego jakoś wyłączyć? Jak dla mnie motion blure to już za dużo, a co dopiero jakieś dodatkowe rozmywacze.

Oj tam akurat skoti się nie popisał, aż tryska stronniczością. Żeby przytoczyć tylko kilka sytuacji:
DX10.1 i patch do MSAA - nieprawda. W tym konkretnym wątku DX10.1 pozwalało nieco odbić wydajności kartom AMD. NV pokazała kod potrafiący mniej więcej to samo zrobić bez 10.1, a nie żadne postprocesowe AA (MLAA, FXAA, SMAA). Mniej więcej nie znaczy to samo - ścieżka 10.1 mogła zostać opcjonalna dla radeonów, ale zdecydowano inaczej. Bez jakiejkolwiek innej motywacji niż opinia NV.

Crysis 2 i tess factor - no heloł. Jak ktoś tesseluje niewidoczną wodę pod całą mapą, albo kawał płaskiego bloku betonowego z współczynnikiem 64x to bzdurą byłoby napisanie, że to Crytek poszalał, bo go AMD na teselację namawiało... To zwykła spina 8 czy 16 tesselatorów Fermi vs 1 czy 2 Cypressa. I nie ma się co oszukiwać, że chodziło o coś innego, a nv niewinne było zupełnie w to niezaangażowane.

Zabijanie OpenCL, OpenGL etc. Taa, tutaj trzeba być kompletnym kretynem by tak pisać. OpenCL od początku miał wadę w postaci online compilation - kod .cl był przetwarzany na platformę docelową w momencie uruchomienia aplikacji. Niosło to dwa poważne ograniczenia. Kernele nie mogły być zbyt skomplikowane (mało warunków, dużo danych do przepuszczenia czyli data parallelism) i brak ochrony kodu. Ale... m.in. to właśnie dawało uniwersalność, aplikacja napisana w OpenCL 1.0 działała na GF8800GT i zaraz po wejściu Fermi też działała. W przypadku appsów CUDA skompilowanych do binarek niestety wielokrotnie było tak, że aplikacje przestawały działać wraz z nową architekturą (m.in. G92 vs GT200, GT200 vs GF100 ...) I tutaj SPIR co prawda oferuje to co CUDA wiele lat wcześniej, ale w dalszym ciągu jest to znacznie bogatsza baza sprzętowa.
Teraz dalej - OpenCL a AMD. Kolega poruszył kwestię raytracerów, a może warto spojrzeć na naukowe osiągnięcia. WCG (IBM) miał aplikację Help Conquer Cancer. W fazie drugiej zastosowano aplikację OpenCL. AMD z Radeonami zwyczajnie okazało się dość znacząco efektywniejsze w przetwarzaniu zadań niż NV. Projekt Folding@Home operował na PS3 i z użyciem BrookGPU/CAL na rodzinie X1800/X1900, a później na HD. I do czasu pojawienia się klienta CUDA to Radeony prowadziły prym... Później okazało się, że CAL idzie do kosza, a AMD stawia na OpenCL. Pojawił się klient GPU3. I w tym momencie Radeony HD5k i 6k dostawały strasznie po tyłku. Średnia karta NV gniotła nawet dwugłowe potwory AMD. Folding@Home to aplikacja MD (molecular dynamics) z klientem AMBER i GROMACS (chyba AMBER jest przepisany na OpenCL i CUDA). Te klienty MD są używane w wielu innych projektach. W naukowym świecie to znacznie większy wpływ niż farma renderująca... Czemu o tym piszę tak historycznie? Bo wreszcie przy odpowiednim wsparciu AMD i pojawieniu się kart GCN udało się przywrócić balans i AMD znów osiąga przyzwoite wyniki w tej aplikacji. Baaa... wsparcie OpenCL na AMD (a częściowo wcześniej właśnie CAL) dało początek takim aplikacjom jak Luxrender (SmallptGPU, SmalluxGPU) czy serii Accent Password Recovery (i np. cRARk). Ale najlepiej stwierdzić, że AMD daje wszędzie dupy bo tu silnik fizyki @ OpenCL bruździ, tam jakiś raytracer się wywala... aż dziw bierze, że inni potrafią zrobić działające aplikacje OpenCL na AMD
Nie, żeby zawsze było wesoło - w przykładzie GPUGRID AMD tak zniechęciło twórców, że chyba nawet do dziś oficjalnie nie ma wsparcia. Z drugiej strony w milkyway to nv tak dawała dupy (teraz AMD też przez cięcie FP64) że szkoda było nawet odpalać na GeForce. Collatz z kolei działał dobrze na obu platformach z lekką przewagą AMD, to samo POEM. Dla chcącego nic trudnego. Jeśli już miałbym się AMD czepiać to wyłącznie za cyrki wyczyniane przy WinZIP 14.5 iirc. Dodam też, że przez dłuższy czas kompiler OpenCL (x86) od AMD działał zwyczajnie lepiej i warto było instalować ICD AMD nawet dla procesorów intela. W tej chwili nawet nie widziałem porównań i możliwe, że intel już wyszedł na prowadzenie w swoich procesorach.

skoti poruszył wiele rzeczywistych problemów i dał wiele merytorycznych argumentów, jednak merytoryczne argumenty drugiej strony do niego nie docierały. I to jest właśnie problem również wielu z was. Stronniczość, nawet gdy się zapieracie, że macie otwarty umysł i patrzycie obiektywnie każda igiełka która wam się wbiła przez radeony już powoduje łatwiejsze przyswajanie argumentów pro-nv.

To całe 1080p to nie prawda. Gra upscaluje się z 720p do 1080p z MSAAx4

The Windows 10 version of Quantum Break uses the same reconstruction method as on Xbox One. If your resolution is set to 1080p, the game temporally reconstructs the image (except UI) from four 720p buffers rendered with 4xMSAA, just like on Xbox One. Engine assigns input geometry samples from 4xMSAA rendering into shaded clusters in order to maximize covered geometry while keeping the performance on acceptable level by reducing expensive shaded samples. When you change the resolution, the buffers used to construct the image are always 2/3rds of the set resolution, i.e. in 2560×1440 they would be 1706×960.

Wolumetryczne oświetlenie to kula u nogi w tej grze, co najlepsze zjada strasznie fps'y

W tym momencie to szczerze powiem, że żałuję propozycji wprowadzenia systemu oceniania postów ... dawno dawno temu była wolna amerykanka, nie można było zakopać niewygodnych fanbojskich komentarzy, ani zablokować wyświetlanie postów kogoś kogo nie lubimy. Niestety m.in. taki Promil zasiał ziarenko w umysłach pclabowych guru i gdy odpowiednia ilość podobnych opinii się zebrała to machina poszła w ruch. Najgorsze są te minusy i raporty 'ot tak', taki skrytobójczy cios bez możliwości rewanżu. Brak uargumentowania swojej opinii a jedynie szpila wsadzona komuś kto się rzetelnie wypowiedział.

...
Nie mówię, ze tak jest na 100% to tylko moje domysły na podstawie tego co czytałem w internecie.