- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Milyen belső merevlemezt vegyek?
- Fujifilm X
- ASUS ROG Ally
- VR topik (Oculus Rift, stb.)
- Milyen egeret válasszak?
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Steam Deck
- Vezetékes FEJhallgatók
- Háromféle processzor is része lesz a Core 200 sorozatnak
Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Konzolokra is megjelenik a Fera: The Sundered Tribe
gp A kooperatív szörnyvadászós játékhoz a minap egy friss trailert kaptunk.
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Azért egy OpenGL ES 3.0-s támogatást ki lehet használni simán, hiszen erre fognak épülni az új mobil játékok. Miért is maradnának a fejlesztők az OpenGL ES 2.0-nál, amikor az API funkcionálisan tartalmaz komoly hibákat. A hardverek az ES 3.0 támogatás hiányában az előző API működésbeli hibáit is a hátukon viszik. Igazából pont az NV-től nem vártam, hogy nem érdekeltek a fejlesztői munka megkönnyítésében. Gyakorlatilag már mindenkinek az új fejlesztése kompatibilis az ES 3.0-val, egyedül az új Tegra ragadt le. Igazából nem tudom, hogy miért. Az OpenGL ES 3.0 nem csak egy szimpla ráncfelvarrás, hanem egy alapjaiban hibása specifikált API-t újít fel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igazából a DX-es dolgokat érteni lehet. Az OpenGL ES esetében nincs indok a 3.0 ellen, mert nem vezet be olyan hardveres újításokat, ami egy olyan architektúrát, mint a GeForce ULP hátrányosan érint. Esetleg amit el tudok képzelni, hogy minden újításra saját kiterjesztést akarnak, ami aztán hátrányosan érinti a többiek hardverének támogatását. Ez egy opciós dolog, mert a TegraZone tervekbe a Chainfire3D alaposan belepiszkított, hiszen Tegrának hazudta a konkurens hardvert és rögtön működtek rajta a THD játékokban letiltott effektek, amik marketingben Tegra exkluzívok.
A DX11-es Conservative Depth Bufferre a Microsoft elfogadja az emulálást is. Nem kötelező a hardver oldaláról támogatni. Ez rendben van az NV oldalán is. Igazából csak sebességet vesztenek vele a hardveres implementációhoz képest. A mostani DX11.1-ben is rengeteg opcionálisan támogatható szolgáltatás van. Ez szerintem normális az MS részéről. Nem lehet tökéletesen szabványosan ennyi hardvert kiszolgálni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez hülyeség. Direkt azért terveznek butára egy hardvert, mert úgyis újat vesz a júzer egy év után. Szerintem öngyilkosság egy cégnek így gondolkodni. Amit lehet azt az új fejlesztésekbe be kell építeni. A Tegra 4 úgy járhat, mint a Tegra 3. Agyon lesz marketingelve, és utána az NV-nek meg nem tetszik majd, hogy minden vállalat hozzájuk méri az új fejlesztések teljesítményét, amelyek meg lazán ripityára verik. Az Apple sem viccből mér a Tegra 3-hoz. A Qualcomm és a Samsung lapkákat nehéz verni. A Tegrát könnyű, ráadásul meg sem kérdőjelezik az egészet, mert a Tegrának a legnagyobb a marketingje.
Nem azt mondom, hogy alkossanak forradalmit, bár tőlük pont ezt várom el, mert a folyamatos felzárkózás nem az NV szokása. Amit igazából problémának tartok az az OpenGL ES 3.0 támogatásának hiánya. Ez egyáltalán nem lenne forradalom, de fontos szempont lenne, mert a 2.0-s verziója az API-nak egy kifejezetten gyűlölt felület a sok hibája miatt. Az, hogy nem támogatnak OpenCL-t, meg más fontosabb szabványokat az az ő bajuk, maximum nem tudnak reagálni a legújabb szoftveres fejlesztésekre, de az OpenGL ES 3.0 az 2013-ban kötelező. Hidd el egyik fejlesztő sem azért használ OpenGL ES 2.0-t, mert tetszik nekik, hanem azért, mert nincs alternatívája. Magát a 2.0-t a halálba kívánják, mert egy hibás specifikáció miatt minden hardverre egyénileg kell optimalizálni a programot.(#9) Bici: Még mindig meggyőződésem, hogy a Kepler szerepet kap majd a Tegrában, de valszeg később. A Tegra 4 eléggé laza fejlesztésnek tűnik. Semmi forradalmit nem mutattak be. Mindenképp a unified shader felé kell haladni, mert az hatékonyabb, és az egyetlen architektúra, ami Tegra szintre leskálázható az NV-nél az a Kepler. Az persze kétségtelen, hogy egyszerű számítások mellett egy hasonló méretbe belepakolt Kepler nem lenne annyira gyors, mint a mostani GeForce ULP. Bonyolult compute számításokat pedig ez a hardver nem is tud elvégezni, míg a Kepler igen.
(#11) juzer78: Nyilván a Tegra 4-en az OpenCL eleve tipli. De igazából ez a legtöbb mai hardveren az. Az új Mali-T600, a PowerVR G6000 és az Adreno 300 sorozatok támogatják normálisan az OpenCL-t. Valszeg a Google is akkor engedélyezi, amikor ezek a hardverek már elég tesztelésen mentek át. A Tegra 4 nyilván ebből a buliból teljesen kimarad. Egyébként első körben az NV nagyjából annyiból fog kimaradni, hogy a Tegra 4-es tablet képtelen lesz a fényviszonyokhoz igazodni. A gyártók elsősorban azért vizsgálják az OpenCL-t, hogy a tabletekre kerüljön egy szenzor, ami a fényviszonyoknak megfelelően állítja a megjelenített kép kontrasztját. Ezzel a nagyon sokat fogyasztó panelek extrém fényerejére nincs szükség. Eleve maga az egész jelenség egy kontrasztprobléma, amit eddig tévesen jobb fényerejű panellel próbáltunk orvosolni. Eredménye van, de az IGP erejéből átszámolni a kép kontrasztját sokkal hatásosabb és energiatakarékosabb. Ehhez még egyéb paraméterek is bevehetők. Nagyjából ez lesz az OpenCL első felhasználási területe. A CUDA szerintem már eleve egy veszett ügy a mobil szinten.
A hardvergyártók már két-három éve megkapták, hogy milyen hardvert kell tervezni. Szóval az NV is tudott volna ilyet, csak nem akartak. A TIR speciel nem lenne számukra probléma. Szerintem a Kepler esetében eleve a compute herélésére mentek. A DX11.1 pedig lehetővé teszi, hogy minden shader futószalagról kitehess számítást compute shaderre. Ez a fő gondjuk szvsz. Nem akarják, hogy a compute shader annyira terjedjen.
Az opciós dolgok olyanok, mint a SAD4 utasítás. Ezt nem kötelező támogatni. Valszeg később szabványos opció lesz, de ma még csak a Radeonok tudják használni. Sőt, meggyőződésem, hogy az AMD beszélte rá az MS-t, hogy építsék már be az opciós támogatást.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nyilván a rootolás eleve kockázat. Ettől függetlenül rengetegen megcsinálják.
(#14) Bici: Szerintem sehogy. Az MS több mint valószínű, hogy egy saját szabványt akar erre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én eleve nem váltottam le az Android telómon a 2.3-as Androidot, pedig van 4.0-s frissítés. Egyszerűen nekem nem éri meg, hogy elveszítsem a flash támogatást, de nyilván a többi korlátozást is szeretném elkerülni.
Új telefont nyilván nem mernék rootolni, de egyelőre attól is messze vagyok, hogy telefont vegyek 3.0+ Androiddal. Szimplán nem akarom magam ennyire megkötni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Ezt tőlük kell megkérdezni.
A TIR az egyik dolog csak.
A DX 11.1-gyel a DX 11 tudása is kiegészült opcionális technikákkal. Ezeket más DX 11-es GPU-n is aktiválni lehet. Persze a programot úgy kell megírni, hogy be is aktiválja.Nyilván a fogyasztás lehet az egyik legfőbb indok, amiért az NV hátat fordított a Fermi compute irányának. Ezért gondolom, hogy a Kepler egyszer benne lesz a Tegrában, mert ha nem, akkor a döntés hibás volt.
A SAD utasítást használja számos lejátszó (még a QSAD-ot is használja a VLC), csak OpenCL-lel. A DirectX 11.1-be azért kerülhetett bele, mert ott az UV API, amivel egyszerűbb lehet elkészíteni a támogatást.
(#26) lenox: Mert csak a kontraszt és a fényerő állításával részletek is elvesznek. Egy elég komplex számítás, amivel ez megoldható. Ebben az Apical a jártas. Ők kínálnak ehhez hardveres megoldást, de ma már szoftveresen dolgoznak, mert a hardvert kevesen szeretnék beépíteni, így megoldják a számítást az IGP erejéből. Ehhez ma OpenCL érhető el. Valószínű, hogy mindegyik ilyen funkcióval felvértezett termék az Apical technikáját használja majd. Egyébként van CPU-s implementáció is, csak a fogyasztás miatt nem ez az ajánlott.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez eleve magával hozza a herélést, mert a feldolgozók száma nő, akkor a számítási kapacitás nő, de a hatékonyság már mástól is függ, így a compute hatékonyság összességében csökkent a Fermihez képest. Cserébe jobb lett a fogyasztás, viszont minden új, compute igényes DX11-es játékban hátrányba kerülnek a konkurens architektúrához képest. Igazából pont most volt a legrosszabb meglépni ezt, amikor a fejlesztők megkapták az eszközt, hogy használják is a compute shader előnyeit.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pár Qualcomm már 3.0-s és a PowerVR G6000-re is érkeznek a lapkák. Még nincs mind bejelentve. Ezzel a cégek megvárják az MWC-t. Ezenkívül a Vivante GC800+ IGP-t használó termékek is támogatják az OpenGL ES 3.0-t.
A fejlesztők azonnal rá fognak erre kapni, mert már az új API támogatásával megmentik magukat számos hardverre való direkt optimalizálástól, hogy egyáltalán elinduljon az alkalmazás. Az OpenGL ES 2.0 az egy olyan rosszul specifikált API, hogy ha még szabványos kódot írsz, akkor is jó esély van rá, hogy nem fog minden hardveren futni, amikor elvileg kellene. Az ES 3.0 főleg ezen javít, végre úgy működik, ahogy egy API-tól azt elvárnád.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Harmadára esett a helyi adatmegosztás sebessége, jelentősen esett a kontextusváltás sebessége, ezzel látod, hogy mennyivel gyengébben teljesít a Fermi architektúránál, ha a hatékonyságról van szó.
Nagyon rosszul hasonlítod össze. A HD 7800 egy sokkal kisebb GPU-t használ. A GK104 és a Tahiti mérete közel megegyezik. Ezek egymás ellen valók. A Pitcairn mérete a GK106-hoz hasonló, míg a Cape Verde kiterjedése lényegében a GK107-hez mérhető. Ennyi. Ezek ténylegesen egymás ellen lettek tervezve. Ami miatt a Kepler ilyen gyengének tűnik, hogy a GCN egy radikálisan új elvek szerint fejlesztett architektúra, vagyis nagyságrendileg nőtt a rendszer compute hatékonysága, minden eddigi GPU-hoz képest. Az NVIDIA pont ellenkező irányba ment a Fermi után.
Persze azt nem állítom, hogy a GCN eredményeinek és a Kepler kezdeti erős szereplése után való visszaesésének nincs köze ahhoz, hogy az AMD jelentősen növelte a Gaming Evolved büdzsét és marékszámra vásárolják fel az érkező játékokat, hiszen ezzel alapvetően befolyásolják a fejlődést is. Nyilvánvaló, hogy az új compute hatékonyságra gyúró játékok közül a DiRT: Showdown, a Sniper Elite V2, a Ghost Recon Advanced Warfighter, a Sleeping Dogs és a Hitman: Absolution nyilván nem lenne olyan compute-ra gyúró program, ha az AMD nem készít el beléjük bizonyos effekteket. Ezt érzi a Kepler, valószínű, hogy miután az AMD-nek is leesett, hogy a Fermihez képest nem a várt irányba fejlődött, így egyre inkább azon lesznek, hogy több és bonyolultabb compute shader legyen a megvásárolt játékokban. Nem véletlenül adták ki gyorsan a ForwardPlus SDK-t. Azt akarják, hogy cseréljék le a fejlesztők a deferred rendert a DiRT Showdownban alkalmazott Forward+-ra. Persze ez annyira nem egyszerű, mivel ezt könnyebb mondani, mint megtenni, de a Forward+-nak érkezik egy kiegészítése is deferred renderre, amivel sorrendről független átlátszóság hozható létre. Ez is segítség a fejlesztőknek, mivel könnyű implementálni, és megoldja az amúgy is problémás átlátszóság kezelését. Viszont az előzetes teljesítményadatok alapján ez nem fog barátian bánni a hardverekkel.
A DiRT Showdown alatt a GTX 680 sebessége nagyjából megegyezik a Radeon HD 7850 sebességével. A HD 7970 GHz Edition terméktől, ami egyébként hasonló árban van, nagyon messze van. Utóbbi az 50 fps-t csípi az új driverekkel. A DiRT Showdown az jó, mert az nagyon kíméletesen bánik a VRAM-mal. Ezzel a GTX 680 nem szenved nagy hátrányt amiatt, hogy a megcélzott kategóriához mérten kevés a memória-sávszélessége.
Az on-chip bandwith alapvetően a rendszer működéséhez van szabva, vagyis függ attól, hogy mennyi tár van a multiprocesszorokban előtte. Tehát az az adat, hogy a Tahiti 384 GB/s-ot tud az L2 data cache felől, míg a GK104 2 TB/s-ot, lényegében annak is az eredménye, hogy a Tahiti sokkal izmosabb az L2 előtt, mint a GK104. Eleve a Tahitinek 8 MB regiszterterülete van szemben a GK104 2 MB-jával, illetve az elsődleges gyorsítótárak kapacitása szempontjából is jelentős a különbség, mivel a Tahitiben 2,5 MB elsődleges gyorsítótár van az adatokra, míg a GK104-ben 512 kB. Nem véletlen, hogy az L2 cache esetében a GK104 annyira gyors, míg a Tahiti esetében annyira nagy az elsődleges gyorsítótárak kapacitása, hogy nem szükséges olyan gyors L2 cache.(#62) Dare2Live: Nem a hardver számít. Azt érdemes nézni, hogy az OpenGL ES 3.0 használata a fejlesztőknek kevesebb munka, mintha vinnék a hátukon az OpenGL ES 2.0 hibáit, és minden egyes hardverre külön optimalizáljanak, hogy egyáltalán elinduljon a program.
[ 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
Dare2Live
#65
üzenetére
Nem azzal van a baj, hanem a pufferformátummal. Az OpenGL ES 2.0 hanyagul definiálta ezt, így szinte mindegyik hardver másképp értelmezte. Ezt a program oldalán le kellett kezelni, különben akkor sem indult az alkalmazás, ha az API támogatva volt. Az ES 3.0 ezt javította.
A unified shader az automatikusan érezteti hatását. Ahhoz nem kell API. Igazából semelyik API sem követeli az egységesített felépítést, de nyilván 3+ shader fázissal már ez a logikus.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha a program nem használ olyan eljárást, ami OpenGL ES 2.0 alatt nincs meg, akkor nyilván attól, hogy OpenGL ES 3.0-s az app még működik a régebbi hardvereken. Ha van olyan eljárás, akkor nyilván az letiltásra kerül, ami a képminőségre, vagy a sebességre hatással lesz. A képminőségben elvileg mindenképp lesz változás, mert az OpenGL ES 3.0 követeli az FP32-es precizitást, tehát az adott alkalmazás minősége a pontosabb számítások miatt automatikusan javul.
Az OpenGL kompatibilitása nagyon korrekt. Nem lesz gond abból, hogy ES 3.0-ban írnak egy progit.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Akkor a számok:
Mindkét cég három GPU-t tervezett a kategóriáknak megfelelően. Egyszerűen a piac szűkülése mellett ez a logikus.
Mainstream:
GK107: 118 mm^2
Cape Verde: 123 mm^2
Performance:
GK106: 221 mm^2
Pitcairn: 212 mm^2
Enthusiast:
GK104: 294 mm^2
Tahiti: 352 mm^2A cél az volt a tervezésnél, hogy a mainstream szint a 100 mm^2 felé törekedjen, a performance réteg a 200 mm^2 felé, míg a enthusiast GPU-k a 300 mm^2 felé. Nagyjából ezek azok a lapkaméretek, amelyekből hasznot is lehet termelni a megcélzott kategória árazásával.
A Pitcairnnak konkrétan van egy olyan ellenfele, ami méretben picivel nagyobb nála ez a GK106. A GK104 az top chip. Az NV nem középkategóriásra tervezte, mert tudták, hogy 2012-ben már waferekért fizetnek a TSMC-nek és nem a jó lapkákért. 2012 előtt a TSMC-vel olyan szerződésük volt, hogy csak a jó chipeket veszik meg, a többivel pedig azt kezdenek a tajvaniak amit akarnak, mivel ez a TSMC-nek a legkevésbé sem volt jövedelmező, így ilyen szerződést nem kötöttek újból. Ennek megfelelően az NV nem fog veszteséggel árulni egy 400-500 mm^2 közötti lapkát, vagyis az a tervezés, amit korábban használtak értékelhetetlen lett a gaming termékek piacán. A GK104 persze alultervezett a kategóriájához mérten, de ezt szándékosan csinálták ilyenre. Az NV tudta, hogy nem fognak elsőként beugrani a 28 nm-be, így sejtették azt is, hogy limitált gyártókapacitáshoz is jutnak. Ahhoz is jutottak. Ezzel a GK104-re kellett a teljes kapacitást használni, míg az AMD jóval nagyobb kapacitást használt az év elején és három GPU-ra. Ergo amíg az AMD-nek a kisebb GPU-k kitermelték a hasznot, addig az NV-nek csak a GK104-re kellett hagyatkoznia, ami eladási tételben elég kis mennyiséget jelent a 100-300 dollár közötti bázishoz képest. Azért ilyen a lapka, mert az NV úgy tervezte, hogy hasznot termeljen a várt körülmények között 2012-ben. Ha például az AMD esett volna ilyen helyzetbe a Tahitivel, amibe az NV volt, akkor a Tahiti nem termelt volna hasznot. Ezért volt fontos az AMD-nek, hogy elsőként foglalják le a TSMC gyártókapacitását, mert akkor biztosan nem ütköznek majd limitációkba a gyártás kapcsán. Ebből a szempontból a nagyobb Tahiti már megérte, mert a kicsi GPU-kból meg volt az a mennyiség, ami a Tahiti amúgy nem túl velős hasznát összességében bőven túlteljesíti.A marketing ezzel a kérdéssel nem foglalkozik, amivel te. Ők a GTX 680-at top terméknek kiáltották ki. Nyilván végig tisztában volt vele az NV, hogy egy GK100-at képtelenség 500 dollárért haszonnal árulni. Ezért nem jelent meg az a lapka soha. Helyette lett GK110, ami arra épült, és lényegében Quadro, illetve Tesla kártyára kerül. GeForce-ra nem éri meg, mert szimplán nem termelne hasznot. Hacsak a top GeForce ára nem emelkedik 700 dollárra. De igazából annyira profi szintre lett tervezve a GK110, hogy egy kisebb lapkával is ki lehet hozni annak a terméknek a játékokban felmutatott teljesítményét. Ergo olyan 330-370 mm^2-re érdemes a következő kört belőni, mert a kapacitás most már nem lehet probléma, és a waferárak is csökkennek. Ezzel az 500 dollár ismét megcélozható haszonnal.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az árak szempontjából VGA a VGA-nak az ellenfele. Az nyilván egyértelmű. Egy x árú GeForce egy szintén x árú Radeonnal versenyez.
Amit te hoztál fel az a lapkák szerinti összehasonlítás, aminek a végfelhasználók szemszögéből eleve nulla értelme van, mert nem ár szerint történik. Én csak elmondtam, hogy mi minek az ellenfele a termékpalettán, a te összehasonlítási módszereddel. Azt nyilván nem mondtam, hogy ennek lenne bármi értelme.Mindketten csináltak top gaming GPU-t. Az NV a GK104-et, míg az AMD Tahitit. Ennyi. Ennél világosabban nem lehet megfogalmazni. Persze az NV csinálhatott volna egy GK100-at, és akár az AMD is egy 500 mm^2-es szörnyet, ami anyagilag nem éri meg. Innentől kezdve, hogy te mit gondolsz mindegy, mert egyik cég sem fog többet 500 dolláros szintre 500 mm^2-es lapkát csinálni. Mostantól a 300-400 mm^2-es szint van megcélozva. Lehet persze mondani, hogy de hát a GF100/110 az sikerült, akkor ez most miért nem? Erre is leírtam, hogy változtak a feltételek a gyártás során. Minden szempontból az egy termék célja, hogy hasznot termeljen. Ma a jelenlegi 28 nm-es waferárak mellett 500 dollárért 300-400 mm^2 közötti, max. 384 bites lapkával lehet hasznot termelni. Mivel ezeknél nagyobb lapkát nem csinálnak ide, így ezek a top GPU-k!
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én pedig megmutattam, hogy mi minek az ellenfele a te értelmezésedben. Eléggé világosan látszanak a kategóriák.
Felejtsd már el a GK104-Pitcairn összehasonlítást, mert ez csak a te agyadban létezik. A Pitcairn kisebb, mint a GK106, de vegyik inkább hasonló méretűnek. Olyan összehasonlítás van tehát, hogy Pitcairn és GK106. Te eldöntötted, hogy azt a két lapkát kell nézni, ahol a Keplernek előnye van. Ergo a GK104-et mindenféle alap nélkül kikiáltod a Pitcairn ellenfelének, de ezt sem az árak, sem pedig a lapkaméret nem indokolja.Nyilván generációnként értem, de ringasd magad továbbra is álomvilágba. Engem nem zavar.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Tényleg ne fárasszuk egymást. Konkrétan leírtam, az aktuális generációs lapkáit és a méreteket. Ha ebből nem jössz rá, hogy a GK106 kiterjedése közel azonos a Pitcairnnal, akkor ennyi.
Felhozhatnám a GK106-ot és a Pitcairnt is, vagy a Cape Verde-GK107 párost is, hiszen ebben az összehasonlításban ezek mérete közel azonos. A probléma ezzel, hogy a Kepler az kevésbé blokkosított felépítésű, mint a GCN, így utóbbit jobban lehet skálázni lefelé. Ergo a GK106 és a GK107 olyan belső szűk keresztmetszeteket hordoz magán, amelyek limitálják bizonyos helyeken a működést. A GK104 kiegyensúlyozottabb termék, így ezért jövők elő a Tahiti és a GK104 viszonyával. Ezzel az NV még jobban is jár, mint a GK106-Pitcairn és a Cape Verde-GK107 összehasonlítással.
A GK106-hoz áll a Pitcairn a legközelebb. Még egyszer leírom a lapkaméreteket: GK106 - 221 mm^2, míg a Pitcairn 212 mm^2. A GK104 jóval nagyobb lapka, az inkább a Tahiti ellenfele. Nyilván a Tahiti esetében sok tranzisztor megy el arra, hogy 1/4-ben számolja a DP-t, míg a GK104 1/16-ban, de az AMD úgy döntött, hogy ezzel a hendikeppel együtt tudnak élni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Működniük kell. Az lehet, hogy a Kepler blokkosításának tipikusan vannak gyengébb felépítései, de piciben ez annyira nem jön ki.
Az biztos, hogy a fogyasztás/méret/teljesítmény viszonyban a mostani a jobb, de csak addig, amíg a programokat nem fejlesztik a modernebb ultramobil GPU-khoz.Valószínű, hogy telibe le van tojva a Windows RT a szemükben, legalábbis egyelőre, és inkább az Androidra koncentrálnak. A Keplernek igazából a Windows RT-n lett volna értelme, mert ott lehet azt az extra tudást használni. Androidon maximum az OpenGL ES 3.0-val lettek volna előrébb. Mondjuk ez nem kis előny, de mindegy. Nyilván ha egy shader proci precizitása nem 32 bites, hanem kisebb, akkor az energiaigénye is kisebb lesz. Ergo a Tegra 4 erre akar gyúrni. A többieknek a képminőségük lesz jobb, mert az OpenGL ES 3.0 már követeli a 32 bites precizitást.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem értem. Én azt látom, hogy mindenképp a Pitcairnhez akarod hasonlítani a GK104-et, ami még a GK106-nál is kisebb lapka. Ennek az egyetlen célja az lehet, mert nem tartod a GK104-et elég jónak ahhoz, hogy a Tahitivel hasonlítsuk. Ezt elfogadom, illetve alá is írom, de ez nem erről szól, sőt nem szól semmiről, hiszen Gbors írta, amióta ennyire eltérők az architektúrák igazából ennek vizsgálatának nincs sok értelem. Mindegyik kerül amennyibe kerül, és az alapján lehet ítélkezni.
A felépítés dolog meg teljesen hoax, azt összehasonlítani abszolút lehetetlen. Mégis mi alapján vizsgálod ezt két gyökeresen eltérő architektúrá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
Nem az API szabja meg a teljesítményt. Az OpenCL-ben azért jó, mert compute. Ugyanúgy extrém hatékony a GCN minden korábbi architektúrához képest DirectCompute-ban is.
Ha megnézed a tesztjeinket, ahol a legújabb DX11-es játékok szerepelnek, akkor nem lehet kétséged afelől, hogy a Tahiti gyorsabb.
És melyik játékban vizsgálod, mert egy csúcsmodern motort használó DiRT Showdownban azért teljesen más eredményt kapsz, mint egy átlag DX9-es játékban. A fő különbség a GCN és a Kepler között, hogy a GCN nem riad vissza a bonyolult shaderektől. Ez teszi az architektúrát annyira hatékonnyá. Az egyszerűbb shadereket ma már szinten minden GPU képes hatékonyan kezelni, de a branchy kódok azok kihívások. Itt jön be az architektúrák hatékonysága, a nyers teljesítmény helyett.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A peak FLOPS az egy olyan érték, amit eléggé nehéz reprodukálni. Elmélet és gyakorlat különbsége. Ha a grafikus motorokat nézed, és azon belül a shadereket, akkor eléggé nyilvánvaló, hogy vannak egyszerűbb shaderek és bonyolultabbak. 2012 előtt azért nem volt jellemző, hogy túlzottan branchy shadert írtak a fejlesztők, mert ez nem a GPU architektúrák kedvelt terepe, illetve azért egy ilyen shadert debugolni pöppet melós. A GPU-k abban jók, hogy egy nagy adattömeget rázúdítasz, és azon számolgat. De ezt neked úgysem kell magyarázni. Amikor jönnek a gondok azok az elágazások, és ott már azért jelentősen esik a hatékonyság. A GCN alapvető fejlesztési szempontja az volt, hogy a feltételes elágazásoknál legyen olyan hatékony, mint egy központi processzor. A közhiedelemmel ellentétben ezek sem hatékonyak itt, mert az elágazás eleve egy nehezen kezelhető probléma a hardveren belül, de azért jóval jobban dolgoztak, mint a GPU-k. A GCN ezen a ponton felnőtt hozzájuk. Ezért látsz ekkora különbséget a DiRT Showdownban a GCN és a többi architektúra között, mert a fejlett megvilágítás egy nagyon branchy kód. Ez a GCN-nek csemege, míg a többi hardvernek inkább szenvedés. Eközben a GCN az egyszerűbb shadereknél nincs lemaradva a többi architektúrától. Ezért mondom azt, hogy a GCN jóval hatékonyabb a bonyolult kódokban. De ez logikus, mert konkrétan erre tervezték, míg a többi hardvert azért nem.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyszer mindenképpen bekerül a Tegrába, különben teljesen értelmetlen volt a Fermi irányának hátat fordítani. Ami egyébként jó irány volt.
(#100) Bull1: Le lehet skálázni. Ha megnézed a Keplert, akkor pont úgy van megcsinálva, hogy kevés blokkal is adjon nagy teljesítményt. Az AMD-nek is le tudja skálázni a GCN-t. Gondolom láttad a CES-en, hogy kevesebb, mint 5 wattból ~3400 pontot tud a Temash 3DMark06-ban. A Clover Trail, ami a konkurens tabletchip ma ~190 pontra képes. És ez még egy elég erős IGP-t is használ, ha a többi ultramobil megoldáshoz hasonlítunk. Ergo meg lehet csinálni.
Ami egyedül ellene van az az, hogy az Androidon a Kepler tudását nem lehetne kihasználni. Ha az NV-t nem érdekli a Windows RT, akkor valóban jobb maradni a korábbi megoldásnál, de az sem túl hatékony már. Az új generációs konkurensek, mint a Mali-T600 és a PowerVR G6000 erősebb.[ 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
ph Tudásban nem valami acélos, de legalább gyors a Tegra 4 IGP-je.
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800XT 16GB GDDR6 videokártya garanciával hibátlan működéssel
- ZOTAC GeForce GTX 1080 AMP Edition 8GB GDDR5X 256bit
- Rog 4070 Ti //KERESEM!!//
- 4070 Ti Aorus Master //KERESEM!!//
- PowerColor RX 6800 XT Red Dragon 16GB GDDR6 256bit - Számla + Garancia, Ár alatt! BeszámítOK!