Hirdetés
-
Mozgóképen a Razr 50 Ultra még nagyobb kijelzője
ma A hivatalos kedvcsináló megnyerő, csak nem hivatalos forrásból érkezett.
-
Ellopták a Tesla akkumulátor-titkait
it Beperelte egy korábbi beszállítóját a Tesla, és azzal vádolja, hogy üzleti titkokat lopott a Tesla akkumulátorgyártási technológiájával kapcsolatban.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
PROHARDVER!
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
Jack@l
#35734
üzenetére
SSG nélkül inkább 5-6 másodpercen belül. Valószínűleg nincs sok tapasztalatod erről, de vizualizációnál beállítod a kamerát, és a rendszer abból a nézőpontból elkezdi a leképezést. Úgy nagyjából 1 másodperc múlva már látsz annyit a jelenetből, hogy kifejezetten az ilyen felvételeken az késznek tűnik, de ettől a hardver dolgozik tovább, és a teljes eredményig azért jó pár másodperc eltelik, csak ilyen távolról, ilyen minőségű videón ez nem látszik. Maga a rendezvény is professzionális közönségnek szólt, ezért nem rágták ezt szájba, mert feltételeztek annyit, hogy a közönségnek azért van egy minimális tapasztalata a tartalomvizualizációról, ergo tudják ezt. Ők sem a sebességet értékelték, mert ahhoz nem ilyen demót szoktak mutatni, ugyanis kérhetsz olyat is, hogy benyomod a jelenetet a programba, és leméred, hogy mennyi időt vesz igénybe egy képkocka elkészítése. De itt nem ezen van a hangsúly, hanem azon, hogy van egy bitang nagy, TB-os szintű adathalmazod, és azt nem kell 100-200-300 darabra bontani, mert a hardver egyben megoldja out of memory hibaüzenet nélkül. Vagy ha az anyagi részét fogjuk meg, akkor nem kell hozzá venni több tucat kétutas EPYC-et, hogy legyen 4 TB-nyi rendszermemóriád betölteni az adatokat. Ergo, ha nem akarsz hatalmas CPU-s renderfarmra költeni, vagy darabolni, akkor most már van alternatíva, igen olcsón is. Ezt akarták megmutatni ezzel. Ezért viccel egyébként a fószer a fehér képernyő láttán, hogy évek óta ezt látja. Persze, Bollywood sem olyan gazdag, hogy CPU-ból csinálják meg ezt, annak komoly fenntartási költségei vannak, így inkább vesznek GPU-s workstationt, szopnak a darabolással, és alapvetően sokkal olcsóbban megvan, csak közben marha sok extra meló is, mert ha nem jól daraboltad ki, akkor fehér képernyőt kapsz nincs több memória üzivel.
[ 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
#35743
üzenetére
Igen. Az a lényeg, hogy maga a Vega, ezen belül is a professzionális verzió 512 TB-ig be tud tölteni bármit. A gamer verzió csak 256 TB-ig, ez egy driveres limit. Na most igazából mindegy, hogy hol van az adat, a HBCC eléri, akár lehet a hálózaton egy NAS-ban is, a HBCC-nek nem számít. Az SSG amiatt gyorsabb, hogy a GPU melletti HBC mellett van még NAND a NYÁK-on, tehát oda tud gyorsítótárazni a rendszer, így a legtöbb adatot hamarabb éri el, és nem kell elnyúlni érte a rendszermemóriáig, a helyi adattárolóig, vagy akár a hálózati adattárolóig. Funkcionálisan viszont az SSG és az SSD nélküli professzionális Vega ugyanarra képes, csak utóbbi lassabban, sokszor jelentősen.
Maximum elkezdte leképezni, és a hiányzó ray-ek adatai nem látszanak a felvételen. De megközelítőleg sem volt kész. Ahhoz több másodperc kell. Ha egy 250 milliárd háromszöges modellt 1 másodpercen belül megoldaná egyetlen mai GPU, akkor az iparág a seggét csapkodná a földhöz örömében, és nem építene senki 100+ processzorból renderfarmokat. Az AMD sem építette volna meg a Project 47-et, hiszen minek is telepítsen bérelhető, petaflopsos szintű erőforrásokat Hollywood mellé, ha egy GPU-val simán megvan a feladat egy másodpercen belül. 7000 dollárt mindenki ki tud fizetni, az még a ZS kategória alatt is vállalható összeg. De sajnos nem, jóval több időbe kerü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
Yutani
#35752
üzenetére
Ha hasonló lenne, akkor 10 nm lenne ráírva és nem 7. Értsétek meg, hogy nem a gyártó dönti el, hogy milyen számot írhatnak a nanométer elé. Az ITRS végzi az osztályozást. A gyártó leadja a node igényelt paramétereit, ami egyébként több tucat adat, és az alapján az ITRS besorolja a node-ot egy osztályba. Ráadásul a 10 és a 7 nm között még van 8 nm is, tehát nem lehet azt mondani, hogy vagy 10 nm valami, vagy 7.
[ 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
#35754
üzenetére
Ezek tök jó cikkek, csak ha nem lenne annyi különbség ezek között, akkor az ITRS nem ismerné el őket más számú node-ként.
(#35755) Oliverda: Mire? Hogy az ITRS kategorizálja ezeket? Nem akarom elhinni, hogy ez neked újdonság. Ott az archívumotokban több Bizó Dani cikk, azokban van arról szó, hogy itt igazából semmi sem x nanométeres. Egyszerűen a gyártó specifikálja magának az adott node-ot, majd a specifikációt elküldi az ITRS-nek, hogy ők hitelesítsék azt. Addig mondhat a gyártó bármit rá, de csak akkor lesz x-y-z nm-es a node, ha az ITRS azt elismeri. Ami a leginkább számít az az M1 huzalok sűrűségének nagyjából a fele, de ez sem egyezik meg a nanométer elé írt számmal. Valójában semmi sem x-y-z nanométeres, ez csak egy osztályozás.
(#35757) cain69: Igen, bocs.
[ 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
Oliverda
#35758
üzenetére
Nem végzik hanyagul a munkájukat, csak négy paraméternél sokkal többet vesznek számításba. Ezért létezik ez a szervezet, nélkülük mindenki azt írna az adott node-jára, amit csak akar. Nem lenne ellenőrzés, amivel ezek iparágilag igazolhatók. Ha nem tetszik a döntésük, akkor feléjük jelezd, hogy elégedetlen vagy azzal, ahogy ők ezeket a node-okat besorolják.
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
#35764
üzenetére
Maga a VRAM nincs definiálva a Vega esetében. De ha mindenképpen akarod valahogy ezt definiálni, akkor gyakorlatilag a VRAM megegyezik a beállított caching szegmenssel. Na most ebbe a HBCC működése alapján, kifejezetten a professzionális driverben (mert a sima driver itt is különbözik) beletartozhat a GPU melletti memória, a rendszermemória, a helyi adattároló és a hálózati adattároló. Az egész egy csúszka a szoftverben, amit oda állítasz ahova akarsz, persze az elméleti limitekig bezárólag. Persze az igényelt adat a HBC-n belül lesz. Gyorsítótárazza. Ha nincs direkt támogatás a szoftverben, akkor pedig a HBC+rendszermemória lehet a HBCC szegmens.
[ 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
#35767
üzenetére
Cache. A GPU melletti memória ebben a rendszerben hasonlóan működik, ahogy a processzorok L3 gyorsítótára. Az SSG-nél pedig az SSD olyan, mint az Intelnek az eDRAM-ja, egy jó nagy, de L3-hoz képest azért jóval lassabb L4 gyorsítótár.
[ 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
Oliverda
#35771
üzenetére
És jegyezzük meg azt is, hogy az Intel volt az a gyártó, aki elkezdte titkolni a lapkáinak a tranzisztorszámát. Pedig milyen jól össze lehetne hasonlítani most a GloFo 14 nm-es node-járól a Summit vagy a Raven Ridge-et, az Intel Coffee Lake-kel és Skylake-X-szel. Ezt egyébként miért lépte meg az Intel? Régebben folyamatosan közölték ezeket az adatokat, hiszen jobban voltak, mint a konkurensek, most pedig a legutolsó CPU-s adat a Broadwell-EP LLC 3,2 milliárd/246 mm^2-es értékei. Pedig annyira jól mutat az Intel 14 nm-es csodatechnológiája a GloFo 14 nm-es iparági szarja mellett, amivel a Summit Ridge tud 4,8 milliárd/213 mm^2-t.
Vagy a gyakorlati lapkákkal nem szabad már foglalkozni, csak ami a papírra le van írva azt érdemes összevetni? A gyakorlat akkor nem is határozhatja meg, hogy egy node mire képes, hiszen a táblázatok alapján le is írtuk ezeket, és az a négy paraméter aztán perdöntő, másnak itt szerepe sincs? Az Intel a faszagyerek, csak éppen a lényeget nem árulják el, a gyakorlatban is elérhető lapkák adatait. Nem is értem miért... 
[ 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
Oliverda
#35774
üzenetére
Nem hiszem. Az Intelnél is volt ilyen, méghozzá a Sandy Bridge kapcsán. Az Intel ezt meg is magyarázta anno, hogy ez miért fordulhat elő. [link]
Az AMD mindig valósat ad meg, de egyébként megmondják a sematikusat is, ha megkérdezed őket. Mindkét érték helyes. A probléma az, hogy sok média ezt nem tudta, illetve kicsit kavarást okozott az Intel azzal, hogy egyszer a Sandy Bridge-re sematikust adott meg, de azóta valósat is közöltek mindig, de csak addig, amíg ezt a paramétert közölték is. Egy ideje viszont teljesen leálltak. Az AMD máig megadja a valósat, bár a sematikusat nem, azt külön kérdezni kell.
Szerintem az a problémájuk, hogy még ha a 10 nm-t csodával határos módon el is magyarázzák, hogy miért jobb a 7 nm-nél, a tranzisztorszámokat túl egyszerű összevetni, és abban már azonos "nanométer előtti számmal" is kikapnak, tehát ott úgy már nagyon kevés újságírót lehetne megvezetni. Sokkal egyszerűbb ezeknél a táblázatoknál maradni, és acélosan mutatni, hogy minden a legnagyobb rendben, így terveztük, szándékosan ilyen, stb. Kapaszkodni a végletekig abba a pár számba, amit még lehet mutogatni a médiának, és az erre vevő újságíróknak, és mereven eltitkolni a gyakorlati adatokat, hogy valós összevetés ezekből még csak véletlenül se születhessen.
[ 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
keIdor
#35786
üzenetére
Nem kell a Naviig várni a Vega 20 is ilyen. A GMI linkeket kell figyelni. Ha az van a GPU-ban, akkor alkalmas efféle összeköttetésre. Mondjuk a Vega 20 esetében ez szerintem az EPYC-hez van, ahol majd a CPU-val kapcsolják össze. De ennek előbb-utóbb lesz asztali verziója, ami dobja a PCI Express-t, és akkor egy 250 wattos tokozáson belül kapod a CPU-t és a pGPU-t, az összeköttetésük pedig memóriakoherens lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35797
Abu85
HÁZIGAZDA
Petykemano
#35796
Abu85
HÁZIGAZDA
válasz
Petykemano
#35796
üzenetére
A semi-custom nem nem tud meghatározni semmit az RTG-nek. Hiszen nem része ennek a divíziónak az R&D részleg. Ha valakinek esetleg egyedi igénye van, például a Sony-nak volt a superstencil, akkor azt úgy biztosították, hogy beleadták a semi-custombe a mérnökeiket. De az AMD R&D részlegtől nem vontak el semmit. Persze a semi-custom licencelése eléggé specifikus lehet. Például az AMD licencelte a Sony superstenciljét. Ilyenkor jut az R&D szerephez, vagyis megszerezték a szabadalom használatára a jogot, és terveztek rá egy Sony-tól eltérő implementációt, mert a Sony-é nem került az AMD tulajdonába, annak ellenére sem, hogy a semi-custom részleg részt vett a tervezésében, és persze megvan az áramkör vázlata is. A licenc viszont ennek a felhasználását tiltja, tehát semmit sem ér, így az AMD-nek le kell terveznie a saját fizikai implementációját.
A semi-custom úgy nem tud meghatározni semmit, hogy a licencek tiltják a bevitt technológiák, egy az egyben történő felhasználását. Szép is lenne, ha a Sony ad egy IP-t az AMD-nek, amit az AMD rögtön tudna is biztosítani a Microsoftnak.A WCCFtech meg hasonlókkal ne foglalkozzatok. Iszonyat baromságokat írnak, az AMD konkrétan röhög a mai "exkluzív" cikkükön is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35800
Abu85
HÁZIGAZDA
huskydog17
#35799
Abu85
HÁZIGAZDA
válasz
huskydog17
#35799
üzenetére
Mi ellenőrizzük a híreiket. Csak azokat közöljük, amire azt kapjuk vissza, hogy igaz. A mostanit is ellenőriztük. Egy marha nagy LOL-t kaptunk vissza. Néha a hülyeségeiket is megírjuk csak bullshittelenítve: [link] ; [link] ; [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35803
Abu85
HÁZIGAZDA
Petykemano
#35802
Abu85
HÁZIGAZDA
válasz
Petykemano
#35802
üzenetére
Egyáltalán nem hasonló. Az Intel hasonló az AMD-hez. Az NV jelenleg nem biztos, hogy tudja ezt a két céget oda követni, ahova tartanak. Ezért is volt a GPP, mert semmi más eszközük nincs arra az időszakra, amikor a GPU-t a proci tokozására rakják rá. És itt a Kaby Lake-G csak egy kezdés, amit sokan az AMD előnyének írnak, de valójában nem az. Az Intel ennek az utódját nem AMD GPU-val fogja kínálni. Az AMD-nek a legnagyobb versenytársa jelen helyzetben az Intel, mert pontosan meg tudják ugyanazt csinálni, amit ők, odarakhatják a GPU-t a CPU mellé. Ezután az Intel fogja meghatározni, hogy lesz-e esélyed dGPU-t venni a platformjukhoz. És ez az AMD-nek is bajos jövő, mert ugyanúgy érinteni fogja őket, mint az NV-t, ha az OEM megveszi az Intel processzorát, rajta a pGPU-jával, és tovább nem is tud menni., mert a homlokához van szegezve az árazópisztoly. Az AMD önmagában nem elég nagy ahhoz, hogy saját magát eltartsa ezen a piacon a saját platformjával, tehát még ha ki is segítik magukat azzal, hogy nem zárják le a dGPU-s irányt, annyira visszaesik majd ez a terület, hogy iszonyatosan drága lesz, szinte luxuskategória.
Nem nagyon foglalkozik most senki a dGPU-kkal, ha fontos lenne már láttad volna az újdonságokat a Computexen, de a stratégia kialakítását az köti le, hogy az Intel durván megindult a bezárkózás felé. És ez az AMD-t és az NV-t egyszerre érinti, mert nem csak GeForce-ok kerülnek ám az Intel procikkal egy házba/vázba. A következő generációknak erre kell reagálni, nem arra, hogy egymással milyen jó lesz a verseny. Semmit sem érnek el vele, ha a piacot 70%-ban birtokló Intel azt mondja, hogy szép-szép, de mi azért odarakjuk a saját pGPU-nkat a procihoz, és fizessétek csak ki azt, aztán felőlük le lehet tiltani, ha már megkapták a pénzt a nem használt hardverért.
Itt semmit sem fog érni az R&D, meg az anyámkínja milyen GPU. Az nyer, aki megtalálja majd az Intel pGPU-s modelljének az ellenszerét, mert megtalálja az utat ahhoz, hogy az OEM által kifizetett pGPU le legyen tiltva, és az adott OEM még fizessen meg egy extra GPU-t, ami már nem az Intelé. Na mi lehet ennek az ellenszere?[ 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
Televan74
#35804
üzenetére
Mert amúgy az OEM-ek által összerakott gépeknél akkora beleszólásunk van ezekben?. Azt lehet venni, amit összeraknak, és eljutnak a boltig. A DIY pedig nem érdekes. Az OEM-hez képest törpepiac. Ott már most is elég nagy az AMD részesedése. Volt olyan hónap, amikor nagyobb volt az Intelénél.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#35806
üzenetére
Szerintem nem. De az Intel nagyon nagy szereplő, márpedig nekik az az előnyös, ha nem az AMD-t és az NV-t követik oda, ahol nem lenne esélyük (VGA-piac), hanem őket kényszerítik a saját terepükre (pGPU-k). A VGA így is jó lehet még, mert a több GPU-s módok szempontjából nagyon jó lehetőségeket kínálnak az API-k, mondjuk egy texel shading motornak, vagy sugárkövetéshez.
Persze az igaz, hogy a pGPU mondjuk egy memóriakoherens interfésszel sok előnyt tud adni, mert a HBM2 már elég jó cache-nek is, szóval haszna ennek az iránynak mindenképpen van, csak nem kényszerítve, hanem amolyan egészséges fejlődés mellett. A kényszerítésből nagyon ritkán születik a piacnak előnye.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35809
Abu85
HÁZIGAZDA
Petykemano
#35808
Abu85
HÁZIGAZDA
válasz
Petykemano
#35808
üzenetére
Az Intel pont nem heggeszt igazán rajta semmit. Már három generáció óta ugyanaz a Gen9 az alap. Csak a multimédiás blokk és a kijelzőmotor változik. Utóbbi is le van maradva a natív HDMI 2.0 hiányában.
Ez a kulcstényező. A piac 70%-át hozza a semmivel. És akkor érted már, hogy miért nem azzal törődik az NV és az AMD sem, hogy mi lesz a következő nagy dGPU-s mérkőzés eredménye...
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35812
Abu85
HÁZIGAZDA
Petykemano
#35811
Abu85
HÁZIGAZDA
válasz
Petykemano
#35811
üzenetére
Azt azért tudod, hogy Krzanich lassan 4 éve lőtte le ezt.
A Gen10 hardverrel amúgy nem lenne nagy baj, ha aktiválható lenne a Cannon Lake-ben. De nem az basszus.Az tök jó, hogy jöttek ezek az emberek, de tudod, hogy mikor kapsz tőlük eredményt? Úgy leghamarabb 3 év múlva. Meg azért az Inteltől a programozók is elmentek, elég sokan. A helyükre sok igen okos embörkét kell felvenni. És egyébként hiába van a sajtó Raja és Chris Hook érkezésével elfoglalva, legalább egymilliószor többet ér náluk Joshua Barczak. Csak őt alig ismerik, így nem számított szenzációnak, hogy az Intelhez ment, de az ő feladata lesz az Intel játékfejlesztési modelljét újraépíteni, amit anno Richard Huddy nagy nehezen felhúzott és Krzanich egy pillanat alatt lerombolta. Szóval messze nem Raja és Chris a legnagyobb fogása Murthy-nek. Utóbbival szerintem még gyengültek 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
Oliverda
#35828
üzenetére
Szóval amíg ők írták a legjobb számokat oda, addig hittek ebben, de most hogy beelőzték őket, hirtelen bullshit lett az egész.
Tehát akkor azt mondod, hogy az egész összevetés lényegtelen, mert a gyakorlatiban még sok, elméleti szinten nem jelentkező paraméter határozza meg ezt az eltérő dizájnok miatt?
[ 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
Oliverda
#35830
üzenetére
És most hogy ezt beláttad, remélhetőleg látod azt is, hogy miért folytatta az Intel a nanométer előtti szám marketinget, mert ez régen sem volt másképp. Csak annyira körülményes lett volna elmagyarázni a felhasználónak, hogy egyszerűbb volt azt mondani nekik, figyeld a kisebb számot a nanométer előtt, mert az a jobb. Viszont ezzel beleestek a saját csapdájukba. Elmagyarázni a jövőben sem tudják ezt, csak egyre kellemetlenebb helyzetbe hozzák magukat, amikor próbálják ecsetelni, hogy régen miért hazudtak erről. Eközben a többiek szépen írogatják a nanométer elé az egyre kisebb számokat, építve az Intel évekig tartó félrevezetésére, hiszen ez a korábban propagált, szinte agymosás szintjén leadott információ most nekik dolgozik.
[ 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
Oliverda
#35832
üzenetére
Az előbb írtad le, hogy "az eltérő felépítésű lapkák összevetése alapján nem lehet besorolni egy gyártástechnológiát, hisz a logikai áramkörök és pl. az SRAM sűrűsége alapvetően eltér." Vagyis a táblázat igazából a gyakorlatban úgyis lényegtelen, mert végeredményben sokkal több dolog határozza meg, hogy egy gyakorlati lapkánál mik lesznek ezek a paraméterek.
Én nem vitázok a táblázattal, azon a véleményen vagyok, hogy nem lehet ezt meghatározni egy számmal, de még négy számmal sem, sőt, hattal sem. Az egész abból ered, hogy az Intelnek a régi, "nanométer előtti kisebb szám a jobb" marketingje már nem működik, így mostantól azt magyarázzák, hogy miért nem igaz, amit az előző évtizedekben minden gyártástechnológiai váltásnál ecseteltek. Csak én még emlékszem erre, hogy ez mennyire fontos paraméter volt, és minő véletlen, amint beérték itt őket a többiek, ez túl egyszerűsítetté vált, stb-stb. Persze van aki gyorsan felejt.
Ugyanígy azért nem közlik már a tranzisztorszámot és a lapkaméretet, mert nem ők benne a legjobbak. Pedig régen mindig kihangsúlyozták. Nem a cég marketingesei világosodtak meg arról, hogy ezek így hülyeségek, évtizedeken át megvezették őket a mérnökök, na de most aztán felszívták a tudást, és "baromságot" nem közölnek, hanem elvesztették ezekben az első helyet, és így váltak "hülyeséggé" ezek a paraméterek.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#35835
üzenetére
Értem. Illetve egyáltalán nem. Tehát a nanométer előtti szám az nem fontos, a táblázatban szereplő számok fontosak, de csak azok, a gyakorlatba áthelyezve már nem fontosak, mert úgyis befolyásolja még rengeteg más tényező a tényleges lapkák tranzisztorsűrűségét, és egyéb adottságait. Az a kérdésem, hogy ha ezeket a számokat úgyis befolyásolják más tényezők is, akkor azok nem fontosabbak, mint a táblázatban szereplő számok?
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35839
Abu85
HÁZIGAZDA
Petykemano
#35838
Abu85
HÁZIGAZDA
válasz
Petykemano
#35838
üzenetére
Éppen kérdezem mi ez, és állítólag van több infó, szóval wait and see.
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
#35849
üzenetére
Dehogynem. Úgy hívják, hogy triple buffering. Ilyenkor két back buffer van, és azt párhuzamosan számolja a hardver. Az utófeldolgozás olyan lehet, amilyen az algoritmusa. Egyáltalán nem kötelező hozzá az előző képkocka. Még a régi Xbox 360 esetében számított bevált trükknek, hogy az előző képkockához megmaradt adatokból számoltak bizonyos dolgokat az új képkockánál, de azt is amiatt, hogy a 10 MB eDRAM nem volt elég nagy a bizonyos leképezési eljárások mellett.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35851
üzenetére
Lesz átfedés a képszámítások között. Az egy dolog, hogy ezek sorban jönnek, de mivel maga a GPU extrém párhuzamosításra van tervezve, így nem várja meg az új kép számításának megkezdésével azt, hogy az előző teljesen elkészüljön. Egyedül a scene pacing modell az, amikor csak akkor kezdődhet meg a következő kép számítása, az előző már elkészült teljesen. De ilyen modellt direkten nem támogat egyik API sem, maximum driverből lehet kényszeríteni ezt, de mivel elég bonyolult, így az AMD kívül nem csinálja senki.
Ezért is van egyébként akkora különbség a késleltetésben a scene pacing kényszerítés és a szabványos modellek között. Szinkronizált double buffer esetén a kijelzőn látott állapot nagyjából 2 frame-mel van lemaradva az éppen számolttól. Szinkron nélkül pedig előfordulhat, hogy nem is egy jelenet eredményét látod.
Azt nem mondom, hogy ez a modell jó, de így lett kialakítva. Ezért is ügyködnek azon a driverek, hogy ezeket a szabványos modelleket valahogy megkerüljék. Például az egyszerű módszer a háromlépcsős szinkronizáció, double buffer mellett (AMD Enhanced Sync/NV Fast Sync), míg a bonyolult a scene pacing (AMD Chill). Utóbbi az egyedüli olyan megoldás, ami tényleg sosem számol párhuzamosan két frame-et. Nincs is ugye back bufferje.
[ 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
#35856
üzenetére
A mai játékokban azért a motion blur faék egyszerűen van megoldva. Az adott pixel végeredménye mindig a környező pixel valamilyen módon számolt súlyozott középértékéből van származtatva. A gyorsulást szimplán skálázhatod a képkockasebességből. A temporális screen space megoldások marhára nem elterjedtek ám. Persze kétségtelenül lehetségesek, csak egyrészt a számítási idő és a memóriaigény tekintetében relatíve költségesek, másrészt az eredményük nem sokkal jobb, így például nem adnak választ azokra a problémákra, hogy mi van azokkal az objektumokkal, amelyek már pont nincsenek rajta a képen. Szóval az egész egy baromi nagy screen space trükközés jelenleg. Úgy tudom egyedül a Nitrous működik másképp, az valóban temporális, ráadásul objektumszintű motion blurt használ, de ott eleve a leképező marhára más a texel shading miatt, tehát egy csomó mai motorra jellemző limitációval nem kell küzdenie. Ha kész egy objektum árnyalása egy viewportból, akkor azt annyiszor használhatod fel, ahányszor akarod, csak extra rajzolási parancs az ára, nem kell másodjára, harmadjára, vagy sokadjára árnyalni, mint az árnyalást és leképezést nem függetlenül elvégző motorok esetében.
Nem kapsz több fps-t a tripla puffereléssel, vagy csak egy nagyon picit. Egyszerűen arról van szó, hogy a késleltetés növelése és a memóriaigény emelése árán biztosíthatod a jobb szinkronizációt tripla pufferelés mellett. De attól, hogy három képkockapuffered van, még a GPU erőforrásai nem nőnek meg, vagyis az éppen számolt képkocka mellett elkezdi számolni az következőt is a GPU, azaz valamekkora mértékben megtörténik a képkockák párhuzamos számítása. De ne úgy képzeld ezt el, hogy egyszerre elkezd két képkockát számolni, és egyszerre el is készülnek azok, hanem amikor az n képkocka számítása a vége felé jár, akkor már elkezdődik az n+1 képkocka számítása, a parancsok parancspufferekből történő behívásával. Ez az oka annak, hogy minél jobban növeled a képkockapufferek számát, annál inkább nő a késleltetés 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
Jack@l
#35858
üzenetére
Nem kell nőnie, mert nincs több erőforrásod a hardver oldalán, de persze nagyon picit nőhet, viszont a mértéke elhanyagolható. Az történik, amit leírtam. Amikor az n képkocka számítása a végéhez közelít, akkor az n+1 elkezdődik. Ezzel lesz átfedés, mivel a feldolgozás egy részében van olyan pillanat, amikor két képkocka számítása zajlik párhuzamosan. Ez teljesen normális, mivel egy grafikus vezérlő heterogén processzornak tekinthető, vagyis amikor az n képkocka már nem terheli a parancsmotorokat, a tesszellátort, stb., akkor az n+1 képkockának eléggé szabad az út, hiszen azok aktuálisan malmozó részegységek. Emiatt az átlapolás a mai driverekben egy abszolút használható stratégia. Az más kérdés, hogy ennek a késleltetésben komoly ára lesz szinkronizálás mellett.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35880
Abu85
HÁZIGAZDA
Petykemano
#35877
Abu85
HÁZIGAZDA
válasz
Petykemano
#35877
üzenetére
Teljesen mindegy. A Pro driver lecsupaszított. Ezért van ugye a Gaming mód, hogy a Professional módot ne kelljen mérgezni a trükkökkel. Érdemes kipróbálni, aki szerez magának Radeon Pro VGA-t. A gaming mód sokszor háromszor is gyorsabb a játékokban, de jóval lassabb a professzionális programokban. A Professional mód a fordítottja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35891
Abu85
HÁZIGAZDA
Petykemano
#35885
Abu85
HÁZIGAZDA
válasz
Petykemano
#35885
üzenetére
Az átváltós driver nem pont így működik. A gaming driver alapesetben fel sem megy a Radeon Pro megoldásokra. Az AMD igazából egy fejlesztői igényre reagált a meghajtóváltással, ugyanis a játékfejlesztőknek nagy probléma, hogy nekik kellene a professzionális támogatás a munkához, de akkor csak úgy tudják valós környezetben tesztelni az eredményt, ha az adott gépbe raknak még egy VGA-t, amin már nem professzionális meghajtó fut. Ez egy probléma, mert nem csak költséges, hanem körülményes is.
A Frontier Edition sorozat pont erre reagál azzal, hogy van egy alap professzionális meghajtó, ami jó a munkára, és mellé még két gaming meghajtót lehet telepíteni. Ideális esetben egy véglegeset, és egy tesztmeghajtót. Ez a munkát jelentősen leegyszerűsíti, mert pro és a tesztmeghajtóval dolgozol, és az eredményt lényegében azonnal lehet ellenőrizni olyan környezetben, amilyen a usernek van. Ez a lényege az egésznek.A Radeon Pro alapvetően egy professzionális sorozat, a Frontier Edition ami a kevert megoldás, arra van gyári szinten ilyen támogatást. Persze aki Radeon Prót vesz elérheti, ha kéri, de ez egyedi meghajtónak minősül, amiért fizetni kell az AMD-nek. Valahol ez is megéri, mert gyakorlatilag sokkal egyszerűbb rendszert kapsz, és megúszod a több VGA alkalmazásából eredő kellemetlenségeket, amit igazából egyik gyártó sem kezel support szintjén. Gyártón belüli párosítással az AMD azt fogja mondani, hogy ez nem ajánlott konfiguráció, ha meg GeForce kerül a Radeon Pro mellé, akkor a két cég egymásra fog mutogatni.
Manapság ezek miatt a kiadás előtt nem tudsz igazán tesztelni. Főleg nem Radeon Próval, amire a gaming driver egyedi támogatás nélkül nem is települ fel.
(#35890) Jack@l: A jelenlegi doksik alapján elég sok dolog változott. Maga az ISA sem ugyanaz. A GFXIP 906-os iterációt használja, ami a Vega 10-hez képest hárommal modernebb. Valószínűleg nem kell a meghajtót nagyon újraírni, de az alkalmazásprofilokat azért nem árt bemásolni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35940
Abu85
HÁZIGAZDA
Petykemano
#35939
Abu85
HÁZIGAZDA
válasz
Petykemano
#35939
üzenetére
A Colorful/ColorFire nem a TUL márkája. Ők külön cég, bár tudtommal kevés tulajdonrésze van benne a TUL-nak. De nem TUL-PowerColor szintű a kapcsolat, hanem csak szimplán üzleti.
Az történik, hogy a Colorful a ColorFire kártyákat nem adja el többé, hanem az ASRock megrendeléseit teljesítik. Ennek több előnye van. Egyrészt az ASRock olyan piacokat is célozhat, amit a Colorful nem tud, így több Radeon VGA-t tudnak gyártatni és eladni, emellett pedig az ASRock viseli a support és az egyéb költségeket. Persze hátrány, hogy így kevesebb egy VGA-n a haszon, de gondolom kiszámolták, hogy a többletrendeléssel megéri.Sosem próbálta megakadályozni az AMD az ASRock európai megjelenését. Ez kamu volt. Az EU-s piacra más dobozok kellenek, erre fel kell készülni, tehát hiába vannak kártyáid a kínai piacra, azokat legalább egy hónap hitelesíteni Európába, és megfelelni az itteni törvényeknek. Szóval a belépés nem volt megoldható áprilisban.
[ 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
Televan74
#35958
üzenetére
Eleve a FreeSync 2 nem abból a szempontból vizsgálja a monitort, mint a DisplayHDR. Az rendben van, hogy vannak bizonyos minimum követelmények, de a FreeSync 2 HDR olyan dolgokat specifikál elsődlegesen, amiket a VESA nem is néz. Ilyen például a közvetlen HDR transport, ami VESA-ban nem létezik. Valószínűleg később sem fog létezni, hacsak az API-kat fejlesztő érintettek fel nem karolják a kijelzőoldali tone mapping problémáját, és nem kínálnak egy megoldást rá, amit egyébként lehet, de azzal meg az a probléma, hogy az addig kialakított HDR pipeline-okkal nem kompatibilis. Az AMD azért csinálja, mert ők írtak maguknak egy saját HDR pipeline-t, arra biztosítottak az API-kra kiegészítéseket, így azt közvetlenül elérhetik a fejlesztők. Ilyen formában a HDR-ben a fejlesztő nem csak egy utazó a HDR transport mögött, hanem szoftverben megírhatják a HDR transport feltételeit. Ezért is kell API szinten kezelni az FreeSync 2 HDR-t, mert ehhez le kell kérdezni a kijelző adatait. Na most lényegében ezeket az adatokat specifikálja az AMD, és a kompatibilis monitorgyártóknak kötelező az információt bejuttatni a rendszerbe, amivel már a program számolhat is.
A szabványos HDR pipeline-ok ennél jóval egyszerűbbek. Nincs lényegi információ a kijelzőről, így gyakorlatilag a HDR transport mögött már csak utazik a kép, vagyis az utolsó tone mapping fázis a számítógép felől befolyásolhatatlan.Nagyon egyszerűen megfogalmazva a mai HDR szabványokkal a teljes pipeline-on a HDR transportig befolyásolható a kép a program oldaláról. Utána már nem, és lesz is egy olyan lépcső, ami gyakorlatilag befolyásolhatatlan. A FreeSync 2 HDR csak annyit csinál, hogy ezt az utolsó lépcsőt kivágja, és az egyel korábbi lépcsőre osztja vissza a feladatait, ami a program oldaláról még befolyásolható lépcső.
[ 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
#35993
üzenetére
Teljesen mindegy, hogy mi lesz a konzolokban, SoC vagy nem SoC. Az AMD-n kívül nem kínál senki más olyan üzleti konstrukciót, amit a Sony és a Microsoft keres. Ez a Semi-Custom átka a megrendelők felé. Egy idő után annyira függővé vállnak a kiszolgálótól, hogy nincs hova menni, az AMD-nél van az összes IP-jük fizikai dizájnja, amit ők könnyen be tudnak építeni a saját dizájnjaikba. Nem tudnak mást választani, mert egyrészt egy csomó cég ezeket a dizájnokat be sem építi, még igényre sem, másrészt annyira át kellene alakítani azokat, hogy kompatibilisek legyenek a más partnerek által használt tervezőkönyvtárakkal, hogy arra se pénz, se erőforrás, se akarat. Nyilván az AMD nem fogja odaadni nekik a saját tervezőkönyvtárát, tehát mindent újra kell terveztetni valaki mással.
Ebből a helyzetből csak úgy tud szabadulni a Microsoft és a Sony, ha lemondanak minden olyan fejlesztésükről, amit az elmúlt nyolc évben dolgoztak ki, és akkor tudnak venni egy tömegeknek szánt kész lapkákat másoktól is, ahogy például a Nintendo is tette a Tegra esetében. A gond ezzel annyi, hogy lópikula lesz a teljesítménye, miközben elég sok pénzbe kerül, hiszen nincs egyedi megrendelés, ehhez szabott üzleti feltételekkel.[ 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
#35995
üzenetére
Ha ez ennyire egyszerű lenne, de a helyzet az, hogy a Sony és a Microsoft saját IP-ket is fejleszt, míg mondjuk egy rakás OEM nem. Ez a Semi-Custom bája és egyben rákfenéje. Ezek az IP-k a Sony és a Microsoft számára úgy lesznek meg fizikailag, hogy az AMD Semi-Custom részlege elkészíti a logikai dizájnból, méghozzá a megrendelő mérnökeivel közösen, és ez a fizikai dizájn az AMD tervezőkönyvtáraival lesz megalkotva, hogy kompatibilis legyen az AMD saját IP-ivel, a teljes lapkára kialakítva a saját routingot. Ilyen formában például semmit sem tud vele kezdeni mondjuk az Intel, mert más tervezőkönyvtárakat használnak, és már szimpla legózással sem lesz kompatibilis az IP. Ezt újraterveztetni igen nagy költség, főleg amiatt, mert a legalsó szoftveres réteget is újra kell írni a nulláról, és nem egy ilyen IP van a mostani konzolokban, hanem több tucat. Szóval a Sony és a Microsoft számára igen kedvezőtlen bárki máshoz menni a következő generációban, mert mindent, amit az elmúlt nyolc évben megalkottak közel a nulláról újra kell tervezni, míg az AMD-nél maradva egyszerűen le lehet portolni az egészet egy új lapkába, elvégre a Semi-Custom fő célja az egyedi dizájnok kialakítása, vagyis a birtokolt fizikai dizájnokat mindig egymáshoz legózhatóvá tervezik.
Az OEM-eknél azért sokkal könnyebb, mert ők nem adnak semmit egy kész lapkába. A legnagyobb teher a platform leváltásánál a nyomtatott áramköri lap áttervezése, és némi szoftveres probléma, ami aránylag olcsón megoldható. Ilyen szerencséje a Sony-nak és a Microsoftnak nincs. Nekik a beszállító leváltása rendkívül extrém költségekkel járna, annyira komollyal, hogy jobban megéri minden technológiát elengedni, amin az elmúlt évtizedben dolgoztak az AMD-vel. Kérdés persze, hogy erre megvan-e az akarat. Ha mondjuk nem találnak olyan partnert, aki tényleg tud egyedi igényekhez lapkát tervezni, akkor nincs értelme váltani sem. Már csak azért sem, mert az AMD-ben már megbíznak, hogy a titkaikat nem szivárogtatják ki harmadik félnek, ami egy komoly szempont, hiszen mégis dollármilliós nagyságrendű kutatásokat kell megosztani egy konkurenssel.
[ 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
stratova
#36007
üzenetére
Polarist nem érdemes erőltetni. Borzalmasan drága a GDDR5 és a GDDR6 is, márpedig HBCC nélkül 8-12 GB kellene a kártyákra. Sokkal olcsóbb egy 4 GB-os HBM2 stack és HBCC-vel hátránya sincs. A másik probléma a Polarisszal, hogy nincs benne rapid packed math, ami az egyik leginkább nyomott fícsőr a játékfejlesztők oldalán. Az Ubisoft (Dunia, Snowdrop), a Bethesda (ID tech), az EA (Frostbite), a Rebellion (ASURA), a Croteam (Serious Engine), a Flying Wild Hog (Road Hog Engine) támogatja, illetve támogatni fogja.
Az új Frostbite-ban látszik is, hogy mennyire jól működik ez a Battlefield V-ben. A mostani DX11-es módban a Vega 64 ott van a GTX 1080 Ti nyakán. És ez ugye még csak a high beállítás, aminek a VRAM igénye az ultra mód fele. És itt szintén hátrányban lenne a Polaris, mert 16-20 GB közötti fedélzeti tár kellene rá az ultrához, de HBCC-vel elég lenne fizikailag 4 GB is.
Ezeket a Polarisba nem tudják beletervezni, és olyan mértékben nyomják a fejlesztői oldalon, hogy egy újabb Polaris már komoly hátrányban lenne.[ 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
Looserke
#36013
üzenetére
Össze, de a GDDR6 annyira drága, hogy értelmetlen ezzel tökölni. Az AMD-nek nem kritikus fontosságú, hogy 12-24 GB-os kártyákat hozzon a következő körre, mert ők 4 GB-tal is elvannak a HBCC miatt. Az NV-nek ez azért fontos, mert nekik nincs lapalapú memóriamenedzsmentjük a hardver oldalán. Nyilván az AMD-nek nem jelent különösebben nagy problémát az, hogy a BF5 ultra módja 4K-ban a 16 GB VRAM-ot is túllépi terhelésben, mert a mostani Vegával annyit kell hozzá csinálni, hogy megnyitod a meghajtó vezérlőpultját és a HBCC szegmens csúszkáját 16 GB-ra húzod.
(#36014) HSM: Addig nincs vágott Vega, amíg elviszik a lapkákat Vega 56-ként is. Van egy gyártási mennyiség, amit tudnak biztosítani, és nyilván a legdrágábban válnak meg tőle.
[ 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
Looserke
#36017
üzenetére
Ez mindenkinek a saját döntése. Aki a meghajtóba nem nyúl bele az jellemzően a játék beállításait sem matatja, hanem jó a default medium szint, amit a játék nagy biztonsággal beállít magának. Az AMD csak a lehetőséged adja meg arra, hogy mehessen az Ultra is, ha a júzer ezt akarja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ahhoz is az kell, hogy ne vegyétek a mostani felhozatalt. Nyilván nem a töküket vakargatták a mérnökök az elmúlt egy évben, de a termékek kiadását ideálisan kell időzíteni, és a mostani helyzet egyáltalán nem ideális arra, hogy újjal jöjjenek elő. És ez nem csak az AMD meglátása, az NV sem adott ki semmit. Ezt okkal teszik. Úgy látják, hogy a júzerek még veszik a mostani kínálatot is. Na meg a bányászláz lecsengésével egyre több ragad a raktárakban. Azokat előbb el kell adni.
Ugyanannyi rendszermemória kell hozzá, mint a szoftveres allokáció-alapú menedzsmenthez. A különbség annyi, hogy a szoftveres ezt on the fly foglalja be, míg a lapalapú a kijelöléskor. Annak a teoretikus 8 GB rendszermemóriának egy mai játékban nagyjából a fele shared terület lesz, amit a CPU és a GPU is elérhet. A HBCC-nél ezt a shared területet előre kell befoglalni. De ettől nem használ a játék több rendszermemóriát, csak meg lesz határozva, hogy a shared terület a HBCC szegmensen belül legyen.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pont az az érdekes, hogy nem kell több. Az az elképzelés alapjaiban hibás, hogy a grafikához csak a VRAM van használva. Rengeteg adat a rendszermemóriában van. A hagyományos menedzsment innen másolja az allokációkat a VRAM-ba, de hiába tűnik el a rendszermemóriából az allokáció, ezek mérete eltérő, és annyira fragmentált lesz maga a terület, hogy nehéz beszúrni harmadik allokációt kettő már elhelyezett közé. A HBCC csak azokat a lapokat helyezi át, amire szükség van, és ennek az a hatalmas előnye, hogy mindegyik lap mérete ugyanaz, tehát ha elviszel egy lapot, akkor tuti vissza tudsz rakni egy másikat, amit már nem használsz, mert pont annyi üres terület alakult ki a rendszermemóriában, amennyire szükséged van a művelethez. Emiatt még némileg kevesebb terület is kell hozzá. Az allokációk valós idejű defragmentálásával lehetne jobb a hagyományos modell, de ezt igazából csak a konzolokon szokás alkalmazni.
(#36022) stratova: Nehezen tud lejjebb játszani. A memória drágulása a középkategóriát érinti a leginkább. Itt egyrészt túl olcsók maguk a VGA-k (a régi ár szintjén), másrészt tipikus, hogy magas órajelű GDDR5 lapkákat használnak, amelyek háromszorosára drágultak másfél év alatt. Nem véletlen, hogy a VGA-gyártók nem akarnak visszatérni a régi árazáshoz. Nem fér bele.
Ez itt nagyrészt már gazdasági kérdés. Alapvetően az fogja meghatározni a középkategória sorsát, hogy a felhasználók hajlandók-e megfizetni a nagyobb árú termékeket, vagy inkább elfogadják az IGP-ket helyette.[ 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
stratova
#36024
üzenetére
A mostani memóriaárakkal két oldalról lőheted magad lábon. Ha kétszer szélesebb a busz, akkor kétszer több memórialapka kell, ami nem olcsó, még akkor sem, ha alacsony az órajele. Szűkebb busszal elég feleannyi memória, de ez sem olcsó, ha magas az órajel.
A DCC ezen semmit sem segít. A memória mennyiségével van probléma nem pedig a sávszélességgel. Ezen a HBCC tud segíteni, amivel elég fizikailag is kevesebb memóriát használni.Éppenséggel le se kell menni. Az RX 570 mobil szinten 80 wattos TDP-vel van árulva. Itt már rég nem az órajelekről szól ez a dolog, hanem arról, hogy milyen limitet állít be a BIOS. A PowerTune úgyis hozzáigazítja az órajelet.
[ 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
stratova
#36026
üzenetére
Az Intel és az AMD már teljesen másképp gondolkodik, mint az NV. Ők nem keresik a mindenáron történő eladhatóságot. Nekik jó lesz az, hogy pGPU-val árulják a CPU-ikat, és ha a notebookgyártó azt kifizette, akkor utána letilthatja, és vehet egy dGPU-t, amit még egyszer kifizet. Ez a koncepció ide. Az Intel is ezért csinál magának saját pGPU-t. Akkor is eladják, ha a notebookgyártó letiltja, hiába nem működik, az ára bele lesz számolva a noti árcédulájába.
[ 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
Oliverda
#36028
üzenetére
Egyszerű. Az Intel nem adja bármi áron a Kaby Lake-G-t, az AMD sem a Radeonokat. Előbb-utóbb övék lesz ez a piac, mert nem lesz olyan notebookgyártó, aki a CPU-k mellé csomagolt pGPU-t letiltja azért, hogy vegyen helyette egy dGPU-t. Ez anyagi szinten őrültség lenne, mert se az AMD, se az Intel nem fogja nézni, hogy mi a felhasználók és a notigyártók érdeke. Ők abban érdekeltek, hogy a mobil CPU melletti GPU-t akkor is eladják, ha a notigyártó nem is fogja használni. És természetesen ezt nem teszik majd olyan olcsón, mert procira szükség van notiban, és az árazással kikényszerítik azt is, hogy a partner rá se nézzen a konkurens dGPU-ra, meg se forduljon a fejében, hogy letiltják a pGPU-t. Mondhatni árazópisztolyt tartanak majd a fejükhöz. Ez sajnos megritkítja majd a választási lehetőségeket, és gyakorlatilag kivégzi a gyártók keverését is.
(#36029) stratova: Az EMEA az nem probléma. Inkább Európa keleti része az. A kis piaccal pedig finoman fogalmazol. Emlékszem, amikor az MSI hozta be ide a gamer notikat. Ők mesélték, hogy a magyarországi darabban mért elvárást egy kézen meg tudod számolni ezekre a gémer cuccokra. Azon nevettünk még régen, hogy a HP eladott két drágább gamer notit anno, és viccesen mesélte az akkor még MSI-s ismerősöm, hogy egyben teljesítették két évre is a kvótájukat. És akkor ezzel számszerűsítettem az itteni piacot.
Azóta ugye a forint sokat romlott, a gazdaság sem javult igazán, több gyártó ki is vonult innen, mert az egy eladás is álom kategória.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
Raymond
#36038
üzenetére
Megkérdeztem, hogy az high->ultra váltás miért jár csupán 1-3 fps sebességcsökkenéssel, holott korábban azért többet okozott. Erre kaptam azt a választ, hogy az ultra mód magasabb felbontású textúrái, illetve modelljei nincsenek szállítva a zárt alfában. Egyrészt azért, mert így helyet spórolnak meg, és a hibákat kiszűrik max grafika nélkül is, másrészt alig van olyan VGA, amin annyi VRAM van, hogy eltűrné a 4K-s textúrákat 4K-s felbontáson.
A mostani zárt alfa egyébként 1K-2K-s textúrákkal van szállítva. A véglegeshez már lesznek 4K-sak is. Gyakorlatilag ez lesz az első Battlefield, ami sok 4K-s textúrát is kap.(#36037) Oliverda: Nyilván nem, csak a nagyobb teljesítményűek mellett. Az U-s modelleknél megmarad az IGP. De az Intel ezt a terméket eladásra tervezi, nehogy azt hidd, hogy nem rakják oda.
Az AMD-nek nulla pGPU-ja van. Később persze lesz, ők tudják követni ide az Intelt. Sok reményük nekik sem lehet abban, hogy az Intel pGPU-ja mellé bárki is rendelni fog még egy GPU-t.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#36047
Abu85
HÁZIGAZDA
huskydog17
#36046
Abu85
HÁZIGAZDA
válasz
huskydog17
#36046
üzenetére
Ki beszél gyártóspecifikus megoldásról? Az RPM már szabványosítva van a Vulkan 1.1 API-ban, és a DX12-ben is benne van a shader modell 6.2-ben, bár utóbbi csak októberben lesz véglegesítve. Abszolút nem gyártóspecifikus már. Az így írt kód is működik akármin. Az Intelnek is van ugye ehhez megfelelő hardvere. A mostani támogatást ne vedd számításba, nyilván az Ubisoft vagy az Bethesda nem tudott sokat tenni a szabványos megoldásért akkor, amikor fejlesztették a Far Cry 5-öt és a Wolf 2-t. Átírni ezeket szabványosra nem túl szerencsés már, főleg kiadott játéknál. De a jövőben mindenképpen a szabványos megoldás felé mennek el, mert a mostanival csak a Radeonokat tudják célozni, míg az idén elérhető szabványokkal mindent.
Egyébként mindketten Radeonokat kaptak pár hete a fejlesztésekhez. Az Intel most még nem pont olyan játékokat vadászik, amiket a Croteam és a FWH készít (bár maradnak az Ubi partnerei a következő Assassin's Creedre, a Kaby Lake-G miatt kellenek már a komolyabb címek is), míg az NV problémás a Vulkan miatt. Maradt az AMD, arra van is elég erős integrált támogatás a Renderdocban, amelyik debuggert Vulkan mellett főleg használják a fejlesztők.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#36054
Abu85
HÁZIGAZDA
huskydog17
#36050
Abu85
HÁZIGAZDA
válasz
huskydog17
#36050
üzenetére
A szeretetcsomagot a Vulkan miatt kapták. Ezzel az API-val RenderDoc nélkül nem nagyon tudsz elboldogulni, és a RenderDoc ma már eléggé hozzá van kötve az RGP-hez, ami viszont megköveteli a Radeont (Fiji vagy újabb). Másképp a debug-profilozásra vonatkozó interoperabilitás, mint idei húzófícsőr nem működik. Az egyébként tervben van, hogy a jövőben biztosítanak más profilozónak is interoperabilitást, de ahhoz előbb nyílt forráskódúvá kell tenni az adott profilozót.
Az Intel GPA esetében szó van erről, de még csak most alakították át a szoftveres részleget, és nemrég döntöttek arról, hogy egyre több dolgot tesznek nyílt forráskódúvá. Időbe fog telni, amíg erre átállnak. Mindenesetre nagyon jó a Vulkan driverük, tehát van keresnivalójuk ezen a területen. Amikor kész lesz a saját pGPU-juk, akkor már fejlesztőeszközökben is elérhetik azt a szintet, amit az AMD ad. Addig pedig a Kaby Lake-G-vel úgyis profitálnak mindenből, amit az AMD csinál. Ügyes volt aki ezt kitalálta.Ahogy írtam az RPM az már nem egy zárt megoldás. Természetesen az AMD-nek működnek még az erre vonatkozó kiterjesztései, de ezt maximum akkor érdemes használni, ha kell DX11-es portot szállítani. Az ugyanis szabványosan semmiképpen sem megoldható, csak az AMD kiterjesztéseivel. DX12-től kezdve viszont ezekre nincs szüksége egy fejlesztőnek, egyszerűen ott van benne a shader modell 6.2-ben a szükséges tudás, ahogy a Vulkan 1.1 is támogatja. Hardveres szempontból pedig lényegesen jobb a szabványos megoldás, mert az AMD zárt konstrukciója ma már csak Vegán működik, míg a szabványos GCN3/GCN4/GCN5-ön és Intelnél a Gen8-től felfelé, valamint működni fog a következő generációs NV-n is. És nem kevés sebesség van ezekben a packing optimalizálásokban. Egyes eljárásokat a duplájára lehet velük gyorsítani. De még a rosszabbik struktúrával is 2/3-dal gyorsabb lesz a számítás. És ami még kedvező, hogy automatikusan kezeli a regiszter/LDS pressure problémát, amitől egyébként a Croteam és a FWH is rohadtul szenved egy ideje, mert szoftveresen az übershaderekre épülő programozási módszerekkel nem lehet velük mit kezdeni. Egyszerűen a statikus erőforrás-allokáció marhára pazarló. Akkor is be kell foglalni az erőforrást, ha alig fogod használni, és amíg a shader fut, addig nem szabadítható fel, függetlenül attól, hogy a programozó tudja, hogy marhára feleslegesen van befoglalva.
[ 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
stratova
#36055
üzenetére
Ha átállnak, akkor az Intel sose kerül vissza. Már most sokkal rosszabbul teljesítenek a Metal API-val, mint az AMD megoldásai. Számos újítást csak emulálnak. Az argumentum puffer például a Metal 2 fő fícsőrje és az Intel IGP-i nem támogatják hardveresen. Mondjuk persze a DX12 és a Vulkan hasonló megoldását sem, de a Metal esetében egy olyan implementáció van, amiben sokkal jobban fáj az emuláció. Egyébként valószínűleg nem lenne ebből probléma, ha a terveknek megfelelően már a Cannon Lake IGP-je dolgozna a rendszerben, ami egyébként hardveresen támogatja a DX12-ben az ExecuteIndirectet, és valószínűleg az argumentum pufferrel sem lenne különösebb problémája.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#36060
Abu85
HÁZIGAZDA
huskydog17
#36059
Abu85
HÁZIGAZDA
válasz
huskydog17
#36059
üzenetére
Oda nekik igazából ez kell: VK_KHR_draw_indirect_count. Legalábbis akkor, ha GPU-driven pipeline-ra mennek, de meglepődnék, ha ilyen számok után brute force lenne alkalmazva. Azért oké, hogy explicit API, de a százezer ellenfél ez nem csak százezer rajzolás, hanem több, és kvázi nyolc mag lenne a minimum. Szóval kellenek a trükkök. Akár nagyobb váltást is el tudok képzelni, mondjuk texel shadinget. De az elég nehéz, durván felrúgná a mostani production pipeline-t, függetlenül attól, hogy marha sok előnye van.
Az emberek jönnek mennek, nem áll le ettől a cégeknél az élet.
[ 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
Valdez
#36062
üzenetére
Ezek leginkább annak az eredménye, hogy az AMD GPU-k egyedi shadereket futtatnak. Arányaiban a Frostbite Team jár a legelőrébb az AGS 4/5 kihasználásával, tehát nekik van a legtöbb olyan nem szabványos shaderük, amelyeket az AMD futtathat, de más hardver nem. Ezért is kötött velük szerződést az NV, mert ők is szeretnének részesülni ilyen dolgokban, csak ez időben sem egyszerű, mert az, hogy az AMD-nek már ennyi külön kódja van az bő két éves munka eredménye. Tehát előbb kellenek a függvények az NVAPI-ba, aztán azokat jól kell tudni használni. Kell hozzá egy megfelelő fordító, ami a PSSL kódból csinál nem szabványos, de az NV driver számára is emészthető bájtkódot. Szóval ez leginkább idő kérdése. Az AMD ehhez már nem tud sokat hozzátenni, amit lehetett azt alkalmazza a Frostbite, így most a Bethesdánál csinálják ugyanezt.
Hasonlót egyébként elérhet az NV, mert tényleg csak szervizkönyvtár és fordító kérdése az egész. Ha beleölnek hasonlóan három évet, ahogy az AMD tette, akkor eljuthatnak oda, ahova szeretnének.[ 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
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.
- Az USA tisztifőorvosa figyelmeztető címkét ragasztana a közösségi médiára
- Fával ékesíti magát a Jonsbo Mini-ITX gépháza
- Sorozatok
- Rejtett díjak, nehéz lemondás: az USA pereli az Adobe-ot
- Autós topik
- Milyen billentyűzetet vegyek?
- Milyen NAS-t vegyek?
- Tudományos Pandémia Klub
- Napelem
- Mini-ITX
- További aktív témák...
