Do puki stare konsole czyli X360 i PS3 nie odejdą na dobre gry nadal będą w większości robione pod DX9 i będą na takim sprzęcie nadal działać, z prostej przyczyny ekonomia produkcji. Nowych konsol M$ jest na razie zbyt mało, aby przejść w całości na DX11, z kartami graficznymi u graczy też jest różnie, więc nie spodziewajmy się nagle porzucenia starych standardów.

W pierwszym Surface z Win RT miałeś Tegre 3

Czyli dopiero K1 ma unifikowane jednostki PS/VS
Wydawało mi się, że T4 było w WinRT... czyli wspierało wszystkie featury DX11?

Jak tylko przeglądnę to Ci je wyślę.


48 jest PS, a 24 jest VS - tylko PS nadają się do obliczeń więc skoro w tym kontekście mówimy to tylko o 48. Co do samego dzielenia przepustowości przez ilość rdzeni to już odpowiedziałem Ci wyżej jakie to idiotyczne. Jeśli już chcesz wiązać ogólnie rdzenie i przepustowość pamięci (w nie najczęstrzych przypadkach kiedy pamięć jest wąskim gardłem) to powinieneś liczyć przepustowość na cykl (bo kilka słabszych rdzeni, może wymagać mniej pamięci niż jeden szybki (który liczy szybciej i musi częściej nowe dane dostawać)).


Dalej gadasz bzdury. Deferred to zupełnie inna technika, jednak robi to samo i efekt jest identyczny i efekt jest taki sam (używasz zarówno z deferred jak i forward tych samych modeli cieniowania (wręcz co do kropki kodu)). Jeśli już szukasz analogii to samochód i rower ;p. Chcesz dostać się do danego miejsca (danej identycznej klatki) to możesz wybrać rower (forward) lub samochód (deferred). Samochód ma taką przewagę, że dociera na miejsce szybko i można zaplanować daleką podróż (lepsze efekty) osiągalną też na rowerze (przeszkodą nie jest to, że się nie da, a bardziej to, że trwa to za długo), ale w tak długim czasie, że się odpuszcza, ale znowu w wiele miejsc samochodem nie dotrzesz, a rowerem bez problemu (półprzezroczyste obiekty), dlatego najlepiej jeździć samochodem z rowerem w bagażniku (hybrydowo deferred+forward).

hehe... wyglądają inaczej bo....
.... no sh... jednak to dla Ciebie proste. EOT Hashi ogarnia

Przede skalowność, wtedy 4m@4,w ch... dużo MHz procesory mogłyby zapewnić rywalizację wydajnościową dla 4c Intel-a



Nie ważne czy taktor, czy osobe auto jeśli widzisz tylko efekt czyli przewiezienie xy osób... Deferred jest znacznie szybszy i tyle, miałeś od dawna silniki takie i takie i różnica była głównie szybkości.Po prostu plazma uderzyła ci do głowy.

Jeżeli rendering wydajniejszy możesz dać więcej detali, lepsze cienie, światło.

Tylko, że AMD nie tworzy Mantle, by kontrolować API. Dla AMD liczy się obniżenie narzutu na procesor i zwiększenie skalowalności, bo AMD ma procesory z powolnym w stosunku do Intela jednym wątkiem, ale za to sporo rdzeni w dosyć taniej cenie. Dla AMD może to wprowadzić również DirectX12, nowe OpenGL itp, ale jeśli zmniejszy to narzut i zwiększy skalowalność - skorzysta AMD.
Oprócz tego ludzie będą wydawać mniej kasy na procesor (np. kupią i5 zamiast i7), a z pozostałej kasy być może część pójdzie na lepszą, droższą kartę AMD.

@up
Tegra 4 nie miała zunifikowanych shaderów?

Takie sprawdzanie zazwyczaj prowadzi Cię na manowce co często pokazujesz (ważne są tylko rzetelne papierki, a nie to co google wypluwa). Co do XDR i 400MHz to dobrze, że w Elpida Cię nie słuchają bo ich XDR (1 nie 2) 900MHz (7.2GHz efektywnie) jakoś nie chce się do twoich sensacji dopasować.


Napisałem, że tak ma Tegra 4 (bo wiem jaka tam pamięć jest), a co 64procki to zastanawiam się jakim cudem Ci się one wzieły. Tegra 4 ma 72 rdzenie, do obliczeń nadają się 48 (4x rdzenie SIMD, każdy liczy po 12 liczb FP32). W wypadku Cell jest to 32 rdzenie licząc w ten sam sposób (8x SIMD (SPU) liczące po 4x liczby w FP32). Cell jednak są wyżej taktowane rdzenie, więc pojedynczy rdzeń potrzebuje częściej danych z pamięci i wychodzi na to, że Cell ma gorszy stosunek wydajności procesorów do wydajności ramu niż GeForce ULP z Tegra 4.Nie wiem co chcesz w ten sposób udowodnić poza idiotycznym stwierdzeniem ile z transferu przypada na rdzeń. Nawet jeśli przyjmiemy scenariusz programu bardzo uzależnionego od przepustowości pamięci to przeliczanie na rdzeń jest idiotyczne. Przykładowo rdzeń X ma wydajność 0.5 rdzenia Y, to 2x rdzenie X będą miały takie samo zapotrzebowanie na pamięć jak 1x rdzeń Y w takim programie (2x częściej ten rdzeń będzie musiał odczytywać nowe dane niż rdzenie słabsze, ale liczniejsze). Liczenie przepustowości pamięci na rdzeń wygląda jak liczenie ile da się przejechać na baku samochodu porównując niewielkie różnice w pojemności baków, a zapominając o spalaniu auta.


Czytać może czytałeś, ale wielokrotnie pokazywałeś, że jednak nie zrozumiałeś, dlatego postanowiłem jeszcze raz Ci wytłumaczyć i dalej czekam, na to aż zacytujesz mnie lub odszczekasz oszczerstwa.

Każda zmiana w GPU wymaga przeprojektowania całego układu. Naprawdę odkryłeś amerykę.
Dodasz dodatkowe CU też musisz przeprojektować całe GPU, dodasz ACE musisz przeprojektować całe GPU, dodasz cache też trzeba przeprojektować całe GPU...

Danie x ACE od początku nie było problemem i od samusienka miałeś różne ACE w x GPU AMD.

Ty nie pojmujesz ze jak Ci się w taki sposób powiększa 'magistrala' to musisz przeprojektować cały układ. Jak ty sobie to wyobrażasz, dodajesz 6 magistral pierścieniowych + nowe kolejki bez przeprojektowania całego układu?
Ośmiornica to protoplasta glizdy.

A 2 ACE to protoplasta 8 ACE?



Nie no wiem, ale chciałem się upewnić czy coś mi się już kompletnie nie pokićkało.

Jest, ale według Hashiego zdaje się Ram ma taką przepustowość więc na tym się skupiłem (ofc PPE może prosto ze swojego cache przesłać dane do SPE bez pośrednictwa Ramu (jednak przez EIB, z prędkością 2x wyższą niż Ram), ale nie o tym Hashi mówi).

Ty też, ale nie przeszkadza Ci


Słyszałem, że Sony zaprojektowało ACE w radeonach.


Nie jest tak, że PPE/RSX/SPE nie muszą komunikować się przez RAM.

2. Poszukam później papierków to Ci podeślę.
3. Po to samo po co każdy rdzeń w może pochłonąć prawie całą przepustowość pamięci. EIB Ma przepustowość teoretyczną 204.8 GB/s (w teorii), bo teoretycznie każdy SPE ma 25.6 GB/s (osiąganą jeśli tylko 1x SPE działa) i suma maksymalnie 8x SPE daje 204.8 GB/s. Ofc nie o to chodzi, że wszystkie SPE mają taką jeśli działają wszystkie, bo pamięć XDR nie wyrabia, a mają taką a nie inną przepustowość, aby jeśli liczysz tylko na jednym SPE nie ograniczała go przepustowość EIB (dlatego każdy może pobierać dane z wydajnością całego RAMU, ale gdy już działają 2x rdzenie SPE to ta wydajność wynosi już po 12.8 GB/s (25.6 jeśli czyta z cache), jak 6x rdzeni to już przepustowość 4.3 GB/s czytając z RAM i 8.5 GB/s czytając z cache). Zresztą ładnie IBM Ci przedstawił jaką maksymalną przepustowość ma pamięć XDR w Cell (na dole przy Memory).
6. Dobrze wiesz, że obok Crysis 1 to to nie leżało nawet. W takich ustawieniach to nawet na GF8500 by działało (10x wolniejszy od K1).


Masz dobrą pamięć do tego, że ubzdurałeś sobie coś czego tam nie było nigdy (często to robisz, bo czytanie ze zrozumieniem leży). Dlatego poprosiłem o cytat, aby się ludzie pośmiali jak można prostego tekstu zupełnie nie zrozumieć. Mogłem powiedzieć, że Deferred daje identyczne rezultaty co Forward (bo to prawda - różni je wydajność i jedna wada Deferred czyli obiekty półprzezroczyste (dlatego je renderuje się hybrydowo w forward)), mogłem powiedzieć, że wprowadzenie deferred jest tanie/darmowe, bo w forward i tak masz wszystkie tekstury do wykorzystania jako gbuffory (nie do forward, a do efektów postprocess). Używa się identycznych modeli oświetlenia. Różnica pomiędzy deferred a forward rendering polega nie na efekcie (ten jest taki sam), a sposobie dojścia do tego samego efektu - forward cieniuje na geometrii (przez co oblicza często rzeczy które robi niepotrzebnie, bo coś go zasłoni i każde kolejne światło jest kosztowne, bo trzeba przetwarzać geometrię kilka razy), a defered zbiera informacje wszystkie w teksturach i dopiero tam w oparciu o identyczne dane jak w forward liczy dokladnie to samo (ale już na etapie fragmentów, przez co kolejne światła nie są tak kosztowne i zawsze liczy się dokładnie tyle ile będzie widoczne (no poza półprzezroczystymi obiektami, bo widać na teksturach tylko najbliższy obiekt, a nie te zaslonięte przez niego (dlatego to robi się dalej w forward))). Różnica jest spora w sposobie dostarczenia danych do algorytmów cieniujących, ale nie w efekcie.


Bo fakuje się GI za pomocą wielkiej ilości lamp, które zabiłyby wydajność forward (efekt byłby identyczny ale FPS znacznie niższy (przez znacznie ma się rozumieć poniżej 1 FPS ;p)). Deferred na PC wygląda tak samo (z tą różnicą, że pozwala na więcej w tej samej wydajności) jak Forward, ale na konsolach ze względu na MRT z 4x tekstur obcina się przykładowo kolory specular odbicia (masz tylko nasycenie odbicia w odcieniach szarości (1 kanał zamiast 3x kanałów tekstury) itp. po prostu usuwa się mniej istotne dla efektu dane, aby wykorzystać wydajność deferred - laik i tak nie zauważy różnicy).

Po za tym Skoti nie wierze ze twierdzisz ze oświetlenie w deferred wygląda gorzej. Ono wygląda kilka razy lepiej niż w forward.