NVIDIA Kepler - informace, spekulace

[Ache]

blbost... proč by na mainstream kartu cpali 3GB drahé paměti? 1,5GB sice občas na GTX580 přetéká v některých hrách (Serious Sam, Crysis 2 + DX11 + Textury...), ale zatím to nemá viditelný dopad na hratelnost (typické záškuby dotahováním textur).

[Alfajk]

Imho fake, dvojka v "512" nie je rovnako vysoká ako päťka a jednotka.

mno ono i gddr5 vypada divne,jakoby kazdy psany jinym fontem

101% fake

jinak zrovna pameti nejsou vubec drahy,jako samotna soucastka,mozna ze jedna z nejlevnejsich na cely karte

[flanker]

Další tabulka
http://tof.canardpc.com/view/8ed1c0db-d ... a98b06.jpg
http://cpc.cx/3Du

Znovu v tom zmatku těžko říci, kde je pravda...

[dexterav]

už 1024SP sa mi zdá dosť 1536 je blbosť

[flanker]

jakoby to trochu připomínalo dobu GT400 řady....Tehdy se nVidia snažila strašně na sebe upozornit. Ale nemyslím si,že tentokrát to bude špatný produkt. Věřil bych,že naváže na úspěch GTX500.

[Alfajk]

pokud by to byla pravda a vykon by bylo skutecne dvojnasobnej,oproti rade 500,byl by to narez ale vlastne by byly samy proti sobe,s nicim dalsim uz by prakticky nemohli prijit,vzdyt velikostne jsou uz temer na hranici (28nm) a zvetsovanim poctu vypocetnich jednotek to taky uz moc dal nepujde kvuli spotrebe a teplotam

[Raikkonen]

Ta 760 by takto vypadala velmi zajímavě. Kdy se odhadem dá očekávat nástupce 560Ti?

[flanker]

myslím si, že Nvidii to bude trvat někdy do pozdnějšího jara.

[del42sa]

stejný takt pro jádro i shadery ?

according to 3d Center, Nvidia has dropped "Hot Clocks" for the shaders. They will now be clocked at the same rate as the rest of the chip.

In addition, the shaders themselves have been redesigned to be smaller, so that they can pack more of them on the die. They are looking at ca. 1500 for GK 102 and ca. 1000 for GK 104.

http://translate.google.cz/translate?sl ... 2011-12-16

CHarlie Demerjan: Easy enough. GF104 = 384 shaders at ~1645MHz, so a total of 631,680 mythical shader MHZ. If GK104 has 1024 shaders of equal capability, you would need to be at 616MHz. If you are 50% up on that as rumored, then you get about a 50% performance increase, or a bit better than a 580. So far, so consistent with the rumors.

This would however at least double the transistor count, if not more, and the 40->28nm shrink buys you less than 50% savings, so lets just call it 1/3 less. 360 * 2 * .66 = 475. Not looking so good there.

With ONLY a doubling of transistors, then you are at a 15% power savings for the process, and lets be charitable and say they unfuck another 20ish% for the architecture. That means power is 170W * 2 * .66 = 225W. Fair enough.

_IF_ the rumors are true, then the shaders would have to be radically different and smaller, not more capable. I haven't heard directly though.

-Charlie

[no-X]

Charlie zapomíná na to, že scheduling už teď dokáže pracovat s dvojnásobkem SPs, než kolik jich v čipu fyzicky je. Musí - aby tím kompenzoval, že SPs běží na dvojnásobném taktu. Takže pokud by Nvidia hypoteticky zrušila hot-clock a zdvojnásobila namísto toho počet SPs, tak v žádném případě ke zdvojnásobení počtu tranzistorů nedojde. Jako bonus ještě může vzrůst denzita, která dosud byla kvůli stabilitě poměrně nízká. Těžko říct, jestli tímhle směrem Nvidia půjde, ale je to možná a poměrně výhodná cesta.

[flanker]

http://i41.tinypic.com/24yoljb.png


A pak něco jistého:
http://lenzfire.com/2011/12/nvidia-kepl ... att-81669/

[del42sa]

to je ohromný výkonový skok a nějak to nekoresponduje s velikostí jádra u Kepleru. Vše má svoje hranice a tyhle grafy jsou až moc optimistické. Nakonec to nakousnul už NO-X, GCN je mnohem radikálnější změna GPU architektury ve srovnání s Caymanem, zatím co Kepler je jen vylepšená Fermi. Rozhodně se nedá očekávat tak obrovský nárust, to by musely opět být mamutí čipy jako první GF100/110 na hranici možností výrobního procesu, okolo 530mm2 (i když GT 200 bylo ještě větší 576 mm2) a to nějak nekoresponduje s tou zveřejněnou roadmapou Nvidie. Spíše v tom více vidím marketing namířený proti AMD Tahiti.

PS: mě osobně by zajímala ta část : "Tighten integration of GPU and CPU"

[Shakall605]

Ptal jsem se na datum vydání přes FB

NVIDIA Česká Republika Bohužel. Máme přesné datum, ale zatím tato informace nění veřejná.

NVIDIA Česká Republika V nedohlednu to určitě není. Bude to dříve než si myslíte.

[H2SO4]

uz aby to tu bylo,do Ati se mi jit nechce

[DOC_ZENITH]

to je ohromný výkonový skok a nějak to nekoresponduje s velikostí jádra u Kepleru. Vše má svoje hranice a tyhle grafy jsou až moc optimistické. Nakonec to nakousnul už NO-X, GCN je mnohem radikálnější změna GPU architektury ve srovnání s Caymanem, zatím co Kepler je jen vylepšená Fermi. Rozhodně se nedá očekávat tak obrovský nárust, to by musely opět být mamutí čipy jako první GF100/110 na hranici možností výrobního procesu, okolo 530mm2 (i když GT 200 bylo ještě větší 576 mm2) a to nějak nekoresponduje s tou zveřejněnou roadmapou Nvidie. Spíše v tom více vidím marketing namířený proti AMD Tahiti.

PS: mě osobně by zajímala ta část : "Tighten integration of GPU and CPU"

Já si myslím že tím je zmiňováno především sblížení v ohledu schopností a instrukcí. GPU jsou totiž dnes stále velice neuniverzální čipy, neschopné podávat jakékoliv solidní výsledky pokud jim kód neni psanej přímo na míru, a zdaleka ne všechno jde napsat tak aby v tom GPU byly efetivní. Jsou opravdu dobré jen na něco a to je to co se NV snaží změnit. Tou integrací určitě nemyslej HW integraci do jednoho křemíku, atd. Protože ono u GPU je vlastně fuk jestli je někde na PCI-E či sedí u CPU, jeho výpočetní jednotky jsou tak jiné a latency-wise vzdálené, že nemůže být použito pro ten samej thread kterej běží na CPU, i kdyby byl schopen využít schopností GPU. Sen NV je hold to že bude stačit jednoho dne malinkej slabej úspornej CPU (pokud možno jejich že) a veškeré výpočetně náročné operace dokáže schroupat GPU, či potencionálně vícero GPU. V současné době je to ale spíše sen. + To má v tom, že AMD se vydá obdobným směrem, jelikož na poli CPU dokáží konkurovat méně a méně, budou se snažit o naprosto stejnou věc. Jedinej průser tady ale je, že architektury GPU obou výrobců jsou naprosto nekompatibilní a SW psanej pro jedno nejde použít na druhé (aniž by jel třeba 10x pomaleji), což by mohlo vést k rozštěpení PC trhu a tudiž i jeho definitivní smrt, hrálo by se už jen na konzolích a pár PC se specifickym výkonem by bylo ve workstationech a lidi by doma čučeli na net přes různé ARMové hovadiny. To se klidně může stát, pokud AMD a NV nenajdou společnej standard. OpenCL se jím bohužel nestalo.

[del42sa]

Tou integrací určitě nemyslej HW integraci do jednoho křemíku, atd. Protože ono u GPU je vlastně fuk jestli je někde na PCI-E či sedí u CPU, jeho výpočetní jednotky jsou tak jiné a latency-wise vzdálené, že nemůže být použito pro ten samej thread kterej běží na CPU, i kdyby byl schopen využít schopností GPU...... OpenCL se jím bohužel nestalo.

Já si právě naopak nemyslím, že je to jedno zda GPU sedí někde na PCI-E nebo je integrováno přímo v CPU. Právě touhle cestou jde filozofie APU. Jasně že u Llano není GPU s CPU nijak výpočetně provázané, ale už návrh architektury BD s FP unit umístněnou narozdíl od Intelu zcela "samostatně" mimo x86 INT, se samostatným schedulerem umožňuje teoreticky bez velkých latencí nahradit FP SIMD výpočetními bloky GPU *(pozn.)
Samozřejmě GPU je proto potřeba také upravit, aby "mluvilo stejným jazykem" jako CPU a prvním krokem je právě GCN nebo u Nvidie její architektura Fermi.Viz http://pctforum.tyden.cz/viewtopic.php? ... 7#p8230117 Pro takovéto řešení je umístnění GPU výpočetních částí přimo v CPU zásadní.Dopuručuju na toto téma pročíst Kantera, hned první odstavec: http://realworldtech.com/page.cfm?Artic ... 181333&p=6 ale to spíše jen pro upřesnění ať nejsme off-topic

Osobně si myslím, že Nvidia vytváří nějakou obdobu APU na bázi ARM CPU propojeného výpočetně s GPU na bázi heterogenního comutingu (Denver ?) ale to se netýká ani Keplera, spíše až architektury Maxwell. http://www.xbitlabs.com/news/cpu/displa ... Cores.html

Nemyslím si že se Open CL neuchytilo, právě naopak. Jeho nástup je sice pomalejší (právě kvůli CUDA) ale už jen to , že NV portovala Cuda compiler na Open CL před dvěma lety ukazuje, že je to cesta správným směrem. Cuda měla výhodu jen v tom, že byla psaná přímo pro konkrétní hardware (tudíž běžela mnohem líp než cokoliv jiného) a Nvidia tomuto software poskytovala opravdu silnou podporu. Bohužel tato "výhoda" se zároveň stala nevýhodou, protože umožňovala běh GPGPU pouze na jednom propietárním hardware jediné značky.
Otevření CUDA to jenom potvrzuje. Budoucnost je Open CL nebo jiný otevřený jazyk, jako příklad mohu uvést DX, Open GL, Glide, i když se nejdná o GPGPU, ale jako příklad postačí. Proto také Glide začalo upadat, i když bylo z těch rozhraní nejrychlejší a nejjednodušší na programování.Stejně tak dopadla PhysX... ale to už je fakt hodně OT.

*

Each Flex FP has its own scheduler; it does not rely on the integer scheduler to schedule FP commands, nor does it take integer resources to schedule 256-bit executions. This helps to ensure that the FP unit stays full as floating point commands occur. Our competitors’ architectures have had single scheduler for both integer and floating point, which means that both integer and floating point commands are issued by a single shared scheduler vs. having dedicated schedulers for both integer and floating point executions

[Krteq]

Ptal jsem se na datum vydání přes FB
...

Ještě zapomněli na "Are you ready?!"

[DOC_ZENITH]

Tou integrací určitě nemyslej HW integraci do jednoho křemíku, atd. Protože ono u GPU je vlastně fuk jestli je někde na PCI-E či sedí u CPU, jeho výpočetní jednotky jsou tak jiné a latency-wise vzdálené, že nemůže být použito pro ten samej thread kterej běží na CPU, i kdyby byl schopen využít schopností GPU...... OpenCL se jím bohužel nestalo.

Já si právě naopak nemyslím, že je to jedno zda GPU sedí někde na PCI-E nebo je integrováno přímo v CPU. Právě touhle cestou jde filozofie APU. Jasně že u Llano není GPU s CPU nijak výpočetně provázané, ale už návrh architektury BD s FP unit umístněnou narozdíl od Intelu zcela "samostatně" mimo x86 INT, se samostatným schedulerem umožňuje teoreticky bez velkých latencí nahradit FP SIMD výpočetními bloky GPU.Samozřejmě GPU je proto potřeba také upravit, aby "mluvilo stejným jazykem" jako CPU a prvním krokem je právě GCN nebo u Nvidie její architektura Fermi.Viz http://pctforum.tyden.cz/viewtopic.php? ... 7#p8230117 Pro takovéto řešení je umístnění GPU výpočetních částí přimo v CPU zásadní.Dopuručuju na toto téma pročíst Kantera, hned první odstavec: http://realworldtech.com/page.cfm?Artic ... 181333&p=6 ale to spíše jen pro upřesnění ať nejsme off-topic

Osobně si myslím, že Nvidia vytváří nějakou obdobu APU na bázi ARM CPU propojeného výpočetně s GPU na bázi heterogenního comutingu (Denver ?) ale to se netýká ani Keplera, spíše až architektury Maxwell. http://www.xbitlabs.com/news/cpu/displa ... Cores.html

Nemyslím si že se Open CL neuchytilo, právě naopak. Jeho nástup je sice pomalejší (právě kvůli CUDA) ale už jen to , že NV portovala Cuda compiler na Open CL před dvěma lety ukazuje, že je to cesta správným směrem. Cuda měla výhodu jen v tom, že byla psaná přímo pro konkrétní hardware (tudíž běžela mnohem líp než cokoliv jiného) a Nvidia tomuto software poskytovala opravdu silnou podporu. Bohužel tato "výhoda" se zároveň stala nevýhodou, protože umožňovala běh GPGPU pouze na jednom propietárním hardware jediné značky.
Otevření CUDA to jenom potvrzuje. Budoucnost je Open CL nebo jiný otevřený jazyk, jako příklad mohu uvést DX, Open GL, Glide, i když se nejdná o GPGPU, ale jako příklad postačí. Proto také Glide začalo upadat, i když bylo z těch rozhraní nejrychlejší a nejjednodušší na programování.Stejně tak dopadla PhysX... ale to už je fakt hodně OT.

Takhle. U NV by se dalo říci že už APU dávno má že.... Tegra.... GPU můžou zvětšit vždy, ale na lepší CPU nemaj a proto ten koncept v desktopech či latopech nazím narozdíl od AMD nemůžou použít. Pokud by někdo vymyslel GPU co je schopno nahradit FPU jednotku v CPU, bude mít rázem nejrychlejší herní CPU na trhu (pokud něco neposere typu extra slabá ALU či L1 write-trough only, atd.). To bych velice rád viděl ale nikomu se to zatim nepodařilo. Fermi ani neni schopna plně zpracovávat 64-bit kód, částečně ano ale má tam omezení, umí zpracovat kód pro ALU i FPU v 32-bit (samo sebou neni to x86 čip) nicméně efektivita je katastroficky nízká.

K OpenCL řeknu jen to, že je moc otevřené. Ono to ze začátku znělo hezky, že bude možné spustit OpenCL kód na čemkoliv co to podporuje. Ani to nemusí bejt grafika, stačí napsat OpenCL ready driver pro raid řadič a může počítat také, ale tohle je právě ten problém. Už ten fakt že Směrem Cuda -na- OpenCL je možné udělat přímej port naznačuje že zde cosi smrdí. OpenCL totiž jen zaštiťuje celou věc dohromady, ale jednotlivej SW se furt musí psát pro jednotlivé architektury. Neni žádnej univerzální OpenCL software. OpenCL je jen něco jako SW layer, něco jako OS pro tyto aplikace. Kdybych to přirovnal k windows třeba, tak si představ 2 CPU naprosto jiné architektury, jeden by byl třeba současnej Sandy bridge s tou tunou MMX, SSE instrukčí, atd, kolem těch 4Ghz, atd. A druhej by byl třeba fiktivní CPU co je x86 compatible, SW na něm běží ale má úplně jiné instrukce které vyžadují vlastní optimalizaci, a SW psaný pro intela na něm poběži extra slow protože bude moci používat jen základní x86 a x87 instrukce.

Tak přesně to se děje v OpenCL. Co jsem viděl ňáké testy tak vždy byly jak na houpačce. Buďto byla aplikace psaná pro NV a ATI tam naprosto propadla, tak že jet to přes CPU bylo rychlejší, a nebo naopak aplikace byla psaná pro ATI a NV tam naprosto propadla. Vše to byly openCL aplikace, a to je právě ten problém. OpenCL nic nesjednocuje. Zaručuje ti, že ten kód spustíš, ale furt ten kód musí bejt psanej pro konrétní čipy jinak to bude useless a slow. V tomhle dle mého názoru OpenCL selhalo, je to SW specifikace příliš volná aby specifika splnila tuna HW. Ne, měla to bejt jasně daná a přesná věc, aby HW co to podporuje musel být vyvíjenej s tím úmyslem. Oba výrobci by pak měli efektivní čipy pro toto rozhraní, a zároveń by bylo sjednocené a nic by nebránilo tomu aby se pro něj začaly masivně psát aplikace. Ale teď? Je jich jak šafránu a ještě musíš mít GPU toho a toho výrobce aby ti ten či ten SW jel.

Tady je ale ten paradox, že oba výrobci chtěj aby se GPGPU prosadilo, ale zároveň nechtěj udělat společnej standard a společné instrukce, protože to je vždy o něco slower než psát kód rovnou na čip že..... Jenže dokud to neudělaj, tak se SW mezi běžné smrtelníky nerozšíří.

[Krteq]

Jak nesjednocuje? Vždyť OpenCL je čistě API, nikoliv middleware jak jsi popsal.

[webwalker]

Společným standardem (nejen) výrobců gpu je právě OCL. Problémem každé multiplatformy je ale rozdílnost HW na kterém běží (u gpu doteď obzvláště). S příchodem GCN by se ale tahle situace mohla radikálněji změnit, protože AMD opustilo vliw.
Vzhledem k neunifikovaným shaderům se o Tegra dá, jen s přimhouřením obou očí, mluvit jako o APU. ale dejme tomu. Nicméně jsem zvědav, jestli nVidia v ARMu prosadí Cuda, když už se ARM, jako takový, přihlásil právě k OCL.

PS: Tím "Tighten integration of GPU and CPU" imho není míněna Tegra.