Polecam przeczytać wszystko co Skoti48 (tutejszy bywalec) ma do powiedzenia. Mój link
Szkoda, że tak wiele osób dało się omamić takim marketingowym bełkotem o tej rzekomej przewadze kart AMD w DX12
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.
Optymalizacja wygląda moim zdaniem dobrze, widać też w zestawieniu, że gra korzysta z obliczeń równoległych, o których wiemy to, że karty AMD potrafią je wykonywać, a NVidia ma je wyłączone na Maxwell'ach (tak przynajmniej twierdzili przy testach dema AoS) ale też raczej już go nie włączy bo przecież za rogiem Pascal, który jest niby rozwinięciem Maxwell'a, a przydałaby się dodatkowa motywacja dla kupujących.
Nie ma tez co liczyć, że Vulkan 'naprawi' problemy NVidii, w najlepszym wypadku będzie tak samo wydajny jak DX12, a skoro oba API mają wspólny pierwowzór, a mianowicie Mantle, można się spodziewać podobnych rozwiązań i też dużego nacisku na obliczenia asynchroniczne.
Sądziłem że nikt już nie wierzy w te bzdury o pochodzeniu DX12 od Mantle. Przecież w DX12 po prostu odblokowali pewien znacznie bliższy sprzętowi sposób zarządzania, który uwalnia pewne zasoby. Znane to już było w czasach...... DX9
Zwyczajnie wycofali się rakiem z tego co forsowali od czasów DX10
ta 'show behind'... Co za przyziemny sposób mówienia o całkowitej zmianie poziomu abstrakcji, przyjmowanej do pisania kodu. Mam nadzieje, że jak łykniesz trochę tematu interfejsów, to zmienisz zdanie...
MS właśnie wysłał darmowe klucze PC dodawane do preoderów z Xbox. Jak ktoś planuje zakup Quantum Brak to warto sprawdzać serwisy gdzie gracze wymieniają się kluczami. Bo w najbliższych dniach powinno się pojawić kilkaset tysięcy kluczy dla PC.
'Problem tkwi w różnicy wspierania przez AMD i Nvidię - czytaj AMD ma inaczej rozwiązane, ma stałą wydajność niezależnie od ilości wątków (czy 32, 64, 128 czy więcej wątków dla AMD wszystko działa tak samo). Nvidia rozwiązała to tak samo jak Intel i AMD na CPU, przez co najlepiej mieć tyle wątków ile sprzętowo może obsłużyć sprzęt i tak samo jak na CPU u Nvidii jeśli przesadzisz z ilością wątków dużo ponad sprzętową ilość to dostajesz obniżenie wydajności spowodowane przez context switching.
W sprawie wyłączenia w sterownikach async chodzi o to, żeby nie dać oszustom zarobić na marketingowych machlojkach. Chodzi ofc o AMD i współtworzone z nimi od podstaw Ashes of Singularity, które wrzuca tysiące wątków, co nieznacznie spowalnia karty AMD, ale zabija wydajność Nvidii i to się liczy w tym marketingu, a nie to, że normalne gry będą używać od 32 (sprzętowo wspierane przez Nvidię - teraz przez zmianę w Pascalu Nvidia powinna obsługiwać do 128 wątków) do max 64 wątki (architektura AMD i maksymalna ilość wątków które mogą działąć równolegle). Tu nie ma się co dziwić Nvidii, że wyłączyła, gdy konkurencja po prostu gra nieuczciwie.
Taką propagandę uprawia PR AMD, ale to zabawne, bo AMD w wsparciu dla Dx12 jest w tyle, asynchroniczne obliczenia zrobione dobrze działają lepiej na Nvidii (zrobione źle sprawia, że Nvidia się dusi, ale AMD nic nie zyskuje).'
Ale jakie granie nieuczciwie?
Jeżeli autor tych słów rozumie czym jest programowanie do metalu, jaką rolę w kreacji obrazu odgrywa API, to chyba nie trzeba nic więcej pisać.
Ten komentarz na purepc to jedynie fanowskie głaskanie posiadaczy Nvidia, by nie czuli się gorszymi. Sam autor pisze o obliczeniach równoległych i asynchronicznych... tyle że tworzysz kontekst, przedstawiający to jak coś złego. To może od razu oskarżmy konsole o to, że od samych swoich początków były jednolite pod względem konfiguracji i umożliwiały programowanie do metalu? Przecież AMD wcześniej i Nvidia (teraz i wcześniej) blokowały takie rozwiązania na PC...
GeForce 780 ledwo pozwala na 30 klatek/s w Ultra 1080p. Do czego to doszło XD
Z drugiej strony stareńki Radeon 7970 pozwala na 60 klatek/s w Medium 1080p. Co nie jest złym wynikiem, bo Xbox pokazuje grę w 30fps. Tylko, że do High trzeba już Radeona 290 przy 60 klatkach/s.
Taką propagandę uprawia PR AMD, ale to zabawne, bo AMD w wsparciu dla Dx12 jest w tyle, asynchroniczne obliczenia zrobione dobrze działają lepiej na Nvidii (zrobione źle sprawia, że Nvidia się dusi, ale AMD nic nie zyskuje).'
Cytujesz wprost Skotiego, który IMO piszę po prostu bzdury ( jeśli mi nie wierzysz wejdź na fachowe forum beyond3d i tam poczytaj ).
Jakie to asynchroniczne skoro wg Skotiego metoda działania nvidia to mutli threading jak na CPU amd i intel, dalej będziesz miał luki idle https://youtu.be/v3dUhep0rBs?t=66... nvidia nie potrafi działać równolegle obliczenia + grafika, ma problem z szybką zmianą kontekstu. Co za asynchronicznie obliczenia skoro de facto nie liczą nic asynchronicznie http://www.extremetech.com/extreme/213519-...-we-know-so-far
Nie, raczej skopanego, całkowicie skopanego portu z konsoli. Kilka komentarzy wyżej masz więcej info na temat obsługi DX12 przez AMD i Nvidia
Aha czyli gdy skopana optymalizacja, w jakiejś grze, powodowała spadki na radeonach to była wina AMD, że nie umie napisać sterowników. Teraz gdy mamy grę niemal bezpośrednio z konsoli to wina Gry, że Gforce tak słabo wypadają. Ciekawa logika
Z tym dx12 to nie wiadomo jak jest - za mało gier i rzetelnych testów... To że w jakiejś grze czy 'smarku' radzi sobie lepiej jedna lub druga strona jeszcze o niczym nie świadczy.
Cytujesz wprost Skotiego, który IMO piszę po prostu bzdury ( jeśli mi nie wierzysz wejdź na fachowe forum beyond3d i tam poczytaj ).
Nie pisze bzdur dosłownie. Prawda jest taka, że 64 wątki pseudorównolegle gdy jest np. 30CU per GPU max to przegięcie bo to jak odpalenie 8x orthosa na FX8320...
Thirdly, said Cerny, 'The original AMD GCN architecture allowed for one source of graphics commands, and two sources of compute commands. For PS4, we’ve worked with AMD to increase the limit to 64 sources of compute commands -- the idea is if you have some asynchronous compute you want to perform, you put commands in one of these 64 queues, and then there are multiple levels of arbitration in the hardware to determine what runs, how it runs, and when it runs, alongside the graphics that's in the system.'
'The reason so many sources of compute work are needed is that it isn’t just game systems that will be using compute -- middleware will have a need for compute as well. And the middleware requests for work on the GPU will need to be properly blended with game requests, and then finally properly prioritized relative to the graphics on a moment-by-moment basis.'
This concept grew out of the software Sony created, called SPURS, to help programmers juggle tasks on the CELL's SPUs -- but on the PS4, it's being accomplished in hardware.
The team, to put it mildly, had to think ahead. 'The time frame when we were designing these features was 2009, 2010. And the timeframe in which people will use these features fully is 2015? 2017?' said Cerny.
.
Dlatego XboxOne dostał tylko 16 kolejek bo koncept ten (po części) pochodzi.. uwaga. Z procesora Cell. https://sites.google.com/site/konsolki/eib...ize-410-274.gif
AMD zresztą tez ma większe doświadczenie (od Nv) z magistralami pierścieniowymi. A co do samego Sony to patent na 32 rdzenie SPU połączone razem 'siecią' mieli złożony w 2004 roku. Według mnie nie ma opcji by Nv lepiej to ogarniało bo to 'patent' Sony-AMD.
W PS4 będzie lepiej zoptymalizowane bo CPU jest tu tak naprawdę w jednym chipie (jest podpięty do GPU magistralą asynchroniczną).
Wspomina się właśnie o middleware w kontekście asynchorus. Więc karty AMD na starcie powinny lepiej ogarniać VR.
Nie mówię, ze tak jest na 100% to tylko moje domysły na podstawie tego co czytałem w internecie.
Dlatego XboxOne dostał tylko 16 kolejek bo koncept ten (po części) pochodzi.. uwaga. Z procesora Cell. https://sites.google.com/site/konsolki/eib...ize-410-274.gif
AMD zresztą tez ma większe doświadczenie (od Nv) z magistralami pierścieniowymi. A co do samego Sony to patent na 32 rdzenie SPU połączone razem 'siecią' mieli złożony w 2004 roku. Według mnie nie ma opcji by Nv lepiej to ogarniało bo to 'patent' Sony-AMD.
W PS4 będzie lepiej zoptymalizowane bo CPU jest tu tak naprawdę w jednym chipie (jest podpięty do GPU magistralą asynchroniczną).
Wspomina się właśnie o middleware w kontekście asynchorus. Więc karty AMD na starcie powinny lepiej ogarniać VR.
Nie mówię, ze tak jest na 100% to tylko moje domysły na podstawie tego co czytałem w internecie.
No ty gadasz?
Każdy PCLolowiec powie ci ze to nie prawda i bajka, propaganda siana przez AMD a tak w ogóle to się nie znasz bo nie stać ciebie na kartę od nVidia.
Wystarczy rzucić okiem a art. Wszystkie przepełnione są miłością do 'zielonych' a pogardą co 'czerwonych'.
MS wczoraj rozesłał darmowe klucze PC dodawane do wersji Xbox i zgodnie z oczekiwaniami spora część trafiła na Allegro i Ebay
Allegro średnia cena - 99zł
EBay średnio - 30 dolarów
Jak ktoś kupił grę w Windows Store za 250zł to będzie żałował. Ale od początku było wiadomo że klucze do Quantum Break będą bardzo tanie. MS rozdał kilkaset tysięcy kluczy PC za darmo ludziom którzy grają na konsolach to musiało się to skończyć tak te klucze trafią na aukcje. Sam wczoraj swój kucz do wersji PC sprzedałem koledze i zwróciła mi się ponad połowa kosztu zakupu gry.
@Bandit: z tymi wątkami async jest jak z faktorem tesselacji. Niby nie widać różnicy a można łatwo dobić konkurencję. Nvidia w wielu grach gdzie maja partnerstwo wymuszała na dev użycie tess-factora x64, który w małym stopniu ucinał wydajność na GeForce-ach a zabierał sporo % z wydajności na kartach czerwonych. Jak wspomniałem różnic jakościowych nie widać. DjXbeat na forum poruszył ostatnio tą kwestie w W3, gdzie zmiana jakości wody z high na uber = zmiana tess-factora z x32 na x64. A najlepsze w tym jest to, że karty czerwonych tracą na tym nawet tam gdzie wprost nie widać wody. Aż się przypomina Crysis 2 i tesselowany ocean pod mapą. Także wykorzystywanie słabości konkurencji Nvidia ma ograne.
Piłeczka jest po obu stronach. A na async też znajdzie się odpowiedź w postaci ficzerów z FL12_1, które wspiera teraz tylko Maxwell. Szkoda, że na takich zagrywkach tracą gracze.
Nie tylko czerwoni tracą na zwiększonym ponad miarę faktorze teselacji. Keplery też dostają po dupie, choć teselatory mają trochę wydajniejsze od Radeonów to jednak znacznie słabsze od Maxwelli. Właściciele kart czerwonych mają jednak możliwość zniwelowania tego zabiegu z poziomu sterownika obniżeniem faktora teselacji, właścicielom Keplerów pozostaje przyglądanie się jak jest sztucznie uwalana wydajność ich kart.
PC Ultra wygląda niemal identyko jak Xone. No coś tu nie halo jest.
Bo domyślnie Ultra ma te same tekstury co na Xbox One. Rozdzielczość też jest taka sama - 4 bazowe klatki 720p są analizowane i rekonstruowana jest docelowa klatka 1080p. Ale na PC możesz ustawić rozdzielczość 4K która jako bazowe klatki używa rozdzielczości 1080p. Jakość obrazu będzie dużo lepsza. Bo karta graficzna będzie liczyła pełną klatkę 1080p czyli będziesz miał detale z dokładnością do 1 pixela. Bo obraz z 4 klatek 1080p zostanie zrekonstuowany do obrazu 4K który później możesz w ustawieniach karty zmniejszyć do 1080p. Obraz będziesz miał ostry jak żyleta
Xbox nie uciągnie pełnej bazowej klatki 1080p bo ma słabe GPU. Ale dobre PC z szybką kartą może sobie z tym poradzić. A jak komputer jest za słaby do 1080p (4K po rekonstrukcji) to można spróbować 900p (1440p po rekonstrukcji). Dobra karta na PC sobie z tym bez problemu poradzi. A jak się pojawi Pascal i Polaris to rozdzielczość 1080p (rekonstrukcja 4K) będzie w zasięgu każdego bo te karty będą lepiej obsługiwały DX12
Polecam przeczytać wszystko co Skoti48 (tutejszy bywalec) ma do powiedzenia. Mój link
Szkoda, że tak wiele osób dało się omamić takim marketingowym bełkotem o tej rzekomej przewadze kart AMD w DX12
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.
Nie ma tez co liczyć, że Vulkan 'naprawi' problemy NVidii, w najlepszym wypadku będzie tak samo wydajny jak DX12, a skoro oba API mają wspólny pierwowzór, a mianowicie Mantle, można się spodziewać podobnych rozwiązań i też dużego nacisku na obliczenia asynchroniczne.
Sądziłem że nikt już nie wierzy w te bzdury o pochodzeniu DX12 od Mantle. Przecież w DX12 po prostu odblokowali pewien znacznie bliższy sprzętowi sposób zarządzania, który uwalnia pewne zasoby. Znane to już było w czasach...... DX9
Zwyczajnie wycofali się rakiem z tego co forsowali od czasów DX10
ta 'show behind'... Co za przyziemny sposób mówienia o całkowitej zmianie poziomu abstrakcji, przyjmowanej do pisania kodu. Mam nadzieje, że jak łykniesz trochę tematu interfejsów, to zmienisz zdanie...
http://www.winbeta.org/news/tip-quantum-br...-starting-today
W sprawie wyłączenia w sterownikach async chodzi o to, żeby nie dać oszustom zarobić na marketingowych machlojkach. Chodzi ofc o AMD i współtworzone z nimi od podstaw Ashes of Singularity, które wrzuca tysiące wątków, co nieznacznie spowalnia karty AMD, ale zabija wydajność Nvidii i to się liczy w tym marketingu, a nie to, że normalne gry będą używać od 32 (sprzętowo wspierane przez Nvidię - teraz przez zmianę w Pascalu Nvidia powinna obsługiwać do 128 wątków) do max 64 wątki (architektura AMD i maksymalna ilość wątków które mogą działąć równolegle). Tu nie ma się co dziwić Nvidii, że wyłączyła, gdy konkurencja po prostu gra nieuczciwie.
Taką propagandę uprawia PR AMD, ale to zabawne, bo AMD w wsparciu dla Dx12 jest w tyle, asynchroniczne obliczenia zrobione dobrze działają lepiej na Nvidii (zrobione źle sprawia, że Nvidia się dusi, ale AMD nic nie zyskuje).'
Ale jakie granie nieuczciwie?
Jeżeli autor tych słów rozumie czym jest programowanie do metalu, jaką rolę w kreacji obrazu odgrywa API, to chyba nie trzeba nic więcej pisać.
Ten komentarz na purepc to jedynie fanowskie głaskanie posiadaczy Nvidia, by nie czuli się gorszymi. Sam autor pisze o obliczeniach równoległych i asynchronicznych... tyle że tworzysz kontekst, przedstawiający to jak coś złego. To może od razu oskarżmy konsole o to, że od samych swoich początków były jednolite pod względem konfiguracji i umożliwiały programowanie do metalu? Przecież AMD wcześniej i Nvidia (teraz i wcześniej) blokowały takie rozwiązania na PC...
Zwłaszcza że wiekszość nawet nie wie że coś takiego powstaje
To, że ty nie wiesz to mało kogo interesuje. Ważne, że wie o tym np DICE i EA, które jest członkiem grupy Khronos
https://www.khronos.org/members/contributo...nic_arts_inc_ea
Toż tu optymalizacja leży i kwiczy.
Dokładnie ukazuje to porównanie grafiki konsolowe 720p vs 1080p (wszystkie tryby).
I jeszcze ta cena
Tylko pogratulować frajerom kolejny raz ztegowanych bez mydła.
Super przyszłość rozdmuchanych tytułów...
Z drugiej strony stareńki Radeon 7970 pozwala na 60 klatek/s w Medium 1080p. Co nie jest złym wynikiem, bo Xbox pokazuje grę w 30fps. Tylko, że do High trzeba już Radeona 290 przy 60 klatkach/s.
Taką propagandę uprawia PR AMD, ale to zabawne, bo AMD w wsparciu dla Dx12 jest w tyle, asynchroniczne obliczenia zrobione dobrze działają lepiej na Nvidii (zrobione źle sprawia, że Nvidia się dusi, ale AMD nic nie zyskuje).'
Cytujesz wprost Skotiego, który IMO piszę po prostu bzdury ( jeśli mi nie wierzysz wejdź na fachowe forum beyond3d i tam poczytaj ).
Jakie to asynchroniczne skoro wg Skotiego metoda działania nvidia to mutli threading jak na CPU amd i intel, dalej będziesz miał luki idle https://youtu.be/v3dUhep0rBs?t=66... nvidia nie potrafi działać równolegle obliczenia + grafika, ma problem z szybką zmianą kontekstu. Co za asynchronicznie obliczenia skoro de facto nie liczą nic asynchronicznie
http://www.extremetech.com/extreme/213519-...-we-know-so-far
Zasługa dx12 ?
Nie, raczej skopanego, całkowicie skopanego portu z konsoli. Kilka komentarzy wyżej masz więcej info na temat obsługi DX12 przez AMD i Nvidia
Aha czyli gdy skopana optymalizacja, w jakiejś grze, powodowała spadki na radeonach to była wina AMD, że nie umie napisać sterowników. Teraz gdy mamy grę niemal bezpośrednio z konsoli to wina Gry, że Gforce tak słabo wypadają. Ciekawa logika
Z tym dx12 to nie wiadomo jak jest - za mało gier i rzetelnych testów... To że w jakiejś grze czy 'smarku' radzi sobie lepiej jedna lub druga strona jeszcze o niczym nie świadczy.
Cytujesz wprost Skotiego, który IMO piszę po prostu bzdury ( jeśli mi nie wierzysz wejdź na fachowe forum beyond3d i tam poczytaj ).
Nie pisze bzdur dosłownie. Prawda jest taka, że 64 wątki pseudorównolegle gdy jest np. 30CU per GPU max to przegięcie bo to jak odpalenie 8x orthosa na FX8320...
Podaj jakikolwiek przykład na poparcie tego co napisałeś
'The reason so many sources of compute work are needed is that it isn’t just game systems that will be using compute -- middleware will have a need for compute as well. And the middleware requests for work on the GPU will need to be properly blended with game requests, and then finally properly prioritized relative to the graphics on a moment-by-moment basis.'
This concept grew out of the software Sony created, called SPURS, to help programmers juggle tasks on the CELL's SPUs -- but on the PS4, it's being accomplished in hardware.
The team, to put it mildly, had to think ahead. 'The time frame when we were designing these features was 2009, 2010. And the timeframe in which people will use these features fully is 2015? 2017?' said Cerny.
Dlatego XboxOne dostał tylko 16 kolejek bo koncept ten (po części) pochodzi.. uwaga. Z procesora Cell.
https://sites.google.com/site/konsolki/eib...ize-410-274.gif
AMD zresztą tez ma większe doświadczenie (od Nv) z magistralami pierścieniowymi. A co do samego Sony to patent na 32 rdzenie SPU połączone razem 'siecią' mieli złożony w 2004 roku. Według mnie nie ma opcji by Nv lepiej to ogarniało bo to 'patent' Sony-AMD.
W PS4 będzie lepiej zoptymalizowane bo CPU jest tu tak naprawdę w jednym chipie (jest podpięty do GPU magistralą asynchroniczną).
Wspomina się właśnie o middleware w kontekście asynchorus. Więc karty AMD na starcie powinny lepiej ogarniać VR.
Nie mówię, ze tak jest na 100% to tylko moje domysły na podstawie tego co czytałem w internecie.
https://sites.google.com/site/konsolki/eib...ize-410-274.gif
AMD zresztą tez ma większe doświadczenie (od Nv) z magistralami pierścieniowymi. A co do samego Sony to patent na 32 rdzenie SPU połączone razem 'siecią' mieli złożony w 2004 roku. Według mnie nie ma opcji by Nv lepiej to ogarniało bo to 'patent' Sony-AMD.
W PS4 będzie lepiej zoptymalizowane bo CPU jest tu tak naprawdę w jednym chipie (jest podpięty do GPU magistralą asynchroniczną).
Wspomina się właśnie o middleware w kontekście asynchorus. Więc karty AMD na starcie powinny lepiej ogarniać VR.
Nie mówię, ze tak jest na 100% to tylko moje domysły na podstawie tego co czytałem w internecie.
No ty gadasz?
Każdy PCLolowiec powie ci ze to nie prawda i bajka, propaganda siana przez AMD a tak w ogóle to się nie znasz bo nie stać ciebie na kartę od nVidia.
Wystarczy rzucić okiem a art. Wszystkie przepełnione są miłością do 'zielonych' a pogardą co 'czerwonych'.
Allegro średnia cena - 99zł
EBay średnio - 30 dolarów
Jak ktoś kupił grę w Windows Store za 250zł to będzie żałował. Ale od początku było wiadomo że klucze do Quantum Break będą bardzo tanie. MS rozdał kilkaset tysięcy kluczy PC za darmo ludziom którzy grają na konsolach to musiało się to skończyć tak te klucze trafią na aukcje. Sam wczoraj swój kucz do wersji PC sprzedałem koledze i zwróciła mi się ponad połowa kosztu zakupu gry.
Piłeczka jest po obu stronach. A na async też znajdzie się odpowiedź w postaci ficzerów z FL12_1, które wspiera teraz tylko Maxwell. Szkoda, że na takich zagrywkach tracą gracze.
Nie tylko czerwoni tracą na zwiększonym ponad miarę faktorze teselacji. Keplery też dostają po dupie, choć teselatory mają trochę wydajniejsze od Radeonów to jednak znacznie słabsze od Maxwelli. Właściciele kart czerwonych mają jednak możliwość zniwelowania tego zabiegu z poziomu sterownika obniżeniem faktora teselacji, właścicielom Keplerów pozostaje przyglądanie się jak jest sztucznie uwalana wydajność ich kart.
Bo domyślnie Ultra ma te same tekstury co na Xbox One. Rozdzielczość też jest taka sama - 4 bazowe klatki 720p są analizowane i rekonstruowana jest docelowa klatka 1080p. Ale na PC możesz ustawić rozdzielczość 4K która jako bazowe klatki używa rozdzielczości 1080p. Jakość obrazu będzie dużo lepsza. Bo karta graficzna będzie liczyła pełną klatkę 1080p czyli będziesz miał detale z dokładnością do 1 pixela. Bo obraz z 4 klatek 1080p zostanie zrekonstuowany do obrazu 4K który później możesz w ustawieniach karty zmniejszyć do 1080p. Obraz będziesz miał ostry jak żyleta
Xbox nie uciągnie pełnej bazowej klatki 1080p bo ma słabe GPU. Ale dobre PC z szybką kartą może sobie z tym poradzić. A jak komputer jest za słaby do 1080p (4K po rekonstrukcji) to można spróbować 900p (1440p po rekonstrukcji). Dobra karta na PC sobie z tym bez problemu poradzi. A jak się pojawi Pascal i Polaris to rozdzielczość 1080p (rekonstrukcja 4K) będzie w zasięgu każdego bo te karty będą lepiej obsługiwały DX12
Ilość raportowań powinna być wyświetlana w profilu, a po stwierdzeniu, że większość jest niesłusznych - ban konta na tydzień.