Új hozzászólás Aktív témák
-
Sir Ny
senior tag
,,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."
mi lenne a tegra3-as játékokkal, ha a piacon mindenki oGL ES 3-at használ? nem hiszem hogy jó stratégia megölni a legjobb marketingest - az elődöt, ami még csak most van élete delén - az OUYA például szép siker lehet a tegra vonalnak.
(valószínűleg sok ok közrejátszhatott abban, hogy így döntöttek. talán időhiány, vagy csak simán bénák) -
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. -
#100
Bull1
aktív tag
FragMaster
#99
Bull1
aktív tag
válasz
FragMaster
#99
üzenetére
Hát, hogy mi az ésszerű, az nVidia jobban tudja (többéves vezető tapasztalat hardver,szoftver terén, mérnökök hada vs Abu a PH-ról).
De belegondolsz, egy alapvetően diszkrét, nagy fogyasztású kártyát sztem le se lehet nyomni ultra-mobil szintre. Csak az ultramobil lapkák között is van magas és kis fogyasztású, legjobb példa erre a Tegra, az extra ötödik, kis fogyasztású maggal. Kepler ide h férne bele, nem tudom... -
#98
Bull1
aktív tag
FragMaster
#97
Bull1
aktív tag
válasz
FragMaster
#97
üzenetére
Pedig mást sem lehetett tőle olvasni, csak azt, h a Kepler azért lett "megnyirbálva" mert milyen jó lesz a Tegrába...
-
lenox
veterán
A peak FLOPS az egy olyan érték, amit eléggé nehéz reprodukálni.
Persze, hogy nehez, egy architektura hatekonysaganak benchmarkja pont ezert lehet az, hogy mennyire tudja ellatni adattal a shadereket. Persze nem tokeletes meroszam ez sem, mivel az egy tervezesi kerdes, hogy mennyi shader kerul egy mp-be vagy cu-ba, attol nyilvan nem lesz abszolut ertelemben jobb vagy rosszabb valami, ha ebbol tobb vagy kevesebb van benne, csak kulonbozo feladatokban mashol lesz a bottleneck. Arra viszont jo lehet, hogy le lehessen merni egy aktualis feladaton, hogy arra mennyire hatekony. Mindenesetre a gcn hatekonysaganal meg mindig ott tartunk, hogy a levegoben log, a nagyobb fps nem jelent nagyobb hatekonysagot, csak nagyobb teljesitmenyt. Ha az nv-t egy pillanatra kihagyom, es a caymanhoz hasonlitom a tahitit (6970 vs 7970), akkor peak flopsban es mem bandwidth-ben is kb. masfelszeres a 7970, szoval akkor mondanam hatekonyabbnak egy feladatra, ha tobb, mint 50%-kal gyorsabb. Es akkor nem arrol beszelunk, hogy nagysagrendekkel hatekonyabb, hanem eppen hogy. Ez igy van dx11 jatekokban? Nekem nem jott le...
-
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.
-
lenox
veterán
Hat pont arra akartam ravilagitani, hogy a hatekonysag es a gyorsasag nem ugyanaz. Persze, hogy gyors a tahiti, de valoban hatekony is? Ezt szimplan az fps alapjan nem lehet megmondani. Nv fobiasok merhetik tolem 6xxx sorozatu amd-hez is, csak osszak be az fps-t a peak flops-szal, es hasonlo mem bandwidth-szel rendelkezo kartyakat merjenek ossze. De amugy a fermihez is erdemes lenne igy hozzamerni. Az opencl-t nyilvan nem a directcompute elleneben irtam, hanem a gfx motorok elleneben.
-
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. -
lenox
veterán
Mindegyik kerül amennyibe kerül, és az alapján lehet ítélkezni.
Ez mindenkepp igy van.
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?
Azt az allitast kifogasolom, hogy azt irtad, hogy a gcn nagysagrendekkel hatekonyabb minden elozo architekturanal. Illetve nem is ezt az allitast, hanem ennek az indoklasat. Egyreszt van az opencl alatti teljesitmeny, azzal kapcsolatban tul sok kerdes nem lehet, de van a dx11 jatekok alatt nyujtott teljesitmeny, ahol arra hivatkozol, hogy a tahiti gyorsabb a gk104-nel. Szerintem pl. az fps per flops mertek alapjan erdemes vizsgalni a hatekonysagot, es ehhez nyilvan hasonlo mem bandwidth-t kell biztositani. Egy ilyen osszehasonlitashoz szerintem a gk104 vs pitcairn jobban megfelel, mint a gk104 vs tahiti. De ha jol latom a wikipedian van vegul is tahiti le, szoval az akar jo is lehetne, mindenesetre a sima fps a 7970 vs gtx 680 viszonylatban nem jo erre.
-
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?
-
lenox
veterán
Szerintem en is leirtam tobb parametert is, teljesen biztos vagyok benne, hogy ertetted, es hogy magadban igazat is adsz nekem, de ugy tunik, eltokelted, hogy ragaszkodsz irasban ahhoz, hogy csak a meret szamit, jo, legyen igy.
A GK106-hoz áll a Pitcairn a legközelebb.
Igen, meretben mindenkepp, egyetertunk. Csak nem ezzel vitatkozol, hanem azzal, hogy a gk104 felepitesben a tahitihez vagy a pitcairnhoz all-e kozelebb. Ugye ertheto, hogy nincs benne gk106? Es nem az van odairva, hogy meretben vagy arban? Persze, hogy ertheto... De jo, szerintem is kiveseztuk ezt a reszet.
-
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.
-
Az nem lehetséges, hogy a Kepler-ből visszabutított GPU nem működik úgy a Tegrában, ahogy kellene? Vagyis jelentősen rosszabbul műxik egyelőre, mint a GeForce ULP - fogyasztás, teljesítmény, méret, stb. tekintetben?
Erről vannak infók?Mi más oka lenne az nV-nek arra, hogy egy régi felépítés mellett döntsön?
-
látom, újabb topikban indult be az ámokfutás
én nem akarok kilométereket írni, csak két megjegyzés:
- nem túl reális chipméret alapján összevetni két GPU-t. az AMD-nek az RV770 óta jelentős előnye van a tranzisztorsűrűségben, úgyhogy minden ilyen összevetés automatikusan AMD-párti.
- ha már technikai paraméter, akkor tranzisztorszám. a GK104 ebben pont félúton van a Tahiti és a Pitcairn között, tehát műszaki szempontból egyiknek sem közvetlen ellenfele. ehhez képest a GK104 valóban ott lohol a Tahiti nyakán, ami egyrészt derék, másrészt azt erősíti meg, hogy az nVidia erősen a jelenben él, és úgy gondolja, hogy majd akkor jön el a jövő, amikor ő úgy dönt. -
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. -
lenox
veterán
Én pedig megmutattam, hogy mi minek az ellenfele a te értelmezésedben. Eléggé világosan látszanak a kategóriák.
Hat ebben azert az csusztatas, hogy en csak a gk104/tahiti/pitcairn gpu-krol irtam, a tobbirol egy szot sem, szoval annak, hogy egyik lowend gpu-nak mutattal masik lowend gpu ellenfelet semmi jelentosege nincs.
Felejtsd már el a GK104-Pitcairn összehasonlítást, mert ez csak a te agyadban létezik.
Fogadnal ra, hogy egy ph-s teszt sincs, amiben mindketto van?
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.
Az arak meg mindig nem technikai kerdes. Ha probalnal a tenyekhez ragaszkodni, akkor en azt irtam, hogy meretben a ketto kozott, fp-ben a pitcairnhoz kozelebb, mem busz szelessegben a pitcairn-nal, compute resource-okban alatta van. Nem igy van? Ez egy kicsivel arnyaltabb, mint amit te irsz, hogy meretben a tahitivel egyezik, tehat technikailag olyan szintu gpu. Legalabbis eddig azt hittem, hogy tobb is erdekel, mint a meret, de lehet, hogy akkor tevedtem. Mindenesetre a minden alap nelkul az nyilvanvaloan nem igaz, es mar sokadjara irom, hogy nem ellenfelenek kialtom ki, hanem technikai tudasat tekintve mondom, hogy sokkal inkabb az a szint, mint a tahiti. Ha jol ertem az a problemad, hogy szerinted engem az motival, hogy a gk104-et valamifele gyoztesnek hozzam ki. Pedig ha vegiggondolnad, hogy ha en a gk104-et a pitcairn-nal gondolom egy szintre, es kozben ranezel az arcedulara, akkor szerintem ebbol le is jott, hogy ez eleg komoly tevedes.
Nekem azzal van problemam, hogy a gcn hatekonysaganal ervkent mindig azt hozod fel, hogy lam a tahiti gyorsabb, mint a gk104. Persze, hogyne lenne gyorsabb, hat nagyobb is, tobb szamoloegyseg is van benne, nagyobb a shared memory bandwidth, szelesebb a mem busz, stb., nem egy kategoria, csak a zoldek valamiert el tudjak adni tobb penzert (mondjuk azt nem is ertem, hogy ki es miert ad erte annyit, ha nem cudara hasznalja). Mennyire jo erv az, hogy a gcn szuper hatekony, mert 30%-kal nagyobb peak fp performance-szal gyorsabb tud lenni? Vagy 50%-kal nagyob memory bandwidth-szel gyorsabb tud lenni? Vagy tobbszoros shared memory bandwidth-szel gyorsabb tud lenni? Szerintem nem tul jo. Az ennel sokkal jobb erv, ha a gk104-hez kozelebb allo pitcairn tud gyorsabb lenni nala. Es mint tudjuk nehezebb opencl feladatokban ez igy is van, tehat ebben mindenkepp hatekonyabb. Vajon igy van ez a dx11 jatekokban is?
-
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.
-
lenox
veterán
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.
Ez igy van. De ha megnezed nem a vegfelhasznalo szemszogebol mondtam, hanem a technikai elemzes (fanyalgas) szemszogebol. Szerintem teljesen kulonbozo az, hogy top gpu herelve, butitva, es lam, nem tud lepest tartani (ezt mondod te), es a valosag, hogy kozepkat gpu felturbozva, ami lam, a konkurencia top gpu-jat is megszorongatja itt-ott. Az van meg benne ebben, hogy ha atlatja az ember, hogy compute resource-okban a gk104 a pitcairn alatt van, es kozben meg azt latjuk, hogy alig van olyan program, amiben a pitcairn verne, akkor rogton kiderul hogy valos alkalmazasban a gcn elonye nem jon ki. Persze ha azt nyomja az ember, hogy ez olyan gpu, mint a tahiti, akkor abban a hitben lehet, hogy megis kijon, csak hat nem igy van.
Mivel ezeknél nagyobb lapkát nem csinálnak ide, így ezek a top GPU-k!
Persze, es az S3 legutolso gpu-ja is top gpu, hiszen nem csinalnak nagyobbat (vagy az volt, ha mar nem gyartjak). Szoval ez nyilvanvaloan nem igy mukodik.
-
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!
-
lenox
veterán
Tehat ha jol ertem egyreszt az az erv, hogy a pitcairn-nak a gk106 az ellenfele, tehat a gk104 nem lehet (de mondjuk ha megnezem az arakat, akkor gk106-os kartyat joval olcsobban adnak, es amugy sem azt mondom, hogy ki kinek az ellenfele, mert azt a marketing jeloli ki, es ugye ez nem egy technikai erv), masreszt elmeselted, hogy miert nem csinaltak top gpu-t (csak kozben beleirod, hogy az), vegul odairod, hogy a gk100 lenne a top, csak azt nem csinaltak meg. Jol ertettem? Nem lett volna egyszerubb azt irni, hogy hat igen, nem erte meg top gpu-t csinalni, hat nem csinaltak?
-
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.
-
lenox
veterán
Nem tudom, te milyen adatot nezel, nekem a gk104 meretileg a tahiti es a pitcairn kozott van kb. feluton, fp szamoloegysegek tekinteteben joval kozelebb a pitcairn-hoz, mem busz szelesseg a pitcairn-eval egyezik, a tobbi compute-ban erdekes resource-ot tekintve meg a pitcairn alatt van. Pontosan mitol is lenne a tahiti ellenfele technikailag? Mert az, hogy a user top gpu arat ad egy kozepkategorias gpu-ert az nyilvan nem technikai kerdes. De meg a neveben is megadtak a hintet, nem tudom, mi kell ennel tobb, hogy ne a marketingnek higgy...
-
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. -
nkmedve
őstag
Persze egyértelmű hogy váltani kéne, nem sokat programoztam OpenGL ES-ben (nagyon keveset azt is 1.1-ben azt hiszem) de én is tudom hogy a 2.0 nagyon szivás. A kérdés csak az, hogy át lehet-e térni fejlesztői oldalról az új verzióra úgy hogy nagyon kevés hardver támogatja azt.
Lesz rá mód hogy 2.0-s hardveren fusson a 3.0-s kód (hasonlóan a DX feature level-ek működséséhez)? Ha nem, akkor nem sok esélyt látok rá, hogy egyhamar váltsanak, ha Apple Samsung és NV nem támogatják teljes erejükből az új verziót.
-
Egyetértek, ha a CWM műxik, akkor vagy a rom nem jó, amit fel akar tenni, vagy elmaradt a wipe.
A kernel sérülése szerintem szinte kizárt.
(#66) CimbiX: Az ASUS-nak nincs valami szoftver frissítő progija? Mert USB-n keresztül még a kernelt is helyre lehet pofozni, ha az sérült. -
Hobbbyt
őstag
Hmm..
Abszolút nem vagyok jártas az Asusok körében, de az alapelv úgyis ugyanaz, csak a programok mások. Elvileg.. ha Recovery menüből teljesen formázod a belső particiókat (a rendszerparticiót) , esetleg ha kívülről teljesen újraosztod a belső memóriát semmilyen maradványnak nem lenne szabad maradnia.. Mielőtt újra raktad a Főzött romot, wipeoltál mident?
Olyan nincs, hogy nem megy.. annak mennie kell. Mivel a Recovery működik, nagy baja biztos nincs.
Gyárbakban is utólag nyomják fel rá az oprendszert.. szóval biztos van megoldás -
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. -
CimbiX
aktív tag
Szerintem az NV megprobalja eröböl lenyomni a fejlesztök nyelöszerven az uj hardvert, ujfent lesz par exkluziv jatek, egy jo erös marketing kampany, es müködni is fog. Ennek ellenere kar, hogy nem a standardok utjat jarjak.
@Hobbit
Hat akkor itt van egy, ugyan nem telefon, de egy TF300T-t teglasitottam. Felraktam ra egy fözött romot, azota meg a CWM-be beenged, elmeletileg tudok is ra uj romot pakolni, az installaciot el is vegzi (a kepernyön megjelenö üzenetek szerint), a rendszer megsem indul. Ennyi! Sajna programozo kollegam sem tud mar 2 hete mit kezdeni vele.
-
Dare2Live
félisten
"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."
ez már 100* lefutott 100* helyen. ott az ushader, hiába volt sokkal jobb fejlesztései szempontból Dx10nél még nem évig, hanem inkább évekig a címek 90% DX9volt, de említhetném a pár rétegalmalkamzásos OpenClt... is.
-
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.
-
#60
FragMaster
addikt
Bull1
#23
FragMaster
addikt
Baromság, a hozzászólók háromnegyede meg látszólag jó, hogy megtalálja a bekapcsoló gombot. Egyrészt adreno200-on az egy dolog, hogy működik, de egy mai, de akár két évvel ezelőtti szemmel tekintve is lassú, buta gpu-tól mit vár az ember? Persze, hogy lassú.
Másfelől szépen le van írva, hogy 2.3-ig kompatibilis, mert nem volt frissítve 2011 ősze óta. 4.0.4 alatt gnexen még működik, JB-n viszont a romot tényleg megnyekkenti, de egy factory reset simán megoldja.
2.3-ig semmilyen kockázata nincs és erre is találták ki. A legtöbb telefonon nyom nélkül eltüntethető a root, aki meg nem ért hozzá az nemes egyszerűséggel ne csinálja.
Jöhetne viszont egy frissítés hozzá, mert baromi jó kis program, Főleg így, hogy jóformán a tegra2 óta nem történt jelentős fejlődés a hardverben. -
lenox
veterán
Mivel erosodtek a multiprocesszorok, igy herelesnek eleg fura hivni szerintem. Akkor mar inkabb a termekpalettat hereltek, mivel csak a gf104/gf114 szintjeig adtak ki gpu-t geforce-kent. A konkurens termekekhez is igy erdemes merni szerintem, a termekpaletta hatranyban van, mert nincs top gpu kiadva, de ha a gtx680-at a 78xx-hez mered, ahova gpu es kartyafelepites alapjan valo, akkor nem hinnem, hogy tul nagy lenne a hatrany. Az, hogy mennyi penzt tudnak ezert elkerni az mar nem technikai kerdes. Ezen kivul azert megneznem pontosan, hogy altalaban a dx11-es jatekokban mekkora hatekonysaggal dolgozik melyik gpu, mert pl. dirt showdown dx11 ph-s teszten a 7970 40 fps-t ment, a gtx 680 meg 31-et, szoval a peak performance-ra vetitett hatekonysag elterese 5%-nyi (persze ezzel egy kicsit csusztatok, mert a 7850 pl. mindkettot veri 70%-kal, de mindenesetre lathato, hogy az amd vs nv hatekonysagkulonbseg dx11-ben nem pont ugy letezik, ahogy te allitod). De nem ertek a jatekokhoz, szoval ha szerinted mas jatekot (illetve igazabol gfx engine-t) erdemes nezni, azt is nezhetjuk tolem, meg bele lehet venni a bandwidth-t is, vagy akar nezhetnenk az on-chip bandwidth-re vetitett hatekonysagot is, gyanus, hogy egyaltalan nem fekete/feher a dolog, pl. a legutobbiban gondolnam utcahosszal nyer az nv.
-
Cassi
őstag
Az NV ugyan most egyértelműen vezet az asztali GPU-knál, de a Tegrák teljesen más kategóriában versenyeznek, ezért itt láthatóan nagyon konzervatívak és csak azokat a funkciókat teszik be, amikre feltétlenül szükség van. Akár az Apple-t, akár a Samsungot nézem, a jelek szerint ebben az évben nem fogják erőltetni az ES 3-at, ezért nincs értelme előre rohannia az Nv-nek sem. Ez van, sok más funkciónak nagyobb a prioritása.
-
twine
veterán
S3-nál egy perc alatt tunteted el a rootot(garivesztes nelkul),onex-nel meg nincs szukseg cf3d#re mert alapbol tegras...
Ekkora "bakot" ilyen hirnel nem lovunk
Amivel "lebogeted magad az ismerosok elott",az a "tudatlansag",es nem a brickeles
Attol fuggetlenul, hogy nem rootolotam a ket utolso telom,es gyari romot hasznalok...azt javaslom,szerezz tapasztalatot,,,vagy hagyd az eszosztast azokra,akik tudjak mit beszelnek...
Az addig rendben hogy te "nem mered",....de hogy egyenesen velemenyt alkotsz egy "szakmai" topicban egy komplex temarol azert mert egy telefonodon volt cm 2 hetig... 
Ps:
Nem szemelyes sertesnek szantam egyik kijelentesemet sem...
-
Hobbbyt
őstag
Nem tudom, hogy milyen Típusról beszélünk, de S2-S3-Note1-Note2-nél vannak a Wanamlite romok. Amik lényegében gyári romok, kicsit kipofozva.. (annyira stock ,hogy a TouchWiz rém is rajta van, plusz pár extra tudással, stabilabban, jobb üzemidővel, és teljes kies támogatással) Neked is valami hasonlóra van szükséged szerintem
(#52) vicze1 Most igen, de tényleg kicsi az esélyed, hogy hozzám hasonlókba fuss
Irigy vagyok rád.. mert neked van T68i-d De nekem viszont van "Kamerám" hozzá, kis kék Bőr/műbőr tokban bibibii ![;]](//cdn.rios.hu/dl/s/v1.gif)
-
vicze
félisten
A CM szinte csak Nexusokon stabil és 100% funkcionalitású. Más készülékeken XY szintet elérhet, de valami hibája 100% (lehet nagyon pici), hogy lesz, nagyon nem is találkoztam hibátlannal. (Tipikusan pont azok a gondok, amiket felsoroltál, kamera (videó felvétel, másodlagos kamera), wifi (wifi megosztás), BT, és GPS.)
Első körben inkább moddolt gyárit érdemes próbálni, van olyan is ami gyár ROM de "vanilia" android, tehát gyári kernel, minden funkció megy, de ki van gyomlálva a gyártó felülete és programjai. (HTC-nél tipikusan ezek nonSense ROM-ok.) -
vicze
félisten
Bizony a T68 a legszebb, és mindig is az lesz.
A T68i (SW) tud MMS-t! (és még valamit, de nem jut eszembe, be kéne kapcsolni és megnézni. )
Akkor pont rossz embert találtam meg, de úgy általánosságban sokkal kevesebben csináltak ilyet mint most androiddal.@Bull1: Azért ez egy picit sarkított ahogy te összeraktad. A CM ROM-ok viszonylag kevés készüléken stabilak 100%-an, ez rettentően készülék függő. De a moddolt gyári ROM-ok, többnyire stabilak, gyorsabbak, és csak + funkciókkal rendelkeznek. (A Kies-re inkább nem mondok semmit.
) -
-
Bull1
aktív tag
Ne érts félre, elismerem a főzött ROM-ok előnyeit, tényleg sok szempontból jobbak, csak sokszor alapvető dolgok nem működnek időnként (pl. kamera, Bluetooth stb.) emiatt vagyok most biztonságképp egyelőre gyárin. Persze most is foglalkoztat a JB-s ROM, csak most nincs türelmem ezeket rakosgatni, de ha lesz kedvem adni fogok ezeknek egy esélyt.
-
Típustól függ, hogy a gyári vagy a főzött a jobb.
Van sok szemét a főzöttek között, ez tény, de meg kell találni azt ami jó. Nem nagyon találkoztam még olyan telefonnal, amihez ne lett volna a gyárinál jobb főzött ROM, csak keresni kell.
Én már a CarrierIQ és utódai miatt sem használnék soha gyári ROM-ot
-
Bull1
aktív tag
Nekem mondhatod, próbáltam CM-modot (így került hozzám a telefon), kb. 2 hétig használtam. Bizonyos appok szaggattak, teló feloldáskor szaggatott, recsegő rádió, nagyon lassan csatlakozó wifi, KIES-et nem ismeri fel etc. Gyári ROM-al ilyen gondom sose volt, nehezen tudsz meggyőzni jelenleg főzött szoftverről.
Alapvető gond a főzöttel, hogy a gyári szoftvert külsős csapatok szerkesztik, és bizony semmi garancia nincs a működésre, lévén ezeket nem tesztelik le és sosem lesznek megbízhatóak.(#46) Drever v
-
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. -
nkmedve
őstag
Nekem nem tűnik úgy hogy az OpenGL ES 3.0 olyan nagyon támogatott lenne jelenleg.
Pont tegnap volt hir, hogy Exynos 5 Octa PowerVR IGP-t használ Mali helyett és OpenGL ES 2.0-t támogat (Galaxy S4-ben gondolom ez lesz). Ha jól tudom, az Apple A6X-ben levő PoverVR SGX554 is 2.0-t támogat csak.Mali T600 és PoverVR 6-os széria támogatja a 3.0-t de nem sok eszközt tudok amikben ezek ketyegnének. Egyáltalán nem úgy tűnik, hogy a Tegrának olyan nagy hátránya származna abból, hogy csak 2.0-t támogat. Még nagyon sok idő fog eltelni amig használva lesz az új verzió (főleg ha a Samsung nem támogatja az Exynos által).
-
Hobbbyt
őstag
Dehogynem
Annakidején kb. (14 évesen) egy Motorola V550-ra tettem rá a V600 softját. (Utána Egy mezei E398-ra a.. hmm na erre már nem emlékszem, de tudom hogy ez valami fehér zenés kiadásnak az swjét kapta meg.) És pár vakmenün kívül simán ment.. és menne a mai napig ha az aksi még betöltené a szerepkörét.
Sajnos túl "korán" csöppentem bele a Symbian világába, ott meg nagyon nem volt ugrálási lehetőségem(meg nem is tudtam) eleinte. (7610 és 6600 korában) Meg az más volt.. De szép idők voltak ezek.. Ejj.D750 ből csináltam K750 mert az a sok T-s téma meg ilyenek... fúúj. Gondolom nem bonyolultabb a W800 se, ha már ugyan az a készülék mint a 3 típus.
T68i A világ egyik legszebb telefonja szerintem. Sajnos nekem csak a T310i volt ami lényegében ugyan az csak olcsobb, és csúnyább.
(a mai napig nem tudom, hogy mi a különbség a 68i és 68 között)
(Még nem mondtam le a T68i-ről. Ha találok egy új állapotban lévőt, tuti megveszem
) -
vicze
félisten
Azt nem érted, hogy ő fél. Innentől lehet győzködi, akkor is félni fog. (Olvasta pár nagyon béna bejegyzését, akik "tönkretették" a telójukat és ennyi elég, hogy egy életre féljen valaki.)
pl. Szerintem mondjuk majd 10évvel ezelőtt te se vállaltál volna be ilyen mókolásokat egy telefonon, cseréltél volna SW-t otthon, vagy egy kis forrasztás? Na látod, a ROM csere neki kb. ugyanez.
Te se próbáltál volna T68-ból T68i-t csinálni, vagy K750-ből W800-at stb., lényegében tök ugyanazt csináltad mint a roottal, csak kb. 100x rizikósabb, és csak nagyon picit hibázhatsz. (Fizettem pár tanulópénzt.)Igenis azt mondom, ha nem ért hozzá ne csinálja! (Ha nem tudod, hogy rossz kernelt raktál fel és azért nem bootol, akkor azt se tudod, hogy a sarki GSM-es 2e-ért újrahúzza...)
-
juzer78
tag
"Szerintem a Kepler esetében eleve a compute herélésére mentek."
Ezzel kapcsolatban még annyi, hogy az nv igyekszik intenzíven használni a GPU-s fizikát, ott is szükség van rá, ha egyre több és komplexebb effekteket akarnak létrehozni. Akkor mi értelme van ennek az iránynak? Vagy netán a Maxwellel már nem a shader processzorokra fogja bízni ezeket a feladatokat, hanem az abba integrált ARM magokra? Ekkor fogja a fél világ fogja körberöhögni őket, hogy csapkodják az asztalt, hogy igen is GPU fizika mindenek felett... bla-bla-bla... és utána külön magokra bízza azt, mert a shader processzorok nem bírják az egyéb feladatok mellett...
-
Hobbbyt
őstag
Najó, mindegy.
Személy szerint egy mérnöki végzettséggel rendelkezőtől több talpraesettséget várok. (Mérnöki karra járok..)
De ismétlem, különösen tehetségesnek kell lennie valakinek ahhoz, hogy hazavágjon így egy telefont. Sőt, igazából 1 esetről se hallottam-olvastam még ,hogy ezzel végleg tönkretett volna bárki is egy telefont.. Mivel fizikai módosítás nincs, így helyrehozhatatlan kár sem keletkezhet.
De megéri piszkálni.. mert sok olyan dologtól megtisztíthatod a telefont, amire semmi szükséged.. jobban magadra formálhatod. Sebességben, üzemidőben is javulhat. A főzött romokat meg sem említem.
Persze azt eltudom fogadni, hogy neked Gyári állapotban is tökéletesen megfelel.. és nincs igényed többre/jobbra/szebbre. Nem zavar a menstruációs naptár és a kalória/lépés számláló.. esetleg 5 féle béta gyári app. 3 Féle online bolt.. stb. Mert van ilyen, nincs ezzel baj.
De Arra fogni, hogy veszélyes meg tutibukta meg égés meg nehéz meg stb-stb.. Botorság.
Nem csak nekem működik tökéletesen, hanem mindenki másnak is.De befejeztem. Megértettem, hogy te semmiképp nem akarod belátni, hogy az általad elképzelt realitás ebben a témában egyszerűen nem reális.
-
Bull1
aktív tag
Mérnöki végzettségem van és hidd el, nekem jobb a gyári állapot. Aftermarket ROM-okról is ugyanez a véleményem. Összetett az Android, nem éri meg fölöslegesen piszkálni, már alap állapotban is nagyon sok lehetőséget nyújt. Persze, lehet neked tökéletesen működik, de elég ha egyszer hazavágsz egy telefont, főleg másét, egy életre lebőgsz előtte.
-
juzer78
tag
Igen, de alkalmazható objektum felismerésre, illetve felderítésre így akár egy élsimító algoritmus is kreálható lenne rá, amely nem fut végig az egész képen csak azokon a területeken ahol az élt érzékeli, így pl a teljes kép elmosódása is kerülhető lenne, és valszeg gyorsabb is lenne, mint az MSAA, kisebb erőforrásigénnyel...
"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."
Na ez az, oda kerül egy szenzor, az OpenCL-el számítani egyszerűbb, és megint mi történik? Az okosabb hardver miatt lényegében azonnal beépíthető, nem kell új hardvert tervezni, mindössze egy szenzort kell beépíteni.... A buta hardver miatt pedig ott is a lemaradás, mert most hiába jobb a fogyasztása, ha később amikor jönnek a szenzorral felszerelt ilyen fényerő állítgató takarékoskodó szoftverek, akkor már is az okosabb hardver kerül előnybe, javulnak a fogyasztási és használhatósági mutatói. És nem történt nagy fejlesztés, csak a meglévők képességeit használják ki. És ezzel az az előny amira az nv épít, el is veszett, örökre...
-
Hobbbyt
őstag
Nem, ez tiszta paranoia.
Minden egyes zsebrerakásnál ott a lehetőség, hogy félre csúszik és a beton fogja meg a telefont. Mégis minden áldott nap zsebre vágod.. kb. ekkora kockázatot jelent megrootolni egy telefon, és használni az ilyen plusz alkalmazásokat.
Tök átlagos/alapvető műszaki ismeretekkel rendelkező 20 éves húgom, egy tőlem kapott link alapján (PH! fórumra mutatott) egyedül tökéletesen megrootolta az Xperia Mini Pro-ját, Sztereósította a videofelvételét, és frissítette a telefonját.. majd próbaképp tett rá egy főzött romot is. Elsőre nem jött neki össze, annyit segítettem neki, hogy "Akkor kezd előről.." Másodjára ment. Majd feltetettem vele a Titanium backup pro-t és megmutattam, hol tudja törölni azokat a gyári vackokat amiket soha nem használt.. és nem is fog. ...És törölte, és nem vágta haza... Pedig nem nehéz olyat törölni (csak egy pipa) amitől a rendszer használhatatlanná válik.
Szóval igen. Paranoia.
-
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.
-
lenox
veterán
Szerintem a Kepler esetében eleve a compute herélésére mentek.
Szerintem nem, marmint nem direkt, inkabb feltuningoltak a multiprocesszorukat, es igy fele annyi is eleg lett belole, hogy jatekokban jobban teljesitsen, mint az elozo szeria, tehat egy huszarvagassal lecsokkentettek a gyartasi koltseget, a fogyasztast, es megis ugy nez ki, mintha erosebb lenne a hardver altalaban, pedig nem.
-
-
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.
-
Cathulhu
addikt
Raktam fel ICS era utan is, egyszeruen nem mukodik es kesz. A rootolas meg a legtobb esetben a vilag legegyszerubb dolga. Attol, hogy te paranoias vagy, meg nem kell remhireket terjeszteni. Oda van irva, hogy ICS felett nem jo, ne probalgasd, ennyi.
pre-ICS eraban alap dolog volt uj ROM utan CF3D-t felraknom, meg is van belole a premium, nem lassitott semmin, de cserebe a THD-s jatekok szebben futottak mint tegran... -
lenox
veterán
Eredménye van, de az IGP erejéből átszámolni a kép kontrasztját sokkal hatásosabb és energiatakarékosabb.
Ezt nem ertem annyira, a mostani telefonom is reagal a fenyviszonyokra, es van rajta szenzor, ami alapjan teszi, de nincs benne opencl. Masreszt miota kell opencl ahhoz, hogy igp-t hasznaljon az ember?
-
juzer78
tag
"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. "
Ha, de miért nem akarják???
"A TIR speciel nem lenne számukra probléma."
Valahol olvastam, hogy ezt pont nem képesek használni a 6xxx sorozat tagjai. De sok mást igen.
"Szerintem a Kepler esetében eleve a compute herélésére mentek."
De miért is? Amikor minden ebben az irányban halad? És az új konzolok fejlesztései is valószínűleg ebbe mutatnak...
"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."
Ahogy olvasom ez annyira nem is baj, elég sokmindenre használható, és ha több gyártó is támogatja, akkor már akár be is lehet építeni alkalmazásokba... Bár ezt kis pénzzel meg lehetett volna már oldani!
Ebben mondjuk még nincs gyakorlata az AMD-nek, de majd ráéreznek -
Hobbbyt
őstag
Én fölraktam, mindegyik profilt kipróbáltam.. állítgattam benne mindent. De a célomat nem értem el vele.. A Settlers-t nem tudtam normálisan futtatni. Azonkívül hogy 20 percet elszenvedtem vele, semmi károm nem szárazott belőle..
Csak 1 héttel később tudtam meg, hogy nem kompatibilis az ICS-vel és ami utána jön..A Google Play hozzászólásokat hagyjuk inkább.. semmiképp nem nevezhető komoly információforrásnak. Játékoknál oké.. De másban nem.
(#22) Abu85 : Igen, azt tudom hogy maga a Rootolt telefon nem garanciás.. de ha valaki annyira béna, hogy rootolás közbe szép leírás után rossz kernert tegyen fel, vagy akármi.. és képtelen házi eszközökkel életre hívni, az megérdemli azt a kis kiadást ami azzal jár, hogy elviszi egy Sufni GSM boltba ahol Jig segítségével 5 perc alatt gyári állapotra hozzák vissza. Szerintem nem több 2e Ft-nál. (tanulópénznek is elmegy)
-
Bull1
aktív tag
Google Play hozzászólások az appról, ELSŐ oldal, ezek után kíváncsi vagyok fel mered-e rakni, mert én biztos nem.
---
A játékok egy kis részét gyorsitja, nagy részét pedig lassítja vagy fagyasztja. Vagyis nem jó semmmire. Gondolkodjatok!
---
it was worked well with ICS, but after i have installed on my new Jelly Bean tab, it had destroyed my tab i have to take it to the service:p
---
Do not use with jelly bean.....Killed my phone -
Hobbbyt
őstag
Ez a Rootolásból fakadó garanciavesztés meg, hogy ki lehet nyírni vele stb.. szerintem akkora bulshit, hogy eszméleten. Mindenki ismer legalább 1 olyan embert aki nem esik hasra egy rootolástól.
A Chainfire3D sem nyírja ki, csak simán nem működik. Tudom, végigpróbálgattam.. 4.04 és 4.1.2-en
(#19) Abu85 Nemtudom, te hogy csinálnád, de nekem 4.1.2-őn is van Flash. Csak annyi, hogy nem gyárilag.. hanem le kell szedni playből. (nehéz dolog
) -
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.
-
Bull1
aktív tag
De úgy mondod mintha ez a Chainfire alapjaiban rengetné meg a Tegrás játékokat, mert varázsütésre megoldható minden.
Pl. kezedbe adnék egy gyári Galaxy S3-at vagy HTC One X-et, amin tegyük fel a legújabb Android fut (4.1.2).
Meg mernéd rootolni azt a telefont ?
Engedélyeznéd az ál-GPU-t ?
Ha brick-es lesz a telefon, megtéríted az árát ? -
Bull1
aktív tag
-
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. -
juzer78
tag
Na ez az, nincs indok ellene, mégsem építik be... ráadásul a a konzol akármin Androidot akarnak használni, idéznék egy másik cikkből, talán ismerős lesz!
"Az Imagination Technologies példájából látható, hogy a Google és az Apple nem véletlenül szeretné beépíteni az OpenCL támogatást a mobil operációs rendszerekbe, továbbá nem véletlen a WebCL irányába mutatkozó komoly támogatás, hiszen a legtöbb okostelefont és tabletet böngészésre használnak, és jól párhuzamosítható megterhelő tartalmak mellett az IGP-vel való feldolgozás sokkal energiahatékonyabb a központi processzornál, vagyis jelentősen nőhetne a termékek üzemideje."
Andoidot akarnak használni, de OpenCL nélkül? Amikor ezeknek a fejleszéseknek a célja, hogy növeljék a rendszerek teljesítményét, csökkentsék a fogyasztását... akkor most mi is van? Gyorsabb és kevesebbet fogyaszt, most... de mi lesz holnap amikor már elkészül a megfelelő támogatás a hardverekhez nem lesz letiltva és jönnek azok az alkalmazások amik már a IGP erejét is képesek kihasználni... Akkor meg ugyan úgy le fognak maradni, mint ahogy a Tegra 3 lemaradt... pont azért mert egy buta hardvert tettek le az asztalra... bárhogy is közelítjük meg az nv részéről hosszútávon ez mellényúlás... persze lehet azt mondani ott a CUDA, de amikor a fejlesztők mindenhol OpenCL-t használnak, akkor az nv kedvéért piszkosul nem fognak kivételezni...
Ami a DX11.1-et illeti, a Tahiti előbb jött ki, és van DX11.1 támogatása, hogy is van ez??? Az opciós dolgokról meg csak annyit, hogy a TIR (target independent rasterization) nem opciós, mégis azok közé a dolgok közé tartozik, amit a 6xx széria nem támogat... amúgy meg az nv-re jellemző, hogy ami opciós, azt nem kell támogatni, majd fizetünk a fejlesztőknek, hogy ne használják... jó példa erre pl assassins creed első darabja, és a DX10.1 esete... (bár ez nem opciós cvolt, de nem volt nv dx10.1-es hardver, és jött a javítás, ami el is tűntette ezt a játékból örökre)
Az Android esetében viszont sok más gyártó is van, akiknem nem ellensége az innováció, itt a pénzzel nem mennek semmire sem... Ahogy már az asztali szegmensben sem, elég megnézni hány Gaming Evolvedes játék jött ki és hány nv partner programos tavaly...
smkb: "Egy mobil eszköz életciklusa jelenleg jó ha egy év..."
Szerinted azt az nv féle konzolt 1 évre tervezték??? Mert akkor abból nagy ....ok lesznek a jövőben...
-
smkb
őstag
Egy mobil eszköz életciklusa jelenleg jó ha egy év... totál mindegy hogy a szinte alig pár eszközbe majd bekerülő más igp-k tudnak e opengl es 3.0-át (meg ugye egyáltalán az adott os-ben benne van e az api meg driver). Mire arra jönnének alkalmazások, kinn lesz az új Tegra. Pont, hogy az NV nagyon okosan játszik a dizájnokkal. Kb pont arra lőnek amire kell. Mi a fenének dobjanak piacra korukat több évvel megelőző dizájnokat. Inkább pont annyit feccelnek a fejlesztésbe amit bőven ki tudnak termelni.
-
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.
-
juzer78
tag
"egyedül az új Tegra ragadt le. Igazából nem tudom, hogy miért."
Az ok egyszerű, az nvidia nem szereti az innovációt, elvannak a maguk kis világában. Ha az nvidián múlna még mindig csak DX9-es vezérlők lennének az asztali gépekben...
Amikor jött a DX10 csináltak egy tessék-lássék megoldást (igaz bejött nekik, de csak azért mert senki nem épített rá) jött a DX10.1 az nvidia válasza az volt, minek az? Jött a DX11 nagy kinlódásra jött a Fermi, ami ha jól tudom, nem is teljes egészében támogatjaa Dragon Age 2-be használtak valamit, amikor is ez kibukott... itt a DX11.1 amit meg valójában nem is támogat egyetlen nv hardver sem, persze a vezérlőpultban ott virít, hogy DX11.1...
Arról nem is beszélve, hogy OpenCL1.2 támogatás még mindg nincs sehol...
A sebességgel meg mehetnek a levesbe, amikor a fejlődést gátolják, és erre akarnak kézi konzolt építeni, na ne már, ki a fene fog rá fejleszteni, amikor mindenki más újabb jobb megoldásokat támogat?!
-
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.
-
smkb
őstag
"hogy az új generációs konkurens ultramobil grafikus vezérlők számottevően jobb képességekkel rendelkeznek majd a Tegra 4 IGP-jénél, de a potenciális vásárlók nem éppen technikai beállítottságú emberek"
Egyébként van aki azért vesz egy mobil eszközt mert abban húúde nagy tudású gpu van, BÁR semmire nincs használva a nagy tudás, és képesség, de azért nagyon rülök annak hogy van ?
A mobilszegnmens vásárlói aztán pont leginkább azok, akiket egyetlen dolog érdekel, a felhasználói élmény az akkuidő tekintetében. Az, hogy mekkora csoda cucc lakozik a gépben az nagyon nem...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
És erre vonatkozott Abu-hoz intézett kérdésem, melyet meg is válaszolt. 
)
Új hozzászólás Aktív témák
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- A nagy Szóda, Szódakészítés topic - legyen egy kis fröccs is! :-)
- Spórolós topik
- E-roller topik
- Samsung Galaxy A56 - megbízható középszerűség
- WoW avagy World of Warcraft -=MMORPG=-
- ASUS notebook topic
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Azonnali fotós kérdések órája
- LG LCD és LED TV-k
- További aktív témák...
- Telefon felvásárlás!! Samsung Galaxy A22/Samsung Galaxy A23/Samsung Galaxy A25/Samsung Galaxy A05s
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- HIBÁTLAN iPhone 13 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3104
- GYÖNYÖRŰ iPhone 15 Pro 512GB Blue Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3070
- LG 65" C1 OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
Állásajánlatok
Cég: FOTC
Város: Budapest