Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31241
üzenetére
Ha megnézed itt a 4 GB-os kártyák jól érzik magukat, de a 3 GB-osak nem. Az AMD-nek pedig nincsenek már 3 GB-os VGA-i.
A Doom esetében sem volt máshogy. Az AMD-nél 1 GB volt a minimum, míg az NV-nél 2 GB. Sőt, Windows 7-tel 3 GB kellett a GeForce-ra. De aztán jött a dedikált allokáció és ez levitte a VRAM-igényt 1,5 GB-ra az NV-n.Már a Vulkan implementáción is látszik, hogy mennyire máshogy van rámappelve az NV az API-ra, szemben az AMD-vel.
AMD memtype implementáció:
Memory type 0
Heapindex 0
Flags DEVICE_LOCAL_BIT
Memory type 1
Heapindex 1
Flags HOST_VISIBLE_BIT
HOST_COHERENT_BIT
Memory type 2
Heapindex 2
Flags DEVICE_LOCAL_BIT
HOST_VISIBLE_BIT
HOST_COHERENT_BIT
Memory type 3
Heapindex 1
Flags HOST_VISIBLE_BIT
HOST_COHERENT_BIT
HOST_CACHED_BITNVIDIA memtype implementáció:
Memory type 0
Heapindex 1
Flags none
Memory type 1
Heapindex 1
Flags none
Memory type 2
Heapindex 1
Flags none
Memory type 3
Heapindex 1
Flags none
Memory type 4
Heapindex 1
Flags none
Memory type 5
Heapindex 1
Flags none
Memory type 6
Heapindex 1
Flags none
Memory type 7
Heapindex 0
Flags DEVICE_LOCAL_BIT
Memory type 8
Heapindex 0
Flags DEVICE_LOCAL_BIT
Memory type 9
Heapindex 1
Flags HOST_VISIBLE_BIT
HOST_COHERENT_BIT
Memory type 10
Heapindex 1
Flags HOST_VISIBLE_BIT
HOST_COHERENT_BIT
HOST_CACHED_BITMuszáj trükközni a program szintjén is, mert a Vulkan a memória kezelése szempontjából nem került módosításra a Mantle-höz képest, így utólag kell egy külön kiterjesztésben kezelni az erre vonatkozó potenciális problémákat.
Ha megnézed az id Doom Vulkan előadását, akkor ki van emelve, hogy voltak az NV-vel memóriakezelési gondjaik. Akkor még csak tesztszinten létezett a dedikált allokáció.
És ha lényegtelen lenne a memóriakezelés, akkor nem szarakodnának a dedikált allokációval, hanem hagynák az API-t rendeltetésszerűen működni, de ez már a Doomnál sem vált be.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31244
Abu85
HÁZIGAZDA
FollowTheORI
#31243
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#31243
üzenetére
Igen, csak ezek már nem kaphatók. De valóban, ezekre lehetett lőni.
Amúgy szerintem tök sokan félreértik ezt az egészet. Ahogy ez alakult az senkinek sem a hibája. Talán a Khronos felelős egy picit érte, de nekik kellett nagyon gyorsan egy API a D3D12-vel szemben és a Mantle pont jó volt. Talán átírhatták volna más részeit is nem csak a bekötést, de utólag ez már mindegy, viszont kiterjesztésekkel kezelhetők a problémák. Látszik a Wolf 2-n, hogy nagyon is jól, tehát nem reménytelenül GCN-orientált a Vulkan API, csak kell egy alternatív path a GeForce-okhoz. Látható, hogy az id is csinál két külön pathot a gyártókra, és ez nem akkora teher igazából. Ha már írnak 1000 sornyi menedzsmentet, igazán nem kézzsibbasztó meló még 50 sort beírni a dedikált allokációhoz. Nem véletlenül támogatja az id tech 6 (jó ez csak egy későbbi patch-csel) és 6.5 motor, de egyébként az AotS Vulkan módja is ilyen. Eltérő AMD-n és NV-n. Nem nagy meló a különbséget lekezelni programszinten.
Hosszabb távon pedig úgyis úgy fognak működni a hardverek, ahogy a GCN, és akkor a Khronos lesz a nagy előrelátó, mert ilyen memóriakezeléssel egyszerűbb lesz az élet. Ugyanígy a bekötés is nagyon kellemesen kiegészíthető bindless-re, tehát egyáltalán nem hülyeség, amit a Khronos csinál. Egy réteg járt csak rosszul, méghozzá a 3 GB-os 1060 tulajok, de most őszintén, eleve nagyon ajánlott volt azt a terméket 6 GB VRAM-mal venni.
[ 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
Locutus
#31245
üzenetére
Elég nagy tévedés. A Khronos Group egy nagyon nagy konzorcium, amelyben rengeteg cég és alapítvány van benne. Az AMD csak egy tag az ARB-ben, és pont annyi joguk van, mint az NV-nek, az Intelnek, az ARM-nak, az Imaginationnek, a Qualcomm-nak, stb. Amikor tehát egy cég számára úgymond kedvezőtlen döntések születnek, azokat az adott cég mindig jóváhagyja. Bár tudja, hogy rövidtávon kedvezőtlen, de ismeri már, hogy 2-3 év múlva milyen architektúrát fognak hozni, és ahhoz lehet, hogy a új modell a jó.
Annak sincs igazából jelentősége, hogy a Vulkan a Mantle-re épül. Ezt az ARB-ben mindenki jóváhagyta. Ráadásul ezek a döntések eleve nem többségi szavazósak, hanem mindenki beleegyezését igénylik.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31353
Abu85
HÁZIGAZDA
huskydog17
#31332
Abu85
HÁZIGAZDA
válasz
huskydog17
#31332
üzenetére
A Frostbite-nak is vannak különböző verziói. A Ghost még mindig a három éves alappal dolgozik, mert a Frostbite Team nem igazán törődik a szükséges versenyzésre írt modullal. Egyetlen egy játékért túl nagy erőfeszítés lenne minden motorverzióhoz portolni. Ráadásul nincs is különösebb haszna, mert arra a terhelésre, ami az NFS-hez kell, jó az öreg motor is. Például a Battlefront 2 Frostbite verziója sokkal modernebb. Abban már benne van az új tiled light trees eljárás, ami váltja a Half Z-t, bár teljes funkcionalitással a bétában még csak a DX12 alatt működött. DX11-re továbbra is egy speckó Half Z volt az alapértelmezett. Azt nem tudni, hogy a véglegesben hogyan alakul.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31355
Abu85
HÁZIGAZDA
huskydog17
#31336
Abu85
HÁZIGAZDA
válasz
huskydog17
#31336
üzenetére
A Bethesda igazából nem barátot keresett, hanem R&D partnert. Ők is azt akarják, amit az EA, hogy egy motor és sok játék, mert az összköltséget tekintve igen kellemes így fejleszteni, még akkor is, ha kell egy combos stúdió a motorhoz, de hát ott az id software. Amíg azonban az EA az R&D-t megoldja a SEED részleggel, addig a Bethesda ezt túl költségesnek tartja, és részben lepasszolja az AMD-nek. Ilyen formában azért hatékony fejleszteni, mert a Bethesda megcsinálja a kutatást, az AMD pedig megmondja, hogy azt hogyan érdemes implementálni, ráadásul úgy képesek megmondani, hogy az jó legyen a konzolokra is. Gyakorlatilag az egyik legdrágább részét az R&D-nek megosztják az AMD-vel. Ez azért vonatkozik csak az id tech 6+-ra, mert egyetlen korábbi motoron sem dolgozik már az id software.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#31392
üzenetére
Kukázni nem fogják, mert kell másra is, de például az Intel nem úgy gondol a dedikált GPU-kra, mint mások. Ők reagálni akarnak egy potenciális változásra, aminek a PCI Express eleve nem része, mivel nem memória-koherens az interfész. Ilyet fejleszt az Intel, az AMD-nek már van GMI-je, míg az NV-nek NVLinkje.
Utóbbi miatt nehezen tudják megölni az NV-t, mert ha az AMD és az Intel procijai már nem lesznek használhatók a számukra, akkor csinálnak a GPU mellé egy ARM-os saját procit. Még a Windows is telepíthető lenne rá, hiszen hamarosan ARM-os Qualcomm gépeken lesz ott a rendszer az ultramobil szinten. Tehát önmagában az az irány, amerre az AMD és az Intel elindult nem probléma az NV-nek. Megvan minden komponensük a követésükre.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31403
Abu85
HÁZIGAZDA
FollowTheORI
#31396
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#31396
üzenetére
Igazából lesz belőle desktop is, nem csak mobil megoldás a Kaby Lake-G.
Hosszabb távon a PCI Expressnek mindenképpen problémái lesznek. Nem véletlen lett ennyire a 4.0-ra tolva az 5.0. Ezekkel az új API-kkal, a különböző kísérleti technikákkal még a 4.0-s sávszél is rohadtul kevésnek tűnik. Emellett a PCI Express nem memória-koherens. De probléma ebből nincs, az AMD-nek és az NV-nek is van saját memória-koherens interfésze a PCI Express helyére, és az Intel csinálja a sajátját. Ráadásul ezeket is ki lehet vezetni foglalatba, csak nem lesznek kompatibilisek egymással.
Alternatív lehetőség a CCIX. Az egy szabványos memória-koherens interfész. De ezt például az Intel és az NV nem támogatja. 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
Raggie
#31404
üzenetére
Ha nem állnak be a CCIX mellé, hogy ezt a részt szabványosítsák, akkor igen, a gyártók keverése megszűnne. De még az sem biztos, hogy érdemes külön foglalatba kivezetni a GPU-t. Simán jobb ötletnek tűnik odarakni a CPU mellé ugyanabba a tokozásba, és akkor alacsony marad a rendszermemória elérésnek a késleltetése is a dedikált GPU számára.
Van még számos ötlet a tarsolyban. Az egyik ilyen a texel shading. Ez eleve teljesen függetlenítené a shadinget a raszterizálástól, tehát utóbbira jó lenne a tokozásban lévő GPU, míg a shadinget ki lehet helyezni egy PCI Express kapcsolaton beköthető gyorsítóra. Ilyen formában még a multi-GPU is baromira skálázódna, mert annyi szolgagyorsítót rakhatsz a rendszerbe, amennyi csak befér a házba.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
#31414
Abu85
HÁZIGAZDA
cskamacska
#31408
Abu85
HÁZIGAZDA
válasz
cskamacska
#31408
üzenetére
A gyártók már az implementációkat prezentálják, mivel a HSA specifikációi elkészültek. Mostantól a saját HSA implementációk kapják a marketinget. Lásd AMD ROCm. A Linux már támogatja.
Windows verzióhoz meg kell várni a Microsoft módosításait. Ezt célozza az Intel is az új divíziójával, amit vezet majd Raja. Nem a GPU-piac dGPU-kkal elérhető alig 20%-át akarják, hanem azt a potenciálisan nagyra hizlalható területet, amit a változásokkal meg lehet majd fogni.
Azokkal a szabványos modellekkel, amik készülnek nem feltétlenül szükséges a lapkaszintű integráció. Elég, ha a CPU és a GPU össze van kötve egy memóriakoherens interfésszel. Utóbbi lehet saját (GMI, NVLINK), vagy szabványos, lásd CCIX.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31415
Abu85
HÁZIGAZDA
cskamacska
#31411
Abu85
HÁZIGAZDA
válasz
cskamacska
#31411
üzenetére
Sajnos nagy innovációkat nehéz multiplatform szintre fejleszteni.
Elég sok PC-s innováció volt terítéken. Például signed distance fields ray tracing vagy voxel cone tracing. Ezek azért léteznek ma csak a PS4-en, és nem PC-n, mert nehéz a PC-n megoldani a problémákat.
A voxel cone tracingre példa a The Tomorrow Children. PC-n viszont eddig jutottunk el: [link] - statikus minden, mert az animáció rosszul viselkedik, illetve a VXGI csak egymenetes, szemben a Sony kétmenetes+szimulált megoldásával.
A signed distance fields ray tracingre már kellemesebb. PS4: Dreams ... multiplatform: ClayBook.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31417
Abu85
HÁZIGAZDA
cskamacska
#31416
Abu85
HÁZIGAZDA
válasz
cskamacska
#31416
üzenetére
A rombolhatóság most is jöhetne mainstreambe. Két dolog tartja igazán vissza. Egyrészt az Intel nem nagyon rakott pénzt a Havok újabb moduljainak PC-re portolásába, így sok régebbi fejlesztés még mindig PS4/X1 only. Másrészt, ahogy korábban is mondtam a rombolhatóságnál az AI beragadása komoly problémaforrás, és ezt rendkívül nehéz jól kezelni. Emiatt is gondolkodik a Microsoft a fizika szempontjából inkább a felhős megoldáson.
Az AI igazából már nem akkora probléma. Az explicit API-kkal rengeteg munka került le a CPU-ról, így egyre több erőforrás fogható be erre is. A GPU-s útkeresés persze egyfajta mass-AI-ra nem rossz, de itt teljesen reális megoldás lenne az aszinkron compute is, és az így számolt adat az n+1 frame-ben megjelenne.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31421
Abu85
HÁZIGAZDA
cskamacska
#31418
Abu85
HÁZIGAZDA
válasz
cskamacska
#31418
üzenetére
Egyáltalán nem állunk jól grafikailag. Inkább messze állunk az elvárhatótól. A voxel cone tracing se ray tracing.
Tudom, hogy sokszor linkeltem már, de érdemes ezt a részt megnézni, hogy miképp is zajlik a fejlesztés a programozói és a tervezési oldalról. [link] - igazából minden szava arany, mert hallod, hogy akarják a tervezők a fejlődést, de elmondja, hogy miért nem tud ezzel a fejlődéssel lépést tartani egy programozó.
(#31420) Raymond: A multis lövölde még nagyon speckó dolog is. Ott leszinkronizálni egy rakás változást eléggé nehézkes lenne. Akkor már fusson a felhőből, ahogy például a BF4-ben a víz hullámzása is úgy volt megoldva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Destiny 2 végleges verziója elég sokat változott a bétához képest. Ezért a korábbi béta profilok nagyon szarok lettek teljesítményben. Ezért tudott az AMD a 17.10.2-ben 43-50%-ot javítani a korábbi profilokhoz. Most az NV ugyanezt a váltást hozta, mert eddig a bétához írt profillal működött a játék náluk.
Tehát a megjelenés óta mindkét gyártó pumpált bele átlag 40%-nyi teljesítményt. Valószínűleg az NV-nek is kész lettek októberben az új rutinok, csak amíg az AMD-nél egy csapat írja a meghajtót, addig az NV-nél három részre van osztva a fejlesztés. Tehát előfordulhat, hogy úgy jön ki egy újítás, hogy annak a megjelenésig még két környi frissítést kell várnia a WHQL miatt, mielőtt megoldható a committelés.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ugyanez igaz az NV-nél is. A 3rd party programok náluk is generálnak hibákat, amelyeket javítgatni kell, lásd a legutolsó GeForce meghajtó erre vonatkozó, mikroakadásokat megszüntető javítása. Nem ez az oka annak, amiért az AMD elmegy ebbe az irányba, hanem az, hogy a DX12/Vulkan programokban az OSD felületek nem igazán működnek, és hiába próbálják ezeket kezelni külsőleg, az eredmény egyszerűen nem jó. Emiatt az AMD inkább integráltan kezdi el kezelni a problémát, mert egyre több programfejlesztő direkt olyan kódokat ír a programba, hogy a 3rd party OSD működését akadályozzák az újabb API-kkal. Viszont a meghajtó mögött ezt nem tudják befolyásolni, így a program oldali mesterséges korlátokat az AMD könnyen ki tudja kerülni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Micro-stuttering occurs in games when GPU monitoring tools are monitoring GPU power (“Power” monitoring enabled). [2016377] - [link]
(#31525) Dtomka: Emiatt nem szeretik a programfejlesztők ezeket az OSD-ket. Az UWP-s megoldás sokkal jobb, mert ott külön rétegen fut, így ha esetleg megpusztul, akkor csak a hozzá tartozó réteg pusztul vele. UWP-ben mindenki azt csinál, amit akar, kárt nem tud okozni egy 3rd party OSD. Maximum lefagy, megdöglik a hozzá tartozó réteg, de ezen kívül minden fut tovább. A Win32 ezzel szemben sokkal sérülékenyebb.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31543
Abu85
HÁZIGAZDA
Petykemano
#31538
Abu85
HÁZIGAZDA
válasz
Petykemano
#31538
üzenetére
A profilozó már be van építve a driverbe, ehhez szükséged van a Developer Panelre, hogy elindítsd a szervizfolyamatot. Utána működik a rendszer nyomkövetést támogató hardvereken. [link] - részletes videó a kipróbáláshoz.
Ha a Microsoft a primitive shadert implementálni akarja, akkor azt az API-ban tehetik meg. De ki kell dobniuk hozzá a vertex, domain és geometry shadert. A hull shadert pedig érdemes compute shaderrel kiváltani. Ez a legacy kompatibilitást eléggé megtörné, amit nem szerencsés eljátszani ilyen sűrűn. Persze nyilván a gpu-driven pipeline rendszerekhez sokkal jobban illik a primitive shader, mint a régebbi problémákra kitalál, de az új problémák kezelésére teljesen használhatatlan shader lépcső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
imi123
#31552
üzenetére
A primitive shader sokféleképpen használható. De ez még kialakulóban van. Az AMD első körben egy driveres megoldást fejleszt, ami egyszerűen a meglévő kódokat ismeri fel és primitive shaderbe fordítja. Ez korlátozott formában működik, mert az API mögött lehet ügyködni a meghajtóban. A második körös megoldás kérdéses, de nyilván vissza lehet hozni a Mantle API-t. Ezekért a lehetőségekért nem állították le a támogatását. Viszont ez csak akkor lesz visszahozva, ha a fejlesztők igénylik. Kisebb specifikus igények például teljesíthetők SPIR-V kiterjesztésből vagy AGS-ből - ha valakinek nem elég jó "a driver megcsinálja helyetted" opció.
A konzolhoz igazodik mindenki. A PC specifikus optimalizálása a fejlesztés nagyon késői szakaszában jön képbe.
Én amúgy nem tartanám jó ötletnek, ha a primitive shaderre új szabványos futószalag lenne felhúzva. Ez nem kiegészítés lenne, hanem alapvető reform. És ha már meglépünk egy ilyet szabványos szinten, akkor inkább az egyénileg definiálható shader lépcsők felé kellene menni.
[ 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
#45997568
#31554
üzenetére
Ezekből nem lesznek eladások. Ezek fejlesztőknek való technológiák.
Alapvetően az NGG pathból a user csak a teljesítményt fogja érezni. Mást nem igazán. A GPU-driven pipeline-ben utazó fejlesztőket viszont érdekelheti a dolog egy driveren túlnyúló megoldás formájában is. Csak kérdés, hogy mennyire nyúljon túl. Elég a kiterjesztés, vagy vissza kell hozni az AMD API-ját? Erre nem most lesz válasz. Valszeg megvizsgálják mindkét lehetőséget. Az API-nak annyi az előnye, hogy azzal gyakorlatilag teljesen átfogó megoldás készülhet a mostani futószalag lecserélésére, míg a kiterjesztés bizonyos specifikus igényekre bőven elég lehet.
[ 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
TTomax
#31572
üzenetére
Ez nem ilyen egyszerű. Alapvetően egyik teszt sem különb a másiknál. A probléma az, hogy rengeteg környezet valósítható meg VR alatt, így egy teszt nem tudja optimálisan visszaadni a hardverek teljesítményét. Emiatt a Futuremark csinált három félét. Az Orange a mai környezetre vonatkozik. A terhelés tipikusan olyan, amilyet egy mai átlagos VR játékban látsz, és itt az átlagos alatt nyilván ne a gagyikat nézd, hanem mondjuk például egy Serious Sam VR-szerű megoldást. A Blue tulajdonképpen ugyanazt a technológiát használja, mint az Orange, csak lényegesen több grafikai számítás történik benne, így azt próbálja megmutatni, hogy mire mész a mai környezetek mellett, ha a program grafikája az átlagosnál komplexebb. A Cyan teszt azért készült, mert a Futuremark azt is meg akarta mutatni, hogy mire képesek a hardverek azokkal a környezetekkel, amelyeket a mai VR játékok még nem használnak. Nem véletlen, hogy most jelent meg, ez tipikusan a Windows 10 MR platformjának a környezetét prezentálja. Persze ettől a VR runtime akármi lehet, de a Cyan tesztet a Microsoft VR koncepcióját figyelembe véve tervezték meg. Emiatt a Cyan room már lényeges hangsúlyt fektet a jelenetre is, nem csak a nyers grafikai dolgok számítanak benne, hanem a hardverekhez tartozó implementációk többletterhelése, a bekötés hatékony kezelése, stb. Tehát alapvetően a Cyan tesztben a hardver ereje mellett nagyon számít a D3D12-es meghajtó hatékonysága. Hosszabb távon valószínűleg nem lesz ekkora különbség az AMD és az NV között a Cyan tesztben, csak az AMD tudja, hogy nekik a D3D12 implementációjuk sokkal jobb, mint az NV-nek, és amíg az NV fel nem zárkózik, addig erre lehet teszteket mutogatni. Az eltérést valójában nem a hardver, hanem a driver okozza.
[ 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
Fred23
#31630
üzenetére
A driver nem segít rajta. Az 1.05-ös patch tartalmaz javításokat a különböző konfigokon előforduló mikroakadásokra (de a korábbi 1.04 is tartalmazott optimalizálásokat). Elméletben persze, mert valakinek ezek megszűntek, valakinek pedig eddig nem voltak és az 1.05-ös után lettek.
[link] - általánosan nem túl jók a tapasztalatok. Szinte mindenki küzd valamivel.
[ 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
Fred23
#31632
üzenetére
Teljesen mindegy a VGA típusa. Láthatod, hogy GeForce mellett is akad a fórumozóknak. A különbség az, hogy az egyes architektúrák máshol akadnak. De a jelenség teljesen általános. A wrapper okozza, amit az Ubi használ. Az NV és az AMD nem tud vele mit kezdeni. Annyit hallottam, hogy mindketten figyelmeztették az Ubit, hogy nem lesz jó, amit csinálnak, de az Intel volt a fejlesztői partner, és ők azt mondták, hogy működni fog. Ilyenkor nem az NV-re és az AMD-re fognak hallgatni, mert nekik eleve kevesebb rálátásuk volt a projektre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Rövid időn belül nem. Az alapprobléma nem olyan, hogy azt egy hónapon belül meg lehet oldani. Hosszabb időn belül bármi lehet, de a hosszabb időnél is olyan három hónapos távlatra gondolj minimum.
(#31642) RareParrot: Nem fut jobban.
(#31645) Dtomka: Ezekhez szerződések kellenek. Az AMD-t csak a Far Cry 5 érdekelte. A Microsoft komoly erőforrásokat tett az AC Originsbe, de ennek a hatásait csak Xbox One-okon láthatod. A PC-s verziókkal csak akkor törődik az MS, ha azok UWP-re jönnek.
Ott a Wolf 2. Az csak Vulkan, és nem véletlenül használ csak explicit API-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
korcsi
#31681
üzenetére
Mert nincs összefüggés. Akármilyen memóriával működik a HBCC, csak a külföldi fórumokon beszélnek össze-vissza.
Az AMD csak azért használ a HBCC-hez HBM2-t, mert ezzel elég csak egy vagy két HBM2 stacket vásárolni, ami olcsóbb és energiahatékonyabb, mintha vásárolnának hasonló sávszélességre 12-16 GDDR5(X) stacket. Amúgy semmi hátránya nem lenne az árán és a fogyasztásán kívül a GDDR5(X)-nek. Maximum annyi, hogy a NYÁK bonyolultsága jelentősen megnőne, de a HBM-nek ott az interposer, mint nehézség, tehát mindkét opció hasonló komplex, csak más területen.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31829
Abu85
HÁZIGAZDA
Petykemano
#31825
Abu85
HÁZIGAZDA
válasz
Petykemano
#31825
üzenetére
Semmi ilyesmi nincs. Az Radeon Vega Frontier Edition egyre kedveltebb a gépi tanuláshoz, mert a ROCm mellett egyre erősebb. Már sokkal veri a Titan Xp-t. Utóbbi pedig nem elég jó hardver, mert nagyon lassú FP16-ban, Tensor magja pedig nincs. Tehát aki ma olcsó gépi tanulásra kínált hardvert akar, annak egyedül a Radeon Vega Frontier Edition, vagy akár a pici consumer Vegák kínálnak 25+ TFLOPS-os teljesítményt. Ezt a tempót más hardver meg sem közelíti. A Titan V erre reagál csak. Nem véletlen az sem, hogy számítási teljesítményben hova érkezett: a top RX Vegára 0,1 TFLOPS-ot ver FP32-ben és FP16-ban.
[ 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
Locutus
#31831
üzenetére
Semmiféle hírforrás nem kell ide. A dolog egyértelmű. Az AMD-nek a ROCm csomagja nagyon gyorsan fejlődik, és egyre többen választják a Vegát gépi tanuláshoz. Hogy miért? Mert megközelítőleg sincs olyan relatíve olcsó és gyors hardver, ami 27,5 TFLOPS-ot leadna FP16-ban. A Titan V most képes 27,6 TFLOPS-ra, ami sokkal-sokkal-sokkal több, mint amit a korábbi Titan Xp tudott. És a gépi tanulás szempontjából a 3000 dollár relatíve olcsónak számít. Leginkább azért, mert a memória miatt úgyis a Frontierben gondolkodtak a "dezertőrök". A CUDA sem lényeges kötés már, a ROCm támogatja a HIP-en keresztül.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31838
üzenetére
Sokkal többen választják. A problémát az adja az NV számára, hogy a Tensorflow HIP konverziója pöcre ugyanolyan gyors, mint a CUDA kód. Csak amíg utóbbit nem tudod futtatni olyan hardveren, ami ~10 TFLOPS-nál többre képes, addig a HIP konverzió fut 25+ TFLOPS-os hardvereken is. És mit ad isten, az NV kihozott egy 25+ TFLOPS-os hardvert. Ha ezt nem tudjátok összerakni, akkor az nem az én gondom.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az lesz kiemelve a hírben. Hova készült és mit tud. És ha visszaolvasol egyedül én hoztam számokat, szóval rajtam számon kérni ezek hiányát finoman fogalmazva is vicces.
(#31840) Locutus: A tényeket nem lehet tálalni. Azok tények. Az már más kérdés, hogy mit képzeltek bele, de ez nem rám tartozik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem hiszem, hogy ez géming kártya. Azt írták páran, hogy az NV azért titkolja a ROP-ok számát, mert 48 van benne. Ezért sem esett szó a géming felhasználásról, csak a gépi tanulásról. Én próbáltam rákérdezni a ROP-ok számára, de csak az volt a válasz, hogy ez nem géming hardver, így ezek száma lényegtelen. Ez igazából megkerülése volt a kérdésnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az én lelkem nem bántja. Örülök neki, hogy van miről írni, és nektek lesz mire sivalkodni.
(#31845) ÁdiBá: Igen csak az a hardver marha drága. Van egy réteg, ami nem tudja megfizetni az annyira drága hardvert, így az NV és az AMD ide vezette be a Titan és a Frontier opciókat. Nem annyira durvák a terméktámogatásban, de elég jól működnek, és relatíve olcsók. Ez a réteg amúgy sem a Tesla vagy az Instinct verziót venné, hanem választana GeForce-ot és Radeont, ha nem lenne Titan és Frontier.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Miért törném magam azon, hogy provokáljalak titeket? Szimplán önmagatoktól képesek vagytok olyan dolgokat látni a hírekbe, amelyek benne sincsenek.
Láthatod most is. Szó se volt itt arról, hogy mennyire szuper a Vega. Egyszerűen csak leírtam, hogy picit gyorsabb nála FP16-ban a Titan V, és pont azért jött, mert a korábbi Titan Xp nem tudott 25+ TFLOPS-os FP16-os tempót felmutatni. Ebből a tényből sikerül azt leszűrni, hogy mennyire szuper a Vega. Ez itt a szövegértelmezési problémát tipikus esete, amit "provokációzással" palástoltok.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pontosan.
És akkor tételesen. HIP-re van ugyanolyan gyors Tensorflow, mint a CUDA-ra. Dedukcióban egy Vega tud neked adni ~25 TFLOPS-ot, míg egy Titan Xp ~10 TFLOPS-ot. Miért is éri meg a Titan Xp-t, ha az alternatívája két és félszer gyorsabb és nincs szoftveres hátránya?
Most pedig jött a Titan V, ami már képes ~25 TFLOPS-ra, sőt igazából többre is, erről majd a hírben, tehát ez már egy nagyon is megfontolandó alternatíva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31856
Abu85
HÁZIGAZDA
Petykemano
#31854
Abu85
HÁZIGAZDA
válasz
Petykemano
#31854
üzenetére
Igazából a ROCm nem akarja áttörni a CUDA-t. Ennek a konstrukciónak a CUDA egy fontos eleme, amivel fel tudják használni az AMD GPU-kra az eddig megírt CUDA kódokat. Emiatt van az, hogy az AMD manapság nem arról beszél, hogy a CUDA rossz, annak mennie kell, hanem arról, hogy a CUDA az jó, használjátok a HIP-en keresztül, és tudjátok célozni az NV, illetve az AMD hardvereit. A CUDA tehát ma a stratégia része lett, amit még reklámoznak is, mert már megvan az eszköz (HIPify), amivel ezeket a kódokat lehet futtatni a saját GPU-ikon.
[link] - itt bővebben beszélnek a CUDA-HIP kapcsolatáról.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31877
Abu85
HÁZIGAZDA
Petykemano
#31867
Abu85
HÁZIGAZDA
válasz
Petykemano
#31867
üzenetére
Sokkal olcsóbb. Ennyi. Az Mi25-nek is megvan az előnye, ahogy a Teslának is, de például az egyedi support előnye egy csomó potenciális vásárlónak nem kell, ezért jobb nekik a Titan és a Frontier.
(#31874) Petykemano: Kiderült már, hogy a Wolf 2-ben működnek. Nem általános, hanem per game alapú jelenleg a profilozás.
Csodadriver egyébként nem létezik. Ezek nem csodák.(#31876) Szaby59: Relax, az Adrenalin meghajtóval nem fogod megnyitni a vezérlőpultot. Majd az ágyból átállítod, amit szeretnél.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az FE és a referencia RX verzió az ugyanaz. Két külön partner tokozza a GPU-t és a memóriát, de ugyanaz a hardver. Időközben már lett egy harmadik cég is, aki beszállt a tokozásba, de ők csak az Apple rendeléseit szolgálják ki. Utóbbi miatt lassan tényleg utoléri majd a kínálat a keresletet. A referenciák gyártását is leállítják, hogy minden lapka+memória mehessen a custom modellekre.
Most azzal a harmadik partnerrel jóval többet gyártanak a tervezetthez képest. Eredetileg úgy tervezték, hogy az Apple igényit is ki tudják majd szolgálni két tokozó partnerrel. Emiatt csúszik az iMac Pro hivatalos bejelentése, de persze az sem segít, hogy az Apple sokat kér, első batch-re mindig szokásuk nagy készletet rendelni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Leginkább az a baj, hogy nagyon sok piacra megy a Vega 10. Ott a gamer, ott a félprofesszionális, ott a szerver, ott a professzionális, ahol ráadásul van az SSG, ami ugye pont egy olyan dolog, amire a filmkészítők nagyon buknak, mert 2 TB memóriába már elég sok adat belefér, így nem kell darabjaira szabdalni a tartalmat a vizualizáláshoz. És akkor még ott az Apple, aki adná ki az iMac Prót. Ez az egész egyébként tisztán az AMD hibája. Egyszerűen elszámolták magukat az igényekkel kapcsolatban, és amikor nagyobb az igény, mint amennyire számítottak, akkor az már eleve egy hátrányos helyzet, mert lassan lehet rá reagálni. Sokkal célszerűbb lett volna a professzionális modellek kiadását csúsztatni, de persze gondolom kellett a Project 47-be is a hardver, tehát belekergették magukat ebbe az ellátási problémába. És hiába hoznak be egy harmadik partnert a tokozásra, az is jó két hónap, mire ténylegesen tudja éreztetni a nagyobb kapacitást. Jobban ki kellett volna számolni, hogy mik a piac igényei.
[ 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
s.bala31
#31910
üzenetére
Az Intel nem akar VGA-kat. Nekik nem elég nagy a piac. A jelentős részét le tudják fedni IGP-vel, vagy CPU-val közös tokozású GPU-val. A többi terület túl pici. A GPGPU-val sem tudnak mit kezdeni. Van helyette FPGA, AI-ra pedig speciális fejlesztés jön.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#31911
üzenetére
A Samsungnak ez nagyon kockázatos lenne. Egyrészt nem lenne olcsó, másrészt az Intelt már nem köti az FTC arra, hogy legyen elég PCI Express csatorna a VGA-knak. Az AMD magának úgyis megoldja, de ha nekik sem fűződik érdekük hozzá, akkor áttérnek GMI-re.
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
#31917
üzenetére
Nem a VGA-kra. Az Intel csak reagálni akar egy eseményre. A PCI Express egyre korlátozóbb lesz és a Microsoft már dolgozik egy olyan strukturális átalakításon a Windowst érintően, ami gyakorlatilag megszünteti azt, hogy a GPU kernelek csak rendszerhívásokon keresztül legyenek futtathatók. Ergo a GPU a CPU-val közös logikai szintre kerül, és ha ezt egy gyors memóriakoherens interfésszel be tudják kötni a CPU mellé, akkor az új konfiguráció tökéletesen megfelel a Microsoft új irányának. Raja ezért ment oda, mert ő igazából már részt vett ilyen projektekben, és persze ismeri az AMD hardvereit, addig amíg az Intelnek nem lesz sajátja a CPU mellé a tokozásba. Az Intel VGA-kat nem akar, ezt nem is értékelik jövőképnek (a teljes piac 90%-a lefedhető nélkülük), de mondjuk a zárt vagy nyitott, memóriakoherens interfészen bekötött GPU a CPU-val közös tokozásban már igen kedvező jövőkép számukra. Nem beszélve, hogy tudják, hogy az AMD is erre megy, elvégre ott van nekik a GMI, az Infinity Fabric, a HBCC, mind-mind olyan technológia, ami erre való. És az Intelnek mindene megvan ahhoz, hogy ezeket lemásolják, és kövessék az irányt, csupán kellett egy szakember, aki ezt le tudja vezényelni. Nyilván első körben puhatolózással, de 4-5 év múlva úgyis lesz saját hardverük.
Azt nem tudni, hogy ebben a jövőképben a PCI Express-es VGA-knak milyen szerep jut. Simán elképzelhető, hogy az Intel és az AMD úgy dönt, hogy nincs tovább, és lelövik az egész VGA-piacot. Persze sokkal valószínűbb, hogy valami alternatív irányt dolgoznak ki, mert a VGA-k azért gyorsak, még akkor is, ha buták. Tehát például lehet olyan opciót kidolgozni, hogy a Microsoft vagy a Khronos csinál egy olyan specifikációt, amivel az árnyalást általánosan átrakják az objektumtérbe, és ekkor magát az árnyalási feladatokat a VGA-k még el tudják végezni, ráadásul ilyen modellel akár 2-3-4-5-6... VGA-t is beköthetsz, azok skálázódni fognak. A többi feladatot pedig elvégzi a CPU melletti GPU.Aztán egyébként az is lehet még, hogy az Intel, az AMD és az NV megegyezik arról, hogy a PCI Express helyett csináljanak egy új csatolót a nyílt CCIX-re építve, de ettől nagyon messze állunk, mert az NV a saját NVLinkjét erőltetné, de az Intelnek ez nem kell, sőt a Intelnek az lenne a jó, ha a PCI Express helyett nem jönne semmi, mert az fájna leginkább a VGA-knak, amit ugye ők nem is gyártanak. Az AMD érdekei is igazából az NV szívatásához fűződnek, tehát ők se biztos, hogy egy ilyen egyezményt támogatnának.
[ 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
Habugi
#31949
üzenetére
Egy éve az AMD kiadott egy új API-t, amin keresztül ezek működnek. Na most a régi API-ra a támogatás megszűnt. Ezáltal a 3rd party programfejlesztőknek át kellene térni az új API-ra, mert a régi API bizonyos funkciói már nem találhatók meg a meghajtóban, vagy nem jól lesznek ezek lereagálva. A 3rd party programfejlesztők pedig sírnak, hogy ezekre áttérni nekik drága, mert az rendben van, hogy az új hardvereknél ezt muszáj, de a régieknél is újra kell írni mindent, ráadásul egyre kevesebb pénzt kapnak a gyártóktól is, hogy ezeket a programokat fejlesszék, mert egyre inkább gyári szintre emeli a felkínált szolgáltatásokat az AMD, ami a gyártóknak jobb, mert nem garázspista írja, hanem egy garanciát vállaló cég. Szóval itt ütköznek a dolgok. A gyártók nem adnak már elég pénzt a garázspistáknak, akik elég pénz nélkül nem akarnak dolgozni.
[ 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
Habugi
#31952
üzenetére
Szegény kicsi Unwinder, csak neki nem sikerült megoldania, a Sapphire az ASUS, az XFX, mindenki sikeresen átállt.
Elmorzsoltam egy könnycseppet a hatalmas erőfeszítéseiért. 
Respect neki, hogy néha ránéz, ha már a többiek támogatják. Az egészhez biztos nem volt semmi köze annak, hogy az MSI másik tuningappot fejlesztett az Afterburner mellé (amiben meglepetésre szintén megoldották a támogatást), így az After felé csúnyán elzárták a pénzcsapot.
[ 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
Raggie
#31957
üzenetére
A gyártók többi tuningappja. Mindegyik verzió már az új API-t használja. Elvégre a régit a második generációs Polaris, illetve Vega nem is támogatja, tehát ezek nem is lennének tuningolhatók egy külső programból az új API nélkül. A régi API-val hiába állítgatsz bármit, a meghajtó nem tudja értelmezni az adatokat.
Az egész mögött pénz húzódik. A gyártók számára az AMD új API-ja azért jó, mert egy csomó dolgot az AMD elvégez helyettük, így ők csak beletenyereltetik magukat a tutiba egy saját külső programmal. Ergo nincs többé szükségük például Unwinderre, vagy a többi ma még fizetett fejlesztőre, mert az AMD megcsinálja a munkájukat ingyen, és erre még gyártói garanciát is vállalnak. De persze csodálkozunk, hogy Unwinder nem kompatibilis egy olyan új API-val, ami hosszabb távon megszünteti a munkahelyét. Azért néha ránéz na.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Muszáj az új API-t használniuk, mert másképp nem lehetne 2nd gen Polarist és Vegát tuningolni.
Egyébként a probléma alapvetően az, hogy az új API sokban különbözik. Már maga az alapkoncepció más. Az AMD egyszerűen felkínál lehetőségeket a programnak, hogy hívja meg a meghajtó egyes funkcióit. Ezek ugye be vannak építve a Wattmanba. Az új API ilyen formában egy olyan megoldás, amivel a gyártók fel tudnak húzni egy alternatív felületet a Wattmanra. Na most nyilván a régi API-ra írt programokat erre lehetetlen portolni, mert az jóval komplexebb volt, nem csak abból állt, hogy a driverben már kész van az alapszolgáltatás, amire kvázi elég csak egy másik UI-t húzni, illetve betáplálni a megengedett paramétereket. Aki a régi kódját akarja portolni el fog bukni, de megértem, hogy egy csomó programozó ebből a régi kódból él, mert ezért fizet nekik xy gyártó, akiknek nincs okuk többet fizetni, ha már csak egy UI-t kell felhúzni.
[ 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
Habugi
#31963
üzenetére
Én már az egész alapproblémát nem értem. A gyártók biztosítanak egy meghajtót a hardverhez, ami megenged maga mellé bizonyos 3rd party programokat bizonyos funkciókra. Ezt a lehetőséget támogatják bizonyos API-kkal. Viszont nem vállalnak garanciát azért, hogy a 3rd party program működik, mert nem ők írták őket. De ők a hibásak, amiért xy 3rd party program nem működik. Ráadásul tuningprogram, ami eleve nem arra való, hogy stabil alapot adjon.
Én alapvetően csodálkozom azon, amikor hallom az OEM csatornákról, hogy az AMD és az NV is nagyon ki akarja végezni az Afterburnert. De a fentiek alapján már értem, hogy miért. Más hibájáért nem akarják a felelősséget vállalni. Elmagyarázni pedig nem tudják az embereknek, hogy az Afterburnerre nem vállalnak garanciá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
Raggie
#31966
üzenetére
Nekik nem ez a problémájuk. Ha ez lenne, akkor nem kínálnának gyári szinten tuningfelületet feszültségemeléssel.
A probléma az, hogy xy felhasználó használja az Afterburnert, amivel hibája van, és megírja az adott gyártó supportra, mert az Afterburner supportjára nem lehet, elvégre olyanja ennek a programnak nincs is. Innentől kezdve leesik zw hónapos szinten úgy százezer hiba erre vonatkozóan, aminek kb. az 1%-a adódik a meghajtó oldaláról, de mindet ki kell vizsgálni, elvégre a hiba beérkezésekor még nem tudni, hogy hol a gond. Vagyis az AMD-nek és az NV-nek nem azzal van a baja, hogy ez a program létezik, hanem azzal, hogy már a program létezése is havi szinten elképesztően magas tesztelési költségekbe kerül nekik a hibabejelentések kivizsgálása miatt.
A Sapphire Trixx és az EVGA Precision például azért nem annyira fájdalmas az AMD-nek és az NV-nek, mert ezekre a Sapphire és az EVGA saját supportot tart fent. Van saját hivatalos csatornája, és nem egy Unwindernek kell/lehet írni a Guru3D fórumára.
Semmi probléma nem lenne, ha az MSI felvállalná az Afterburner supportot, belerakná a szükséges pénz abba, hogy a felhasználók panaszainak legyen hivatalos helye, hivatalos formája, nem a Guru3D-n, vagy a világ egy másik eldugott fórumában... na meg legyen egy csapat, ami elvégzi a tesztelést a panaszokra. Ja, hogy úgy egy nullát hozzá kellene írni a költségekhez... az már nem tetszik, jó a Guru3D 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
Raggie
#31974
üzenetére
De jól, csak a drága user ettől még panaszkodik, és még véletlenül sem említik meg a support ticketben, hogy tuningolnak.
Innentől kezdve az esetet ki fogják vizsgálni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Attól, hogy fut egy 3rd party program még nem szabad hibát generálnia. Ezért ellenőrzik le. Viszont az NV és az AMD addig tud eljutni, hogy kiderítik a hiba okát. Ha van és nem náluk van, akkor például a Trixxnél van support, megy a ticket a Sapphire-nak, a Precisionnál megy a ticket az EVGA-nak. Az Afterburnernél nincs hova ticketezni. Van a Guru3D fórum, ami közösségiként működik.
Nem sok érdek van emögött. Amíg a Sapphire és az EVGA úgy gondolja, hogy megéri a programjaik mögé annyi pénzt rakni, hogy legyen hivatalos support, addig az MSI úgy gondolja, hogy nem. Nem nyernének vele annyit, hogy megérje. Igazából a Sapphire és az EVGA számára is csak a kiemelt státusz miatt éri meg.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az Apple mindenképpen így tervezte, de az AMD valószínűleg nem gondolta azt a nyáron, hogy be kell állítani egy harmadik tokozóüzemet is, hogy majd decemberben egyáltalán ki tudják szolgálni az Apple-t. Valószínűleg úgy számoltak, hogy két partner is tud majd elég Vega 10-et gyártani. Ez lehet, hogy az iMac Pro esetében nem érezteti a hatását, mert elég nagy megrendelő ahhoz az Apple, hogy az AMD ne packázzon velük, de más területeken visszavágta a terveket, lásd az egyedi Vegák.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Elmorzsoltam egy könnycseppet a hatalmas erőfeszítéseiért. 
Respect neki, hogy néha ránéz, ha már a többiek támogatják. 
Ú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!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Call of Duty: Warzone
- Fűnyíró topik
- Mibe tegyem a megtakarításaimat?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Olasz autó topik (Fiat, Lancia, Alfa)
- Mit tehetsz jogilag, ha átvertek, megkárosítottak a Hardveraprón?
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Autós topik
- Vezetékes FEJhallgatók
- Kupon kunyeráló
- További aktív témák...
- Eladó bontatlan AMD Ryzen 7 7800X3D processzor
- Új bontatlan Sandisk Ultra 3d SSD 4TB és Samsung 2.5 870 Evo 500GB SATA3 (MZ-77E500B)
- AkciÓ ÚJ Bontatlan MacBook Pro 16 M3 Pro 12CPU/18GPU 18GB/512GB SSD Magyar bill Azonnal átvehető.
- ÉRKEZETT Bontatlan Új M2 M4 IPAD PRO 2022 11 128GB - 256GB Wi-Fi Azonnal Deák Térnél Átvehető.
- DeLL Precision 7740 workstation, üzletből, I7-9850H/32RAM/512GBSSD/NVIDIA QuadroRTX3000/17,3"FULLHD