Hirdetés

Keresés

Új hozzászólás Aktív témák

  • Abu85

    HÁZIGAZDA

    válasz Asusu0 #44624 üzenetére

    Konkrétan mit akarsz ezen hűteni? Nagyon messze vagy a lekapcsolási határoktól.

    (#44626) Yutani: Azok is ennyin mennek, csak a beépített dióda nem tudja megmérni.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Asusu0 #44628 üzenetére

    A 70-80 fok egy ilyen chipnek olyan, mint neked a hideg vízben fürdés.

    (#44630) Asusu0: A bottleneck alkalmazásfüggő. Lehet, hogy igen, lehet, hogy nem.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #44645 üzenetére

    Nyet.

    (#44647) Tyrel: Nincs API-hoz kötve. Egyszerűen csak van a Chillnek egy blacklistje. Ha a játék benne van, akkor nem engedi a driver bekapcsolni. Ennyi.

    A Boost első körben whitelistes lesz, ahogy a Chill volt anno, és utána lesz majd blacklistes.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz paprobert #44680 üzenetére

    Akármilyen API-val működik. Ugyanaz, mint a Chill, csak mást kezd az információkkal.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Tyrel #44683 üzenetére

    Mindenféle inputra reagál a Boost, csak az AMD elmondta, hogy figyelembe veszik a képkockasebességet is, és ha a rendszer úgy ítéli meg, hogy nem kell nagyon emelni a tempón, akkor inkább nem állítja dinamikusan a felbontást. A press meghajtóban direkt ezért aktív a developer mód, hogy ha valaki tesztelni akarná a minőségcsökkenést, akkor elég csak a shiftet nyomogatnia, és arra azonnal reagál a Radeon Boost, mert az algoritmus alapján nincs kőbe vésve, hogy minden gombnyomásra, vagy bemozdulásra csökkenni fog a felbontás, ahhoz teljesülnie kell egyéb feltételeknek is, és ebből a szempontból eléggé bonyolult a rendszer, nincs egy fix mozdulatsor, ami alapján ez biztosan kiváltható. A végleges meghajtóban ez a trükk a shifttel nem lesz benne.

    Régi Boost működést az AMD azért mellőzi, mert olyan megoldást akartak, ahol erős odafigyelés nélkül nagyon nehezen legyen észrevehető a minőségcsökkenés. Egy képkockasebességhez kötött módszerrel a jelenethez lenne kötve a minőség, vagyis simán tudnál úgy nézelődni, hogy nem natív részletességet kapsz. Ezzel a módszerrel ezt nem tudod igazán megtenni, mert ahhoz, hogy nézelődj, mellőznöd kell a gyors mozgásokat, és ezek nélkül a Boost nem igazán működik extrém minőségcsökkentéssel. Mozgás mellett pedig egy rakás olyan tényező van, ami elmossa a Boost minőségcsökkentését, a legtöbb játék már eleve alkalmaz valamilyen motion blurt, de pusztán a gyors mozgás ténye is elég ahhoz, hogy maga a minőségvesztés kevésbé legyen látható. Emiatt mondják azt a reviewekben, hogy ha csak játszanak, és nem keresik a felbontáscsökkenés hatását, akkor nem igazán veszik ezt észre, és pont ez volt a koncepció, hogy elérjék ezt a hatást. Szimplán sebességszintekhez kötve nem lehetett volna megcsinálni.
    A fentiek mellett a dinamikus felbontásskálázást rendkívül egyszerű beépíteni egy játékba. Az API-k minden tartalmaznak ahhoz, hogy a fejlesztő írjon a motorba egy ilyen rendszert. Egy input alapján működő felbontásskálázást viszont nem lehet csinálni, mert az API-knak az az alapvető követelése megakadályozza, hogy legyen parancslista. Lényegében illegális dolgot csinálna a játék, ha ezt valahogy elkezdené kontrollálni, mert ezek menedzselése az OS és a driver feladata. Alapvetően nem is tudnák megcsinálni a fejlesztők anélkül, hogy az OS-en belül bizonyos fájlokat felül nem írnának. Tulajdonképpen az AMD is ezt csinálja a Chillel, megkerülik a Microsoft korlátjait. Ilyen szempontból ugyanaz a helyzet a Boosttal is, mint a Chillel. Nem tudja senki sem lemásolni, nem mellesleg a szabadalmak is az AMD-nél vannak. Ez gyakorlatilag egy egyedi funkció ismét a driverben, amit se fejlesztő, se konkurens nem tud felkínálni. Ez innentől egy marketinges szempont is, mert csináltak egy olyat, amit előttük még senki, és a szabadalmakat figyelembe véve, valószínűleg utánuk sem. Ugye a Chillt se másolják a konkurensek. Túl bonyolult, túl sokáig tartana megcsinálni, és még fizetni is kellene az AMD-nek érte.

    (#44687) Tyrel: Lehet a képkockasebességhez kötni. Igazából az nem is olyan nehéz. Kb. olyasmi meló, mint az Anti-Lag. Ugye ott is az alap a Chill, csak nem a Chill működéséért felelős bonyolult algoritmus fut rajta, hanem egy jóval egyszerűbb, és így nyilván sokkal kevesebb idő volt tesztelni is, mert nem dimanikus a helyzetekre való reakciója. Ha mondjuk az fps-hez kötnék ezt, akkor ott is az lenne, hogy adott az alap a Boostban, csak a döntésért felelős algoritmus változik. Elképzelhető, hogy ha megcsinálják a Boostot blacklistesre, tehát úgy, hogy működjön mindennel, mint a Chill, akkor raknak be egy alternatív algoritmust. Ez tényleg nem egy nagy meló. Viszont ennek a minősége biztos nem lenne olyan jó, mint a mostanié. De kivitelezhető és viszonylag egyszerűen megvalósítható nekik, csak kérdés, hogy akarnak-e vele foglalkozni. Első körben biztos nem, mert a fókuszt biztosan a Boost befejezése jelenti. Utána lehet, ha kész a Boost, akkor onnan nem lenne több három hónapnál egy módosított algoritmussal működő rendszer.

    (#44689) Tyrel: Az AI az jó dolgot csinálna a DLSS-nél, ha az NV rakna bele pénzt. Alapvetően a DLSS-nek nem a technológiai háttere a rossz, hanem az, hogy az NVIDIA egyszerűen nem ad ingyen gépidőt a fejlesztőknek. Így meg azért rohadt nehéz ám jó eredményt elérni, hogy kell egy rakás számítási kapacitás a tréninghez, de közben egy órát is marha drágán mér az NVIDIA. A Microsoftnak van egy ugyanilyen megoldása DirectML-re. Csontra ugyanezt csinálja, csak a különbség, hogy a neuronháló tréningelését ingyen mérik a DirectML-t támogatók között. És elég jók is az eredmények, ha nem azt kell nézni, hogy van x pénz, és az elég y órára, ha pedig nem jó a neuronháló, akkor ez van, ennyire volt zseton. Az AI az nem ilyen, ott nem lehet előre megmondani, hogy mennyi idő múlva készül relatíve jó eredményt biztosító neuronháló, emiatt lenne kritikus ezeknél a megoldásoknál, hogy legyen a fejlesztőknek ingyen elérhető számítási kapacitás, mert egy helyi munkaállomáson ez a munkafolyamat nagyon sokáig tartana, úgy kb. örökké.
    Itt valószínű egyébként, hogy az NV erre üzletet akart építeni, tehát amíg a Microsoftnak megéri ingyen Azure kapacitást adni csak azért, mert a fejlesztő DirectML kódot ír (ez nincs Linuxon->több Windowst adnak el->profit), addig az NV-nek nem feltétlenül éri meg ez, mert drágábbra jön ki gépidőt adni, mint lehúzni a WC-n a technológiát. Ettől függetlenül a DLSS koncepciója jó, csak a piszkos anyagiak elrontják a gyakorlatot. Ugyanakkor, ha bevállalnának egy rakás anyagi veszteséget ezen, akkor bőven jobb lehetne a minőség, mint amit az alternatívák adnak. Jensennek azonban kell a zsé új bőrkabátra. :)

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #44691 üzenetére

    A probléma eleve az, hogy a játék 13-14 fps-sel fut átlag az adott gépen. A Boost nem tesz csodát. Nem éri meg azt várni tőle, hogy 13-14 fps-ből 60-70-et csinál.

    (#44693) b. : Szerk.: Oké, bocsi. :))

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz do3om #44721 üzenetére

    Szeptemberben az R9 3950X jött volna, de elnapolták novemberre, most is alig tudnak belőle eleget gyártani, szóval még így is korai volt kiadni, de nem ment fel nagyon az ára a listaárhoz képest. Most december 7-én az jött volna, ami jön a következő héten, csak elnapolták az új driver utánra. A többi hónapban megvolt a bejelentés.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz do3om #44725 üzenetére

    Július Ryzen, augusztus Epyc, október Radeon, november Threadripper.
    Januárban egyébként a Renoir jön, az zárja a sort.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz do3om #44728 üzenetére

    Nem hiszem, hogy különösebben aggódnak emiatt. Az R9 3950X-et muszáj volt elrakni, mert a 12-magosból sem tudtak eleget gyártani. És ugye egy hete azt mondták nekem, hogy a 16-magosból többet adnak el most, mint a 12-magosból, tehát még így sem jó az ellátás. Mondjuk főleg az OEM-ek a ludasak, mert a CES-re rakják össze a 16-magos vérgémer gépeiket, az lesz az asztali gaming szempontjából a fő showelem, és oda rendelik ezeket ezerrel. Most ha kiadják szeptemberben, akkor sem tudták volna szállítani hamarabb.
    A decemberi egészen egyszerűen a driver miatt nem volt optimális. Gondolj bele, a meghajtót nem tudták hamarabb hozni, és elég sok változást hozott. Tehát inkább megéri pár nappal későbbre rakni a hardvert, minthogy a meghajtó előnyeiből kizárd. Ez egyszerű logika. Ez nem csúszik sokat, csak pár napot.

    (#44729) Raymond: Most olvasd el az eredeti hírt, ami bejelentésekről és nem feltétlenül termékstartokról szólt. :)

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #44761 üzenetére

    Nem. Az RX 590 az 225. A másik a 120, aminek még nem mondható ki a neve.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz X2N #44855 üzenetére

    Persze, hogy nem volt áresés a bányászláz után, csak a nagyon luxusárazások dőltek be. Igazából áremelés jön még. De pont a piac szűkülése okozza ezt, hiszen ha kevesebb a potenciális vevő, akkor kevesebb eladásból kell realizálni ugyanazt a bevételt. Emellett az új node-ok drágábbak. Egy lapka tape-out-ja 7 nm-en nagyjából dupla annyiba kerül, mint 1x nm-en, tehát egy VGA-nak most már kétszer annyi tervezési költséget kell visszahozni.

    Erre egyébként az Intel és az AMD kitalált valamit a következő évekre. A CPU-val csomagban adják majd a GPU-t. Így ugyan a VGA-k továbbra is drágák lesznek, de a procikon a haszon sokkal nagyobb, tehát tudnak annyit engedni az OEM-eknek a VGA tekintetében, hogy végeredményben a CPU+VGA költség alacsonyabb legyen. Az Intelnél láttam, hogy ők ezt ki akarják terjeszteni a dobozos piacra is, tehát alaplap+VGA+CPU szintű csomagok lesznek, így ugyanaz a három komponens lényegesen olcsóbb lesz, mint egyenként megvásárolva. És a VGA-n való kiesést az Intel pótolja a gyártópartnernek a proci nyereségén. Abban egyébként nem vagyok biztos, hogy ez legális. Dobozos szinten talán rámondható, hogy az, de OEM szinten gyakorlatilag árazópisztolyt tartana az Intel és az AMD a partnerek fejéhez.

    Konzolok egyébként eddig is voltak. Most ha tartanak tőlük, akkor sem lehet mit kezdeni velük. Túl nagy előnye van a speciális platform miatt a hardvernek, mert a gyártók előállítási költség alatt is el tudják őket adni. Az NVIDIA biztos nem akarja előállítási költség alatt árulni a VGA-it. Ha a piac nem vevő ezekre haszonnal, akkor nincs értelme a piacnak. Ilyen szempontból a konzolokat nem érdemes számításba venni az árazásnál. Ami az NVIDIA számára fontos lenne az a Cloud, mert ha így emelkednek az árak, akkor lényeges az egyik nagy szolgáltatásba bekerülni. A Google, a Microsoft és a Tencent már kiesett, de még ott van az Amazon. Őket meg kellene győzni, hogy ne AMD-t vagy Intelt vegyenek cloud gamingre. Ez sokkal fontosabb tényező az NVIDIA-nak, minthogy a konzol miatt rágják a körmüket. Némileg hátrány, hogy az AMD és az Intel platformot kínál.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Raymond #44857 üzenetére

    A dráguló gyártástechnológia azoknak a cégeknek jelent problémát, akik nem céloznak olyan piacokat, hogy a kezdeti magas költségeket ki tudják termelni. Ergo nem tudnak annyira gyorsan új node-ra lépni, mint azok a cégek, akik vagy tömegpiacot, vagy olyan területet céloznak egy fejlesztéssel, ahol van mennyiségi eladás, és mellé még jelentős a haszon is a terméken. Ez a két lehetőség az, amivel ki tudod gazdálkodni a váltást. Mivel a cégek wafereket rendelnek, így nem annyira kritikus, hogy minden terméken legyen hatalmas haszon. Az is jó, ha a termékek egy részén alig keresnek, míg egy másik részén iszonyatos haszon van. A lényeg, hogy a teljes mérleg legyen pozitív. Az AMD azért tudott gyorsan váltani, mert ott van nekik a szerverpiac, ahova a Rome-ot igen drágán adják, ahhoz képest, hogy ~70 mm2-es 7 nm-es lapkát pakolnak rá, aminek a mérete miatt kellően magas a kihozatala is. Ha mondjuk ez nem létezne, akkor az AMD nem tudna veszteség nélkül 7 nm-re ugrani, mert a GPU-kon ez biztos nem gazdálkodható ki.
    Az NVIDIA két tényező miatt nem váltott még, nincsenek jelen olyan piacon, amely egy ilyen váltást képes lenne finanszírozni, illetve baromira kellemetlen helyzetbe hozta őket a TSMC azzal, hogy egy évre előre kell leadni a rendelést, ami ugye marhára lehetetlen, ha nem tudod, hogy mekkora selejtaránnyal kell számolnod. Főleg az utóbbi a probléma, mert ha sokat rendelsz, akkor túlságosan tele lesz a raktár, ha pedig keveset, akkor nem tudod kiszolgálni a piacot. Ha mondjuk a TSMC jól tudná kiszolgálni az igényeket, akkor ebből nem lenne jelentős gond, mert ha el is rontod az első rendelést a kísérleti gyártás adataiból, akkor is csak pár hétnyi fejfájást okozol magadnak, nem pedig egy évnyit. Jelen körülmények között a nagy lapkákkal kvázi zéró tapasztalattal rendelkező Samsung is jobb opciónak tűnik beugróként.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz X2N #44858 üzenetére

    A 4K 60 fps-t bármin meg tudod oldani. Az egész csak konfigurálás kérdése. Ettől még ugyanúgy jöhetnek az új konzolokra is olyan játékok, amik mondjuk 4K 30 fps-re vannak konfigurálva. Tehát az nem igazán fog változni, hogy ha kiadsz ~5000 dollárt egy csúcs-PC-re, akkor az a jövőben is gyorsabb lesz, mint egy 500 dolláros konzol, ráadásul a PC-t már az elavult API-k sem hátráltatják, a DX12 és a Vulkan nincs annyira messze a konzolos API-k képességeitől. Meg ugye a lényeg, hogy végre skálázódnak, tehát ha nem is tudnak annyira kevés utasításszóból megoldani egy rajzolási parancsot, mint a konzolok, akkor is veszel nyolc mag helyett 12-t, és behoztad ezt a hátrányt. 16-tal felül is múltad őket, és vehetsz akár 32 magot is. Tehát a PC-nek ezekkel az API-kkal a teljesítményelőnye vitathatatlanul megmarad, illetve pusztán pénzkérdés lesz az egész, nem egy szoftveres limit határozza majd meg. Az már nyilván egy másik kérdés, hogy az ebből származó minőségi előny megéri-e +4500 dollárt, ha most a közel csúcskonfigurációkat nézzük.

    A VRR sem új, Xboxon most is van, és nem kell hozzá HDM 2.1, hogy működjön. Az egér-bill részletkérdés. Egyre többen játszanak PC-n gamepadről. Azt veszem észre, hogy én is, egyszerűen kényelmesebb. Persze vannak olyan játékok, ahol ez hátrány, de sokszor nem az.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    A FEMFX-nél nem véletlenül nem említik a konzolokat. Ez a lib a PC-hez készült, a CPU-khoz. SSE2 a minimum, de megy AVX2-vel is, meg mindennel e két véglet között. A konzolokhoz a lesz egy külön verziót, ami nem csak a CPU SIMD-eket, hanem a konzolokhoz tervezett egyedi RDNA-kat is támogatja. Konkrétan le lehet fordítani a kódot a GPU-ra binárisként. Ez PC-n nem lesz opció, mert ugye ide nem jó binárist fordítani, hiszen folyamatosan változik az ISA, illetve a PC-s RDNA-k binárisan nem kompatibilisek a konzolos RDNA-kkal. Egyébként maga a CPU sem lesz ugyanaz a konzolokon, ami a PC-n van, hanem számos módosítást kap, inkább throughputra lesz optimalizálva a dizájnban a cache-rendszer, míg a PC-s Zenek azért ilyen balanced megoldások.

    Az egyébként elképzelhető, hogy később ez PC-n is kiegészül GPU-s gyorsítással, de a FEMFX eléggé bonyolult pipeline. Nem lehet úgy megoldani, hogy egy VGA-n fusson, muszáj közös memóriát használnia a GPU-nak a CPU-val, mert az egyes pipeline-jai a CPU-n sokkal gyorsabban működnek, míg más pipeline-ok a GPU-n. Ha mindet átraknák a GPU-ra, akkor az egész lassabb lenne. Ha pedig VGA-ra menne per pipeline alapon, akkor a round tripbe döglene bele a rendszer. Egyelőre emiatt ez csak CPU-s megoldás, mert erre ott vannak az explicit API-k, azokkal az explicit skálázódás megoldott, és igazából a magszám is drasztikusan emelkedik.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #44923 üzenetére

    Ott van benne az inkluzív cache mód. Amelyik játék támogatja, azzal így működik. Például Far Cry 5.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #44925 üzenetére

    Azoknál a címeknél érhető el, ahol ennek előnye van.

    A driveres megoldásnak van egy olyan hátránya, hogy valaki tud venni egy olcsó kártyát. Rárak ezzel 16 GB memóriát, és onnantól kezdve a Radeon VII-nek probléma, mert nem azt veszi a 16 GB-ért, hanem egy csuszkát használ. Üzletileg nem éri meg. Ellenben az inkluzív cache mód az megéri.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #44927 üzenetére

    Nem lehetne, mert 4 HBM2 stack kell hozzá, tehát 16 GB a minimum konfigurációja a Radeon VII-nek. 2Hi stacket alig gyártanak, így az ára sokkal magasabb, mint a 4Hi stacké. A memóriánál a mennyiség döntően meghatározza az árat, és hiába fele akkor a kapacitása, ha alig gyártanak belőle, akkor a dupla kapacitású a mennyiségi előny miatt olcsóbb.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz hajbel #44929 üzenetére

    Ahogy az előző konzoloknak sem volt közük a Polarishoz, ezeknek sem lesz közük az 5700-hoz. Csak ugye ezt hiába magyarázod a médiának, ők nem fogják fel a semi-custom lényegét.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Z10N #44931 üzenetére

    Custom, ahogy a korábbi konzolokban is custom volt.

    (#44932) hajbel: Ha ugyanazokat a shadereket futtatnák, akkor igen, de nem ugyanazokat kapják meg.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #44934 üzenetére

    Egy túrót. Sosem épültek az új konzolok GCN-re. Csak volt egy félbalfasz ork, aki ezt írta korábban, majd úgy mentette meg a saját baromságát, hogy a Sony gyorsan váltott, csak kb. fingja sincs, hogy egy ilyen váltással az egész konzol 2 évet késne, mert elölről kellene kezdeni a fejlesztőkörnyezetet, az API-t, meg a bináris fordítót. De egyszerűbb volt ezt mondani, mint azt, hogy akkor sem volt erről fingom, és most sincs, csak haluztam valamit az olvasottságért.

    A custom pedig azt jelenti, hogy egyikhez sem áll közelebb, mert például az RDNA-ban és az RDNA 2-ben nincs VSKIP, de a konzolos RDNA-kban van. Na most akkor melyikhez áll közelebb? :) Annyira brutálisan le akarjátok ezt egyszerűsíteni, hogy innen jönnek ezek a GCN hibrid, ehhez közel áll, inkább RDNA1 lesz, mint 2, ésatöbbi, de közben egyiknek sincs köze a valósághoz, mert sokkal bonyolultabb a kérdés, mint amennyire egyszerűen akarjátok kezelni.

    Egyébként példa szintjén azt is említhetném, hogy a két új konzolon megmarad a S_SET_GPR_IDX utasítás, de ezzel együtt a V_MOVREL másképp fog működni, mint a PC-s RDNA-n, ahol viszont nincs S_SET_GPR_IDX, de a V_MOVREL-rel helyettesíthető.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Csokishurka #44946 üzenetére

    [link]

    (#44938) Petykemano: Azért nincsenek bizonyos utasítások RDNA1-2-ben, mert nem kellenek, míg a konzolokban azért vannak, mert kellenek. Ezek nem fognak az RDNA3-ban lejönni PC-be, mert továbbra sem kellenek ide.

    (#44937) szmörlock007: Látni kellene, hogy mit tud a Sony devkitje. Eléggé kevés az infó róla még.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #44973 üzenetére

    Van is. Csak a teszteket nem arra építik fel, hogy kivéreztessék a 4 gigás verziót. De ha erre építenék fel, akkor még az x16-os PCIE4 is előny lenne a PCIE3-hoz képest, hiszen gyorsabban másolja a VRAM-ba a rendszermemóriából az adatot. Csak ilyenkor már rég rossz, amikor ez az adatmásolás a limit, mert még a x16-os PCI Express 4.0 is sokkal lassabb a VRAM-nál.

    Amikor szándékosan nem törekedsz arra, hogy az x16-os PCI Express 4.0-nak kedvezzél, mert be lehet úgy állítani a mai játékokat és keresni lehet olyan jelenetet, hogy az x16-os PCI Express 3.0 is limit legyen, akkor ezek a tipikus különbségek: [link] - Ebben ugye az x16-os PCI Express 2.0 is elég egy RX 5700 XT-nek, ami megegyezik az x8-as PCI Express 3.0-val. De még egyszer mondom, ha nagyon akarom, akkor ki tudnám hozni azt, hogy az x16-os PCI Express 3.0 kevés neki. Az AMD számos ilyen körülményt mutatott a review guide-ban, csak ugye ezek extrém szituációk, amikor pontosan ott kell állni egy területen, hogy belefuss a limitbe, stb. Erre azért nem tértünk ki igazán, mert ez kvázi az, amikor keresni kell, hogy hol kevés az x16-os PCI Express 3.0. Nem életszerű, de kétségtelenül tény, hogy sok játékban találni olyan helyzetet, amikor az x16-os PCI Express 4.0 is előny, csak a játékmenet 99,99999999%-ában pedig bőven elég a 3.0, sőt a 2.0 is, ahogy a TPU is mutatja.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #44977 üzenetére

    A TPU tesztjében pedig x16-os PCI Express 2.0 szerepel, ami megfelel az x8-as PCI Express 3.0-nak. Szóval szándékosan írtam, amit írtam. Az AMD szépen felvázolt pár körülményt, amikor ki lehet ütni az x16-os PCI Express 3.0-t. És ezt kétségtelenül meg lehet tenni, de ez csupán az adott játék 0,00000000000000000000000000001%-a, tehát nem életszerű erre a körülményre építeni. Ezért van az, hogy a TPU az x16-os PCIE 2-3-4 összehasonlításnál nem talált 2%-nál nagyobb különbséget átlagban.

    Meg tudnánk tenni mi is, hogy erre felépítünk egy tesztet, és akkor marha szar lesz mindennek, ami nem PCI Express 4.0-s, csak nem látom értelmét kikeresett körülményt tesztelni, az adott játék 99,9%-ára nem lesz igaz az eredmény.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gbors #44979 üzenetére

    Attól függ, hogy mennyi ideig mérsz. Elég csak másolni, amit az AMD csinált. Nem nagy ördöngösség. A probléma vele, hogy ez nem lenne a valóság. Egyszerűen csak rámész arra, hogy a PCI Express 4 gyorsabb interfész, és keresel olyan pontot a játékban, ahol ez kijön, majd abszolút azon a ponton maradsz. De ez rendkívül mesterségesen teremtett helyzet ám. A valóságban ilyen nincs. Természetesen előfordul az, hogy egy játékban pár frame mondjuk limites lesz a PCI Express miatt, de továbblépsz, és vége a limitnek. Ha viszont leragadsz, akkor mesterségesen tartod fent a limitet. Innen már csak azt kell kitalálni, hogy meddig kell mérni, hogy ezt a limitet erősen láthatóvá tedd az eredményeken. Ha mondjuk mérsz egy valós körülményt, ahol van egy 3 perces jelenetsorod, és tényleg a játékot szimulálod, akkor kizárt, hogy ez látható legyen. Még a minimumon sem, mert eleve leszűrjük a legrosszabb 2%-ot.

    Amiről egyébként te írsz, az nem a PCI Express miatt van. Az AMD RDNA-ra még nem portolta a GCN összes memóriaoptimalizálását. Egyszerűen erre fél év nem elég. Nem is feltétlenül működnek ezek, illetve a DirectX 11-es driver sem kap valami nagy fókuszt.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz X2N #44981 üzenetére

    A mérési hiba az más. A helyzet nagyon egyszerű. Valójában még az x16-os PCI Express 4.0 sávszélessége is kevés a VRAM sebességéhez képest, tehát erre nem éri meg erősen építeni a szoftver oldaláról. Ugyanakkor egy játék is belefut helyenként olyan limitekbe, amelyek ugyan léteznek, de mindössze a teljes játék 0,0000000000000001%-át alkotják. Tehát ha információd arról, hogy az adott játék milyen jelenetsor során terheli a legjobban a PCI Express interfészt, akkor kizárt, hogy ki tudd mérni a 2.0, a 3.0 és a 4.0 között a különbséget. De ha erről van tudomásod, akkor sokkal egyszerűbb a helyzeted, mert tudatosan fel tudod úgy építeni azt a tesztet, hogy a játéknak azt az aprócska szeletét erőltesd, és ott már lesz különbség a csatolók között. Csak ahogy írtam ez mond rendkívül mesterséges körülmény, ami a valóságot nem reprezentálja, így ha ezeknek a körülményeknek az előállítására nem törekedsz tudatosan, akkor azt az eredményt kapod a PCI Express befolyásolása szempontjából, amit a TPU kapott. Ezt linkeltem a hsz-ben, amire reagáltál.

    Ahol a PCI Express 4.0-s VGA igazán számít azok a professzonális alkalmazások. Ott azért találni olyan feladatot, ahol van olyan valós körülmény, ahol ebből előnyt lehet kovácsolni. Mi is találtunk: [link] - akinek erre kell VGA, nyilván törekedjen PCI Express 4.0-ra, de játékra igazából felesleges, mert a játékmenet 99,9999999%-ában nincs előnye, a maradékot pedig túl lehet élni.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #44984 üzenetére

    Úristen. Olvasd már el mit írok.

    (#44983) X2N: A BRAW-ban akármit raksz mellé, bizonyos részletességen túl mindenképpen a PCI Express lesz a limit. Ezért választottuk ezt a programot demonstrációra, mert a Blackmagic írta, hogy náluk a 4.0 előnye tuti kijön.

    Egyébként az AMD is ezt a programot javasolja, mint valós körülmény. A professzionális alkalmazások között kell keresgélni, hogy a PCI Express 4.0-nak megmutasd a hatását. Máshol nincs igazán jelentősége.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #44986 üzenetére

    Egészen egyszerűen. Valójában a játékokban a PCI Express terhelése azért alacsony, mert tudatosan erre építik fel a működést. De előfordulnak olyan helyzetek, amikor nehéz úgy optimalizálni a rendszert, hogy a terhelés minimalizálva legyen. Klasszikus példa a streaming, amikor a textúrák jelentős része a rendszermemóriában van, és onnan kerül át a VRAM-ba, amikor erre szükség van. Főleg a virtuális textúrázást használó játékok esetében (AC: Origins és Odyssey, Battlefield 4-től kezdve az összes, új Wolfenstein 1-2) vannak olyan jelenetek, ahol pusztán a jelenet felépítése miatt ez a terhelés valamivel nagyobb, mint a játék jó részében, és ha bizonyos útvonalat követsz, majd többször bejárod, akkor nagyon meg lehet hülyíteni a megatextúrázó rutint. Ilyenkor mesterségesen ki tudod hozni a PCI Express 4.0 előnyét, mert gyakorlatilag kihasználod a fellépő tipikus problémákat, ideértve a VRAM beszemetelését. De ahogy írtam, senki sem fog úgy játszani, hogy direkt kihasználja az adott motor streaming hibáit, mert ilyenek vannak, nem tökéletesek ezek a programok, de nem baj, mert szökőévente, ha egy ember belefut a százezerből. Emiatt nincs is értelme ezt tovább optimalizálni, mert valós problémát nem okoz, rendbe hozni pedig drága lenne, így jó az a játék így is. Viszont nyilván az AMD rengeteget monitorozza a játékokat, így tudják, hogy mit és hol kell csinálni, hogy x-y címben valamennyire meghülyítsék a streaminget, amit megcsinálhatnánk mi is, csak ugye miért tennénk? Erősen mesterséges körülmény lenne, amit a valóság nem igazán igazol.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #44990 üzenetére

    Alapvetően azonos, csak ha rájátszol erre a dologra, akkor bármilyen hardverek ki tudod ezt hozni. Nem véletlen az a játékválasztás. Csupa megatextúrázó cím, ahol be lehet hülyíteni a megatextúrázót. Az AMD el is árulta a nyáron, hogy miképp kell csinálni.
    Az FC5 is megatextúráz. Nézzék meg egy olyan címben, ahol nem lehet ezt megcsinálni. Ja, hogy ott nincs különbség? Akkor nincs szenzáció sem, és nincs kattintás. ;)

    (#44992) b. : A programokon belül természetesen orvosolható, de azért nem látsz erre túl nagy erőfeszítést a fejlesztők részéről, mert ha normálisan játszol, akkor jelenleg képtelenség előnyt kovácsolni a PCI Express 4.0-ból. Egyszerűen nem válik limitté. De ha a streaming algoritmus problémáira tudatosan rájátszol, akkor természetesen az lehet, csak én még nem láttam játékost úgy játszani, hogy megadott útvonalon fut körbe körbe, és rángatja az egeret. Ez hülyeség. Ezt nem kell javítani, mert ilyet egy játékos nem csinál, de még ha csinál is, akkor sem tudja, hogy pontosan hol kell az adott játékban. Az AMD-nek könnyű, ők azért látják, hogy mit csinál a játék a VRAM-ban, tehát ki tudnak találni olyan szimulációkat, ami belimitálja a buszt. Ezt sokszor a fejlesztők sem látják egyébként. Nem téma ezzel foglalkozni, mert jó eséllyel senkinek sem jön elő, aki játszik vele. A gyártók pedig azért csinálják ezt, hogy hatékonyabb drivereket tudjanak írni, nekik nyilván hasznos egészen extrém szituációkat szimulálni, ami otthoni szinten nem realitás. Jelen pillanatban a valóság a PCI Express 2.0, 3.0 és 4.0 tekintetében ez: [link]

    Ami a Navi esetében specifikus, és driverrel orvosolható az a memóriamenedzsment. Mint írtam az AMD nem portolta az összes GCN optimalizálást a Navira, mert nem mindegyik működik jól, illetve a DirectX 11-es meghajtó már nem fókusz.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #45035 üzenetére

    Tök mindegy, hogy moduláris lesz-e. Igazából az egésznek nincs értelme, mert csinálsz egy házat, raksz bele egy optikai meghajtót, és egy modult, amit tudsz cserélni, plusz a tápot kívülre helyezed. Nem nagy kunszt, de mi értelme? Semmivel nem másabb egy teljesen önálló konzolt adni.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    Nekem volt fagyásom RX 5700-zal, de még az újságírói Adrenalin 2020-as driverrel. Arra azt írta az AMD, hogy használjam a Windows 10 1909-es verziót, mert azzal tesztelték. Azzal működött végig, nagyjából két hetet nyüstöltem. Aztán a 19.12.3-on még egy hetet, majd kivettem és visszaraktam az RX 570-et, mert úgy volt, hogy elviszik a Navikat, csak végül maradtak, de még nem volt időm visszarakni a gépembe.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Devid_81 #45072 üzenetére

    Ez attól függ. Valamelyik marad, valamelyik megy. A Navik biztosan mennek, csak valamikor februárban. Addig itt vannak az otthonomban, a tévé mögött van a raktársarok. :D Most épp jött egy X570-es alaplap, ami például marad.

    Sok kártyás tesztet leginkább a régi eredményekre támaszkodva lehet csinálni. Ez is lehetőség, de mi jobbnak tartjuk állandóan frissíteni a tesztrendszert. Mindkettőnek megvan az előnye és a hátránya.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #45094 üzenetére

    A driver a dual GPU-hoz már nem tesz hozzá semmit. A DirectX 12 és a Vulkan API nem teszi láthatóvá a meghajtó számára a memória tartalmát. Mellesleg messze az AMD-nek működik a legjobban két GPU-val DirectX 12 és Vulkan alatt. Ennek az oka az, hogy ezeket a hardvereket DMA-n keresztüli kommunikációra tervezték.

    (#45090) Cifu: A Radeon VII-hez készült Vega 20-nak vezető szerepe volt abban, hogy kitapasztalják a 7 nm-es node-ot. Mint írtam az egyes tranzisztorstruktúrák vége felé nehéz meghatározni, hogy mi az optimális felépítés, emiatt a cégek hoznak egy pipe cleanert. Ez volt a 28 nm-en is, és most 7 nm-en a FinFET is a végét járja, tehát nagyon félre lehet tervezni egy generációt, ha nem hozol egy pipe cleanert.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #45097 üzenetére

    Az explicit API-s multi GPU-nak nincs köze a driverhez. A Microsoftnak van rá egy szabványos WDDM AFR implementációja, amit arra írtak, hogy a hardverekben van két DMA. De amíg az AMD régóta DMA-val oldja meg az AFR-t, így építettek a GPU-kba egy fast pathot a multi GPU kommunikációra. Ez az NVIDIA GPU-iból hiányzik, mert sosem DMA-val oldották meg ezt a kérdést, tehát értelmetlen volt erre hardvert építeniük, inkább az SLI híd linkjére fókuszáltak, viszont a Microsoft kvázi meghajtója nem használja az SLI hidat, hozzá sem nyúl ahhoz a linkhez, és a DMA-n keresztüli kapcsolatra fókuszál, amire az NVIDIA sosem gyúrta ki a hardverét. Ezért tud nagyon erősen skálázódni a Radeon a WDDM AFR implementációjával.

    Azt fontos kiemelni, hogy a WDDM AFR implementációja egy hirtelen fejlesztés volt. A Microsoft mindig is arra gondolt, hogy jobb ezt a fejlesztőkre bízni, de aztán az AMD írt egy olyan WDDM kódot, ami csak meghívható az alkalmazásokon belül, és működik az AFR. A Microsoft fogta ezt a kódot, és bemásolta a Windows 10-be, így a DirectX 12 és a Vulkan kapott egy egy extra lehetőséget a több GPU-ra. Viszont érthető, hogy hardverben senki sem készült erre, mert sosem került megbeszélésre a funkció. Az AMD megírta, a Microsoft pedig a többi gyártó véleménye nélkül kiadta. Ugye ezt megtehetik, funkcionálisan csak két DMA kell, ami ezer éve ott van a GPU-kban, de nem mindegy, hogy milyen gyors linkkel kapcsolódnak a multiprocesszorok gyűrűs buszához. A tipikus streaming műveletekre elég a lassú busz, ez eleve elég kis részét teszik ki a programoknak, és aszinkron módban simán fut, de az AFR nagyobb terhelés, és oda már erős busz kell.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #45099 üzenetére

    Nem az AFR a lényeg. Az egy technika, amit meg lehet valósítani egy csomó módon. A WDDM 2.0 AFR egy mód rá, amit az AMD dolgozott ki, és a Microsoft kiadott. És ez a mód nem vegyíthető. Itt konkrétan arról van szó, hogy a Microsoft a rutint megírta magába a WDDM 2-be, amit a fejlesztő pusztán meghívhat, így nem kell megírnia a saját DirectX 12-es vagy Vulkan játékába. Ennek az előnye, hogy egy sor, míg hátránya, hogy csak Windows 10 alatt működik, még akkor is, ha a játék Vulkan API-t használ.

    SFR ezer éve létezett. Benne van még a driverekben a rutin, de csak tesztelési céllal. Az AMD driverében konkrétan engedélyezni kell hozzá a developer módot, másképp elérhetetlen. Különösebb haszna amúgy sincs, nem igazán működik a modern játékokban, mert duplán kell hozzá számolni a geometriát.

    Az NV driverébe egy Checkboard Frame Rendering került be. Ehhez hasonló az AMD-nek az SFR supertillingja. Az is sakktáblaszerűen osztja fel a képet, de ugyanaz a hátránya, mint az SFR-nek. A geometria duplán terhel, és ez igaz a sugárkövetésre is, vagyis nem elég egyszer átmenni bejáráson, kétszer kell minden egyes frame-ben.

    A több GPU-s problémákra egyébként ez lesz a megoldás: [link] - kap majd az API is módosítást, hogy ezt segítsék, viszont a probléma vele az, hogy az árnyalást a motorokban át kell írni az objektumtérbe, vagyis texel shading nélkül nem működik.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #45103 üzenetére

    Erről beszélek. Az a koncepciója, mint az AMD-nek a régi SFR supertillingjának. Ugyanazokkal a hátrányokkal, amelyek miatt az sem működik jól, és csupán +40-50%-os előnyt tud felmutatni egy extra GPU-val. Egyszerűen duplán számolja a geometriát, és minden jelenetszámítással kapcsolatos futószalaglépcsőt.

    Ennél sokkal-sokkal jobb az, amin a Microsoft dolgozik, mivel azzal magát az árnyalást osztod szét több GPU-ra. Így nem csak a hatékonyságot maximalizálod, hanem gyakorlatilag annyi GPU-ig tudsz vele skálázódni, amennyi rajzolási parancsra csinálsz texelszintű árnyalást. Nyilván eddig senki sem fog elmenni, de 30-40 GPU-ig ezzel simán tudsz közel lineárisan skálázni (ami szintén egy extrém szám, de kelleni fog majd a chiplethez, hogy azok a dizájnok skálázódjanak). A gond vele az, hogy új leképezőket kell írni hozzá, mert a legtöbb motor leképezője fragment szinten árnyal.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gbors #45108 üzenetére

    Ezért működik csak texel shadinggel. De ott működik, és ez a lényeg. Viszont kell hozzá a módosítás a motorokba, illetve a Microsoft hoz könnyítést az API-ba is, hogy jobban lehessen implementálni.

    (#45109) b. : Úgy lesz a fragment shader lépcső megoldva, mint egy sakktábla. A fekete táblák az egyiket, a fehérem a másik GPU-n futnak le. Ennyi. Régen ez azért működött jól, mert amikor ezt kitalálták még nem volt unified shader, és a GPU-kba eleve sokkal több pixel shader feldolgozó volt, tehát a geometriai munka pusztán kevesebb volt, mivel nem volt ezeknek elég erő. A mai GPU-knál ez nem igaz, mert az összes feldolgozó használható fragment shader előtti számításokra, vagyis egy-egy motor dizájnja lehet annyira megterhelő, hogy 20%-ot sem tudsz ettől gyorsulni, holott vettél még egy GPU-t. Előnyösebb szimplán meghívni a Microsoft WDDM-be épített AFR-jét, és az minimum 80%-ot ad, ha nincs sok interframe kommunikáció, miközben alapvetően pár sor az egész a programban.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Cifu #45128 üzenetére

    Régi probléma, hogy a Steam nem szűri ugyanazokat a gépeket, külön felhasználóval. Tehát ha egy gépbe mondjuk tíz felhasználó belép, akkor az a gép tízszer lesz regisztrálva. És ugye karácsonykor elképzelhető, hogy voltak összeröffenések, és a haverok elkezdtek belépni ugyanarra a gépre.

    Igazából az egész rendszer, ahogy mér szimplán fos. Csak a Valve-ot nem különösebben érdekli, hogy ez működjön. Van az adat, beömlesztik, aztán kész. Túl drága lenne azt normálisan megszűrni.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    Ez az alaplapos dolog nem véletlenül merült amúgy fel, nem száz százalékban üzleti megfontolás. A következő konzoloknak lesz egy olyan képessége, hogy maga az SSD is memória lesz. Konkrétan az XSX és a PS5 is rendelkezik egy olyan móddal, amelynél a rendszermemória maga a játék telepítési helye, és a valós memóriának lesz egy CPU-memory része, illetve egy cache része. Utóbbiba lesz belerakva az éppen használat adat az SSD-ről, vagyis gyorsítótárazás történik, csak igen nagy mértetekben. A PC-n ezt úgy akarja az Intel és az AMD is leutánozni, hogy az alaplapi platformjaikon a PCI Express interfész előtt lesz egy külön switch, ami a CPU-ba lesz bekötve, és szétosztja a sávokat egy SSD és egy VGA között, a VGA GPU-ja pedig képes lesz direkten olvasni és írni az SSD-t, amit az alaplap megfelelő interfészébe helyeznek. A cache pedig lesz a VRAM. Na most ezzel a konzoloknak ez a képessége lemásolható. A probléma az, hogy az Intel nem szabványban gondolkodik, vagyis egy olyan interfész lesz az SSD-re, amibe csak a saját megoldásaik jók. És az AMD is ugyanezt akarja, vagyis nekik is lesz erre egy saját interfész, és ilyen formában már az alaplapnak a megvásárlásával eldől, hogy a gépben AMD vagy Intel VGA lesz, mert ha nem maradsz gyártón belül, akkor nem tudod használni a specifikus interfészt az adattárolóra. És mivel szabvány erre elég sokára lehet, mert a Microsoft nem nagyon törődik vele, úgy vannak az egésszel, hogy majd a user vesz 64-128 GB-nyi rendszermemóriát úgy 32 GB-nyi VRAM-os VGA-val. Az is megoldja ezt a problémát, csak nem ez a legolcsóbb mód.

    Alternatív megoldás lenne amúgy magára a VGA-ra tenni az SSD-t, de ettől maga a VGA még drágább lenne, illetve a GPU fogyasztási kerete is csökkenne.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Cifu #45159 üzenetére

    Megmondom őszintén, hogy itt a Microsoft lehet a hunyó. Ez a specifikus probléma tökre megoldható azokkal a lehetőségekkel, amit ma tudsz venni boltban. Tökéletes egy x4-es PCIe 4.0-s M.2 NVMe SSD, de még a 3.0-s is, illetve a probléma jellege nem olyan komplex, hogy erre ne lehessen írni egy szabványos API-t rá, elvégre a PCI Express adott, ahogy az NVMe is, tehát full szabvány itt az elérés. Erre csak fel kellene húzni egy extra réteget és kész. A Microsoft viszont ezt az előnyt meg akarja hagyni az Xboxnak, tehát nem csinálják meg PC-be időre. Később valószínűleg megoldják, de addig a gyártók magukra vannak utalva, így elkezdik a saját rendszerüket csinálni. Az alkalmazás oldalán ezek nem igényelnek nagy munkát, egyszerűen csak az eltérő API-kra kell támogatást írni, és ez nem olyan jelentős. Az AMD-nek már van is hasonló API-ja az OpenCL/OpenGL/DirectX-hez. [link] Szoftveres szinten tehát ez egyáltalán nem bonyolult, csak a Microsoftnak kellene vennie a fáradtságot, hogy csináljon egy szabványos API-t rá, aminek tökéletesen jó lenne a PCI Express és az NVMe. De amíg ezt nem teszik meg, addig a gyártók persze, hogy be fogják zárni magukat, mert a szoftver oldalán egyszerű ennek a támogatása, viszont a konfigurációk limitjével a saját processzoraikhoz tudják kötni a saját VGA-ikat. Az meg nekik pluszpénz.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Cifu #45165 üzenetére

    A switch csak azért kell, hogy az 16 sáv el legyen osztva a GPU és az SSD között. Mert nagyrészt a GPU és az SSD működéséhez nem szükséges a CPU-ig menni, elvannak ők ketten. Lásd a Radeon SSG. Ott is egy switch van az SSD és a GPU között. Szóval ez nem hardveres ok, a switch csak kell, hogy összekösd őket, és a CPU nélkül is tudjanak kommunikálni.

    Igen. Alapvetően egy olyan API kellene, ami kezel egy tök szabványos NVMe SSD-t. Nem nagy kunszt, tényleg. Csak a Microsoft nem különösen érdekelt most ebben, jó az, ha az Xbox tud olyat, amit a PC nem. Aztán persze egyszer megcsinálják ide is.

    Ahogy jelenleg tűnik az AMD és az Intel sem szabványban gondolkodik. Persze ez nagyrészt egy szoftveres szintű zárás, nem igazán hardveres, de meg tudják csinálni, és az a cél, hogy AMD-hez AMD-t, Intelhez pedig Intelt vegyél. Ez szimpla önbizalom a részükről, hogy többet nyernek azzal, ha magukhoz kötik az egészet. Igazából gondolj bele. Ha még az egymás elleni harcra nem is fókuszálnak, akkor is meg tudják győzni az OEM-eket arról, hogy AMD és Intel proci mellé vegyenek csak AMD és Intel GPU-t. Az már akkor is hatalmas győzelem nekik, ha egy éven belül jön valami szabvány. Mert a probléma bonyolultságát figyelembe véve nem egy vállalhatatlan dolog ez mondjuk a Khronos számára, ahol ugye nem számít, hogy a konzol előnyben legyen. És simán lehet interoperabilitást írni akármelyik grafikus API-hoz (nem nagy kunszt az egész). De az AMD és az Intel már azzal előnybe került, hogy az OEM-eket olyan szerződésre kényszerítette, amely a CPU-ikhoz saját GPU-t követel, tehát egy év múlva már a szabvány is jó, az OEM-ekkel kötött szerződés még él.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Cifu #45168 üzenetére

    Nem kell panaszolni. Megoldható a probléma úgy is, ha a VGA-ra rakod a switch-et és az SSD-t, lásd Radeon Pro SSG. Amiért ettől az Intel és az AMD egyelőre irtózik az az ár, mivel durván megdobná a VGA költségét.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #45182 üzenetére

    Valahogy be kell rakni a terméket nagyjából félútra az 5500 XT és az 5700 közé. Mivel a kihozatal kiváló a TSMC-nél, így felesleges az ALU-kat erősebben letiltani, vagyis elveszik az órajelet. Utóbbi már csak azért is kellemes, mert a blending teljesítményre is negatív hatással van, így egyre messzebb kerül a termék az 5700 teljesítményétől, ugyanis pusztán a 192 bites busz nem lenne olyan jelentős hátrány. Ennyi a lényeg. Aztán persze, ahogy számítani lehetett rá a gyártók dobnak rá egy combos hűtést, hogy vissza lehessen emelni az órajeleket. De az már tuning, tehát nincs rá garancia.

    A probléma annyi lenne a magas órajellel, hogy az ALU-kat kellene letiltani, ami persze megoldható, de a blending teljesítmény magasabb lenne pusztán az órajel miatt, tehát nem lehetne a termék teljesítményét annyira elvinni az 5700-tól, hogy utóbbinak megmaradjon a létjogosultsága.

    Spekulálni felesleges egy olyan terméknél, amely köztes megoldás. Ott az számít, hogy milyen paraméterrel tudsz úgy x teljesítményt hozni, hogy az elég messze legyen a nagyobb, de drágább modelltől. Itt egyáltalán nem a lehetőségek döntenek, hanem az, hogy mik a piac szempontjából optimális paraméterek.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #45185 üzenetére

    Nincs, mert az is egy paraméter. Olyanra állítják, amilyenre akarják. Ha akarnák rakhatnák 100 wattra is. Lásd a Radeon RX 5500M, ami ugyanaz a hardver, mint az asztali 5500, mégsem 150 watt a TGP-je a hivatalos papíron, hanem 60. Ma már ez is csak egy szám a BIOS-ban/driverben.
    Régen ez teljesen más volt, mert nem AVFS hardverek voltak, de ma már ez ugyanolyan meghatározható adat, mint az órajel.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    Elég kevés hibás Navi 10 keletkezik. A TSMC node-jának hibaaránya 0,09/cm^2, vagyis a kihozatal nagyjából 90%-os. Az 5600 XT az 1660 Ti-re egy válasz. Ugyanannyiért megvehető, és gyorsabb nála.

    (#45251) gbors: Elég sok Navi 10 jó ahhoz, hogy ezzel elméletben ne kelljen foglalkozni, mert az 5700 is egy vágott megoldás. Egyszerűen csak csináltak egy kisebb verziót. A legtöbb lapka, ami rákerül jó lenne 5700-ra is, olyan kihozatallal, amivel dolgoznak bőven...

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Z10N #45253 üzenetére

    Nem kell többet vágni. Mint írtam a kihozatal nagyon magas. Ezért sem vágják az RX 5600 XT-t. Nincs értelme, bőven felhasználható majdnem minden lapka 36 CU-val is. Ha most lenne egy 32 CU-s verzió, akkor az csak árfeszültséget okozna, és elindítana egy kis leárazást, amire egyék érintettnek sincs szüksége. Nekik pont jók a mostani árak. Főleg úgy, hogy a következő generációnál növelni kell, hiszen az EUV-s node-ok még drágábbak, az 5 nm pedig a 7 nm duplája kb.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Yutani #45255 üzenetére

    Igen. Waferre licitálnak. De nem számolják azt le csak GPU-ra, mivel az üzletág egybe van olvasztva a CPU-val.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Cifu #45257 üzenetére

    Igen. Kellett egy termék a 279 dolláros szintre. Ez azért lényeges, mert 300 dollár felett kezd el drasztikusan esni a GPU-kra a kereslet. Tehát mennyiségileg egy 279 dolláros hardverből sokkal többet eladnak, mint egy 349 dollárosból. A JPR őszi jelentése szerint majdnem háromszor akkora a felvásárlóbázis, amely 300-at még kiad, de némileg többet nem. Innen hiányzott egy VGA, amivel ez a bázis elérhető. Az teljesen mindegy, hogy az NV-nek volt ide terméke, az AMD akart egy modern megoldást, mert akinek például ennyi pénze volt, az nem tudott venni csak 1660 Ti-t. És ez mennyiségileg relatíve sok potenciális vásárló. Idén már több kapacitás érhető el a TSMC-nél, így lesz is elég Navi 10, elérni ezt a réteget.

    (#45259) gbors: Azt mondom, hogy azok a GPU-k, amiket beleraktak az 5600 XT-be, mehettek volna az 5700-ba is. Egyszerűen bőven elég jó a kihozatal hozzá. Itt a lényeg azon van, hogy mennyiségileg készül több Navi 10. Sokkal több, viszont 300 dollár fölött nem vásárol annyi user, tehát kellett egy olcsóbb modell, hogy eladják a termékeket. Ha árat csökkentettek volna, akkor sorozaton belül lenne árfeszültség, vagyis mindenhol korrigálni kellene. Jobb volt egy olcsóbb verziót kiadni.

    (#45258) sutyi^: Nem állni fog. Növekedni fognak, ergo a usernek rosszabb lesz. De csak így éri meg a piac.

    (#45260) Yutani: A memóriabuszt nyilván le kell tiltani, de 90%-hoz közelítő kihozatalnál ez nem lenne szükségszerű. Már a sima 5700 is egy vágott lapka, oda bőven elmennek a gyártási selejtek. Annyival több nem keletkezik, hogy kelljen egy 5600 XT, de mennyiségileg maga a megcélzott szegmens háromszor több vásárlóval bír, mint amelyik területet az 5700 és 5700XT célozza. Ez már fontos szempont, még akkor is, ha az eladott lapkák többsége hibátlan lesz az 5600 XT-n. Persze rakhatnák ezeket 5700 XT-re, csak nincs akkora vásárlóerő, hogy elvigyék őket, vagyis csak felborítanák a raktárarányt.

    (#45261) Yutani: Igen. Egyben veszi az AMD a wafert. A TSMC-nek is teljesen mindegy, hogy melyik gyártósoron mit gyártanak. A cég pedig nem számolja ezt külön, mert a GPU és a CPU is ugyanahhoz a divízióhoz tartozik.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Cifu #45265 üzenetére

    Bármikor csinálhatnak 220-ért egy terméket, de az 5600 XT teljesítménye a Vega 56 és 64 között van. Ne várjátok, hogy 220-ért fogják adni, mert jelentősen gyorsabb az említett árszinten tanyázó VGA-knál.

    Nincs az 5600XT-nek referenciamodellje. Mindegyik úgymond jobb hűtős lesz.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Raymond #45268 üzenetére

    Az 5500 XT 8 GB MSRP-je 199 dollár.

    Lehet olcsóbban adni bármit, csak miért is kellene egy gyorsabb terméket olcsóbban adni, mint a konkurencia?

    Mindegyik felsorolt NVIDIA terméknél gyorsabb az 5600 XT. Most megnéztem a review guide-ot és az 1660 Ti-nél játéktól függően 10-35%-kal gyorsabb. Átlagosan 20%-os előnye van. És azt akarod mondani, hogy az AMD-nek nincs joga ezt ugyanannyiért adni, amennyibe az 1660 Ti kerül?

    (#45269) gbors: Tisztázzuk ezt a versenyképtelenséget. Nagyjából két tucat játék alapján az RX 5600 XT 20%-kal gyorsabb átlagban az ugyanolyan árú konkurensénél. Mi kell a versenyképességhez? Legyen féláron kétszer gyorsabb? Jó lenne ezt előre tisztázni, mert az sokat segítene a továbbiakban, hogy az AMD-nek mennyivel kell gyorsabb terméket kiadnia ugyanolyan áron, ha mostani 20% nem elég.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    Általánosan reagálva:
    Bármilyen 1660-hoz hasonlítható az 5600 XT, mindegyiknél gyorsabb, még a drágább OC-s Supereknél is. Minden egyes tesztben, amit az AMD mért, és vannak benne régi játékok, DirectX 11-esek, esport címek, modern DirectX12/Vulkan címek, stb. Nyilván utóbbiakban a legnagyobb az 5600 XT előnye. Borderlands 3-ban például 52 vs 69 fps van a gyári 1660 Ti-hez képest, és 53 vs 69 fps a leggyorsabb 1660S OC-khez képest (az 1860 MHz-es boostos modellek). De ha úgy tetszik, akkor a Borderlands 3-ban az 5600XT kb. annyira gyors, mint az RTX 2060 Super... pedig ez Unreal Engine 4. Lényegében akármit raksz ellene az 1660 sorozatból, az 5600 XT gyorsabb.
    Emiatt bátorkodtam rákérdezni, hogy mennyivel kell gyorsabbnak lennie egy AMD terméknek, hogy versenyképesnek mondjuk...

    Ha be akarod lőni a teljesítményét, akkor van Vega 56 mérés is, annál átlagosan 7%-kal gyorsabb az 5600 XT. Ez az alapórajeles, ami fontos, mert lesznek nagyon OC-s verziók is, most ebbe ne menjünk bele, nyilván plusz ~200 MHz-et nem adnak majd ingyen a gyártók. Ezek elvileg 300 dollár fölé kúsznak majd.

    A fentiek miatt nem értem, hogy miért kellene az 1660-aknál olcsóbban adni a terméket... Persze én előnyben vagyok, előttem már itt a guide.
    De ha berakjuk mondjuk a Cifu által beágyazott diagrammodba a Vega 56+7%-kal az RX 5600XT-t, ami talán nem a legjobb módszer, mert mások a tesztjátékok, de jobb egyelőre nincs, akkor azért láthatjuk, hogy nem kicsit ráver az 1660-akra. Persze ezt felárral teszi, viszont ha azt nézzük, hogy a plusz teljesítmény megéri-e a felárat, akkor eleve 4 GB-os Radeon RX 570-et veszünk vagy 4 GB-os GeForce GTX 1650 Supert, mert ezekhez képest minden gyorsabb kártya sebességelőnye kisebb a felárnál, amit kér a cég értük. Tehát az egy igen megszokott jelenség, hogy a sebességelőnynél a felár nagyobb, pusztán azért, mert sokaknak a sebességelőny értékesebb, és hajlandók ezért arányosan többet fizetni. Ha ezt senki sem tenné meg, akkor jelenleg mindenkinek Radeon RX 570-je lenne, mert annak az ár/teljesítmény aránya a legjobb, csak nem így működik a piac. Mit lehet kezdeni az RX 570-nel, ha nem elég a teljesítménye? Menni kell feljebb. Ugyanez leírható az 1660Ti/S-re is. Ha nem elég a tempója, akkor menni kell feljebb, és ott lesz az RX 5600 XT következő lépcsőfokként.

    (#45273) Busterftw: Elképzelhető, mert az AMD tesztjében is megfigyelhető, hogy a DirectX 11-es játékokban relatíve közel van az 1660 Ti. Nagyjából 10% körüli közelségben. Ahol az AMD nagyon elhúz, azok a DirectX 12-es és Vulkan játékok, ott vannak 20-30% közötti különbségek is. Mi pedig ugye egy ideje nem tesztelünk elavult API-kon futó játékkal, tehát nyilván mi a DirectX 12/Vulkan különbségekhez leszünk inkább közelebb. A legnagyobb előnye úgy tűnik, hogy a World War Z-ben van, ott egy tesztelő kolléga, akinél már van kártya mért egy +39%-ot az 1660 Ti-hez képest. De ez extrémítás, a legtöbb DX12/Vulkan címben ennyivel nem gyorsabb.

    (#45276) Z10N: Az OEM-eknek lesz az a termék, amit akarsz, de dobozos szinten nem igazán fér bele, mert nincs hely a 8 GB-os 5500 XT és az 5600 XT között. 80 dollárnyi különbség van köztük az MSRP alapján, és oda egyszerűen nem tudsz berakni még egy terméket a raktárak elbaszása nélkül. Ez meg baj a partnereknek, mert végül leírásra kényszerülnek, azaz veszteségbe küldöd őket. Ez nem célszerű. Akkor lenne értelme még egy modellnek, ha a 8 GB-os 5500 XT és az 5600 XT között nagyobb lenne az árkülönbség. Ez pedig akkor lehet opció, ha nem viszik a termékeket.

    Nem hiszem, hogy érted a gyártók problémáját. Van egy nyereség, amiért megéri maradni. Ha ezt nem tudják hozni, akkor nem éri meg a piac. Nem a két szép szemünkért fejlesztenek, és a legkevésbé hatják meg őket, hogy ha nem jók az árak, akkor a konzolra menekülnek a userek. Ettől csak még magasabbak lesznek az árak, mert a fejlesztési költségeket még kevesebb eladással kell visszatermelni.

    (#45277) Z10N: Nem biztos, hogy mindenhol hibátlan egy 5700 XT-re kerülő lapka. Manapság már eleve van betervezve a chipekbe redundancia, tehát az is elképzelhető, hogy minden részegységet tudnak engedélyezni úgy is, hogy az adott lapkán belül van valami hiba a gyártásból eredően. Ehhez az kell, hogy a gond redundáns területre essen.

    (#45283) AtomSiló: Az EUV csak akkor olcsóbb, ha növeli a kihozatalt, de mivel a TSMC-nek EUV nélkül sincs ezzel gondja, ezért az EUV-s node drágább lesz összességében, mert maguk a berendezések nagyon rossz hatékonysággal dolgoznak még.
    Eredetileg azért mondták az EUV-t olcsóbbnak, mert azt hitték, hogy a TSMC meg sem fogja közelíteni EUV nélkül a 0,1/cm^2-es hibaarányt, csak ennél is jobban megy az aktuális két node, amik EUV nélküliek. Ha mondjuk az eredeti felállás igaz lenne, hogy pusztán az EUV miatt sokkal több eladható lapkád lenne, akkor természetesen olcsóbb lenne összességében az EUV, mert több terméket tudnál belőle kitermelni, de így csak teljesítményelőnye lesz, sajnos drágábban.

    (#45291) b. : Én nem állok ki egy termék mellett sem. A hazai viszonyok szintjén pedig rohadt nagy tény, hogy az AMD nem egy hardvert küld a megjelenések idejére a régióba. Ezért vannak róluk állandóan tesztek. Az NVIDIA alig, decemberben próbáltunk Super kártyákat szerezni, de senki sem tudott adni a partnereink közül. Az 1660 Ti-t is úgy szereztük, hogy SidCorky-nak ez van otthon. Ha nincs neki, akkor ez sem szerepelt volna a tesztben. Szóval így rohadt nehéz tesztelni. De leírtam korábban, hogy a probléma igazából a megbízott cég, aki ezeket intézi. Az AMD egyedüliként képviselteti magát tényleges telephellyel a régióban, vagyis nem kell PR cégeken keresztül bénázni. Sajnos sok PR cég csak felveszi a pénzt a tevékenységéért, de nem látja el igazán a feladatát. Jelezzük mindig a gyártók felé, hogy nem kapjuk meg, amit kérünk, nem működik jól ez az egész, de egyelőre nincs változás. Pedig annyit már tudunk, hogy nem csak mi panaszkodunk rá. Az Intelt meg kb. hagyjuk, ha nem lenne régiós szinten ASUS, Gigabyte, stb. akkor nem lennének Intel tesztek, nemhogy nálunk, hanem sehol a régióban.
    Szóval a három nagy gyártó közül egyes egyedül az AMD veszi a fáradtságot arra, hogy a régióba minimum egy tesztterméket küldjön a megjelenés előtt. Sőt, manapság már az AMD az egyetlen cég, amely a régióban meghívja az újságírókat a briefingekre. A másik két cégnél manapság már nekem kell utánuk rohanni, hogy xy előadásra menni szeretnék, és nem egyszer csak akkor kapom meg az engedélyt rá, ha már lement az előadás, és akkor e-mailezek napokig a felvett anyag után, hogy legyen NDA-ra legalább hír. És olyan e-mailváltások vannak, hogy kérem az anyagot, adom a meghívót, majd mondják, hogy kérjem a helyi PR-től. Írom nincs helyi PR. Erre írják, hogy kérjem akkor a hozzám legközelebbitől. Erre megadom, hogy hol vagyunk, és kérdem, hogy melyik a legközelebbi. Megadják. Írok nekik, majd mondják, hogy ők már nincsenek szerződésben velük, kérjem a cég globális PR-jétől. Visszamegyek a globálishoz. Írják, hogy márpedig szerződésben vannak, nem tudja, hogy miért ír mást a PR-es. De ezután a globális PR elküldte az anyagot egy felhőszolgáltatóhoz feltöltve, ami szabálytalan volt, mert nem volt levízjelezve, de nem izgatott. Csak megjegyzem, hogy ez az AMD-nél úgy megy, hogy van egy tárhely, ahova be vagyok regisztrálva egy globális azonosítóval, és bármi, amire bejelentkeztem, rögtön az előadás után megjelenik. Nem kell írogatni senkinek.

    A Vulkan subgroupop egy szabvány, nincs rá gyártói verzió. A WWZ már nem is tartalmaz olyan kódot, ami csak AMD-n fut. DX11-ben igen, de Vulkan módban nem. Itt minden szabványos, az NV-n is így fut le. A subgroup operációkat viszont nem minden hardver kezeli ugyanolyan gyorsan, emiatt mások az erőviszonyok.
    Dupla wave sem létezik. Variálható wave-méret van. Ez nyilván előny a WWZ-ben, de nem túl nagy.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Új hozzászólás Aktív témák