Hardwarové novinky – 52+53/2009

6. 1. 2010 | David Ježek | Hardware | 2158×

V posledním dílu hardwarových novinek za loňský rok se podíváme na první ohlášené karty na bázi architektury Nvidia Fermi, dále na specifikaci pro 3D Blu-ray filmy, nový patent Sony zavánějící duchem Foveonu a také nový diskový formát ADF, od kterého si Western Digital, jako první z výrobců, slibuje zvýšení kapacity disků.

Obsah

• Nvidia Tesla C2050 a C2070 na bázi Fermi
• GeForce na bázi Fermi později
• Specifikace pro 3D Blu-ray dokončena
• Směřuje Sony k Foveonu X3?
• Advanced Disk Format: 4kB sektory pro HDD u Western Digital realitou

Nvidia Tesla C2050 a C2070 na bázi Fermi

Od záříjové „papírové prezentace“ nové architektury Fermi uběhla spousta vody. Až nyní Nvidia představila první reálné produkty, dvě výpočetní karty rodiny Tesla. Modely C2050 a C2070 se od sebe liší taktem jader CUDA: 1,25 versus 1,40 GHz. Co ale možná každý nečekal, CUDA jader nenesou 512, ale „pouze“ 448. Na jednu stranu podezřele málo, na stranu druhou přicházejí drby o tom, že jde o první várku GPU z předposlední úpravy pro 40nm výrobní proces, která má nějakou část defektní, případně jsou jisté partie úmyslně vypnuty, aby spotřeba karet byla na optimálním poměru výkon/spotřeba tak, aby v Oak Ridge National Laboratory, kde budou stavět nový superpočítač na bázi Tesla Fermi, neměli problém s napájením (už tak tam za rok spotřebují tolik MWh, že z toho mají blízké i vzdálené elektrárny špatné spaní :-).

Každopádně TDP těchto karet činí 190, resp. 225 W, liší se též množstvím 384bitové paměti (tvořené 24 paměťovými čipy): Nižší má jen 3 GB GDDR5, vyšší celých 6 GB, taktovány jsou na 1,8 až 2,0 GHz (to značí efektivně 8GHz GDDR5 čipy, což je snad až příliš vysoké číslo, ale opravdu to ve specifikaci Nvidia takto má). Zapnutí ECC pro paměti způsobí pokles reálné paměti na 2,625, resp. 5,25 GB. PCB karet je 10vrstvé, GPU o rozměrech pouzdra 42,5x42,5 mm má 1981 kontaktů.

Napájení pochopitelně s ohledem na TDP zajišťuje 6+8pin PCIe. Výpočetní výkon Nvidia pasuje na 520 až 630 GFLOPS v double-precision, což by pro budoucí karty s 512 jádry CUDA na řekněme ještě trochu vyšších frekvencích (až se uklidní 40nm výroba u TSMC) značilo schopnost dosáhnout na zhruba 0,8 TFLOPS pro jedno GPU. Za Tesly si Nvidia nechává patřičně zaplatit, takže si připravte 2499, resp 3999 dolarů za C2050, resp. C2070. Spolu s nimi se objeví i 1U racky S2050 a S2070 obsahujíc vždy čtyři karty uvnitř a příslušný napájecí zdroj a chlazení (tyto placky asi budou „fasovat“ v Oak Ridge), ty již „koštují“ 12995, resp 18995 dolarů, ale na trhu se objeví nejdříve ve druhém kvartálu 2010 (S2050), S2070 až ve třetím.

GeForce na bázi Fermi později

To bychom měli nové Tesly. Vedle nich pochopitelně čekejme i karty rodiny Quadro, oboje řady budou mít od Nvidie velkou podporu, ale většina z nás samozřejmě čeká na GeForce. V rámci celé řady Fermi se pustím trochu více na pole spekulací: Lze očekávat, že uvedení proběhne podobně jako v minulosti, kdy Nvidia hned zpočátku uvedla na trh hi-end modely (ať již šlo o GeForce 8800 GTX v roce 2006, nebo GeForce GTX 280 v roce 2008).

Nyní v roce 2010 se dočkáme něčeho, co se předběžně nazývá „GeForce GTX 380“ a přisuzuje se tomu, na rozdíl od prvních Tesel, plných 512 jader CUDA. Nakolik to bude pravda, to ukáže až „den D“, resp. případné uniklé materiálů v době před ním. „Den D“ ještě není přesně znám, pouze DigiTimes hovoří o tom, že to bude březen 2010 – na tento termín měla Nvidia uvedení posunout.

Důvody jsou nasnadě: Vedle pravděpodobných posledních úprav jemných nuancí ve výrobě karet samotných zde vyplouvá na povrch potřeba předvyrobit dostatečné množství karet pro trh, který je v posledních měsících neskutečně hladový a okamžitě polyká úplně každý Radeon HD 5000, zatímco čeká na konkurenci. Jdou zvěsti, že nedostatek Radeonů HD 5000 už vlastně není takový problém. Jde o to, že ATI se na launch této řady dostatečně zásobila, dokonce více, než u Radeonů HD 4800, ale protože na trhu je neskutečné sucho, GeForce řady 200 se v podstatě jen doprodávají, tak i toto nemalé množství karet spolu s „lehce problematickou“ běžící výrobou, nestačilo po uvedení Windows 7/DirectX 11 pokrýt obrovskou poptávku. Já osobně nepochybuji, že tato poptávka vydrží až do března a řada lidí třeba v únoru nebude nakupovat, protože si budou chtít počkat, s čím přijde Nvidia. Ta tedy musí být připravena vrhnout na pulty eshopů v počátečních dnech od uvedení karet ideálně pár set tisíc kousků (nejen „GTX 380“, ale také „GTX 360“ a i případné další modely, přijdou-li).

Specifikace pro 3D Blu-ray dokončena

Blu-ray Disc Association (BDA) konečně dokončila finální verzi specifikace pro trojrozměrné HD filmy, která vstupuje ve známost jako „Blu-ray 3D“. Obsahuje veškeré potřebné specifikace pro hardwarovou i softwarovou stránku věci a mimo jiné z nich (jak jinak, když „tam sedí“ i Sony) plyne, že je v silách Playstation 3 tento formát plně podporovat (nejspíš to bude otázkou některého z příštích firmwarů).

BDA trochu slovíčkaří, pokud se budeme bavit o části disků zahrnující 3D grafiku v menu a různé doprovodné aspekty, pak jej specifikace označuje jako „3D“. Co se však týče vlastních filmů, to BDA označuje jako „3-D“. Systém trojrozměrných filmů využívá samostatných zobrazení pro levé a pravé oko a není závislý na zobrazovacím zařízení, popisuje samostatný princip a jeho implementaci. Zavádí novou verzi kodeku H.264 označovanou jako Multiview Video Coding (MVC). Ta je zpětně kompatibilní s „2-D“ zobrazením, resp. přehrávači. 3-D filmy tak bude možné přehrávat i na starších Blu-ray přehrávačích, které jej zkrátka pustí „dvojrozměrně“. Datová náročnost pro MVC kódování vzrůstá oproti běžnému zhruba o 50 %.

Připomenu, že stolní přehrávače toto umět typicky budou (pouze ty staré to asi nezvládnou ani po aktualizaci firmwaru), vedle Playstation 3 pak své řešení chystají Nvidia i ATI, kde prvně jmenovaná jej již předvedla, avšak obě firmy se s ním pochlubí na lednové akci CES 2010. Filmy jako Avatar tedy mají na modrolaserovém disku zelenou (a neodpustím si tradiční rýpnutí: Jak dlouho asi potrvá, než se ve 3-D objeví první „P“? :-).

Směřuje Sony k Foveonu X3?

Období asimilace Minolty máme již dávno více či méně zdárně za sebou, a tak se Sony poohlíží dále. Na své limity již prakticky narazila, APS-C snímač o rozlišení přes 14 Mpix, resp. fullframe snímač s rozlišením přes 24 Mpix oba představují asi krajní mez, za kterou nemá smysl se pustit, protože za touto mezí již leží buď příliš malé snímací buňky (a nutnost matematicky kouzlit, aby z toho vylezla použitelná fotka), nebo neschopnost běžných objektivů (nestojících desítky tisíc) vůbec na snímač přenést takové množství detailů.

A kam jinam vykročit než směrem od více než 30 let starého bayerova principu snímacích prvků, který zaznamenává pouze třetinu barevné informace a zbytek si vymýšlí (dopočítává). Tedy směrem k Foveonu. Foveon jako firmu založila skupina inženýrů, kteří ze svých dílčích patentů poskládali a dovyvinuli celek známý jako snímač Foveon X3 (PDF), který v praxi implementovala do svých DSLR firma Sigma (od modelu SD9, resp. kompaktů počínaje DP1).

Nyní přichází Sony se svým vlastním patentem, který jakoby principiálně Foveonu z oka vypadl. Zatím není jasné, jak je to možné, takže si proberme varianty (v podání Jirky Součka).

Tou první je, že Sigma zapomněla obnovit svůj patent (bavíme se o US patentech) na Foveon, od jehož registrace uplynulo před několika týdny právě 10 let. Osobně nevím, že by US patenty měly takto krátkou platnost a nevěřím, že by v Sigmě byli tací diletanti, nicméně smysl by to dávat mohlo.

Druhou variantou je to, že Sony mohla realizovat dílčí vylepšení technologie Foveon: Vyčítání a zpracování signálu po vrstvách pro zlepšení SNR. To by předpokládalo, že došlo k jisté dohodě, resp. výměně technologií mezi Sigmou a Sony, takže by v budoucnu mohla Foveon pro Sigmu vyrábět Sony (a přiznejme si, že takový fullframe Foveon X3 s vylepšeným poměrem signál/šum, to by byla radost).

A do třetice může jít o patent Sony na jejich vlastní interní záležitost, kterou chystají, a jen se Foveonu podobá, nicméně to se nejeví reálné. Každopádně snad za pár týdnů/měsíců budeme moudřejší.

Advanced Disk Format: 4kB sektory pro HDD u Western Digital realitou

Všimli jste si, jak se pevné disky zastavily na 2TB limitu? Hloupá otázka, jistě všimli a jednou z věcí, která v tomto ohledu výrobce „zlobí“, jsou dosud používané 512B sektory, které jsou dědictvím minulosti a které vedle samotných dat obsahují vždy i nějaká ta „metadata“ jako Sync/DAM bloky, ECC a mezeru před dalším blokem.

Je zde ale nový formát, který nejmenší adresovatelnou velikost posune na 4096 B při zachování velikosti Sync/DAM bloků, avšak s delšími ECC sekcemi (pochopitelně), což se s úsporou na Sync/DAM trochu „vykrátí“ a celkově dá o 7 až 11 % vyšší kapacitu disku při stejných plotnách.

Úprava je ale pochopitelně zpětně částečně nekompatibilní, takže některé OS si s ní samy o sobě neporadí (pro Windows XP má například Western Digital vlastní Align utilitu). V Linuxu nás to na 99,99 % nebude muset trápit, nepochybuji, že stejně jako v případě USB 3.0, bude první (nebo jedním z prvních) s podporou ADF.

Kompatibilita je zajištěna na úrovni samotného disku, který si s příkazem požadujícím čtení/zápis nějakého 512B sektoru umí poradit tak, že ze 4kB sektoru vybere daný 512B blok. Pouze v případě zápisu je však drobné zdržení v tom, že se nejprve musí načíst celý 4kB blok do vyrovnávací paměti, nahradit požadovaná 512B část a poté celý 4kB opět zapsat na disk. Co to udělá s IOPS, resp. přístupem k malým souborům „starým 512B způsobem“, toť otázka.

Western Digital je prvním výrobcem, který disky se 4kB bloky, tedy ADF disky, inzeruje. Odlišíte je tak, že jejich označení končí na EARS, například tedy WDxyEARS, kde xy značí kapacitu v x,y GB, aktuálně tedy: WD10EARS, WD15EARS a WD20EARS – ano jsou to právě ony disky, o kterých jsme si povídali před týdnem.

       

Komentáře

[Jardík]

V Linuxu nás to na 99,99 % nebude muset trápit, nepochybuji, že stejně jako v případě USB 3.0, bude první (nebo jedním z prvních) s podporou ADF

Článek na diit zmiňuje, že Windows Vista/7 s tím počítá, takže linux první nebude ...

[David Ježek]

no proto je tam ta závorka. nepodařilo se mi to nijak vypátrat, jak to s tou časovou posloupností bylo/je/bude.

[Jardík]

No jo, závorka, já jí přehlédl Taky věřím, že bude např. dřív než v MacOS X, který dodnes neumí ISO Level 3.

[the.max]

To, ze s tim pocita jeste neznamena, ze to i funguje

[petr_p]

Nevím, jak je na tom jádro, ale balík util-linux-ng (od 2.17rc2) je již připraven:

#: fdisk/fdisk.c:780
#, c-format
msgid ""
"\n"
"The device presents a logical sector size that is smaller than\n"
"the physical sector size. Aligning to a physical sector boundary\n"
"is recommended, or performance may be impacted.\n"
"\n"

Podobně blockdev má už nějakou dobu přepínač get sector size a naposledy byl rozdvojen na get logical block (sector) size a get physical block (sector) size.

Spolu tím začal blockdev i fdisk hovořit o tzv. alignment a že

#: fdisk/fdisk.c:792
#, c-format
msgid ""
"WARNING: The device does not provide compensation (alignment_offset)\n"
"for DOS-compatible partitioning, but DOS-compatible mode is enabled.\n"
"Use command 'c' to switch-off DOS mode.\n"
"\n"

Takže to je asi ona podpora zpětné kompatibility ze strany disků.

[Jan Grmela]

Ehm...

[Jardík]

Na to nepůjdu, bych se tam asi hned udělal a v kině se spoustou diváků by to nebylo moc příjemné, ať už pro mě nebo pro ně

[frr]

Heh - čili ADF víceméně znamená, že disk bude interně používat a navenek hlásit velikost sektoru 4 kB (jenom doufám, že disk tohle skrz ATA hlásí / OS to detekuje - no asi jo, třeba CD média mají taky sektor tuším 2 kB, ale zas ATAPI je něco trochu jiného než ATA). Na SCSI příležitostně používám 4kB sektory už delší dobu, u externích RAIDů (je to konfigurovatelné).

Widle s tím nikdy neměly problém (počínaje Windows 2000) a jedná se o klasický způsob, jak ve Windows 2000 / XP 32bit dosáhnout velikosti disku nad 2 TB (protože limit na 2^32 sektorů = 32bitovou LBA adresu nelze v těchto OS obejít). Jde o to, že OS interně softwarově používá pro LBA adresy v blokové vrstvě 32b datový typ.

Druhou možností, jak připojit k počítači disk větší než 2 TB, je použít více bitů v LBA adrese. Třeba v rámci SCSI (a FC a SAS) už od dob U320 existuje možnost LBA64 namísto starého LBA32 (vyžaduje formát rámce CDB16, namísto starého CDB12). Na ATA/SATA už dlouhou dobu funguje adresace LBA48, takže v tomto smyslu disky žádné principielní omezení nemají. Omezení je na straně rozšířených operačních systémů.

To, že se SATA disky momentálně "zastavily na 2 TB" je podle mého spíš shoda okolností. Jednou k tomu dojít muselo, dřív nebo později. Stav technologie disků momentálně neumožňuje výrazně víc, tak proč si komplikovat život tím, že uvedeme disk velký 2.2TB, který stejně spousta Widlí bude detekovat jako 2TB (vyšší adresy nebudou vidět). Vlastně je problém už v PC BIOSu - disk o kapacitě nad 2TB nepůjde opatřit klasickou BIOSovou tabulkou rozdělení, potažmo z něj nepůjde bootovat (pokud budete trvat na využití celé kapacity). Řešením je EFI a jeho GPT (= koupit nový počítač). Nicméně, až bude technologie ploten a hlav dovolovat vyšší kapacitu, tak se nikdo dlouho rozpakovat nebude a větší disky se na trhu objeví.

Konkrétně v Linuxu ještě před nedávnem (řekněme 2 roky zpátky) nebyla podpora sektorů >512B obecně v pořádku. Některé user-space utility s většími sektory nepočítaly a stejně tak některé filesystémy (nebo snad jejich user-space management utility) vykazovaly v těchto situacích chybné chování. Tuším jsem četl poznámky v tom smyslu také o DM/MD subsystémech. Je to maličko paradoxní v tom ohledu, že bloková vrstva v Linuxu 2.6 má odjakživa granularitu přístupů na disk právě 4 kB (je to způsobeno těsným propojením blokové vrstvy s VM = správou paměti, kde je 4kB stránka tradiční), přestože velikost sektoru je stejně tradičních 512B téměř natvrdo. Pokud nevěřite, zkuste "dd if=/dev/zero of=/dev/sdX bs=512" a mrkněte na iostat. Potom totéž s bs=4096. Při velikosti bloku 512B uvidíte dost velký read-ahead, při velikosti bloku 4 kB jenom čistý zápis. Bacha, ten příkaz znamená zápis na disk, cílový disk se smaže do stavu "factory clean" Jinak řečeno, Linux interně dávno dělá to, co teď s velkou slávou zavádí WD do svých disků... a proto vcelku nepochybuji, že "4kB disky" budou v Linuxových kruzích vřele přijaty, a pokud je ještě potřeba něco v kernelu v tomto ohledu optimalizovat, nebude to problém.

Naopak interní podpora LBA64 (a CDB16) v Linuxu je už pár let docela dobrá, i v 32b jádrech (CONFIG_LBD), ačkoli user-space v distribucích taky ještě cca před 3 lety trochu drhnul (podrobnosti si nepamatuju). Pak může být problém s omezeními u jednotlivých filesystémů, ale pokud vím, EXT4, XFS, BTRFS a další moderní FS nikde blízko omezení nemají. XFS na 32b jádře umí max. 16TB. Problém s bootováním přes PC BIOS se týká i Linuxu, ale pokud se nejedná o bootovací disk, tak není problém použít ho nastojato bez rozdělení (lidi od FreeBSD tomu říkají "dangerously dedicated") nebo na něm vyrobit GPT, bez ohledu na to, jestli ho BIOS umí nebo ne.

Mám subjektivní pocit, že některé RAIDy, když nakonfigurujete *venkovní* velikost sektoru na 4 kB, jedou rychleji (proti diskům samozřejmě musí používat 512B sektory). Možná jim to zmenší složitost indexů v interní keši (8x, tj. v průměru o tři patra binárního stromu). Nebo se jim 32b aritmetika s LBA adresami snáz počítá než 64b (ačkoli běžně používané IOP CPU jsou už drahně let interně 64bitové).

[m;)]

pekne

[Stanislav Brabec]

Tvrdit, že u čipu Foveon není nutné data dopočítávat, je poněkud troufalé.

Foveon sice snímá 3 barevné kanály v každém bodu, ale má jednu nepříjemnou vlastnost: Barevné kanály jsou od sebe velmi špatně oddělené a jsou mezi nimi velké silné závislosti.

Což o to, to umí řešit poněkud výrazněji korigující barevný profil, ale to by u Foveonu nestačilo. Po zesílení rozdílu vzniká na barevném signálu několikanásobně vyšší šum než u jasového signálu. Bohužel, lidské oko je na barevný šum mnohem citlivější než na jasový.

Takže se opět dopočitává. Pohledem na okolní pixely se odhaduje, která část signálu je šum a co jsou užitečná data.

Pro srovnání:

Jednoduchá implementace Bayerovy masky v dcraw má 32 řádků.

Implementace filtrování šumu ze snímačů Foveon v dcraw má 661 řádků.

[Kvakor]

Zajímavé. To, že snímač Fovenon XC3 potřebuje také dopočítávání, je jasné už ze zobrazení samotného senzoru - jednotlivé vrstvy jsou přes sebe, takže nezachycují přímo R, G, B, ale spíš R+G+B, R+G a R, a neměří se absolutní velikost napětí, ale jejich rozdíly. Ten problém s barevným šumem ale o dost méně známý, nejspíš k prozatím malému rozšíření tohoto typu snímače.

Je ale pochpitelnější v okamžiku, kdy si uvědomíme, že zatímco senzor s Bayerovou maskou obětuje ve prospěch "pravých" barev prostor chipu (tj. tam, kde se snímá jedna barva, se už nemlůže snímat jiná), Foveon naopak ve prospěch prostoru chipu obětuje "pravé" barvy, protože vrsvy křemíku nejsou moc dobrý barevný filtr a nemohou čistě oddělit jednotlivé vlnové délky.

Tudíž se barvy musejí dopočítat ze vzájemných rozdílů a pokud je zde přítomen šum, tak bude z důvodů různých vlastností vrstev senzoru a jejcih vzájemné závislosti mnohem barevnější než u senzoru s Bayerovou maskou, kde šumí všechny barevné kanály obdobně.

BTW: I z klasického senzoru s Bayerovou maskou můžete dostat "nedopočítávaný" obraz ... pokud vám nevadí, že rozlišení klesne na jednu čtvrtinu. U dcrawu je na to volba -h a celkem se hodí, pokud potřebujete udělat náhledy z RAWů, co nemají v sobě uložený náhled - vzhledem k trivialitě výpočtu je generování výsledného obrazu velmi rychlé.

[DJnero]

Neříká se voda! Říká se pivo!