komentarze
Rybaczek KoziołkaZobacz profil
Poziom ostrzeżenia: 33%
Rybaczek Koziołka2019.08.23, 13:22
20#1
Mnie ta sytuacja nie dziwi. Po co się pakować w coś, co na rynku się nie sprzedaje? Tutaj raczej przydałoby się pocięcia GPU na kawałki tak jak jest w ryzenach i połączenie tego w taki sposób, aby skalowanie w górę faktycznie znacznie zwiększało wydajność. Jednak póki co jest bariera której pokonanie jest kosztowne. AMD skupia się obecnie głównie na CPU, bo tu jest najwięcej kasy.

Przewiduję że sytuacja się odwróci wraz z produkcją nowych tytułów wyłącznie z użyciem Vulcan lub natywnego DX12. Niestety obecnie większość tytułów to DX12 kompatybilny z DX11, co jest w zasadzie użyciem trybu DX11 okraszonego wybranymi elementami DX12.
supervisorZobacz profil
Poziom ostrzeżenia: 0%
supervisor2019.08.23, 13:39
Skoro programowanie na DX12 i Vulkanie mgpu w trybie explicit ma podobny poziom trudności, nie ma powodu na istnienie crossfire. Crossfire i SLI to przeżytek ery DX10 i DX11 i powinno zginąć razem z nimi.
mag_zbcZobacz profil
Poziom ostrzeżenia: 0%
mag_zbc2019.08.23, 13:48
12#3
Po sukcesie projektu CPU bazującego na chipletach i Infinity Fabric, AMD mogłoby skupić się na próbie przeniesienia go na pole GPU - tak, żeby karta składała się z modułów, ale była widziana przez system jako jedno urządzenie.
szefonsZobacz profil
Poziom ostrzeżenia: 0%
szefons2019.08.23, 14:08
Rybaczek Koziołka @ 2019.08.23 13:22  Post: 1215300
Niestety obecnie większość tytułów to DX12 kompatybilny z DX11, co jest w zasadzie użyciem trybu DX11 okraszonego wybranymi elementami DX12.

Nie, dx11 nie może korzystać z elementów dx12, wiec de facto to jest użycie po prostu dx11, teraz wszystko jest zunifikowane i jak się wykrywa opcje to i tak wszystko idzie przez wspólne biblioteki, ale pod powłoką i tak utworzy kontekst dx11, jeżeli tak ma być.
Kasper PCMRZobacz profil
Poziom ostrzeżenia: 0%
Kasper PCMR2019.08.23, 15:24
mag_zbc @ 2019.08.23 13:48  Post: 1215303
Po sukcesie projektu CPU bazującego na chipletach i Infinity Fabric, AMD mogłoby skupić się na próbie przeniesienia go na pole GPU - tak, żeby karta składała się z modułów, ale była widziana przez system jako jedno urządzenie.

Z GPU jest zdecydowanie trudniej co nie zmienia faktu że już dość dawno temu jakiś przedstawiciel AMD mówił że prędzej czy później trzeba będzie szukać rozwiązania w strukturze chipów MCM
mag_zbcZobacz profil
Poziom ostrzeżenia: 0%
mag_zbc2019.08.23, 15:44
Kasper PCMR @ 2019.08.23 15:24  Post: 1215321
mag_zbc @ 2019.08.23 13:48  Post: 1215303
Po sukcesie projektu CPU bazującego na chipletach i Infinity Fabric, AMD mogłoby skupić się na próbie przeniesienia go na pole GPU - tak, żeby karta składała się z modułów, ale była widziana przez system jako jedno urządzenie.

Z GPU jest zdecydowanie trudniej co nie zmienia faktu że już dość dawno temu jakiś przedstawiciel AMD mówił że prędzej czy później trzeba będzie szukać rozwiązania w strukturze chipów MCM

Dlaczego 'zdecydowanie trudniej'? Przecież GPU składają się z osobnych compute units a widoczne są jako jedno urządzenie.
lstarbaZobacz profil
Poziom ostrzeżenia: 0%
lstarba2019.08.23, 15:50
Mam nadzieję, że prędzej, czy później zobaczymy GPU oparte o chiplety widoczne dla systemu i zachowujące się, jak monolityczny produkt. David Wang w wywiadzie udzielonym rok temu mówił, że dla układów obliczeniowych jest to już teraz wykonalne, ale dla zastosowania w grach, póki co nie.
taithZobacz profil
Poziom ostrzeżenia: 0%
taith2019.08.23, 16:25
-4#8
Łączenie GPU jak Ryzenów nie jest drogie, jest niemożliwe.
W chwili obecnej nie ma metody aby rozbić GPU na mniejsze chiplety, nowy projekt jest potrzebny, może Intel core pokaże.
Ale na razie to marzenia.
Makavcio2Zobacz profil
Poziom ostrzeżenia: 0%
Makavcio22019.08.23, 17:11
-2#9
Nvidia była odsądzana od czci i wiary za brak SLI w niższych modelach, a tutaj proszę, zmieniła się firma i nagle rozsądek się odnalazł :E
Łączenie kart graficznych, pomimo obiecywanych cudów-niewidów przy okazji dx12, było wielkim niewypałem i przynajmniej na razie śmierć tego rozwiązania jest czymś zupełnie normalnym. Trochę szkoda, bo wizja współpracy kilku kart graficznych w systemie, łącznie z kartą zintegrowaną z procesorem, była bardzo przyjemna. Nikt nigdy nie wierzył specjalnie w jej realizację, ale brzmiała obiecująco.
GalvatronZobacz profil
Poziom ostrzeżenia: 0%
Galvatron2019.08.23, 18:06
Multi-GPU to drogie rozwiązanie, dla garstki zamożnych entuzjastów, które nie miało i nie ma szans się upowszechnianić.

Nie warto pisać gier i sterowników dla tego promila ludzi, którzy mogą sobie pozwolić na dwa lub więcej GPU. To jest kompletnie nieopłacalne.

Multi-GPU miałby sens w zastosowaniach profesjonalnych, bo tam taka inwestycja się zwróci, ale w grach?
DisconnecTZobacz profil
Poziom ostrzeżenia: 0%
DisconnecT2019.08.23, 18:29
Galvatron @ 2019.08.23 18:06  Post: 1215332
Multi-GPU to drogie rozwiązanie, dla garstki zamożnych entuzjastów, które nie miało i nie ma szans się upowszechnianić.

Nie warto pisać gier i sterowników dla tego promila ludzi, którzy mogą sobie pozwolić na dwa lub więcej GPU. To jest kompletnie nieopłacalne.

Multi-GPU miałby sens w zastosowaniach profesjonalnych, bo tam taka inwestycja się zwróci, ale w grach?


Drogie bo producenci wymyślili sobie wsparcie m-GPU tylko w najdroższych modelach...
Pamiętam jeszcze czasy jak łączyło się dwa Radki HD6850/HD6870 w CF i można było osiągnąć wydajność w okolicach GTX 580 za znacznie mniejsze pieniądze. Oczywiście wady CF/SLI były widoczne, ale i tak dla wielu osób to było znacznie lepsze rozwiązanie pod względem ceny. ;)
DeniryerZobacz profil
Poziom ostrzeżenia: 0%
Deniryer2019.08.23, 18:56
Kasper PCMR @ 2019.08.23 15:24  Post: 1215321
mag_zbc @ 2019.08.23 13:48  Post: 1215303
Po sukcesie projektu CPU bazującego na chipletach i Infinity Fabric, AMD mogłoby skupić się na próbie przeniesienia go na pole GPU - tak, żeby karta składała się z modułów, ale była widziana przez system jako jedno urządzenie.

Z GPU jest zdecydowanie trudniej co nie zmienia faktu że już dość dawno temu jakiś przedstawiciel AMD mówił że prędzej czy później trzeba będzie szukać rozwiązania w strukturze chipów MCM

Vega w Mac Pro używa infinity fabric link AMD Infinity Fabric Link: Advanced Peer-to-Peer GPU Communications

Two Infinity Fabric™ Links per GPU for high speed Direct-Connect GPU clusters delivering up to 200 GB/s GPU peer-to-peer bandwidth.


https://wccftech.com/amds-infinity-fabric-detailed/
https://hexus.net/tech/news/graphics/13135...ga-ii-duo-gpus/
@Galvatron łączenie różnych GPU (mGPU nie mylić z Multi-GPU a.k.a SLI czy CrossFireX) nadal jest i działa w DX12 i Vulkan, ale wymaga większego nakładu pracy żeby to działało, a że większy nakład pracy = dłuższy czas tworzenia = więcej konfiguracji do testów (żeby ktoś je jeszcze w dzisiejszych czasach przeprowadzał, przynajmniej jeśli chodzi o gry...) = większe koszty to żadne Korpo, które tworzy AAA te nie będzie używać.
onix3901Zobacz profil
Poziom ostrzeżenia: 0%
onix39012019.08.24, 10:53
Nie zgadzam się z tym że crossfire jest drogie dla użytkownika. Jak ktoś miał już kartę starszą to później kupił taką samą używaną co zwiększyło wydajność. Sam mam radeon 7990 karta z dwoma gpu i co mam teraz z nim zrobić jak nie mam wsparcia. Na nowych grach działa tylko jeden gpu a drugi ma wakacje raczej już na zawsze. Chciał bym chociaż mieć opcję w sterowniku żeby wybrać który rdzeń ma być używany zeby nie meczyc tylko pierwszego gpu. Nawet nie mozna zwiekszyc obrotow wentylatora na drugim rdzeniu bo wylaczyli taka opcje ... totalna lipa i jestem niezadowolony lenistwem AMD od zawsze ich wspieralem bo nie chciałem monopolu ale oni olali sprawe. Jak nivida bedzie wspierac SLI to kupie ich karte.
AdolphZobacz profil
Poziom ostrzeżenia: 0%
Adolph2019.08.24, 11:23
-3#14
Najbardziej opłacalny moment na SLI/crossfire to był GTX660 vs 680.
Choć lepiej mieć więcej klientów, niż ich nie mieć. To jednak wiadomo od dawna, AMD nie mogło sobie już od długiego czasu na to pozwolić i nawet te karty które mogły działać w CF, to chodziły po prostu słabo. Więc sensowniej było po prostu zablokować taką możliwość.
WibowitZobacz profil
Poziom ostrzeżenia: 0%
Wibowit2019.08.24, 19:32
mag_zbc @ 2019.08.23 15:44  Post: 1215323
Kasper PCMR @ 2019.08.23 15:24  Post: 1215321
(...)

Z GPU jest zdecydowanie trudniej co nie zmienia faktu że już dość dawno temu jakiś przedstawiciel AMD mówił że prędzej czy później trzeba będzie szukać rozwiązania w strukturze chipów MCM

Dlaczego 'zdecydowanie trudniej'? Przecież GPU składają się z osobnych compute units a widoczne są jako jedno urządzenie.

Problemem jest synchronizacja danych między compute units. Obecnie CU i cache L1 jest połączone z cache L2 i kontrolerami pamięci za pomocą gigantycznego crossbara. Każdy kawałek L2 jest zespawany ze swoim kontrolerem pamięci. Z dokumentacji wspomnianego Radeona: 'The L2 cache is shared across the whole chip and physically partitioned into multiple slices. Four slices of the L2 cache are associated with each 64-bit memory controller to absorb and reduce traffic.' To samo jest w GeForce'ach. Przepustowość crossbara (czyli co za tym idzie i cache L2) jest bardzo duża. Dla przykładu w Radeonie RX 5700XT przepustowość cache L2 to jakieś 2 terabajty na sekundę. To prawdopodobnie więcej niż sumaryczna przepustowość wszystkich połączeń Infinity Fabric w pełnym czipie AMD Epyc Rome, a przecież ten Radeon ma zaledwie 251 mm^2 w procesie 7nm. Co by było gdyby takich Radeonów było kilka? Trzeba by czegoś znacznie wydajniejszego energetycznie od Infinity Fabric. Może 3D stacking + TSV (through silicon vias)? Ale co wtedy z odprowadzaniem ciepła?

AMD ma chiplety w CPU, ale takie rozwiązanie znacznie spowalnia komunikację między rdzeniami w różnych chipletach (konkretniej: CCXach). W GPU mogę korzystać z całego cache ostatniego poziomu z taką samą prędkością niezależnie z której części tego cache korzystam. W chipletach CPU tak nie jest - dostęp do LLC na tym samym CCXie jest szybki, ale dostęp do danych w LLC innego CCXa jest już wolny i prądożerny. Przeniesienie architektury chipletowej z Zena wprost do GPU prawdopodobnie skutkowałoby mocnym spadkiem wydajności w aktualnie dostępnych grach. Być może zupełnie nowy sposób pisania shaderów i ogólnie silników gier przywróciłby wysoką wydajność, ale czy nie łatwiej po prostu zakodować w silniku wsparcie dla mGPU już teraz, bez czekania na mniej lub bardziej udane eksperymenty z architekturą?

Poza tym Intel chwali (a przynajmniej chwalił) się że stworzy chipletową architekturę GPU.
Edytowane przez autora (2019.08.24, 19:33)
anemusZobacz profil
Poziom ostrzeżenia: 0%
anemus2019.08.24, 20:50
Spokojnie, dowalili pcie4 to teraz mogą robić karty wieloukładowe na jednym laminacie do woli, a jak wszyscy wiemy potrafią.
SunTzuZobacz profil
Poziom ostrzeżenia: 0%
SunTzu2019.08.24, 23:59
-6#17
Generalnie pisząc multiGPU mi kojarzy się liczenie efektów cząsteczkowych, AI, rendering CUDA/OpenCL... to chyba jest i będzie.
Sli/Crossfire to wykorzystanie kilku kart w celu nie jako emulacji jednej dla silnika gry jedna z wielu technik wykorzystania wielu kart i myślę, że nie ma co się rozczulać, bo chyba najsłabsza.

Najgorsze jest to, że DX11 działa tak dobrze na NV, że praktycznie nikt nie tyka DX12 na poważnie, a AMD praktycznie zatrzymało w rozwoju DX11 i nie ocierają się o poziom NV.

anemus @ 2019.08.24 20:50  Post: 1215388
Spokojnie, dowalili pcie4 to teraz mogą robić karty wieloukładowe na jednym laminacie do woli, a jak wszyscy wiemy potrafią.


Gdyby udało im się ogarnąć niezależne SIMD-y jako jedno GPU to pci-e 4 nic nie da. Jeśli mają to być dwa urządzenia na jednym laminacie to już 5700 są gorące :P
Edytowane przez autora (2019.08.25, 00:02)
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842019.08.25, 07:55
@SunTzu - no co ty opowiadasz, jak ktoś chce RT to siłą rzeczy musi w DX12 ;) DXR to rozszerzenie DX12. Czyli NV ma parcie na DX12 i musi przekonywać developerów do DX12 bo żeby użyli DXR to muszą też zrobić backward compatible renderer bez DXR, a to chyba łatwiej gdy pracuje się w DX12 tylko i wyłącznie, prawda? No... to raz.
Dwa - i SLI nie ma się wcale najlepiej, a już chyba całkowicie zapomniano o konfiguracjach z 3 i 4 GPU, które jeszcze dekadę demu były dla entuzjastów jakimś rozwiązaniem. Te techniki po prostu są nieadekwatne do obecnych trendów. Trzeba by opracować nowe, lepsze, a to konkretny hajs. Rozwój GPU to teraz taka jazda na zaciągniętym ręcznym, niby gaz do dechy, ale coś zamula. Czy chiplety są wyjściem z sytuacji? Oczywiście, że są. Tylko najpierw ktoś musi ogarnąć jak to ma w rzeczywistości wyglądać. Niech tylko nikt nie pieprzy o przepustowościach, bo GPU w samej mikroarchitekturze SĄ modularne. Takimi rzeczywistymi mikroGPU od wielu lat są GPC (w architekturze nvidii). Czyli by to działało trzeba by spełnić kilka warunków np.
- po wydzieleniu GPC na chiplety każdy dostaje swój kawałek L2, ale większy
- po wydzieleniu GPC na chiplety każdy dostaje 64bit IMC, L3 oraz minimum 2 szybkie interconnecty (albo 512bit HBM na głowę i nie trzeba się martwić ścieżkami na PCB co pozwoli na jeszcze szersze interconnecty)
- ring bus by zapewnić komunikację między GPC oraz spójność danych dzięki L3
I oczywiście, zasadniczo jest to (aktualnie) zdecydowanie droższe rozwiązanie niż monolit, ale myślę, że przynajmniej by ruszyło skostniały rynek i rzeczywiście wydajność do przodu. A teraz co i jak techicznie...
GPU monolit też ma 64bit kontrolery w liczbie mnogiej a nie jeden wielki, modularność pozwala blokować niesprawne kawałki i całość działa dalej jako niższy model. Spójność danych jest zachowana dzięki współdzielonemu L2, które kompensuje też opóźnienia w dostępie do pamięci. W przypadku chipletów każdy chiplet ma bezpośredni dostęp tylko do swojej lokalnej pamięci (bardzo szybki, może nawet szybszy niż w monolicie), ale dużo gorszy do fragmentów obsługiwanych przez inne chiplety. Dlatego potrzebne jest większe L2 oraz L3 by to skompensować. Więcej SRAM, większy chip, więcej tranzystorów, większy koszt. Zatem to nigdy nie będzie rozwiązanie nastawione na ekonomię. To będzie rozwiązanie nastawione na maksymalizację wydajności i JESZCZE większą elastyczność konfiguracji. Poza tym samo wdrażanie może być tańsze niż monolitu, a gdyby nie marża za 'nowość' i 'najwydajniejszą kartę' to akurat cena wydajniejszych chipletowych mogłaby być nie większa niż RTX2080 obecnie (przy jednak większej wydajności).
supervisorZobacz profil
Poziom ostrzeżenia: 0%
supervisor2019.08.25, 08:29
Promilus1984 @ 2019.08.25 07:55  Post: 1215395
rawr

Lisa Su wypowiadała się na temat GPU korzystającym z technologii McM (multi-chip-module) czyli z chipletami, i problem jest nie z hardware tylko z software, nie pamiętam która to była wypowiedź bo to było zaraz po wyjściu Threadrippera. Według niej nie ma możliwości software'owej aby skorzystać z McM na skale masową bo konieczne byłoby programowanie specjalnie pod McM w każdej grze i każdym programie korzystającym z GPU.

Dodała też, że konieczne jest rozwiązanie hardware'owe które sprawiłoby iż McM działałby dokładnie na tym samym softwarze co monolityczne GPU, a to zajmie jeszcze kilka dobre lat.
WibowitZobacz profil
Poziom ostrzeżenia: 0%
Wibowit2019.08.25, 10:10
-1#20
Promilus1984 @ 2019.08.25 07:55  Post: 1215395
Rozwój GPU to teraz taka jazda na zaciągniętym ręcznym, niby gaz do dechy, ale coś zamula. Czy chiplety są wyjściem z sytuacji? Oczywiście, że są. Tylko najpierw ktoś musi ogarnąć jak to ma w rzeczywistości wyglądać. Niech tylko nikt nie pieprzy o przepustowościach, bo GPU w samej mikroarchitekturze SĄ modularne. Takimi rzeczywistymi mikroGPU od wielu lat są GPC (w architekturze nvidii). Czyli by to działało trzeba by spełnić kilka warunków np.
- po wydzieleniu GPC na chiplety każdy dostaje swój kawałek L2, ale większy
- po wydzieleniu GPC na chiplety każdy dostaje 64bit IMC, L3 oraz minimum 2 szybkie interconnecty (albo 512bit HBM na głowę i nie trzeba się martwić ścieżkami na PCB co pozwoli na jeszcze szersze interconnecty)
- ring bus by zapewnić komunikację między GPC oraz spójność danych dzięki L3
I oczywiście, zasadniczo jest to (aktualnie) zdecydowanie droższe rozwiązanie niż monolit, ale myślę, że przynajmniej by ruszyło skostniały rynek i rzeczywiście wydajność do przodu. A teraz co i jak techicznie...

Ten znowu z chipletami. Napisałem już, że hierarchia cache w CPU i GPU jest zupełnie różna.

W GPU mamy takie właściwości:
- elementem, który zapewnia komunikację między zestawem CU i zestawem kanałów pamięci jest crossbar,
- tylko cache ostatniego poziomu (nazwijmy ją LLC) jest zapisywalna
- cache L1i, L1d, L0, etc są tylko do odczytu
- nie ma żadnego skomplikowanego protokołu do synchronizacji danych między cache'm - zapis zawsze leci do LLC, a linia pamięci podręcznej L1 jest unieważniona
- każdy kontroler pamięci ma swój kawałek LLC, gdyż crossbar jest połączeniem między L1, a LLC i taki coś ma sens - wszystko za crossbarem jest współdzielone, a więc współdzielona jest LLC
- gdyby zapisywalne LLC było podzielone na prywatne kawałki, to te kawałki musiałyby implementować jakiś protokół spójności danych jak w wielordzeniowych CPU

W CPU za to mamy takie rzeczy:
- elementem łączącym rdzenie jest ring bus, mesh, fabric czy (w starożytności) FSB,
- wszystkie poziomy cache są zapisywalne
- spójność danych w cache osiąga się za pomocą skomplikowanych algorytmów typu MOESI, które wymagają https://en.wikipedia.org/wiki/Bus_snooping
- korzystanie z danych z innego chipletu już jest bardzo wolne, a przecież CPU ma znacznie mniejszą moc obliczeniową niż GPU (a więc ten sam mechanizm współdzielenia danych byłby wielokrotnie bardziej uciążliwym wąskim gardłem, gdyby zastosować go do GPU)

W skrócie: nie można udawać, że problem spójności danych w cache (a także odległości od kontrolera pamięci przydzielonego do danego adresu w pamięci) nie istnieje. Gdyby nie istniał to robienie chipletów byłoby trywialne, zarówno w GPU jak i CPU i już dawno by one były (a tak to dopiero w CPU się pojawiają, a GPU nie ma nawet w zapowiedziach). Dlaczego AMD i nVidia przez lata kopały się z CF/ SLI, skoro mogły zrobić te (nie wpływające na model programowania) chiplety i mieć spokój? Czyżby brakło im ekspertów z PCLaba?

Ktoś pewnie krzyknie, że chipletów w GPU nie ma przez pazerność producentów, ale niech taki jegomość sobie przypomni, że chiplety CPU od AMD mają mało wydajną komunikację między sobą i duże opóźnienia w dostępie do RAMu w porównaniu do monolitów Intela. W przypadku chipletów GPU problem nasili się wielokrotnie, bo danych w ruchu jest wielokrotnie więcej na GPU.
Zaloguj się, by móc komentować