Hirdetés

Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz gejala #55158 üzenetére

    A problémát a konzolok jelentik. Most egy rakás erőforrás áll rendelkezésre next-gen fizikát és AI-t csinálni. Ezt ki is fogják használni, és ha erre lövi az erőforrásait a proci, akkor kevesebb marad a rajzolási parancsoknak, amik kezelése eleve sokkal drágább PC-n. Még az explicit API-kkal is, mert a konzoloknak van egy tényleg nagyon low-level rétegük, ahol egy rajzolási parancs nem több három DWORD-nél.

    Plusz ugye amíg nincs PC-s DirectStorage, addig a tartalomkikódolás is a procit terheli, ellentétben a konzolokkal, amelyeknek erre dedikált erőforrásuk van.

    [ 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 KillerKollar #55160 üzenetére

    Csak jelzem, hogy az Ubisoft sebességnövelésre használja a ray-tracinget. Tehát az egyes RT eljárások aktiválásától pont, hogy nagyobb lesz náluk az fps. Ez is benne lehet egyébként az eredményekben, hogy az Ubi elsődlegesen onnan közelít, hogy mit lehet gyorsabban megcsinálni RT-vel, amivel a hagyományos raszterizálás túl lassú.

    [ 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 gejala #55162 üzenetére

    Attól még a tartalomkikódolás tekintetében a hátrány ott lesz a PC-n. A két új konzolon erre dedikált hardver van. PC-n pedig semmi. Vannak a procimagok és kész, amíg meg nem érkezik a DirectStorage for Windows. És azért a konzolok dedikált egységeit konkrétan több maggal lehet helyettesíteni, ráadásul kellenek magok a jelenetszámításra is.

    A fentiek miatt tök felesleges új VGA-kat várni a PC-s DirectStorage előtt. Egyszerűen túl rosszak a körülmények, hogy bármit is érdemes legyen kiadni.

    [ 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. #55167 üzenetére

    Az FSR működni fog mindenen, ami legalább compute shader 5.0-t és DirectML-t támogat. Szóval ez nem nagy dolog. Kb. az elmúlt tíz év összes hardverével kompatibilis, csak Windows 10 kell hozzá.

    [ 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 Callisto #55170 üzenetére

    Az FSR GPU-n fut. Az összes komponense. Némelyik kód DirectML-en, némelyik pedig DirectCompute-on.

    A fő különbség a DLSS-hez képest az lesz, hogy linear és non-linear networkkel is egyszerre dolgozik az FSR. A DLSS csak linear networköt használ.

    Funkcionálisan akármilyen, fenti szabványokat teljesítő GPU megfelel, de hozzá kell tenni, hogy az már hardvertől függ, hogy a két network párhuzamosan lefuttatható-e egymás mellett. Valamekkora hardverigénye ennek azért van, és nyilván az a jó, ha lemehet a két feladat egyszerre, de lemegy ez sorban is, ha a hardver nem alkalmaz a párhuzamos munkavégzésre.

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

  • Abu85

    HÁZIGAZDA

    válasz Callisto #55172 üzenetére

    Teljesen GPU-n fut.

    Azért erősödik a CPU-limit a felskálázásnál, mert kisebb felbontáson számol a GPU. Tehát a kisebb felbontás limitjei jelentkeznek, nem pedig a skálázott felbontásé. :)

    Manapság 1080p-ben is könnyű CPU-limitbe futni, főleg akkor, ha nincs Ryzen 9 5950X-ed.

    [ 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 #55174 üzenetére

    DirectStorage nélkül? Hát kelleni fog mag rendesen. ;]

    A Khronos Groupot kell ébresztgetni az álmából, hogy hozzanak valami hasonló megoldást, vagy legalább interoperabilitást. :)

    [ 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 Busterftw #55200 üzenetére

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

  • Abu85

    HÁZIGAZDA

    [link] - Ez kellemes nyári napnak tűnik.

    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 #55264 üzenetére

    Az RDNA-n kívül nincs olyan hardver, ami képes párhuzamosan futtatni a linear és non-linear pipeline-t. Ezek a képességek a hardverben vannak benne, és a régi hardverekbe nem tudják belevarázsolni. Akkor sem, ha megemlítik a listá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 GeryFlash #55266 üzenetére

    Semmi. De mint írtam, ha minden GPU-t felsorolnának, ami támogatja a shader modell 5.0-t, akkor még a Radeon HD 5000 is benne lenne, ami lassan 13 éves.

    5 évig visszamenőleg érdekes ezekről adatokat gyűjteni, mert 5 éves gépeket nem biztos, hogy PC-re cserél az illető. Ők pedig adatokat akarnak, hogy 5 éven belüli VGA-kat milyen arányban használnak.

    Igazából az a kérdés, hogy miért zavar bárkit, hogy kihagyták az őskövület GPU-ját. Futni fog rajta? Igen, hiszen a shader modell 5.0-t azért már 10 éve is támogatták a hardverek. De az AMD-t nem érdekli, ha valaki 5 évnél idősebb VGA-t használ. Nincs információértéke számukra.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    Ne legyen már ez ovi. Tudjátok, hogy mely GPU-k támogatnak shader modell 5.0-t? Na ezek vannak támogatva.
    És ez nem elvárási kérdés. Maga a shader tartalmaz DirectCompute 5 és DirectML kódot. Tehát lófaszt sem számít a GPU kódneve, az számít, hogy van-e hozzá olyan fordító, ami shader modell 5.0-s kódot felismer. Értsd ezalatt, hogy olyan kódokat, amilyeneket a DirectX 11-es játékok használtak. Ha ez megvan, akkor le se szarja a program, hogy min futtatod, meg se fogja nézni.

    Az AMD abban az igényfelmérős oldalon arra kíváncsi, hogy az igényt leadó felhasználók között ki milyen VGA-t használ. Leszarják, hogy ha valaki RX 400-at, de az érdekli őket, hogy ha GTX 1000-et.
    A többit bepakolták otherbe, mert nem lényeges információ számukra. Ettől futtatják a kódot, de olyan különösebben nem érdekes a statisztikájukhoz.

    #55268 b. : Ez nem hajcihő, hanem a sírás a szaktudás teljes hiánya miatt. Borzasztóan könnyű kideríteni a Google-lel, hogy a gépben lévő hardver támogat-e shader modell 5.0-t, amit egyébként a DirectX 11 vezetett be. Ha igen, akkor mi a gond? ...hogy nem szerepel egy kérdőív válaszai között? :))First World problem. :))

    [ 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 #32839680 #55279 üzenetére

    A G-Sync teljesen rossz hasonlat. Ahhoz kellett egy külön hardver, ami drága volt, és a monitorgyártók döntő többsége sem volt hajlandó beépíteni. Ma már egyedül az ASUS és az Acer csinál, de 1500 dollár fölé terveznek csak új, klasszikus G-Sync monitort, mert alatta nem éri meg. Egy idő múlva ide sem fognak, mert lassan az NV-nek sem éri meg két évente négy új monitorért egy rakás pénzt költeni. Egyszerűen nem termelhető vissza a befektetés.

    Ezzel szemben a DLSS és az FSR is csak szoftver. Nem igényel egyik sem speciális hardvert. Nem függ egyik jövője sem attól, hogy egy gyártó azt mondja, hogy hajlandó kétezer dollár körül kihányni valami kompatibilis szutykot kétévente.

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

  • Abu85

    HÁZIGAZDA

    válasz Alogonomus #55284 üzenetére

    Csak ebben még a legelső modul van, ami egy rakás dolgot nem tudott. Például skálázni sem. :) Azért 500 dollárért majdnem tíz éves hardvert nem látom nagy biznisznek.

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

  • Abu85

    HÁZIGAZDA

    válasz #32839680 #55287 üzenetére

    Több NN-t is futtat az FSR, de nem kell hozzá tréningezni a fejlesztőnek.

    #55286 csako : Kétféle G-Sync hardver van. Az egyik ami még 2011 körül jelent meg, az a sima G-Sync, és azt ma is árulja az NV. Rengeteg limittel, de nem éri meg újat tervezni. A másik a G-Sync Ultimate-hez való, ez már ASIC, de szintén elég régi, és az új verzióinak a fejlesztését lelőtték, mert nem termeli vissza a befektetett pénzt. Tehát ezekhez a G-Sync-ekhez kell egy NV-től származó modul, de ezek jobb esetben is több évesek.

    Volt egy harmadik G-Sync fejlesztés, ami sosem készült el. Ez lett volna a válasz az AMD-féle HDR-es Freesync Premium Próra, de lelőtték a picsába miután a G-Sync Ultimate sem hozta vissza a befektetett pénzt.

    Jelen pillanatban a normál G-Sync vegetál több éve tervezett modulokkal. Olyanba nincs értelme még az NV-nek sem pénzt fektetni, ami igazából nem eladható. A már létező hardvereket árulják és ennyi.

    #55290 Yutani : A GTX 1060 nem tudja ultra quality-ben sokkal gyorsabban futtatni azt a játékot, mint a natív számítás.
    A sebességnövekedés mértéke négy tényezőtől függ az FSR-nél:
    - CPU-limites lesz-e a GPU kisebb felbontáson (általában a GeForce-ok valamennyire azok, ha nem raksz alá Ryzen 9 5950X-et)
    - párhuzamosan futtatja-e a GPU a két felskálázó pipeline-t (a GeForce-ok nem tudják ezt, de a GCN-es Radeonok sem)
    - mennyire alacsony pontosságú a dedukció a GPU-n (a régi hardverek Int32-re kényszerülnek, ami úgy 8x lassabb, mint az RDNA 2 Int4-je)
    - el lehet-e végezni az NN feldolgozását lapkán belül (bitang nagy gyorsítótár nélkül nem ... hint: Infinity Cache előny)

    Emiatt van az, hogy egy RDNA2-es Radeon RX 6800 százalékosan jóval többet gyorsul még ultra quality mellett is, mint az a régi GeForce szimpla quality-ben. Ugyan az FSR szoftver, de bizony képes nagy előnyt kovácsolni a sok gyorsítótárból, az aszinkron compute-ból, az RDNA2 NN-re tervezett operációiból, meg pusztán abból, hogy DirectX 12-ben a Radeonok jóval kisebb többletterheléssel működnek, ami 1440p fölött nem jön ki, de 1080p-ben és alatta bőven mérhető.

    [ 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. #55297 üzenetére

    De az megvan, hogy a quality mode a közepes minőségi szint? :D

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

  • Abu85

    HÁZIGAZDA

    válasz GeryFlash #55300 üzenetére

    Egyrészt alkalmaz neuronhálót, másrészt itt a maximális minőségi szint: [link]

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

  • Abu85

    HÁZIGAZDA

    válasz #32839680 #55302 üzenetére

    A motion blur az Epic grafikai preset része annál a játéknál. Ha kikapcsolod, akkor az custom grafikai preset lesz. Ezzel nehezebben reprodukálható a tesztkörnyezet.

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

  • Abu85

    HÁZIGAZDA

    válasz killbull #55304 üzenetére

    Csak a saját nevedben beszélj. Van aki már élőzheti. :D

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

  • Abu85

    HÁZIGAZDA

    válasz killbull #55307 üzenetére

    Gondolod már nem tesztelheti a média? :))

    Írni amúgy nem lehet róla.

    Ellenben nemrég elküldték, hogy raktak fel egy videót a Youtube-ra. Mindenki megnézheti, hogy 4K-ban mit megy az Ultra Quality: [link]

    #55308 killbull : Ebben a szövegben rengeteg tárgyi tévedés van. Az FSR alkalmaz neuronhálót. Majd később erről bővebben beszélnek.

    A Resizable BAR nem egyenlő a Smart Access Memory technológiával. A Smart Access Memory egy implementáció a Resizable BAR feature-re, de pont azért látsz az AMD-nél sokszor sebességnövekedést, míg az NV-nél sokszor nem, mert nem ugyanaz a két technológia: [link]

    [ 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 killbull #55310 üzenetére

    Mert nincs is. Az AMD csak megosztotta az adatokat.

    Ha nem számítjuk az Infinity Cache-t, az új parancsmotort, az NN operációkat, az új geometriai motort, az új ROP blokkot, az új textúrázókat, és az új részegységeket, akkor valóban nem több az RDNA 2 az RDNA-nál egy nagyobb órajelű variánsnál, de ez mindenre ráhúzható, ha az újdonságokat direkt kihagyod. :D

    #55311 killbull : Senki se mondta, hogy normális, ha 32-szálas proci kell, de némelyik játéknak előnye származik belőle.
    Leginkább oda kell a sok szál, hogy a tartalmat kikódold. Amíg a DirectStorage be nem jön, addig az ilyen Unreal Engine 5-höz hasonló rendszerek borzasztóan magzabálok lesznek. Nem véletlen, hogy az Epic 12 magot ad meg minimumnak, amin egyáltalán megéri kipróbálni. Egyébként 64 magig skálázódik, 32-48 maggal már egészen jó teljesítményt lehet kapni. Ahogy jön a DirectStorage, illetve optimalizál az Epic, úgy ez csökkenni fog. Mire érkeznek az első UE5-ös játékok, addigra 2022-t írunk, és jövőre az AMD nem is tervez nyolc magnál kevesebbet az 5 nm-es procijaikba. Tehát a 8 mag lehet, hogy ma még sok, de jövő év végén már budget lesz.

    #55312 b. : Egyáltalán nem fos a G-Sync, csak mivel nem raknak mögé pénzt, így nem is fejlesztik a hardvert. Az ne várd, hogy amibe nem invesztálsz, az fejlődni fog.

    Nem értem, hogy mi bajod volt a linkelt hsz-szel. Szerintem jó poén volt. :)) Lehet mérgelődni, hogy a bányászlimit ellenére sem vehették 3080 Ti-t, vagy poénként felfogni, hogy szart sem ért a korlátozás.

    #55313 Raymond : Akik nagyítóval nézik a kijelzőt, azoknak se a DLSS, se az FSR nem jó. Ezek képminőséget csökkentenek, illetve képet torzítanak a jobb sebesség érdekében. Nagyon konyhanyelven fogalmazva olyan részleteket hazudnak be, amelyek másképp mutatnának natív képszámítással.
    Az NVIDIA és az AMD sem mondta soha azt, hogy ha elkezded nézegetni a pixelek szintjén a különbséget, akkor ne látnál. Azt kínálják, hogy a kijelző előtt ülve, úgy normális 60-70 cm-es távolságból, a gigantikus csata hevében ezt nem veszed észre.

    [ 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 killbull #55317 üzenetére

    H.264-re már nem igazán innoválnak a cégek. Sokkal inkább érdekesek az új formátumok.

    Még most is van. Rakhatnának a GPU-kra ilyeneket, de nem biztos, hogy jobban megéri, mint beépíteni egy rakás cache-t, és mellé lassabb memóriát. Ez pro-kontra elven működik mérnöki szinten.

    Ugyan lesz PCI Express 5.0, de se az NV, se az AMD nem izgult rá. Ahol ennek lenne értelme a GPU-knál az a szerverpiac, de oda az NV NVLinkes, míg az AMD Infinity Fabricos gyorsítót tervez a közeljövőben. Szóval tök jó a PCI Express 5.0, de az NV-nek lesz saját procija, saját platformmal, amibe tud saját interfészt rakni. Az AMD-nek pedig már van, tehát ugyanúgy elvihetik a fejlesztéseket magukra építve. Nem véletlen van az útitervben a Genoa mellett a Trento. Utóbbinak a lényege a fuck PCI Express, Infinity Fabric van a MI200-hoz és kész. Ennek több haszna is van az NV és az AMD számára. Amint megveszed az NV vagy AMD CPU-t, rögtön kapsz egy lock-int az NV vagy AMD GPU-ra. De persze a nyilvánvaló platformbezáráson túl azért van olyan előny is, mint a memóriakoherencia. Ez azért nem rossz.
    PC-s szinten annyira nem lesz pörgés a PCI Express 5.0-ra, mert drága az implementálás, és ehhez képest az előnye nem sok, miközben nagyon gyorsan jön a PCI Express 6.0. Tehát ha nem olyan kritikus a PCI Express sávszél, akkor eleve érdemes a 6.0-ra lőni, mert egy csomó pénzt meg lehet spórolni. A szerverpiacon azért még mindig nagy előny a nagyobb sávszél, ott azért ki fogják használni az 5.0-t is.

    Ezekkel a dolgokkal, amiket említettél nem sokat nyersz. Hardveres szinten a közeljövőben leginkább a tokozási technikákkal lehet nagyon gurítani. Például chiplet, akár függőlegesen építkezve. CPU-ra és GPU-ra is alkalmazhatók különféle trükkök, amelyek korábban azért nem fértek bele, mert valamiféle limit keletkezett a monolitikus lapka szintjén.

    #55321 b. : Ha raktak mögé pénzt, és 10 év alatt össz-vissz két lapkát sikerült összehozni, akkor valaki nagyon félrekötötte a pénzcsapot, talán annyira, hogy a saját házába ürült.
    Persze, hogy nem lehet versenyezni, de ez csak az NV saját döntése. Megtehették volna, hogy megnyitják a technológiát, és örömmel építette volna be a monitorgyártók többsége, hiszen nem lett volna semennyi felára. Nézd meg, egy rakás gyártó támogatja ám a G-Sync Compatible megoldást. A hitelesítési tesztet kifizetik, az nem nagy költség, de monitoronként 200 dollárt adni az NV-nek őrültség, naná, hogy nem lesz tömeges támogatása.

    [ 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 killbull #55325 üzenetére

    Aki szoftveresen akar kódolni az vehet most is 16-magos processzort. 8 mag simán megoldja ezt a problémát. De az is megoldás, amit sok streamer csinál. Összerak egy külön PC-t csak kódolásra.

    #55326 morgyi : Lényegtelen, hogy az NV megveszi-e az ARM-ot. Licenc alapján annyi ARM procit terveznek, amennyit csak akarnak. Ugyanoda fognak jutni ezzel, mint a felvásárlással, csak utóbbi több nagyságrenddel drágább. Vagy gondolod csak azért nem venne valaki az NV-től ARM processzort, mert végül mondjuk nem sikerült felvásárolniuk az ARM-ot? Hol érdekli ez a megrendelőt, tök mindegy, hogy több vagy egy cég rakta össze a lapká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 Yutani #55363 üzenetére

    A legdurvább az, hogy az AMD marha jól szórakozik a megjelent cikkeken.

    Eddig mindent leírtak az FSR-ről, csak azt nem, ahogy működik. :DDD

    #55364 Raymond : Sokkal egyszerűbb a quality mód minőségének az oka. Jóval kevesebb adattal dolgozik, mint az ultra quality. Azért lett a GTX 1060 quality móddal bemutatva, mert az ultra quality igazán gyorsan csak az RDNA 2-n fut.
    És ugyanez a minőségkülönbség megvan állóképen is a quality módnál, míg az ultra quality gyorsan mozgó képen sem rosszabb, mint állóképen. A kiválasztottak már próbálgatják. ;]

    Annyit azért berakok, hogy a Godfall esetében egy RDNA 2 dizájn 50+%-ot is képes gyorsulni az ultra quality módban. Egy nem RDNA 2 dizájn erre az extra tempóra csak szimpla quality-ben képes. A Pascalon az ultra quality mód csak +8-12% közötti tempónövekedést jelent.

    [ 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 #55366 üzenetére

    A CPU-t miért pörgetné?

    A képminőség az független a hardvertől. Az a beállítási szinttől függ.

    A régi hardvereken nem fog az ultra quality sokat hozni, mert hiányoznak az ötéves hardverekből azok a képességek, amelyek azt gyorssá teszik.

    [ 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 #55369 üzenetére

    Az alacsony felbontású számítás miatt alakul ki a CPU-limit. Van egy ismert problémája az NVIDIA kártyáinak, amik miatt a DirectX 12-es játékok gyengébb processzorokkal egyszerűen nem skálázódnak jól. Ez leginkább 1080p-ben és alatta keletkezik. Erről csináltak is teszteket. [link] és [link]
    A jelenség megszűnik 1440p-ben és fölötte, de az FSR-rel a számolt felbontás alacsonyabb lesz a beállítottnál, pont úgy, ahogy a DLSS esetében, tehát a CPU-limit ugyanúgy érződni fog a DirectX 12-es játékokban a GeForce-okon, nagyjából úgy, mintha valóban 1080p alatti minőséget számolnál natívan.

    Ha valaki GeForce-szal játszik, érdemes Zen 3-ra lépnie, lehetőség szerint négynél több maggal, de az optimális a nyolcnál több. A Radeonok DirectX 12-ben sokkal jobban kezelik ezt a problémát, így azok nem skálázódnak annyira rosszul gyengébb CPU-kkal, mint a GeForce-ok. Ez is benne lehet egyébként abban, hogy az AMD miért mér jelentős gyorsulásokat RDNA 2-re az FSR-rel, miközben ezt meg sem közelítik a GeForce-os eredmények. Egyszerűen nem használtak a leggyorsabb Ryzent, hogy a GeForce-okat belefuttassák a CPU-limitbe. Ezt majd külön érdemes megnézni a tesztelőknek, így ajánlott Ryzen 9 5950X-szel dolgozniuk, hogy a GeForce-ok sebessége biztosan skálázódjon, ne a proci fogja vissza őket, amikor 1080p alatti felbontáson számolnak az aktivált FSR-rel. Minimum nyolcmagos Zen 3 kell egyébként, hogy a skálázódás elfogadható legyen, hatmagossal már érezhető, hogy a GeForce-ok olyan limitekbe fut 1080p-ben is, amelyeket a Radeonok meg sem éreznek, ezek nem nagyok, de egyértelműek kimérhetők. Biztosra 16-magos Ryzennel lehet menni. Főleg úgy, hogy FSR-rel simán 1080p alatt is számoltathatsz.

    [ 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 #55371 üzenetére

    Attól, hogy nem fogadsz el egy tényszerűen kimért problémát a GeForce-okon, még létezni fog, és nyilván amíg ez kezelhető annyival, hogy 1440p-re rakod a számolt felbontást, hogy GPU-limitbe kerül, addig ez nem akkora para. De ez a gond a felskálázási technikákkal érződni fog, mert azok bizony nem fognak ilyen magas felbontásban számolni, tehát a valóban számolt felbontáshoz közeli limitek fognak élni. Lásd a fentebb linkelt két tesztet. Erre figyelni kell majd a tesztelésnél, mert ha nem raksz elég erős procit a rendszer alá, akkor könnyen lehet, hogy a Radeonok bőven GPU-limitben lesznek akkor, amikor a GeForce-okat még a gyenge proci akadályozza a skálázódásban.

    [ 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 #55373 üzenetére

    Nem is arról van szó, hogy mit látsz, hanem arról, hogy milyen limitekbe ütközik a rendszer alacsonyabb felbontáson számolt képkockákkal. Erről linkeltem két tesztet fentebb, ahol sok procival és sok VGA-val nézték a problémát. És továbbra is hangsúlyozom, hogy attól ez a jelenség nem szűnik meg, hogy félsz rákattintani a linkekre, mert nem kompatibilisek az adatok azzal a világgal, amit felépítettél magadnak. :)

    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 #55376 üzenetére

    Sokkal reálisabb körülmények között bekövetkezik a GeForce-okon a DirectX 12-es alkalmazásokban a procilimit. Lásd linkek. ;)

    #55375 paprobert : Persze. A felskálázással hiába lesz 4K a kirakott a felbontás a számolt ennél sokkal kisebb, és arra már erősen érződhet egy procilimit. Ez egy ilyen móka. De nagyrészt ez elkerülhető az erős Ryzenekkel. Mi alapvetően azért mérünk a tesztgépben nyolcmagos Zen 3-mal, mert a hatmagossal már érezhetően büntit kapnak a GeForce-ok 1080p-ben, annak ellenére is, hogy a Radeonok tökre elvannak hatmagossal. Úgy gondolom, hogy 12-magos lenne az optimális, de egyelőre örülünk, hogy van nyolcmagos. :D

    [ 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 A.Winston #55379 üzenetére

    Az RDNA 2-nek két előnye van, amiből profitál az FSR. A bitang nagy cache és a különböző AI-ra tervezett operációk, amelyek miatt a dedukciót gyorsabban tudja csinálni. Viszont az alap RDNA annyiban jobb, mint a korábbi dizájnok, hogy a két neuronhálót képes párhuzamosan futtatni.

    Az eddigiek alapján az látszik, hogy a legtöbbet az a bitang cache 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 Jack@l #55384 üzenetére

    Ha megnézted volna azt a két linket, amit adtam, akkor tudnád, hogy ez igazából csak a DirectX 12-es játékokban jelentkezik. DirectX 11-ben és Vulkan API-val nem, ott valamiért nincs olyan gondja az NV-nek, hogy hamarabb fut CPU-limitbe.

    #55385 Petykemano : Van. Két képet össze lehet hasonlítani pixelenként, és az eltérés erősen objektív adat. De a felskálázis eljárások eleve olyanok, hogy a hiányzó részleteket neuronháló(k) segítségével pótolják. Tehát pixelről-pixelre vizsgálva mindenképpen jelentős eltérés lesz a natív és a felskálázott kép között, mert se a DLSS, se az FSR neuronhálója nem alkalmas arra, hogy hajszálpontosan ugyanazt az eredményt adja, mint a natív felbontá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 KillerKollar #55440 üzeneté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 KillerKollar #55442 üzenetére

    Valamennyit tényleg segít, hogy integrálva van/lesz a GDK-ba, de ha nem lenne, akkor nem ettől szúrnák tökön magukat a fejlesztők, mert eleve GPUOpen a cucc, tehát csak portolni kell, ami ekkora projekteknél minimális tétel a kasszának. Szóval ez nagyobbrészt marketing, annak egyébként elég ügyes. :)

    Azt nézd amúgy, hogy ezeknél az effekteknél a nehéz rész a megoldás kigondolása a problémára. Ha az megvan, akkor onnan már egyszerűbb azt implementálni. A GPUOpen sem olyan dolog, ami csak AMD ötleteket használ, hanem vannak benne bizony nagyon sok régebben publikált ötletek is, csak újragondolva.
    Például a CACAO alapjaiban az Intel algoritmusa. Az AMD csak fogta az ötletet és átdolgozta úgy, hogy magas minőségű SSAO megoldássá váljon, mert az Intel megoldása egyébként rohadt gyors volt, csak komolyabb dedikált GPU hiányában sose törődtek azzal, hogy jó minőségű legyen az eredmény. Ugyanígy az SSSR sem AMD találmány, hanem egy Frostbite által használt algoritmus ráncfelvarrása. Igazából a Parallel Sort is egy szimpla Radix Sort algoritmus, csak át van rakva SM6.0-ba, így ez most az elérhető leggyorsabb. Ezért van az, hogy a Microsoft sem rakta be a GDK-ba az összes FidelityFX effektet. Csak az kell nekik, amelyek igazán hasznosak, mert például Radix Sort kódot azért bárki tud írni (merik remélni ;] ). Talán nem olyan gyorsat, mint az AMD, de itt mikromásodperces előnyről beszélünk.

    [ 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 #55444 üzenetére

    Mondták, hogy x16 van benne fizikailag, csak bizonyos piacokra nem engedélyezik. Itt speciel fontos, mert bizonyos alkalmazásokban sok a memóriamásolás a PCI Express buszon, de ha nincs sok, akkor inkább a kevesebb energiát választják.

    #55449 Z10N : A W6600 órajele 2,9 GHz. De az játékosoknak szánt asztali másképp lesz konfigurálva.

    [ 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 #55568 üzenetére

    Az Intel sosem kapta meg a forráskódot. A Linux drivert megnézhették, de azt ki nem. Az AMd-től mindig csak komponenseket kaptak, amelyeket az AMD lefordított. Egyedül azt tehették meg, hogy a Radeon Software skinjét lecserélik. De ma már ezt sem teszik, mert nem fizetnek rá licencet. Egyedül azt licencelik, hogy az AMD lefordítsa nekik a meghajtót, és kivegyen belőle pár dolgot, amit az Intel nem igényel. Ez jóval olcsóbb licenc, mint az eredeti megállapodás, mert így nem kell pénzt adni a technológiák újralogózásáért.

    Egyébként létezik az AMD-nél olyan licencelés, hogy a meghajtót is megírhatod magad, de kb. senkit sem érdekel, mert ettől még a hardverről nem tudsz annyit, amennyit az AMD. És ők is tíz év munkájával tartanak ott ahol, egy termék kiadása után nem nagy ötlet tíz évig maszatolni. Sokkal olcsóbb és hatékonyabb megfizetni az AMD-t, hogy adjon szoftvert 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 Z10N #55570 üzenetére

    Ugyanaz a meghajtó, ami az IGP-khez van. A DirectX 11 implementációt újraírták, de ugye kárnak, mert már alig van ilyen játék. A Vulkan elég jó, a DirectX 12 meghajtójuk harmatos.

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

  • Abu85

    HÁZIGAZDA

    válasz gejala #55572 üzenetére

    Manapság már default a Vulkan vagy a DirectX 12. DirectX 11 csak kompatibilitás miatt maradt meg, de némelyik játék már ezt se rakja bele, egyszerűbb a DirectX 12 mellé egy Vulkan módot csinálni. A DirectX 11-et a Microsoft gyakorlatilag megölte a DXIL-lel, amit nem portoltak le a régi API-ra, és eközben az Xbox Series X/S már nem fogad el D3BC-t. Ezzel elvágták a DirectX 11 lehetőségét a fejlesztők elől.

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

  • Abu85

    HÁZIGAZDA

    válasz Busterftw #55577 üzenetére

    Már rég nem a DirectX 11 az új játékok elsődleges API-ja. Csak a tartalék API, ha van, de manapság már inkább kihagyják.

    Az indie címeknél elsődlegesen a grafikus motor dönt az API-ról. Például az új Unity és Unreal Engine esetében csak mostanság vált default API-vá a DirectX 12 és a Vulkan.

    A Valve is most portolja át a korábbi címeit Vulkan API-ra. Persze ők inkább azért teszik, mert a DirectX 11 döglődik, és a gyártók is vonják ki az erőforrást alóla, tehát megéri kicserélni a régebbi játékokban az API-t, mert a Vulkan és a DirectX 12 meghajtókba raknak erőforrást a gyártók.

    Az egész váltás oka egyébként a Microsoft. Eredetileg úgy volt, hogy lesz DXIL DirectX 11-re is. Erre a gyártók is készültek. Aztán a Microsoft hirtelen bejelentette, hogy mégsem lesz, és inkább leviszik a DirectX 12 futtatási környezetet Windows 7-re. A DirectX 11 itt döglött meg, mert nagyjából 100-200 ezer sornyi shader van egy modernebb játékban, és azt a jövőben kompatibilissé kellene tenni két IR-re. Ergo, ami eddig mondjuk 200 ezer sor beírását igényelte az 400 ezer sor lesz. És ezért van az, hogy van már indie, amely egyszerűen kidobta a DirectX 11-et, mert sokkal olcsóbb a DirectX 12 mellé egy Vulkan leképezőt csinálni, mint shadereket konvertálni, és extra 200 ezer sornyi kódot karbantartani. Nincs sok értelme ekkora extra melót vállalni a DirectX 11-ért, amikor a Vulkan beépítése csak +3000 kódsor.

    [ 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 #55579 üzenetére

    Minden motornak van DirectX 12 és Vulkan leképezője is. De ebből egy játékba nem mindenki aktiválja mindkettőt, mert akkor duplázódik a karbantartási költség. Fejleszteni viszont jó, ha mindkét API-t támogatja a motor.

    #55581 Jack@l : Ha a Hangar 21-re gondolsz, akkor azzal a jelenlegi állapotban nem tudnának mit kezdeni a végfelhasználók, mert egy csomó olyan algoritmust használ, amihez a DXR 1.0 és az 1.1 túl buta. A Radeon Rays-en keresztül van implementálva az early traversal stop, a mixed nodes és az on-the-fly BVH generation is. A DXR ezeket nem engedi meg. A Microsoft dolgozik már egy új típusú gyorsítóstruktúrán, amivel megvalósíthatók lesznek, de az még Xbox Series X/S-re is csak az év végén jön, PC-re pedig ki tudja, hogy mikor. A legnagyobb gond, hogy ezzel a struktúrával a meglévő hardverek egy csomó, RT-re szabott részegységet elveszítenek. Olyan lesz, mintha nem építették volna ezeket bele a hardverbe. Tehát ehhez a dizájnhoz új hardverek is kellenek. Az RDNA 2-nél is újabbak, bár ezt azért programozhatóra tervezték, akkor van haszna, ha új intrinsics függvényeket építenek a hardverbe.

    #55583 Busterftw : Ma már amiben van DirectX 12, az default API-nak számít. A DirectX 11-es mód, ami a tartalék, ha van.

    #55585 morgyi : Nem igazán mentenek semmit a Warzone kapcsán. A gyártók tudják jól, hogy a felhasznált motor abból a szempontból speciális, hogy időnként megváltoztatja a pufferek helyét a VRAM-ban. Ezzel a meghajtók együtt tudnak élni, de a third-party overlay applikációk nem, azok nem tudják ezeket a változásokat követni, mert az alkalmazás ezekről nem értesíti őket. Ezek pedig hibához vezetnek. Nem véletlenül írják a fejlesztők, hogy a Rivatunert, és a különböző egyéb tuningprogramokat, zárják be a játék előtt, mert nem fogják tudni követni a motor működését. Egyedül a driverbe épített finomhangolási funkciók képesek erre, mert azoknak sokkal több rálátásuk van a hardverre. Ez tehát nem bug, hanem fícsőr, a memóriamenedzsment komplexitása okozza, és ha nem futtatsz a játék mellett semmilyen third party tuningprogramot, egyéb streaming programot, akkor hibamentesen futni is fog az alkalmazá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 Jack@l #55587 üzenetére

    Azt a Microsoftnak rakták össze. A Microsoftnál van a forráskód, és a lehetőség, hogy kiadják. Az AMD-nek ez a technológiai demója: [link]

    [ 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 #55589 üzenetére

    [link] - itt a teljes előadás, a Microsoft DXDevDay rendezvényéről, ahova készült ez a demó.

    #55590 morgyi : Ez ugyanaz, ami a DXDevDay-re készült.

    Az AMD saját demója a Hangar 21.

    [ 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 kisfurko #55656 üzenetére

    Maradhatna a 96 MB 160 biten is, mert az összes cache szelet rajta van az IF-en, de azért relatíve nem kis lapkaterületről van szó, így lehet nyerni 16 MB letiltásával pár amúgy kukára ítélt GPU-t. Ez jelenleg nem mindegy. :)

    [ 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 sakal83 #55700 üzenetére

    Nem elég nagy dolog, hogy egy 128 bites busszal dolgozó GPU lever egy 1080 Ti-t, ami 352 bites busszal dolgozik? :)

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

  • Abu85

    HÁZIGAZDA

    válasz killbull #55703 üzenetére

    Nem, az AMD a GeForce 30-as sorozathoz áraz. Jelenleg egyszerű a képlet, amivel dolgoznak. -30 dollár a célzott, megegyező teljesítményű GeForce-hoz képest, vagy ha 10%-kal gyorsabb az adott VGA, akkor ugyanannyiért fog menni. Ennyi.

    #55706 sakal83 : Árat még nem láttam, de a 6600 XT elég gyorsra van paraméterezve. Az a kérdés, hogy mennyi gyári tuningot vállalnak a partnerek. Lehet, hogy lesz olyan, aki elviszi 3 GHz fölé az órajelet.

    Azt amúgy már korábban mondtam, hogy az olcsó VGA-k kora lejárt. Ha ennyiért nem kell, akkor konzol.

    [ 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 #55709 üzenetére

    Nincs 4K-s adatsorom róla. Igazából AMD-s sincs. OEM van, és abban csak 1080p-s mérések vannak négy DX12-es játékkal: Dirt 5, WoW: Shadowlands, Hitman 3, Assassin's Creed Valhalla

    Viszont a proci egy Ryzen 9 3900, ami 65 wattos, és az NVIDIA DX12 drivere sokkal lassabb ilyen körülmények között. Viszont a 6600 XT úgy ~25%-kal gyorsabb, mint a 3060 Ti. WoW: Shadowlands-ben 40%-kal, de itt be van kapcsolva a sugárkövetés, ami ebben a játékban szintén nem kedvez az NV-nek, azt kikapcsolva már közelebb lennének. Egyelőre ennyi van.

    4K-ban szerintem gyorsabb lenne a 3060 Ti, mert saját mérésekből kiindulva erősen látszik, hogy az NV még 1440p-ben is procilimites egy Ryzen 7 3700-zal, ami nem sokkal lassabb, mint a 3900. Az AMD már sokkal gyengébb procin sem limites 1080p-ben sem.

    #55710 Raymond : Mint írtam, ár még nincs.

    [ 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 #55715 üzenetére

    Gondolom a TPU adatbázisában nincs CPU-limit. Mint írtam, az NV drivere valamiért egyre jobban küzd ezzel a gonddal. Az AMD GPU-k, sokkal gyengébb CPU-k mellett sem lesznek limitesek. Az NV-nek már a Ryzen 9 3900 is probléma 1080p-ben és 1440p-ben. 4K-ban ez eltűnik. Nem tudni mi okozza, de driverről-driverre rosszabb a helyzet. Ma már simán Zen 3 kell, hogy ne legyél limites GeForce-on. Régen még nem kellett, persze lehet, hogy az újabb játékok terhelése nagyobb.

    [ 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 Alogonomus #55717 üzenetére

    A WoW Shadowlands szvsz erősen CPU-limitel, illetve az RT effekt sem valami jól van megírva GeForce-ra, de amúgy sem menne többel. Egyszerűen 1080p-re és 1440p-re állítva sem igazán tud 100 fps fölé menni. Ehhez képest a Radeonok az áprilisi driver óta 150 fps-t is kipréselnek magukból, a 6900 XT már majdnem 200-at. Egyszerűen nem fogja őket a CPU-limit. Rakhatsz alájuk olcsó hatmagost is, azzal is sokkal jobban működnek, mintha a GeForce alá raknál egy 16 magos Zen 3-at.

    Ha nincs Zen 3-as procid, nincs 8+ magod, és 1080p-ben mérsz, akkor mára már nagyságrendekkel jobban működik a Radeon DirectX 12 drivere. Ezért is váltjuk a tesztrendszert Ryzen 9 5800X-re. De több játékban még ezzel is érződik, hogy CPU-limitben vannak a GeForce-ok 1440p-ben és alatta.

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

  • Abu85

    HÁZIGAZDA

    válasz #32839680 #55720 üzenetére

    Nem csak ott érződik a CPU-limit. Csak ott nagyon kijön. De a Hitman 3-ban, az Assassin's Creed: Valhallában, a Dirt 5-ben is. És úgy is, ha bekapcsolod az RT-t az utóbbinál. Sőt, aktív RT-vel még rosszabb.

    Tudja az NV, csak nem tudnak mit tenni vele. Újra kellene írni a DirectX 12 drivert úgy, hogy mindennek a támogatását kivágják belőle, csak a Turing és az Ampere marad, és akkor nincs szükség arra az emulációra, ami miatt a CPU dolgozik a GPU helyett az erőforrás-bekötésnél. De a Pascal és a Maxwell nem tud enélkül működni, két külön DirectX 12 implementációt pedig nem éri meg fenntartani. Arról nem is beszélve, hogy ha írnak egy új implementációt, akkor megint évekig kell irtani a bugokat, mire olyan stabil lesz, mint a mostani. Ez a probléma jelenleg megoldhatatlan.

    Egyébként, ha csak a 3090 lenne érintett, akkor nem lenne ez gond. De közel sem ilyen egyszerű a helyzet: [link]

    [ 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 #32839680 #55722 üzenetére

    Az AMD manapság másképp írja a drivert. Volt nekik régen a Mantle. És ahhoz írtak egy PAL-t, majd arra húztak egy Mantle ICD-t. Na most a DirectX 12 és a Vulkan is ugyanazon a PAL rétegen fut, csak másik ICD-vel. Tehát amit látunk az konkrétan tíz évnyi munka. És nem API-ra szabott, hanem általános. Ez egy amolyan KISS modell. Kevés erőforrást fektetnek be, és eközben nagyon gyors a kód.

    Erre egyébként pont átállt az Intel a Vulkan API-nál, és nem kizárt, hogy a DirectX 12 implementációjukat is lecserélik úgy, hogy a Vulkánhoz írt alsó rétegimplementációt használják tovább.

    Az NV nem tudom, hogy mihez kezd. Vagy átírják a meghajtót, és akkor nyilván az AMD-féle KISS modellt érdemes követni, vagy megvárják amíg kidobhatják a Pascalt.

    Senki sem akar CPU-limittel játszani, de ezzel mit tud kezdeni egy user? Nem tudja a GPU-ra varázsolni a munka egy részét, ha a meghajtóban a CPU-ra van állítva. Ezt az NV képes átalakítani, de nekik meg egy csomó fejfájást jelentene egy ilyen átállás. Persze a meghajtó sokkal gyorsabb lenne, ez nem kérdés, de nem biztos, hogy megéri vállalni egy új implementációval a bugokat.

    [ 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 #32839680 #55725 üzenetére

    Mi arról váltottunk, mert erős volt a limit. Igazából Zen 3-mal tényleg nem rossz, de még mindig van. Efölött pedig nincs opció. :)

    [ 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