Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
to jsou zase hlody: "V tomto okamžiku zbývá volných ještě 256 MB paměti v pravých modulech - už vás asi napadlo, že je k těmto 256 MB pouze pomalý 64bit přístup. V praxi se tedy karta po zaplnění 768 MB paměti zpomalí - prakticky se stane 64bitovou."
jak se asi stane 64bitovou? nic takovyho se teda fakt nestane. i kdyby to nakrasne fungovalo tak, jak si to hurvinkovsky predstavujes, pomaly pristup by se konal jen k tem 256MB, o kterych mluvis. jenze ono to tak nefunguje. split dat pres vsechny kanaly muze fungovat v dolni i horni polovine tech 256MB bloku uplne stejne. jedine, co musi driver rozlisovat, je do jake poloviny chce u tech dvou modulu pristupovat, experte
ta karta ma sice mene ROPs nez puvodni GTX460, ale zaroven ma dost znacne vyssi frekvenci jadra i pameti. dle meho bude vykonem ekvivalentni a "možná se jim raději vyhněte" je presne v duchu tveho maleho tazeni proti nvidii
Paměťový řadič bude stále používat 192bit přístup, ale už nebude moci zapisovat a číst na celé šířce sběrnice.
U dolní části paměti dokáže na jeden takt vytáhnout nebo zapsat po celé šířce, ale do té horní části to samé množství informací musí poslat po částech, takže se zpomalí 2x až 3x.
Nic nevylučuje, že čip samotný má nějaké instrukce, aby ukládal do horní části prioritně data, která se tam vlezou na jeden takt, potom by dokud je dole dost místa na velké věci nedošlo k tak velkému zpomalení.
souhlas, ale pristup do te horni casti lze realizovat vhodnym adresovanim na tech poslednich dvou kanalech. pak by k zadnemu zpomalovani nemelo dochazet. kanal ma dostatecnou sirku na to, aby se to dalo realizovat
Kanály mají šířku 32bitů. Pokud data proudí dvěma kanály o šířce 32bitů, těžko může být přenosová kapacita stejně vysoká, jako pro data proudící šesti kanály o šířce 32 bitů :-) A když k žádnému zpomalování nedochází, proč je reálná přenosová kapacita 192bit GTX 550 Ti stejná jako u 128bit GTS 450? Teoreticky to nemůže efektivně fungovat, prakticky to nefunguje, ale ty si stále opakuješ svou. Helvetská víra hadr :-)
je videt, ze mas k praxi daleko. pokud budu chcit ulozit 64bitova data na 64bitove sbernici, udelam to stejne rychle, jako kdyz budu chtit ulozit 192bit dat na 192bit sbernici, tzn. oboji v jednom cyklu (nebo poctu cyklu potrebnych k takove operaci)
vzhledem k tomu, ze nad grafickou pameti ma plnou kontrolu graficky driver, nevidim duvod, proc by to tak nebylo implementovane. 64bitovych dat nebo mensich je ve 3d grafice opravdu hodne a nvidia si je tam muze ukladat uplne v klidu. jestli tohle nechapes, tak se divim jak muzes psat clanky v technickem magazinu
64bitových dat je hodně. Jenže jaksi zapomínáš na to, že ty 64bitové data zpracovává každej shader zvlášť. Takže v drtivé většíně potřebuješ ne 64bitů, ale 336*64bitů...
a nemyslis, ze by ti na to nestacila ani 512bitova sbernice? clovece, hledej diru ve sve uvaze, je jak vrata
Jestli jsi nepochopil, tak to bylo čistý vyvracení Tvojí úvahy, nic víc. Narozdíl od Tebe netvrdím, že jsem chytřejší než Ti, co ty karty navrhujou.
No ono to třeba nepotřebuje data každej takt. Proto nějaké úvahy na základě toho, jaké se vyskytují data jsou prostě úplně mimo. Všechny moderní karty v tomdle segmentu maj dimenzovanou paměť takhle: kdyby tam šla paměť na poloviční rychlosti, tak by to už někdo dávno udělal.
Víš co, nechci se s Tebou hádat, je to jak mluvit do dubu. Vem si nějakou 460, podtaktuj ji paměti na polovinu, změř výkon a pak se vrať. Jestli to nebude mít vliv na výkon, klidně se Ti omluvim. Ale očekávám totéž od Tebe.
mel by to byt "Narozdíl od noXe netvrdím, že jsem chytřejší než Ti, co ty karty navrhujou." :D
helet clovece, ty ale vubec netusis, jak tyhle veci fungujou. navic vety, co pises, nejak nedavaji smysl. a uz vubec nevim, co s timhle ma spolecneho podtaktovani pameti :)
no, nebudu si hrát že tomu rozumím, ale z logiky věci není právě ten problém to že tady tohle bude korigovat driver? já ti nevím, já si myslím že by s tím mohly být problémy....
jedine, cu musi driver delat, je spravne adresovat dana data, tzn. ti to zvedne zatez cpu o 1% .. to je ale tragedie ;)
á 1%, a proč ne 0,5%? aneb tvá typicky "zaručená informace". Ve skutečnosti je tahle karta mrzák a šmejd stejně jako HD 6790 nebo 5830. Pochopitelně mám pravdu jenom v té druhé části když mluvím o těhle nepovedených Radeonech, zatímco tenhle křáp je naprosto v pořádku že?
6790, 5830 a gtx465 jsou karty, ktery jsou z tezce zmetkovejch cipu a asi nikdy nemely radsi vyjit. tenhle cip je na tom rozhodne mnohem lip. myslim ze to poznas, az vyjde nejaka recenze
a jestli si u toho 1% nepostrech tu nadsazku a toho smajlika, no to je tvuj problem :)
nepsal jsem nikde zátěž CPU ale problémy.... jakéhokoliv rázu, třeba že si s tím driver neporadí tak jak má a framerate to rapidně sníží.... možností je spousta, nicméně nějaké zatížení procesoru o pár % mě ani nenapadlo.... takže takhle nějak jsem to myslel... radši než nechávat softwarovou část ať si poradí s podivným HW návrhem, měl být ten návrh udělaný lépe. toť můj názor....
Existují dva základní modely, jak je možné k takové konfiguraci přistupovat. Druhý je ale ještě méně efektivní a předpokládal by primární využití 128MB modulů s efektivním 128bit přístupem a následně až využití 256MB modulů s 64bit přístupem. Je sice možné aplikovat různé optimalizace pro efektivnější využití popsané konfigurace, ale stále jen do okamžiku, než se menší moduly naplní. Ke zbývající volné kapacitě je pak pomalejší přístup. Praxe je ovšem taková, že přenosová rychlost těchto "192bit" karet s 1 GB paměti odpovídá v nejlepším 128bit modelům... http://images.anandtech.com/graphs/graph4221/35976.png ;-)
zaprve, kdyz sem chces davat obrazek, dej take link k clanku, at to neni vytrzene z kontextu. za druhe se seredne pletes, protoze pristupy do pameti funguji malinko jinak, nez si predstavujes. nebo spis docela dost, viz muj post nahore
Za prve, kazdy priemerne inteligentny simpanz si dokaze najst clanok(http://www.anandtech.com/show/4221/nvidias-gtx-550-ti-coming-up-short-at...) ak ma link jedneho obrazku, alebo aj niektory z kontextu vytrhnuty odsek ako to ty zvyknes postovat.
A za druhe by ma zaujimalo co ta zivi, lebo podla urovne tvojich prispevkov to programovanie asi nebude. Vykonnostna strata pri takto navrhnutej pameti sa da kompenzovat, ale nie zmazat. S tym, ze pri urcitom type uloh moze byt dost citelna.
ty jsi to nepochopil. ja moc dobre vim, kde se to da najit. chtel jsem, aby to noX postul sem sam. protoze je tam pred tim grafem takovy dost vyznamny odstavec, ktery se noXovi nehodi do kramu:
"In the meantime we did do some testing against the more limited memory capacity of the GTX 550. At this point the results are inconclusive at best. Using NVIDIA’s Bandwidth Test CUDA sample program, which is a simple test to measure memcopy bandwidth of the GPU, we tested the GTS 450, GTX 468 768MB, GTX 460 1GB, and GTX 550 Ti at both stock and normalized (GTX 460) clocks. The results were inconclusive – the test seems to scale with core clocks far more than memory bandwidth – which may be another bug, or an artifact of the program having originally been written pre-Fermi. In any case here is the data, but we have low confidence in it."
podle urovne tvych prispevku bych rekl, ze jsi od programovani vzdaleny dost vyznamne. memory management v grafickych driverech je dost slozita vec a jestli sis nevsiml, tak drivery dokazou kompenzovat i dost zasadni veci, treba jako velikost pameti. to bylo reci od noXe kdysi davno jak nvidia gf100 rada stoji za prd, protoze ma malo pameti a jak oooo uzasne radeony maji 2GB a strcu nvidii buhvi kam. realny rozdil memory constrained pripadu byl az na jeden bug u gtx480/580 kolik, 2fps? a naprosto paradni tresnicku na dortu temhle jeho teoriim nasadila sama AMD, kdyz vydali 1GB verzi HD69xx
takze ASD, zkus se zamyslet nad tim, proc sem asi noX nepostnul odkaz na ten clanek, kde komentar k tomu grafu mu dava zcela jine svetlo, nez jake potreboval noX k podporeni svych argumentu. a pak si zkus udelat obrazek o jeho objektivite a verohodnosti, kterou by on jako autor narozdil od nas diskuteru mel mit
"podle urovne tvych prispevku bych rekl...."
...že slušnost a tolerance Vám moc neříká.
V životě nejde o to všem dokázat, že jsem lepší. Jde o to s nimi umět žít.
aha, nezvany mravokarce. mozna by priste chtelo lepe cist a podivat se, kdo s tim zacal, viz. ASD_SK post nad mym:
"A za druhe by ma zaujimalo co ta zivi, lebo podla urovne tvojich prispevkov to programovanie asi nebude."
a bavime se tu o fakticke urovni prispevku
Jako ja chapu ze marketing je mocna vec, ale nechapu proc si hodne lidi obecne mysli ze jsou chytrejsi nez inzenyri co to navrhuji.
Je si nekdo jisty ze dany kus pameti neni urceny pro nejake specialni data? Resp se k nemu tak hw chova?Treba pro konstantni data ktere se tam nahraji jen pri spusteni daneho programu. Nebo nejaka data ktera nejsou zarovnana...
Taky CUDA SDK test bych nebral uplne jako referencni. Nechce se mi cumakovat do zdrojaku ale tipuju ze to bude neco jednoduche ala zkopiruj tenhle buffer z hlavni pameti do pameti zarizeni a zpet. Co realite neodpovida.
Ty si niekde vydel, ze by No-X pisal, ze je chytrejsi ako konstrukter? On len napisal, ze celkovo je rychlost pristupu nizsia co je fakt. Ak by aj boli dake bloky dat o velkosti 64 bit, tak v ten mozment moze vyuzit pre zvysok sirku kanala 128 bit. V kazdom priprade si limitovany. Mozes tam natlacit data, ku ktorim nepristupujes casto a spomelenie bude nizsie, ale vzdy tam bude.
a 128bit dat je snad malo? to je typicky jeden vektor xyzw, nebo jeden pixel textury rgba, atd. .. porad nevidim problem
Jak píšu vedle: v okamžiku, kdy těch 128bitů potřebuje každej shader a při většině operací každej shader jiné, tak je to málo dost výrazně.
Je to, jako bys osadil 460GTX DDR3 paměťma. Pokud by to bylo jedno, jak píšeš, tak by se asi takový karty dělali, ne? DDR3 stojí o dost míň než GDDR5.
tak abych tedy parafrazoval ten tvuj "prispevek" nahore: "Takže v drtivé většíně potřebuješ ne 64bitů, ale 336*64bitů... "
napinava zapletka - tak si to spocteme 336*64=21504 bitu. tak ti nevim, tak siroukou sbernici sem jeste nevidel :) tak a ted napinave rozuzleni: data se fetchuji postupne. a pak spolu zili stastne az do smrti ...
Samozřejmě, že takto jednoduchej výpočet samozřejmě nefunguje, ale je realitě daleko blíž, než tvoje "sedlácká" úvaha o 64bitovejch datech a tak 64bitová sběrnice stačí.
Zkus si srazit paměti u 460 na polovinu a uvidíš, jaký bláboly tady píšeš.
tyjo tenhle clovek mi prijde jako mix atitoma a lada1. vyznate se nekdo v tom, co rika?
jednoduse (pro nekoho mozna slozite, kdyz na to neprijde sam)
takt 4000MHz pameti na zbernici 64bit ma stejnou teoretickou propustnost jako takt pameti 2000MHz na zbernici 128bit. Jelikoz si zbernici doma na kolene nesnizis, ale muzes si srazit takt tak aby rychlost odpovidala nizsi zbernici, je to od logika logicka uvaha. Narozdil od tveho pseudo vypoctu "336*64=21504 bitu" kterej by platil pokud by karta pracovale jen a pouze s jednim taktem a hotovo, restart, konec. Pokud bych pouzil tvuj vzorec a doplnilho nasledovne 336*64(velikost bloku dat)=21504/64(sirka pametove zbernice)=336(pocet potrebnych taktu), pokud vsa pouziju sirku zbernice 128bit 21504/128=168 taktu co bude rychlejsi??? Toto vsak jak clanek popisuje bude platit az po zaplneni onech 768MB pameti a naslednym doplnovani zbytku pameti pouze 64bitovym pristupem kterej, jak zbytek sveta vi, je pomalejsi nez 128bit.
tech 336*64 je ale logikovo nesmysl, ze kteryho jsem si utahoval :) viz. "Takže v drtivé většíně potřebuješ ne 64bitů, ale 336*64bitů... "
vy si to fakt predstavujete hodne divne. zadny podtaktovani nema smysl. je to retardovana uvaha. do te casti se 256MB bloky se ta 64bitova data mohou ukladat (a cist) klidne i na zacatku, v prubehu, nakonci .. kdykoliv. muzu v jednom cyklu ulozit napr. jeden vektor xyzw a k nemu treba texturovaci souradnici uv, tzn. jednim dechem 128bit + 64bit atd.
to je mimochodem dost typicka vec - je to totiz jeden vertex a souradnice textury, ktere se nachazeji v tomto vertexu
ale takovychto prikladu je vic a VY se poustite nekam, kde nemate zadnou pudu pod nohama
"tzn. jednim dechem 128bit + 64bit atd."
jednim dechem? to jako v jednom taktu?
Proc se tedy nedelaji GK s oddelenou pameti
512MB 64bit + 1GB 128bit kdyz je to tak typicka a revolucne bombasticka vec. Zeby texturovaci cace ctvrte urovne :)
protoze 64bit + 128bit je blbost a ty to nechapes. ja nemluvim o 64bit + 128bit. ja mluvim o 192bit, ktery umi fungovat v driverem rizenych situacich jako 128+64bit nebo 64bit
Tak jinak - když bude potřeba přečíst 64 kB dat z paměti, která má šířku 192 bitů, kolik instrukcí čtení bude potřeba? A když stejný objem dat budete číst z paměti s šířkou sběrnice 64 bitů, kolik instrukcí čtení bude potřeba? Zřejmě více, že ;-)
vtip je v tom, ze ten driver tato data rozdeli rovnomerne do vsech modulu, po cele 192bitove sbernici. a data, co maji jen 64bitu muze, uklada vesele plnou rychlosti do tech 256MB modulu po 64bitove sbernici
"a data, co maji jen 64bitu muze, uklada vesele plnou rychlosti do tech 256MB modulu po 64bitove sbernici "
obzvlast me pobavilo "uklada vesele plnou rychlosti"
no plna rychlost snad u te karty nebude onech 64bit to je nejakej faul ne. jak jsem uz psal (nejenom ja) tak do zbytku je bude pumpovat pomalejsim 64bit pristupem.
64bitova data se 64bitovym kanalem ulozi do pameti stejne rychle jako 192bitova kanalem o sirce 192bitu
ale pokud bude volnych uz jen tech 256MB/o sirce pouze 64bitu, budou se 192bitova data posilat 64bitovym kanalem 3x pomaleji.
Rekl bych ze data se budou posilat stale 192bitove a jakmile se zaplni 768MB blok pameti, budou se ty 192 bitovy bloky dat tlacit do zbyle 256MB/64bit pameti.
proc by mely byt volne jen ty 256MB bloky? pokud tam driver bude cpat 64bit data prubezne, muzou se v klidu naplnit. neboli, proc by 64bitova data, kterych je dost, ukladal do nekterych ze 128MB modulu, kdyz je muze ulozit do tech 256MB a nechat si volne misto pro zapis 192bit
Navíc pochybuju, že tam takovýdle optimalizace dělaj. To by museli pro ten účel speciálně přepisovat drivery a to kvůli takovýdle "zkriplený" kartě IMHO dělat nebudou.
Precti si Heterogeneous Computing with OpenCL nebo OpenCL Programming Guide. Pak pochopis ze jakkoli koukat na grafiku a jeji pametovy subsystem z pohledu pametove architetkury CPU je absolutne zcestne.
Jeste jednou zopakuji ze nevim jestli je to jen marketingovy tah, nebo ne, ale zatim sem tu krome jakychsi domenek necetl nic, co by me presvedcilo ze to tak je.
Nějak nechápu, co tim chceš říci. Jednak jsou dvě naprosto rozdílný věci API, kterym je práce s pamětí přístupná a samotný to, jak je to zadrátovaný na kartě,
jednak to, jak je to na kartě zadrátovaný se vcelku ví, jednak fakt nechápu s čim polemizuješ a jak myslíš, že to je.
ono se vim, jak je to "zadratovany"? tak to me pouc, kde se to vi, at si o tom "zarucenem" zadratovani neco prectu :)
Preto som napisal ze to plati obecne, s No-X nemam ziaden problem. Ale az priliz casto clovek na webe vidi ako autori prispevkov ale aj clankov mozu ist rovno sefovat vyvojarskym oddeleniam. A je jedno ci sa jedna o GT-R launch control, alebo CPU/GPU
trefil jsi povestny hrebicek na povestnou hlavicku :) +1
Asi v duchu diskuze přidám vlastní příspěvek.
To jste tady takový somráci že je vám líto přidat 400Kč na GTX 560 a hádáte se tady o nesmyslech?
čoveče a ty jsi viděl že by tady někdo psal že si chce kupovat grafiku? Dyk to je jen klasická diskuse technického rázu ala Terrorist vs ostatní.... :-D
Ale tak to není. Terrorista má občas i pravdu. Obzvlášť když se hádá s Machinou :-)
kde tam vidíš napsané že kecá blbosti a nemá pravdu? já si nepamatuju že bych to tvrdil, minimálně v tom co jsem napsal před dvaceti minutama :-D
Podle mě je ryze z říše snů aby NV upravovala ovladače aby efektivně využívaly ten drobet paměti navíc. A Terrorista tvrdí že by to šlo. To je podle mě blud.
podle mě taky, tedy to, že by to dělali, nicméně si myslím že má pravdu a udělat v driveru tuhle úpravu pro přímo tyto karty by šlo.
Teď je jen otázka jestli to NV udělá ;-)
Hlavně terroristův Atom a k němu SSD má pravdu vždycky
pokud si vzpominam, tak te posledne setrel tralalak svymi testy :) ssdcko dela divy i s temihle pomalymi systemy :)
tak to bych chtěl ty testy vidět :-D, stejně jako bych chtěl vidět kde Tralalák doporučuje drahé SSD k lowend budgetovým procesorům, jejichž cena nepředstavuje snad ani třetinu ceny toho SSD, takovou blbost by nikdy nevyslovil, to můžeš vyslovit jen ty sám. Je to asi jako na 10 koňovém motoru dělat supertuningové úpravy. Chtěl jsem jenom Kertovi ukázat, jak máš "vždycky" pravdu
cti a plac :)
"Tralalák | 24. 11. 2011 23:41 | reagovat
0 Nahlásit
Inak vstupil som si so svedomia (aj preto, že som posledne VIA Nano X2 testoval len s 3,5" HDD 7200ot/min 16MB buffer a investoval som do 64GB SSD Kingston V200.
Naozaj aj všetkym Zakatistom Bobcatovitým, ale aj Atomistom (teda tam sa obmedzím len na najrýchlejšie tikajúci model D2700 2.13GHz) doporučujem SSDčko.
zdroj: http://extrahardware.cnews.cz/forum/viewtopic.php?f=38&t=20384&p=281272#... "
oo machino, ted bych chtel videt tvuj vyraz :D
Tato karta me pripada stejne nesmyslna jako par low-endovych karet osazenych 2GB DDR3 misto treba 512MB-1GB rychlejsi GDDR5. cenove by to vyslo na stejno, ale jeste nedavno bylo cisilko 2GB pro BFU naprosto magicky a neznalyho zakaznika pri nakupu marketovyho PC toto cislo presvedcilo natolik ze si onu "super 2GB" kartu poridi.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.