Portál AbcLinuxu, 30. dubna 2025 19:58
Me to prijde jako naopak velmi smysluplny krok. V dobe, kdy 'graficky akcelerator' je v podstate univerzalni SIMD vypocetni jednotka, je vcelku prirozene, aby ta SIMD jednotka byla prirozene sdilena pro ruzne mozne aplikace (nekdo ji pouzije na grafiku, jiny treba na DSP) a koncepcne ji mit zcela oddelenou od zbytku 'grafiky' (framebuffer a graficke vystupy).Přesně. Bohužel x86 je konzumní sračka největší a dost je to cítit. Např. k dokonalosti to dotáhli u jiných architektur (OMAP třeba). Tam už nic jako procesor není, ale má to v rámci SoC svoji GPP side (nějaké ARM jádro třeba) a DSP side (třeba hodně populární jsou ty od TI). Jsou to v podstatě dvě nezávislé jednotky (i o nezávislých taktech) se sdílenou pamětí kde jedna z nich je obecná (alias procesor na kterém třeba běžné jádro) a druhá je i když specializovaná, tak hodně modulární a umožňuje spouštět různé aplikace (dekódování perceptuálích formátů &helllip; ale samozřejmě není omezená jen na to – už jsem viděl návrhy kde by se pomocí toho dal spouštět třeba Adobe Flash), které potřebují nějaké speciální funkce a tím jim dovolí zpracování dat větší rychlostí (klidně by to zvládlo i nějaké jaderné moduly, kdyby je někdo zkompiloval a mělo to nějaký význam). A právě DSP strana je docela unikátní a něco co naprosto na x86 arch. schází. A to z toho důvodu, že skrze sdílenou paměť a její vlastní BIOS dovoluje načítat libovolné aplikace (mají většinou zkratku .dll64P a snad se dají pomocí kompilátoru od TI i kompilovat). Tohle než se na zcea konzumní x86 architekturu dostane…no to se tam snad ani nikdy IMHO nedostane.
OMAP ruluje.
A udajne jsou na dobre ceste umet do toho cipu nacpat i RAMku. Sice malou (do giga), ale rychlou jak cache u i386. No rychlou jako pomaly cahce u i386, ale rozumis mi.
Co se tyka DSP, tak tam uplne nesouhlasim. Ty DSP moduly se na ARMy davaji proto, ze ty procesory nemaji dost hrubeho vykonu aby necco takoveho delaly natvrdo pomoci FP (nebo nedejboze integer pipeline). A mam podezreni, ze SSE i nejaky multiply-acumulate (coz je nejcastejsi instrukce pro rychle furierovy transformace, a tedy pro DSP) ma. A i to blby MMX (ktery sdili registry s FPU, ale rika jim jinak, typicky i386 design ) je rychlejsi.
Ale jsem zvedavej na novy ARMy, hm.
OMAP ruluje.Jednoznačně.
A udajne jsou na dobre ceste umet do toho cipu nacpat i RAMku.Vrchol blaha. One chip to rule 'Em all.
Co se tyka DSP, tak tam uplne nesouhlasimTeď nechápu s čím, když:
Ty DSP moduly se na ARMy davaji proto, ze ty procesory nemaji dost hrubeho vykonu aby necco takoveho delaly natvrdo pomoci FP (nebo nedejboze integer pipeline). A mam podezreni, ze SSE i nejaky multiply-acumulate (coz je nejcastejsi instrukce pro rychle furierovy transformace, a tedy pro DSP) ma.
Ale jsem zvedavej na novy ARMy, hm.OMAP4?
One chip to rule 'Em all.
Jo!
Teď nechápu s čím, když:
Mel jsem pocit, ze tvrdis ze DSP z ARMu je silnejsi nez ty veci co se daji najit v i386. Ale asi ne
OMAP4?
No, OMAP je jedna z implementaci, zejo. V zasade na cokoli v cem bude cortex a9 -- dvoujadrovej out-of-order 1ghz procesor zerouci v provozu dva watty -- chci!
Ona ta architektura obsahuje i par hezkych triku, takze ji jako designer mikroprocesoru-teoretik preju stastnou budoucnost.
Mel jsem pocit, ze tvrdis ze DSP z ARMu je silnejsi nez ty veci co se daji najit v i386.O 430Mhz? To bych po něm nechtěl ani já.
No, OMAP je jedna z implementaci, zejo. V zasade na cokoli v cem bude cortex a9Tak jasně, ale předpokládám, že s novým OMAPem nepřijde jen nové exekuční jádro, ale i nový PowerVR, nová IVA a nějaká náhrada za C64x+ a celé to bude ještě křupavější a ještě šťavnatější.
dvoujadrovej out-of-order 1ghz procesor zerouci v provozu dva wattyMám pocit, že tu kdysi dávno byly nějaké zprávičky odvolávajíce se na LinuxDevices o 1.2 Ghz ARMech nebo čem od Marvellu (to cpali do PogoPlugů) a též byli nějaké fýmy o tom, že chystají i 2Ghz verzi (v květnu minulého nebo snad předminulého roku). By mě docela zajímalo jak to dopadlo.
Jo, to je ta sama vec co ma byt zakladem OMAP4. Akorat s tim mavali snad pred rokem, a prakticka implementace furt nikde.
Jo, to sice je 1 Ghz, ale je to nejaky "Sheeva single-issue ARM compatible processor", ne Cortex A-9. Bal bych se to kupovat, aby to nebyl podobny rozdil jako 2 Ghz athlon a 2 Ghz atom :)
Ja chci Cotex A9 ksakru.
A jediny co jsem nasel je tohle: http://www.youtube.com/watch?v=W4W6lVQl3QA&feature=player_embedded#!
který ovladače vyrábí rovnou jako Opensource, a člověk tak neřeší dilema mezi druhořadým opensource nebo funčně vybavenějším blobem.a) ne k vešekerému HW b) u jejich grafik je to druhořadý opensource s druhořadým HW. Jenom se podívej do diskuzních fór, kolik lidí má problém s tím, že na určité konfiguraci grafika - jádro - ovladač jim prostě nic nefunguje stabilně.
a) Poulsbo není HW od Intelu.Dodávají to jako svojí grafárnu
b) Mě se stačí podívat do diskuzních for, kolik lidí má problémy s ovladači ATI nebo AMD.Což nic nemění na faktu, že grafika od Intelu je druhořadý odvladač + druhořadý hardware.
Což nic nemění na faktu, že grafika od Intelu je druhořadý odvladač + druhořadý hardware.Tím bych si nebyl tak jistý. Svůj účel, zobrazovat pracovní plochu na pracovním počítači, plní dokonale. Rozhodně lépe než AMD/ATI. Že na tom nejde hrát mě vůbec nezajímá.
minimalni , ale ne proto ze by nechteli ale diky ptentum tretich stran .....
cat /var/log/Xorg.0.log | grep "XVideo-MotionCompensation"
vrátí
(II) Loading extension XVideo-MotionCompensation
,
takže soudím, že asi akcelerace funguje. Když pustím HD film, zdá se mi, že hraje OK, ale nejsem žádný videofil, abych to mohl říct s jistotou.
mplayer -vo xxmc
hlásí
No X-Video MotionCompensation Extension on :0.0
.
Akcelerace HD videa v OSS ovladačích není a nebude (dokumentace k UVD nebude uvolněna)Takze jedno ze zadani pro jejich letosni SoC (Gallium H.264 decoding) bylo vypsano jen tak pro srandu?
Akcelerace HD videa? To je zas co?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.