- Windows 11
- A call centerekbe viszi az AI-t a Microsoft
- ASUS routerek
- Mikrotik routerek
- Aliexpress tapasztalatok
- Nem szavazza meg Musk 56 milliárd dolláros csomagját a norvég állami vagyonalap
- Autodesk - Revit
- Otthoni hálózat és internet megosztás
- PHP programozás
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
-
IT café
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
#85552128
#15134
üzenetére
A víz nem GameWorks a Witcher 3-ban. Eredetileg valóban WaveWorks volt tervezve, de sehogy sem akart működni. Ezért ezt ki kellett iktatni, és ennek a helyére került egy saját megoldás. Ez a másik baj a GameWorksszel, hogy a forráskód elzárása sokszor teljesen megakadályozza az implementációt. Mivel a víz a CDPR sajátja, így azt lehet paraméterezni, ahogy akarják.
(#15139) Asbee: Nem a címeket kell nézni, hanem az irányt, ami történik. És ez nagyon rossz lesz az egész PC-nek, mert sokszor nem lehet majd driverből hackelni a rendszert, hogy megkapd ugyanazt a minőséget sokkal gyorsabban.
(#15140) decibel: És mit csináljon az a fejlesztőstúdió, amelynek nincs olyan szerencséje, hogy az Intel és az AMD partnerprogramjába beférjen? Nekik nincs választásuk, egyszerűen a pénzért alá kell írni a szerződést, mert az Inteltől és az AMD-től nem fognak látni promóciós pénzt. Ma másképp nem éri meg PC-s portot csinálni. Persze a jövőben ezen talán segít a Microsoft iránya, hogy az Xbox One játékot gyakorlatilag portolás nélkül lehet hozni PC-re.
(#15145) gbors: A kártyán lévő portok szempontjából nem éri hátrány a piacot. Ez egyszerű döntés eredménye. És ez mindkét oldalon probléma, hiszen az AMD-nél nincs HDMI 2.0, míg az NV-nél nincs DisplayPort 1.2a verzió. De ennek az iparágra nincs káros hatása! HA neked HDMI 2.0 kell vegyél GeForce-ot, ha DisplayPort 1.2a, akkor Radeont.
(#15155) Jack@l: Senki sem írt egy sor kódot sem GameWorksszel. Megkapod és használod. Ha nem működik, akkor pedig a játék kiadása előtt letiltod. Aztán majd jönnek az okosok és elmondják, hogy a szemét konzolok tehetnek arról, hogy a PC-n nem aktívak a bemutatott effektek.
Nos, részben nekem az a dolgok, hogy ezeket a dokumentációkat nyálazzam.(#15170) rocket: Ez tévedés. Lényegesen gyorsabb a hackolt futtatás Radeonon, mint amire a GeForce képes. Ezért írtam, hogy ha a GeForce is képes lenne erre a driverből, akkor ott is hozzávetőleg négyszeresére gyorsulna az effekt sebessé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
#85552128
#15181
üzenetére
Nem. A víz az jó a Witcher 3-ban. Egyrészt paraméterezhető. High és very high között a 32x és 64x tesszellálás a különbség. Tehát nem kell kikapcsolnod az effektet, hanem elég visszavenni, ha nem 8K-s felbontáson futtatod.
Másrészt a probléma nem a tesszellálás alkalmazása, hanem a feleslegessége a HairWorks esetében. Egy ilyen rendszernél a hajszálnak elég maximum 64 szakaszból állnia. Ez rendkívül kevés memóriahasználatot jelent még úgy is, hogy nem tesszellálod le a 64 szakaszt több szakaszból. A HairWorks 5 szakaszt használ a hajra, amiből lesz 320 szakasz. Amiért nem látod a különbséget a 16x és a 64x tesszellálás között az az, hogy 16x tesszellálással is 80 szakaszod van és az több, mint a 64, ami szükséges egy hosszú hajszálnál. Rövid hajszálaknál elég még kevesebb is, de azok is 5 szakaszból állnak a HairWorksnél, és abból lesz 320 szakasz. Esetenként egy rövid hajszál mindössze négy pixelt foglal el, és ilyenkor hosszávetőleg 100 szakasz jut egy pixelre, ami azt jelenti, hogy raszterizálás során a munka 99%-a szükségtelen, de meg kell csinálni, mert nem tudod előre, hogy melyik szakaszra van szükséged.
A tesszellálás miatt a HairWorks egy olyan problémával is szembesül, hogy az 5 ms-os időkeretből. 3-4 ms-ot csak a tesszellálással tölt, így az olyan fontos dolgokra, mint az analitikai élsimítás, az önárnyék és az átlátszóság kezelése nem marad idő. Márpedig ezek sokkal nagyobb szerephez jutnak a minőség tekintetében, hiszen mindegyik szükséges ahhoz, hogy a haj ne spagettiszerű recés valami legyen, hanem látszódjon, hogy itt vékony szálakról van szó. És ez teljesen kivégzi a HairWorks minőségét, tehát jelen helyzetben ronda és lassú is. Ez a gond, és nem az, hogy 64x tesszellálást használ. Ha szükséges, akkor használjon, de nem szükséges.A tesszellálásra még kitérve, meglepő lesz amit írni fogok, de nagyon sok játék használ ma már 64x tesszellálást. Tehát ezzel igazából nincs semmi baj. Még a Gaming Evolved játékok is használják 64x-es mértékben, mint például a Sniper Elite 3 és a Thief. Azért van benne az API-ban is, mert van olyan helyzet, ahol hasznos, és látható előnyt ad. A gond itt az, amikor olyan helyre van használva ahol nem ad előnyt, vagy egyáltalán nem is szükséges. És itt nem is a túltesszellálásról van szó, mert a Sniper Elite 3 és a Thief esetében is a phong tesszellálás ott van minden karaktermodellen és számos felületen is, tehát ennél durvábban nem is lehetne alkalmazni.
[ 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
#15190
üzenetére
Amelyek szükségesek ahhoz, hogy az effektet implementáld a motorba, de egyetlen változó sincs például a tesszelláció paraméterezésére vagy arra, hogy hány szakaszból álljon a hajszál, amely a legfontosabb dolog lenne.
Az AMD, az Intel és az NV is kínál anyagi segítséget a fejlesztőknek a partnerprogramokban. Az hülyeség, hogy csak az NV ad pénzt, vagy egyéb anyagi juttatásokat. Viszont nézd azt a gondot, hogy az AMD és az Intel partnerprogramja túlterhelt. Mindkét cég több stúdióval és kiadóval dolgozik együtt, mint az NV, és ezért például nem tudják vállalni a kimaradtakat. De a kimaradt stúdiók és kiadók is próbálnak szerezni anyagi támogatást, és ha nem tudnak elmenni az AMD és az Intel partnerprogramjába, akkor maradt az NV. Nyilván ez a vezető oka annak is, hogy az átlagot tekintve az TWIMTBP játékok rendelkeznek a legrosszabb optimalizálással, mert azokat a kiadókat és stúdiókat tudják felkarolni, amelyek az Intel és az AMD rostáján nem mennek á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
bozont
#15314
üzenetére
És min keresztül vezetsz át több ezer vezetéket, ha nem lesz alatta interposer? Valamiféle interposer rétegre szükség van.
(#15288) ffodi: Mindegyik VGA vissza fogja venni az órajeleket olyankor, amikor egy játék nem a mai 40-60% közötti terhelést fejti ki. 80-90% az már majdnem Furmark szint, és itt játékról van szó, tehát nem fognak a driverbe lefojtást építeni. A hőlimitre is vannak bizonyos követelmények, amelyeket be kell tartani. A legtöbb 39 szériás kártya azért használ 70-80 fokos hőlimitet, mert az alkalmazott egyedi hűtés mellett, ilyen hőfokon éri el a referenciához hasonló működést. A referenciát ugyan nem adták ki, de a gyártók megkapták és annak a hőlimitje 105 fok volt, tehát ki lehetett vizsgálni, hogy mit kell minimum teljesíteni az egyedi termékeknél. Nyilván ha úgy döntöttek a gyártók, hogy raknak rá jobb hűtést, akkor kellett nekik egy összehasonlítás az AMD rendszerével, és aszerint kellett belőni a hőfok limitet a BIOS-ban, hogy az AMD elfogadja az adott dizájnt. Itt nagyon egyszerű a képlet. Minden órajelre van egy teljesítményhatás, amit be kell tartani. Ha a termék a meghatározott teljesítményszint között üzemel, akkor ki lehet adni. Ezt a teljesítményszintet a referenciahardverek szolgáltatták, tehát a gyártók egyénileg ki tudták tesztelni. A gyári tuning pedig ezekre az alapokra épül.
Azt nagy biztonsággal ki lehet mondani, hogy amikor a 200-as szériát kiadták, akkor nem volt olyan teszt, amivel meg tudták volna nézni, hogy az adott generáció hogyan teljesít aszinkron compute mellett. Képesek voltak terhelést szimulálni, de az nem gyakorlat. A 300-as szériánál már ott volt az Ashes of the Singularity, aminek tesztelésével lehetett konfigurálni a bekövetkező órajelcsökkenéseket. És ez már gyakorlati példa. Itt jó +4-5%-ot hoztak még az ugyanolyan órajelre állított kártyák is, csak abból, hogy a PowerTune-t képesek voltak gyakorlati példával tesztelni, így jóval agresszívabb lehet a működése, mint amikor szimulált környezetre építve paramétereznek. Az a baj, hogy bármennyire is próbálod egy játék működését nem tudod leszimulálni, így a játékokra paraméterezett PowerTune addig nem lehet tökéletes, amíg nem tudsz rajta gyakorlati példákat futtatni.
Az egyébként való igaz, hogy a 15.15-ös driver lényegesen jobb, mint a 15.5 beta, és ez is okozott boostot a 300-as szériánál a 200-ashoz viszonyítva. A 200-asra az AMD nem ajánlotta ezt a drivert, mert nem tesztelték, de amint becsomagolják a tényleges Catalystba úgy minden GCN megkapja ezeket a gyorsulásokat. Sőt, a későbbi 15.200/15.300 csomag gyorsulásait is.
[ 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
Drizzt
#15800
üzenetére
Azt már tudja a Tonga is. De nyilván benne lesz a Fijiben is.
(#15801) Menthirist: Dehogynem lehet tudni. A context priority rendkívül sérülékeny, mert a hosszú rajzolásokat nem tudja hatékonyan lekezelni. Nem véletlenül jegyezte meg az NV a GDC-n, hogy később ők is áttérnek majd a finomszemcsés preempcióra, amit a Tonga és az összes GCN3 GPU használ. Emellett majd kell a stateless compute is, mert a timewarpra leginkább akkor érdemes időt szánni, amikor vertex feldolgozás és tesszellálás van, mert az a feldolgozás eleje, de mivel a compute több architektúránál is jellemzően a pixel state-hez van kötve, így vertex shader és tesszellálás mellett a timewarp nem futhat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15818
Abu85
HÁZIGAZDA
Komplikato
#15816
Abu85
HÁZIGAZDA
válasz
Komplikato
#15816
üzenetére
Nem tévedsz, de dátum még nincs a Nanora. Előbb Fury sima lesz egyébként, aztán Nano és aztán a dual Fiji.
(#15817) Demo77: Az új Batman a magyarázat. Az 4K HDMI 1.4 kompatibilis, és nem 30 fps-re cappelt játék.
[ 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
Hakuoro
#15864
üzenetére
A 128 ROP csak most érne valamit. Erről kérdeztem az AMD-t, és azt mondták, hogy 2013-ban még tárgyalták, hogy szükséges a ROP teljesítmény növelése, de aztán látták, hogy minden új generációs motor elment a compute felé. Ray-tracing hibrid effektek stb, így több shader mellett döntöttek kevesebb ROP-pal. Ez bizonyos játékokban nem ideális, de a Frostbite 4, CryEngine 3.8.x, Nitrous, LORE, Dawn Engine, szinte mindegyik új dolog ilyen. Még az Unreal Engine 4-be is bekerült a Ray Traced Distance Field Soft Shadows, amit pont azért raktak bele, mert messze túllépik a hardvere az 5 TFLOPS-ot.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#15886
üzenetére
Ezek komoly mérnöki döntések. Van egy tranyóbudgeted az egész fejlesztésre. Nyilván előre ki lehet számolni, hogy hozzávetőleg mennyit használhatsz fel. Abba kell beleférnie a legjobbnak. De a kérdés, hogy mi a legjobb? Rakjál bele kevesebb ROP-ot, és több shadert ezzel reflektálva a Frostbite, a CryEngine, a Nitrous, és még sok motor irányára, vagy rakj bele több ROP-ot és kevés shadert ezzel lefedve az aktuális motorverziókat. Aztán ott vannak az olyan piacok, mint a VR. Oda nagyon kevés a nyers erő, így le kell tervezni a hardvert úgy, hogy hatékony legyen a timewarphoz. Dönthetsz úgy, hogy én ezt nem teszem meg, mert a finomszemcsés preempció drága, és még nehezebb stateless compute hardvert építeni, vagy úgy, hogy ez egy nagy piac lesz és akkor legyen a hardver VR-ready.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
#15905
Abu85
HÁZIGAZDA
Komplikato
#15899
Abu85
HÁZIGAZDA
válasz
Komplikato
#15899
üzenetére
Ez koncepciókülönbség. Felfedezhető az NVIDIA és az AMD architektúráit vizsgálva, hogy az NVIDIA főleg a geometria komplexitásának a növelését tartja fontosnak, míg az AMD a compute pipeline-ok építését és párhuzamos futtatását. Ezért is akarja az AMD annyira az új API-kat, mert amíg a geometria komplexitásának növelése egy részben ugyan, de reálisan működő irány a DirectX 11-ben, addig a pipeline-ok feldolgozása soros formára van kényszerítve, függetlenül attól, hogy a hardver mit tud. Ennek valószínűleg köze van ahhoz, hogy az AMD már a PS3-nál felfigyelt, hogy mire képes a gép, ha a megszokott módtól eltérően programozzák, míg az NVIDIA ezt valószínűleg látta, de úgy gondolták túl nehéz lenne átnyomni egy olyan váltást a PC-n, hogy az aktuális API-kat konzoloshoz hasonlók váltsák fel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért az túlzás, az év végére még simán itt lesz mindegyik VGA (a mostani játékmegjelenéssel számolva, akkora már a mi tesztcsomagunkban nem is lesz DX11-es játék), ami most a piacon van. Szerintem még a következő nyáron is. Majd talán ősszel lesz váltás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15913
Abu85
HÁZIGAZDA
FollowTheORI
#15910
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#15910
üzenetére
A Fiji fejlesztésénél az egyik vezető koncepció valószínűleg a VR lehetett. Ezt az AMD többször is elmondta. Abban valóban igazuk van, hogy ez ma az egyetlen hardver, ami ténylegesen alkalmas VR-re. Nem csak a teljesítményben, hanem a tudásban is megvan benne a stateless compute és a finomszemcsés preempció, a kis késleltetésű leképzés érdekében. Nem véletlen, hogy minden E3 VR demó ezen futott, semmi sem ad olyan folyamatosságot, mint a Fury X. És a VR Q1-ben bevetésre kerül, addigra pedig nem lesz új VGA, tehát a mostaniba kell belerakni a képességet, hogy meglegyen az élmény.
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
#15917
üzenetére
Nem mindegy melyik játékkal. Azért jönnek olyan játékok a Q1-ben, amelyek nehezen fogják a 90 fps-t stabilan tartani maxon egy Oculus által ajánlott géppel. Mint írtam nem véletlen, hogy ezek két Fijin futottak az E3-on.
HDMI 1.4 lesz a végleges Oculus Riften.[ 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
#15922
üzenetére
Nem ismerem a későbbi Oculus verziókat. Nyilván elképzelhető, hogy a 2018-ban érkező Rift már HDMI 2.0-t kap, vagy esetleg DisplayPortot.
(#15921) stratova: Ha lesz Windows 10 akkor áttérünk rá. Addig Windows 8.1 van.
(#15919) gbors: Elég alacsony a Fury variancia. 4% csak. Ennél még a 980 Ti varianciája is nagyobb, annak 7%. De ezzel nem tudsz mit tenni, ez a DVFS egyik hátránya, hogy ugyanaz a kártya nem ugyanúgy teljesít. Egyébként nyilván előfordulhat, hogy a Fury példány jól sikerült, míg a 980 Ti pont nem, de ugyanez igaz fordítva is.
[ 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
#85552128
#15955
üzenetére
De csakis a Battlefield 4 esetében. A többi Frostbite játékban és úgy általánosságban a többi Mantle játékban ez a gond már nem létezik. A jövőben érkező játékok esetében pedig a Mantle mód nem a teljesítményről szól, hanem az extra eljárások beépítésérő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
#85552128
#15958
üzenetére
A teljesítmény az a körítéstől függ. Nyilván ismerjük az EA álláspontját, hogy a Frostbite 3-on a DX11 nem stabil. Nem mondom, hogy jól döntöttek, amikor ilyenre írták meg a motort, de azzal nyugtatják magukat, hogy van alternatívája a DX11-nek. Ami amúgy nem globális alternatíva, tehát inkább a DX11 stabilitása lenne a cél. De mindegy, ezt a gondot a Vulkan úgyis megoldja univerzális szinten.
(#15960) daveoff: Ez az engine verziótól függ. Nem lehet ennyire egyszerűen leváltani a rendert, főleg úgy, hogy a fő frissítést az első PBR verzió kapta meg, vagyis vissza kellene menteni magát a PBR-t is a régi Frostbite-ba, ami nagy munka. Meg eleve jön a következő, úgymond igazi PBR frissítés, talán elnevezik Frostbite 4-nek, de lehet, hogy szimplán elhagyják a számokat.
[ 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
#85552128
#16007
üzenetére
Ez a Civilization sajátossága. Ha elkezdesz egy pályát, akkor nagyon gyors bármelyik API-val. Amint lefutottál több száz kört már beépítetted a pályát és töredékére esik az fps. Ezt kipróbáltam én is. DX11-ben hozzávetőleg 70-75 fps-sel kezdtem kizoomolva, és a vége felé 10 fps-em ha volt, ha kizoomoltam. Mantle-lel szintén 70-75 fps-sel kezdtem és 65-70 maradt a végén is kizoomolva. De ez teljesen normális. A kezdéskor a draw call mennyisége nem éri el az 500-at, míg a vége felé már 20000-30000-ről beszélünk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#16172
Abu85
HÁZIGAZDA
Petykemano
#16156
Abu85
HÁZIGAZDA
válasz
Petykemano
#16156
üzenetére
Nem lehet még beszélni mindenről. Csak a hardvert leplezte le az AMD azt, hogy mit hoznak még a hardverhez nem. De annyit elárulhatok, hogy nem véletlen, hogy júliusban lesz elérhető a sima Fury. Ezzel az a terv, hogy a Windows 10-hez legyen közel a start, hogy ott is le legyen mérve a teljesítmény a 15.200-as csomaggal, amiből egyébként amúgy is kapott a 15.15-os driver a tesztek előtt frissítést. Bár valószínűleg sokan már nem telepítették fel.
A Nano sem véletlenül jön később, hogy nagyobb legyen a fókusz a DX12-vel.Nagyon egyszerű dolog történt amúgy. Az Intel és az NV ugyanúgy látta cirka 7-8 évvel korábban, hogy az API-k a PC-n korlátozók. Rengeteg limittel, és jó lenne, ha ez megváltozna, de nem hittek benne, hogy egy ilyen váltást a PC-n át lehet nyomni egyáltalán. A célja mindig az volt, hogy biztosítsanak egy egyszerűnek tűnő felületet, és a komoly problémát okozó tényezőkkel a háttérben dolgozhat az API és a kernel driver. Ha pedig ez a cél, akkor ehhez kell tervezni a hardvert. Az AMD úgy gondolta 7-8 évvel korábban, hogy egy életük egy haláluk át kell nyomni a változást. És a potenciális változáshoz tervezték a hardvert, gondolva arra, hogy hagyományos szinten hátrányban lesznek, de ha sikerül letolni az ipar torkán a low-level irányt, akkor már a konkurensek lesznek hátrányban. Most történik a váltópont, mert nem kis meglepetésre egyébként, de átnyomták az irányt.
Többek között a DX12 az AMD-nek nagyon fontos, mert rengeteg olyan dolgot megváltoztat, amely most számukra hátrányos a DX11-ben. Például ma a bekötési modell váltása a legfontosabb és nem véletlen, hogy erről beszélnek a legtöbbet. Ma ez úgy néz ki, hogy a CPU beköt egy puffert az API-val és a kernel driverrel, amelynek az eredménye egy adat lesz a hardver számára. Ezt a driver szimplán elküldi a hardvernek mint erőforrás leírót. Ezt persze minden hardver máshogy csinálja, mert implementálás szintjén lehetnek különbséget, itt arról beszélhetünk, hogy a bekötés hol valósul meg a multiprocesszoron belül, például a legtöbb mai modern GPU-ban a textúra-mintavételezőben történik mindez, de itt is számolni kell azzal, hogy tömbösítve történik a bekötés, vagy különállóan. A GCN viszont teljesen egyedi. Ennek az architektúrának nincs szüksége erre a procedúrára. Egyszerűen a shaderbe bele lehet írni memória elérést és kész, a skalár egység elvégzi a bekötést. A hátránya, hogy ma egyik szabvány API sem működik így, tehát ezt le kell "emulálni" a kompatibilitást egy olyan hardverrel, amit nem hagyományosan terveztek. Az új API-k azonban így működnek, és fordul a kocka, vagyis a többi architektúrának kell "leemulálni" a kompatibilitást.
Ugyanilyen probléma a queuing. Egy mai API DX11/OpenGL úgy működik, hogy van a hardver felé egy parancslista, és abba lesz betöltve minden, majd a hardver szépen egyesével lekéri a feladatokat, és azokat sorban végre is hajtja. Ma több modern GPU-t erre terveztek. Egy mérnöki csapat felteszi a kezét, hogy tudunk mi hardvert tervezni, de miért is költsük tranzisztorokat a párhuzamos feladatfuttatás kigyúrására, ha a pipeline-ok úgyis sorban jönnek? És ez egy érthető döntés a maga szintjén. Valószínűleg senki sem vonja kétségbe az Intel és az NV vezetőségében, hogy a mérnökeik képesek lennének egy alternatív GCN-t tervezni, csak nem ezt kérték tőlük. Az AMD viszont úgy gondolta, hogy egy ilyen reformot is átnyomnak, mert azért masszívan párhuzamosításra tervezett rendszer a GPU, hogy olyan programok is fussanak rajta. Megtervezték a GCN-t stateless compute-ra, megpakolták regiszterekkel, gyorsítótárakkal, és igen ebből ma egyetlen szabványos API-n sem lehet kihozni semmit, de mit ad az úr a DirectX 12 queuing modellje copy/compute/graphics halmazba van szervezve, így a hardver tetszőleges számú compute és copy parancslistát kezelhet, és ezekről párhuzamosan kérhet le feladatokat, ha persze van rajtuk betölthető. Ezzel lehetőség adódik, hogy a feltöltés és a compute minden más feladattal párhuzamosan végrehajtható legyen, vagyis megszűnt a soros feldolgozásra kényszerítő modell. Itt megint fordul a kocka és a hátrányból előny lesz. És ezekről egyébként fognak beszélni H2-ben, csak megvárják a játékokat, hogy megmutathassák, hogy ez mit is jelent. A 3DMark API Overheadben már láthatjátok egyébként, hogy mi történik az architektúrák hatékonyságával a DX11-DX12 váltásná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
Ren Hoek
#16174
üzenetére
Full HD-re szerintem nem ezt a kártyát szánják. 4K-ra készült. Ezt számtalan alkalommal kihangsúlyozták. Full HD-re vannak sokkal olcsóbb megoldások.
A New Era of Gaming nem igazán a Fury-nak szólt, hanem annak, hogy mennyire pici gépbe lehet belerakni ma komoly teljesítményt. Ezt hivatott prezentálni a Quantum.Vannak akik megengedték, hogy beszéljenek a játékokról (Lionhead, CCP, DICE, Oxide), vannak akik csak utalásokat engedtek meg a videóba (Square Enix), és vannak akik a Gamescomra készülnek, és oda kérték a bemutatót.
Elég sok dolog leszűrhető belelő: [link]
A StarSwarm támogatását befejezték 2014 végén. Az AMD nem tartott rá igényt, mert már mindenhol az AotS játékkal demóznak, így csak az NV-nek készült még egy verzió. Senki más nem kapott optimalizálást 2014 eleje óta. Egyszerűen nem volt rá szükség. Az AotS ugyanaz a motor, csak engedve vannak az újítások is. Abban a játékban egyébként a Fury X a leggyorsabb. 4K-ban ez az egyetlen VGA, amely képes magából játszható sebességet kipréselni. Igaz ezt Mantle módban teszi egy A10-7850K társaságában, de valószínűleg az év végi megjelenésre DX12-ben is képes lesz rá egy combos IGP társasága nélkül. Nyilván egy alpha kód gyorsul annyit a véglegesítésig.
[ 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
lowzor
#16180
üzenetére
Ez nem magyarázat, hanem célpiac. Ha nem akarsz 4K-t, valószínűleg nem érdekel majd ilyen gyors és drága VGA. Ez egyébként minden gyártó kommunikációjában ugyanilyen. Az NV is nyomatja a 4K-t a Titan X-szel.
(#16181) Ren Hoek: Az E3 tökéletes alkalom volt. Nem beszélve arról, hogy nem árt, ha a kisebb stúdiók is hozzáférhetnek egy Fury-hoz, hogy tesztelhessék vele a low-level programjukat. Ha kiszámolod, akkor az Xbox One szeptemberben frissül majd az új Windows 10-es firmware-rel, és akkor válik elérhetővé az univerzális áruház. Ha valami gond van, akkor mindenképp szükséges két hónap az Xbox One-ra DX12-es játékot készítő független stúdióknak, mert bár az API megengedi, hogy módosítás nélkül áthozzák a konzolos kódot PC-re, de azért tesztelés nélkül kiadni nagyon nem ajánlott, és tudtommal a Microsoft ezt kontrollálja is.
[ 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
#85552128
#16185
üzenetére
Nincs különösebb akadálya, hogy az említett felbontásokat használd, de a Windows 10-ben azt figyelembe kell venni, hogy a fejlesztő megkapja a kontrollt a frissítés explicit kezelése felett, hogy hatékonyabb vertikális szinkront lehessen írni. Bizonyos alkalmazásokban nem lesznek elérhetők ezek a frissítések, míg a 4K minden alkalmazásban elérhető lesz.
(#16188) rocket: A hardver egy eszköz a tartalom futtatásához. Ma már a szoftvernek legalább akkora jelentősége van az AMD-nél, mint a hardvernek. A kettő egymás nélkül nem létezik. És ez a VR szempontjából eléggé fontos dolog, mert szükséges a LiquidVR is a teljes élményhez. Ha csak a hardverre alapoznak a fejlesztők, akkor az rossz élményt ad a virtuális valósághoz. Szerencsére ez nincs így, hiszen minden E3-on bemutatott VR játék LiquidVR-en/Mantle-ön futott.
Számos Fiji VGA jön még, amelyeket le fognak tesztelni és ezzel együtt a Fury X-et is újratesztelik.
[ 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
#85552128
#16192
üzenetére
Természetesen az 1080p-1440p-4K teljesítménykülönbség az egy hardverkarakterisztika, persze ha ugyanarról a programról beszélünk. Ez régen is így volt. Ehhez egyébként valószínűleg kevés köze van a HBM-nek, leszámítva pár PBR játékot, például a Ryse. Inkább a ROP kialakítása a döntő tényező jelenleg. De a jövőben, ahogy nő a PBR és a komolyabb hibrid leképzőket használó játékok száma, úgy válik a memória-sávszélesség egyre fontosabbá. Nyilván az új, PBR-rel kigyúrt Frostbite játékok az E3-on nem véletlenül futottak Fury X-en.
[ 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
rocket
#16197
üzenetére
A Battlefront hosszabban is megtekinthető volt a PCGamingShown. Ez egy 24 órás rendezveny volt.
Az AotS az eddigi legkomplexebb tereprendszert használja. Annyira komplex a terep, hogy az első stratégiai játék lesz, ami nem a CPU-n oldja meg a generálást. Emellett nehéz azt mondani rá, hogy ZS kategória. A Stardock adja ki, akik a stratégia műfajának éllovasai ma. Nézd meg kik készítik és latni fogod, hogy iparági veteránokról van szó, akik korábban top stratégiai játékokat raktak le az asztalra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Driverbe nem lesz beépítve. A Strongene dekódere licencelhető a szoftverfejlesztők számára. Cyberlink, ArcSoft használja is. Te gondolom nem ezeket használod. A letölthető verzió lassabban fejlődik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
rocket
#16223
üzenetére
Igen ez a legkomplexebb. Annyira fontos fejlesztés, hogy a Nitrous motor mellett külön is lehet licencelni. Tudtommal a SEGA és a 2K már kérte is. A Firaxisnak volt az előző évi GDC előadásában, hogy a legnagyobb problémát nekik a terep generálása okozza, és azért nem tudnak komplexebb terepet létrehozni, mert egy óráig generálná a CPU. Ezt az Oxide GPGPU-val oldotta meg. De erről irtunk is egy hírt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#16229
Abu85
HÁZIGAZDA
Komplikato
#16228
Abu85
HÁZIGAZDA
válasz
Komplikato
#16228
üzenetére
Ne feledjük el a StarBreeze cuccát. Az is jön a VR-es Walking Dead játékkal.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Windows 10 beépített dekódere azért ver el sok dekódert, mert nem csak CPU-s. C++AMP-ben írták, és WDDM 2.0 IOMMU mód támogatása mellett használja az IGP-t is a CPU mellé.
A 10 bites HEVC Strongene dekóder csak licencelhető. Pénzt kérnek érte, ha valaki használni akarja, ezért vannak ez a dekóder a fizetős lejátszókban. Az Ittiamnak van még GPGPU dekódere. Ez minden OpenCL 1.2-t támogató holmin megy, de ez is fizetős, hozzávetőleg 50000 dollár az alap licenc. De persze, ha kifizeted, akár neked is odaadják.[ 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
#85552128
#16435
üzenetére
Valaki megint nagyobb összeggel shortol. A samsungos megközelítés pedig nem érdekes, hanem hülyeség. Mivel az AMD semi-custom gyártó, így a Samsungnak is barmikor leterveznek APU-kat. A Samsung egyébként több csúcskategóriás lejátszójában beágyazott APU-kat haszná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
#85552128
#16441
üzenetére
A Samsungnak a szerver lenne csak érdekes. Minden mást le tudnak rendelni. Ráadásul kockázatok és extrém ráfizetés nélkül.
Az MS pletyka egy manipuláció a tőzsdéi árfolyam növeléséhez. Hátha bejön és dob plusz 10-15%-ot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#16445
Abu85
HÁZIGAZDA
Petykemano
#16443
Abu85
HÁZIGAZDA
válasz
Petykemano
#16443
üzenetére
A cél valószínűleg kattintások gyűjtése, vagy esetleg kis manipuláció, hogy shortolni lehessen, de ez nagyon nehéz.
(#16444) geresics: A 380 általánosan erősebb hardver. A 2 GB sok játéknak elég és elég lesz FullHD-re.
[ 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
MiklosSaS
#16480
üzenetére
A mostani GCN verziók mellett meg kettőt jelez a disassembler. Szerintem a 110 a GCN SI, a 120 a GCN CI, a 125 a GCN VI. A 135, 145 más GCN lesz. Tekintve az AMD teljes GCN tervezetét bevezettek sok dolgot már, de még nincs tranzakciónális memóriakezelés. Gondolom valamelyik új GCN verzióba bekerül. Talán a következőbe.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#16488
üzenetére
Biztosan marad a GCN. Nem azért tervezték évekig az iparági teljes reformját a konzollal, a low-level áttéréssel, az architektúra dokumentálással, hogy amikor ebből előnyt kovácsolhatnak hirtelen leváltsák. Szerintem a fejlesztők is borították volna az asztalt, hogy ráírták az új konzolokra a motorokat, megtanulták a GCN-t, és ebből a befektetésből a PC-be nem tudnak átmenteni semmit.
A CPU-s verzió igen. Az APU-s 2017-ben. Addig sajnos nem lesz ultimate megoldás az IGP-t aktívan használó játékokra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Eddig végig úgy fejlődött, ahogy eredetileg eltervezték. A tervekből a tranzakcionális memóriakezelés és a platfromszintű tranzakcionális memóriakezelés, ami még nem vált valóra.
Maga az x86 nem alkalmas széles SIMD-re. Sosem lesz az. Nem úgy tervezték 30+ éve az ISA-t, hogy kiszolgálja a 201x-es igényeket. Ha pedig módosítod az ISA-t az igényeknek megfelelően, akkor megszűnik a bináris kompatibilitás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A közös L3 cache elég rossz ötlet. Az Intel egyszer csinálta a Sandy Bridge esetében, aztán látták, hogy mennyire teleszemeteli a gyorsítótárat az IGP, és a processzormagok teljesítménye a töredékére lassult. Le is tiltották a funkciót. Ami nem működik, azt nem érdemes erőltetni.
Valószínűtlen. Sokkal nehezebb egy AVX-szel bánni, mint egy GPGPU-val, és az AVX ma 256 bites vektor, míg a GPGPU esetében 2048 bitről van szó. A fejlesztők általános meggyőződése, hogy x86 alatt 128 bitnél nem éri meg továbbmenni. Ahhoz, hogy ennél többet használj assembly kell, és itt jön a specializált kód problémája, amelyet minden hardverváltásnál cserélni kell. Az OpenCL ami valamilyen szinten megoldás, de ott meg az a gond, hogy ha van kódod, akkor GPGPU-n futtatod.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#16520
Abu85
HÁZIGAZDA
FollowTheORI
#16513
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#16513
üzenetére
Az Ivy Bridge óta az Intel alapértelmezetten tiltja ezt a képességet. Persze beleírhatják, mert a programozó egy driver beállítással előhozhatja, csak nem sok igény mutatkozik rá, hogy az IGP szétszemetelje az LLC-t. Az Ivy Bridge óta az Intel IGP-k tartalmaznak egy külön L3 gyorsítótárat, amelyet csak az IGP érhet el.
Ez egy kihasználatlan képesség a lapkában.
(#16514) geresics: A jelenlegi programokban kevés változás lesz. De a Win10 mindkettőnek segít.
A WDDM 2.0 bevezeti a virtuális memóriát a GPU-ra, tehát nyilván nagyságrendekkel javulni fog a fejlesztők lehetősége a VRAM kihasználására vonatkozóan. De ehhez WDDM 2.0-ra kell írni a programot.(#16516) miklosss2012: Az nem a Win10-től függ, hanem az API-tó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
nubreed
#16699
üzenetére
Nem nagyon tudják teljesíteni a rendeléseket. A sima Fury esetében még a partnereket sem tudják kiszolgálni. A Hynix még nem érte el a HBM ideális termelési szintjét, és ehhez még szükséges legalább két hónap. Nagyjából októberre normalizálódhat a helyzet, addig szerintem folyamatosan előrendeléseket kell rá leadni.
[ 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
#45185024
#16701
üzenetére
Ebben nincs semmi fura. Ha valaki HBM-et rendel, akkor kap 10-20 mintát a prototípushoz. Úgyis legalább egy év, mire valamit összeraknak ezzel a technológiával, tehát tömeges rendelésre maximum jövő ilyenkorra számít a Hynix.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Geresics
#16707
üzenetére
Semmi koncentráció nincs a következő évre. Azt kell megérteni, hogy a következő generáció hozzávetőleg másfél évre van. Nem csak 14 nm-re kell váltani, hanem HBM2-re, illetve 2 GHz-es interposereket kell stabilan támogatni, miközben az 1 GHz-es interposerek stabilitásával küzdünk. Hiába vannak meg maguk a lapkák, akkor is legalább egy év, mire hozzájuk igazítják az interposereket és a HBM2-t.
Ami most fontos volt az AMD-nek, hogy legyen egy VR-hez való rendszerük, mert Q1-ben jön a Rift, és senkinek sem volt VR-hez tervezett fejlesztése. A Fiji az első termék, ami tartalmazza a VR-hez szükséges alapokat. Azt pontosan tudja az mindenki, hogy HBM2-höz szükséges 2 GHz-es interposereket senki sem fog tömeggyártani 2016Q3 előtt. Ez volt a Fiji lényege.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
mackosajt
#16709
üzenetére
Nincs olyan kevés alkatrész hozzá, csak az igényeket nem tudják kielégíteni. De ettől technikailag tömeggyártásról beszélhetünk már a HBM kapcsán. Később jóval többet fognak belőle gyártani. Ahhoz, hogy a gyártás jobban felfusson szükséges egy kezdet, amit most a Fury X biztosít. És a növekvő igényekhez kiépülnek az új HBM gyártósorok, és ezek épülnek folyamatosan.
(#16712) DeckardCain: Érkezik, de nincs kőbe vésve az időpont. Mindkét esetben az NV-re vár az AMD. Az NV meg az AMD-re.
![;]](//cdn.rios.hu/dl/s/v1.gif)
[ 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
rocket
#16713
üzenetére
Ez nem ilyen egyszerű, főleg az interposerek miatt, amelyek nem mindegy, hogy milyenek. Az AMD is három opcióból választotta ki az UMC megoldását a Fijihez. És ez szándékos volt, mert nem igazán lehet előre eldönteni, hogy mi a jó választás. Nem is döntöttek, hanem a TSMC, a GloFo és az UMC is más interposert tervezett, és később választották ki a számukra jól működő megoldást. Ezt megtehették, mert a Fiji volt a pilot projekt az egész HBM-hez. Ez már az AMD-nek egy előny, mert tudják, hogy milyen interposerre van szükségük, de más ezt még nem tudja. Szóval a hátrányok mellett a korai váltásnak megvannak az előnyei is. Az AMD nyilvánvalóan egy gyártástechnológiai váltás kockázatai nélkül akarta letudni az amúgy is nagyon kockázatos interposer-HBM bevezetését.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Low-level API-val nincs driver optimalizáció. Amiről szó van, hogy a HLSL ext.=>AMDIL fordítóra az AMD már nem fordít figyelmet, így a CI ASIC és a VI ASIC ugyanazt az optimalizációt használja. Ez azt jelenti, hogy a CI és a VI ASIC teljesítménye megegyezik az AMD API-jával. Elméletben lehetne írni új HLSL ext.-et, ami esetleg kihasználhatóvá teszi a DPP-t vagy az SDWA-t, de ezt nem írja meg az AMD, mert OpenCL C++-ban úgyis kihasználható lesz, és akkor a saját API alatt is kidobható a HLSL ext.
Azt nem tudom, hogy ebből az információból hogyan lett végül a világ felé az kommunikálva, hogy a saját API-ra a támogatás megszűnik.
(#16715) gbors: Nem valószínű. Mivel mindegyik új hardver megjelenése leginkább az interposertől függ, így valszeg egyszerre rajtolnak jövőre az iskolakezdéskor.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Jövő ősz az nagyjából másfél év. Na jó egy és negyed.
Jellemzően a GPU-kat a Wipro vagy a Synapse csinálja. Egyikük sem jelzett FinFET GPU-t tape-outot.
Azt egyébként számold bele, hogy a Synapse a Fiji GPU-t 2013 októberében tapeoutolta ugyanakkor, amikor a Tonga-t. Viszont az interposer ezt az egészet megbolondítja, mert hiába adható ki a lapka mondjuk háromnegyed év múlva, az egyéb komponensei nincsenek készen. Logisztikai problémák is vannak, mivel eddig egy bérgyártó felelt az összerakásért a tokozásig. Mostantól kettő, vagy három fog. A Fiji is úgy készül, hogy a TSMC legyártja, és megy az UMC-hez a HBM-ekkel együtt. Az UMC rárakja az interposerre az egészet, és teszteli az összeköttetést és a tokozást. Majd megy a Hynixhoz memóriatesztelésre, ahol kész lesz.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
#16753
üzenetére
Csak akkor, ha HBM1-et használnak. Eleve a HBM2 kísérleti gyártása Q1-ben indul, és a tömeggyártás a 2 GHz-es interposerekkel nagyjából szinkronban Q2-re van tervezve. A fejlesztésnél is fontos, hogy végleges HBM2 mintákat leghamarabb októberben kap mindenki. Ezért szállítja a Hynix a végleges HBM1 mintákat most, mert nehéz nullá tapasztalatról HBM2-re ugrani. A kockázatoknál mérlegelni kell azt, hogy ha a HBM2 nulla tapasztalattal nem jön össze, akkor az konkrétan magával vonja a teljes tervezett termékskála eltörlését. A HBM2 már nem olyan pilot projekt dolog, mint a Fiji+HBM, hogy minden szükséges komponenst a teljes iparág csak egy konstrukcióra hegyez ki. Itt már tudni kell, hogy kinek milyen interposer struktúra milyen órajelen működik, főleg a korábbi tapasztalatokra építve.
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
#16770
üzenetére
A HBM2 abban nehezebb, hogy jóval magasabb órajelen működik, és az aktuális interposereknél a legnagyobb problémát az órajelszinkron jelenti. Ugyanis az interposer óriási kiterjedésű, és nem lehet hálós topológiával bevezetni az órajelet, mert a lapkával van szinkronban. Ergo az jelenti a problémát, hogy az interposer közepén már elkezdődhet a következő ciklus, amikor még az előző nem futott végig a lapkán. Ez órajelcsúszást eredményez és hibázhat a rendszer. Ezért fontos a jó interposer, akár 0,01 mm-es elhelyezési különbség dönthet a stabil és nem stabil termék között.
Ha 20+ nm-en jön, akkor lehet tesztcucc, mert a Wipro és a Synapse FinFET-re még nem tapeoutolt GPU-t. Gondolom a WCCFtech hozta le, mint abszolút jól értesült kicsit sem clickbait média.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- PNY GeForce Quadro RTX A2000 6GB GDDR6
- MSI GeForce RTX 3060 GAMING X 12GB GDRR6 192bit Videokártya!
- MSI GeForce RTX 3060 Ti GAMING X LHR 8GB GDDR6 256bit Videokártya!
- ASUS GeForce RTX 3060 12GB Dual V2 OC GDDR6 192bit Videokártya!
- Keresek Sapphire Radeon RX 6950 XT / RX 6900 XT Toxic Limited Edition
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen