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.
No, kdyz si vezmu, ze kolegove tady koduji 8K video ve formatu JPEG2000 (samozrejme realtime) pomoci desktopove Nvidia grafiky, tak se AMD nema moc cim chlubit.
Kterou desktopovou grafiku k tomu používají?
http://on-demand.gputechconf.com/gtc/2013/poster/pdf/P0227_JiriMatela.pdf
Díky. Vypadá to zajímavě. Jen jeden detail - srovnáváte software napsaný třetí stranou pro grafickou kartu za 10 000 Kč s nativní funkcí procesoru za 800 Kč.
Srovnavam rok stary vyzkum s tim co ted AMD publikuje jako uzasne vylepseni.
Ano, je mi jasne ze na tomhle procesoru to tak krasne skalovat nebude, protoze integrovana grafika nema tolik jader jako dedikovane. Nicmene to zrychleji je naprosto trapne.
Mozna za to muzou rozdily ve specifikaci JPEG vs. JPEG2000. Mozna JPEG nejde tak dobre paralelizovat.
Výpočetní výkon Kabini je 58 GFLOPS. Výpočetní výkon GTX 580 je 1580 GFLOPS. V případě 27× výkonnějšího čipu je zrychlení 7-50× vyšší oproti (cituji) "proprietary multi-threaded and single threaded open source CPU implementations" docela očekávatelné. V obou případech je zrychlení přepočtené na výkonnostní potenciál čipu prakticky totožné, jinými slovy efektivita obou (byť v mírně odlišném kodeku) je obdobná. Není mi jasné, co vlastně kritizujete.
Odvozovat rychlost cehokoliv ve flopsech dnes muze leda clovek, ktery srovnava x86 a arm podle vysledku v antutu nebo jine trapnosti.
Ta kabini "muze mit" obvod, ktery bude dekodovat jpeg tisickrat rychlej nez ta grafika ..... a kde jsou ted tve flopsy?:)
Srovnáváme konkrétní reálná řešení postavená na výpočetním výkonu unifikovaného jádra (proto má smysl srovnávat výpočetní výkon unifikovaných jader), nikoli hypotetické scénáře se specializovaným obvodem, protože ani jeden ze srovnávaných produktů specializovaný obvod pro JPEG nemá.
No, kdyz pisou, ze AMD aktivovala JPEG dekoder, tak bych cekal, ze maji nejaky obvod/instrukci, ktera to zaridi a jen napsali driver a override knihovnu.
8K? pri zminenych 203MPx/s to dela 6 fps. Mozna jste myslel 4K/24fps...
Bude to mít vliv i na přehrávání videa .MOV s JPEG kompresí?
Nahrazuje to dekodér OS pro statický JPEG, takže pravděpodobně ne.
A minusky zasa lietaju ako dive. AMD sa zasa prezentuje dalsou zbitocnou PR volovinou namiesto toho aby riesili realne problemy. A akcelerovat kompresiu jpegu kde sa to mozno prejavi ak uzivatel bude enkodovat nejake 8k a vecsie obrazky v davke mi pride ako dost uletene. Pri beznom pouziti je prinos nula. Nehovoriac o tom ze z hladiska bezpecnosti su vzdy ovladace grafickych kariet, a to kazdeho vyrobcu, derave a nachylne na nejaky ten bug. Ostatne si satci spomenut ako musel MS riesit bezpecnosne zaplaty v svojom dekodere obrazkov (tusim jpeg alebo png). Uz vidim ako niekto pekne poriesi zhodenie ovladacov/pc cez specificky image. To uz ani nehovorim ze je trochu divne ze si uzivatel ani nemoze vybrat ci chce danu "featuru" nainstalovat alebo nie.
Tak ono ta dekomprese jpegu je spis takovy sideefekt dekomprese videa, u ktereho to ma trochu vetsi smysl ... ale jako ta idea, ze se to vsechno narve do monolitickych ovladacu graficke karty mi taky pripada strelena. Kdyz do toho ovladace narvou takovych blbosti, tak je pak jasne, ze v nich jsou chyby ...
Nuz to odznelo na viacerych prednaskach ako aj nVidie aj ludi od AMD a asi ani Intel nebude namietat - GPU su dost komplikovane state machine ktore sa mozu nachadazt v obrovskom mnozstve stavou a este aj ovladac dnes musi riesit pararelny pristup. Celkovo asi dnes neexistuje komplexnejsi kus HW na beznom PC ako je graficka karta a k tomu patri aj komplexny a teda aj na bugy nachylny ovladac. Ostatne to je bezna hratka na Linuxe, co sa casto testuje na bezpecnost - X server a ovladace na grafiku. Keby to vydali ako samostatny program/kniznicu ktoru ked niekto chce tak si ju do systemu nainstaluje a poleze to standardne cez api karty (d3d,ogl alebo nieco ine) tak ok je to rozhodnutie uzivatela, ale takto ?
Může tohle vylepšení znamenat rychlejší práci s grafickými editory, například bitmapy v Gimpu, Darktable, nebo PS?
O tom docela pochybujem. Teda minimalne co sa tyka Photoshopu. Ten sam o sebe uz par verzii pouziva OpenCL na nejake operacie. Obrazok 16k x 16k zaberie po vytvoreni okolo 500mb (teda cely photoshop). Potom to samozrejme narasta podla operacii. Ukladanie do PSD je prakticky okamzite (zalezi od disku) a do jpegu trva par sekund (4-5). Nebadat nejaky rozdiel podla nastavenia kompresie. Jedine co uz photoshopu robi problem ked si nechate zaskrtnute preview, to pri takom rozliseni ho uz celkom vytazi.Skor si myslim ze to moze byt vyditelne ked sa pusti nejaka batch konverzia, povedzme 300 fotiek. Tam sa moze teoreticky usetrit nejaky cas, ale je otazne ci graficke editory pouzivaju systemove kniznice (skor si myslim ze nie) alebo svoje vlastne (vysoko pravdepodobne).
Kdyz jste u toho, poradte nejaky slusny prohlizec obrazku (jako nahradu za muj acdsee 3.1 - shit, se divam, ze je to SW z minuleho tisicileti pro W95, ale funguje porad i na W8.1 zcela v pohode:o), ktery bude umet vice jader, neco jako je ten metro prohlizec ve W8, ale radsi bych neco desktopoveho .....
Treba irfan mi nevyhovuje, krom pomalosti, taky tim, ze nema nezavisle zpracovani a musi se pockat az se nacte cely obrazek, coz je u 20MB jpegu docela opruz. Taky se mi u acdsee libi, ze pri kliku na enter se zobrazi nahledy fotek celeho adresare a vlevo dole mam pak jeste vetsi tu danou fotku takze se v tom paradne hleda a tridi.
Lol, vidim, ze uz je acdsee 17:o) Ale ja zustaval tenkrat u 3ky, protoze myslim uz 4ka byla hnusny moloch s webbrowserem a picovinama (stihl to stejny osud jak winamp).
Presne verzi, co pouzivam jsem ted nasel na jednom ze svych prvnich CD z dob, kdy jsem jeste krute varil W98 a bal se dvoulitru nebo NTcek:o) A bezi na W8.1 ..... je videt, ze nejsem na linuxu;o))))
FastStone Image Viewer
www.faststone.org
Hm, tak jsem to zkusil, bohuzel to me naroky zdaleka neuspokojuje. Nejenomze to bezi jenom na jednom jadre, ale pouze v jednom vlakne, takze je to stejne pomale a neohrabane jak irfanview, dokonce mam teda pocit, ze je to snad jeste pomalejsi, na prohlizeni NEFu se to neda vubec pouzit. Takze zatim nejlepsi pro desktop, 15 let stara appka, to je bida.
A zdaleka (a to jako hodne) nejlepsi je ten metro prohlizec, nevim jak to dela, asi pres GPU, protoze CPU vubec nevytezuje (a to mam GTX 460 stahnutou pres inspectora do sleep modu). Proste clovek tema obrazkama prolitava jak dabel a je to okamzite, vcetne NEFu. Zajimalo by me, jestli je na to nejaka winAPI funkce, patrne jo, podle toho co pise AMD ...... asi si nakonec udelam vlastni prohlizec ......
Jinak ten metro prohlizec bohuzel nanbizi "this PC", coz je mrzute, ale da se pridat cely disk do te galerie, otazka jestli to pak ten kokot nezacne cele indexovat .... protoze kdyz jsem klikl na adresar, tak tam zprvu nic nebylo a zacaly okamzite pribyvat fotky ..... na tabletu mam jeste jiny prohlizec, ktery ma "this PC", mozna si ho stahnu i do hlavniho pocitace a mozna budu pouzivat, protoze je fakt super rychly a ty nahledy jsou taky perfektni. Vidim to zatim asi jako prvni metro aplikaci, co budu pouzivat na desktopu bez dotykace:o)
Nevěřím, že stařičký ACDSee běží na více jádrech. Jeho rychlost byla hlavně ve vykreslování fotek algoritmem nearest neighbour, takžeto bylo sice brutálně rychlé, ale hodně nepřesné. Pokud si dobře pamatuju, bylo to defaultní nastavení. Šlo to přepnout i do bilineárního přepočtu, ale pak už to bylo stejně pomalé jako cokoli jiného. Ten prphlížeč jsem také roky používal a byl skvělý a rychlý a to také proto, že neobsahoval žádné kraviny.
Jestli chceš něco novějšího, zkus třeba xnView (www.xnview.com). Vypadá to podobně jako ACDSee a po nastavení rozsáhlých opšnů se to podobně i chová, ale nikdy to nebude ACDSee. S tím se budeš muset smířit až budeš přecházet na něco nového.
Nebezi na vice jadrech, ani nevim, ze by se nastavovalo na newarest soused, takovy hloupy prohlizec jsem snad jeste nevidel. Ja nerikam, ze je rychly, ale bezi ve dvou threadech, cili neceka se az se dekoduje cela fotka, ale hned bezi dal i kdyz se natahne treba jen pulka fotky ..... samotny dekoder pobezi asi jen na jednom ..... celkem jiste, v dobe kdy to vzniklo snad ani zadne x86 dvoujadro nebylo:)
Tenkrát se to řešilo deskou se dvěma sokety. Ale už tak dost drahý počítač to ještě značně prodražilo a navíc ne každý systém to využil. V práci jsme měli jeden takový stroj s 2x PIII@1GHz a Win 2000 a byla radost na tom tenkrát pracovat ;) Vlastně se kvůli quakovi nemusely ani shazovat pracovní nástroje ;)
XnView. Neviem ci dekoduje na viacerych jadrach ale ma siroku podporu formatov a nova testovacia verzia je uz aj multiplatformova.
xnviewmp jo, ale ze by byl nejak extra rychly, taky rict nemuzu. A opet ma tu krucialni ubohost, ze GUI jede v jednom vlakne ..... co to proboha vsichni maji s jednim vlaknem?
Jinak jsem zkousel primo winapi funkci pro natazeni JPEGu a je teda celkem rychla jako krava .... sice asi neumi multithread (ikdyz ... jeste to musim vyzkouset, jestli se z bitmap objektu neda tahat vice threadama zaraz), ale zas 24MPIX cca 12MB JPEGy to dekoduje zhruba za ctvrt vteriny na i7-860 na jednom jadre. Kdyz pustim generaci nahledu FHD na osmi threadech, tak to bude rychle jak cyp.
Nevím, co zas trapníte o Linuxu, i tam by nebyl problém takovou aplikaci najít. Vždyť ze systémových funkcí to ACDSee používá tak načtení souboru a zobrazení. Já používám dokonce ještě starší verzi 2.4 a taky jsem nic lepšího nenašel. Jinak třeba Civilizace2 je psaná ještě pro Win 3.11 a na 32b systémech běží doteď taky.
Vidis a ja si stahl pro backtrack rok stare aircrack gui a uz jsem ho nepustil, protoze byl zavisly na dvou knihovnach, ktere uz proste neexistujou .... v novejsich verzich jsou ty knihovny nekompatibilni a starsi verze ani za Boha. Verim, ze kdyby se clovek dlouho stoural, tak by mozna nasel nejaky git k temto knihovnam (ikdyz pochybuju) a dalo by se to treba nejak .... mozna ... ale, to jako fakt neeeee:)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.