Portál AbcLinuxu, 2. května 2025 20:01
Posílám za kolegu Zaatharena:
Ahoj, socket M podporuje maximálně dvoujádrová Core2Duo CPU generace Merom na 65nm procesu, původně vzniknul na Core Duo, což bylo takové nedokonalé Pentium M s dvěma jádry a v době kdy neměli koupené x64 instrukce od AMD. Když přišla C2D T5xxx a T7xxx přišel i pak socket P s rychlejším FSB, správně píšeš, že top CPU na socket M je T7600. Socket P kromě rychlejšího FSB přinesl tuším lehce jiné napájení snad + digitální snímaní teplotních čidel v CPU, to ale podporuje až Penryn.
Socket P v první iteraci byl typicky z 965kou chipsetem a 800FSB v roce 2007. TOP CPU je tam T7800, v roce 2008 s příchodem Penrynu se TOP CPU stala T9600, socket P získal druhou iteraci získáním 1066FSB s Intel PM45 či GM45 chipsety a také první mobilní quad-core ale má to velká ALE.
Quad-Core CPU fungují v socketu P, ale JEN v malém množství notebooků. jednak mají TDP 45W + ale jinak trochu komunikují s chipsetem, je jen malé množství notebooků co je podporuje a umí s tím pracovat, pokude se tedy bavíme o Q9000/91000 či QX9300.
Pokud máš ntb co má socket P a FSB1066 velmi zajímavá CPU na tento socket jsou P9700, T9900 a X9100, jen ta X9100 má dsot vysoké TDP.
on by ten athlon na lecos stačil ještě dneska, ale obrovskej problém je že nemá instrukční sadu SSE2, takže už hromada věcí nefunguje, včetně například všech novějších verzí openoffice, flashe, pětková plasma a kwin, steam, secondlife, google earth a spousta dalšího. prostě se to nespustí nebo to okamžitě padne na sigill :-/
mam v plánu přendat disky do jinýho kompu kde je sempron, stejně slabej, možná i slabší, ale 64bitovej postavenej na novějšim jádře se všema potřebnýma instrukcema. teď mi kde4 kterej už je vyhozenej z repozitářů blokuje i všechny ostatní updaty a přejít na pětku na tomhle procesoru nemůžu, zůstal bych jen s kurzorem na černý ploše, oveřeno 2x...ffmpegu mohl být kód, který neměl SIMD asamblér v MMX2, ale jenom SSE2Tak ve ffmpegu byly šílenosti jako dekodér pro XScale. Nějaký SSE/MMX/3DNow by tam bylo tak od začátku IMO. Nehledě na to, že se SSE generuje v gcc přímo (když není asm optimalizace a dělá se to přes C).
V určitých kruzích je zvykem zdůrazňovat nevýhody LCD a nevýhody CRT zamlčovat. Takže se třeba řeší (nebo spíš donedávna řešily) pozorovací úhly, ale že při pohledu z úhlu byl obraz na CRT monitoru (geometricky) zkreslený až běda (a na "plochých" CRT byl zkreslený i zepředu), to je tak nějak v pohodě. Že můj poslední CRT monitor (a to byla "pouhá" 19") měl běžnou pracovní spotřebu 90-100 W, na to se už taky nějak zapomnělo. O podivně rozmlžených pixelech, jak se paprsek náhodně trefoval do mřížky, se kupodivu také nemluví. Prostě se vybere jeden parametr a na tom se točí diskuse, aby se ukázalo, jak jsou LCD k ničemu.
(Podotýkám, že nejsem žádný evangelista, sám jsem LCD odolával výrazně déle, než bylo běžné - ale i tak jsem přešel někdy kolem roku 2006 a řešit dnes přednosti CRT v době, kdy LCD roky používají i profesionální grafici, mi přijde úsměvné.)
Problém je ale obecnější, stačí se podívat na stále se opakující litanie o tom, jak DSLR nesahají kinofilmu ani po kotníky, nesmrtelný vinylový fetišismus nebo kult Nepřekonatelné plazmy.
O podivně rozmlžených pixelech, jak se paprsek náhodně trefoval do mřížky, se kupodivu také nemluví.+1000, to byl IMHO ten nejzásadnější humus na CRT a vůbec nechápu, proč to těm apologistům nevadí. Ty reálné pixely u LCD - i u špatných TNek - byly velký krok vpřed v ostrosti a tak. Pro mě bylo tak během první půlhodiny následující po vybalení prvního LCDéčka (ve škole i všude tehdy byly CRT, takže jsem s ním tak trochu skákal do neznámých vod) stoprocentně jasno.
Za mě byla nejvýznamnější výměna D-SUB kabelu za DVI-D u prvního LCD, najednou zmizelo všechno co tam nepatří a obraz byl perfektní <3
A vinyl vydrzi skoro vecne, digitalni data odchazi (i orig CD) a je nutno se o ne starat3/10, čumák se mi při čtení ani nepohl ;P
Teď už je asi jasné, proč tomu říkám vinylový fetišismus a jakou souvislost to má s vychvalováním CRT monitorů.
Ač nemám rád konspirační teorie, při pohledu na tohle velebení gramodesek a neustále se opakující články o tom, jak jsou gramofonové desky jediné fyzické (hudební) médium, jehož prodeje rostou, se otázka "Qui bono?" prostě nabízí. A nemůžu si pomoci, ale jako ten, kdo z toho má největší prospěch, mi vycházejí vydavatelé. Když místo CD, které se dá triviálně bezztrátově kopírovat nebo nagrabovat, mohou za dvojnásobek prodávat gramofonovou desku, která je mechanicky choulostivější a bezztrátově z ní záznam nedostanete, to je pro vydavatele splněný sen.
Ja používam LCD kúpený v roku 2004 (17" 1280x1024). Aj v tej dobe boli už LCD celkom dobré. Dosť paradoxné je, že aj pri používaní cca 8h-12h denne vrátane víkendov s vypínaním a zapínaním dosť často (keď mám hibernovaný notebook neviem prečo ale asi každých 5 minút sa prebudí VGA, na chvíľu zasvieti monitor a znovu vypne) má CCFL podsvietenie farbu ako pri kúpe. Čo sa týka podsvietenia ... no nemám reguláciu takže stále beží na 100%, svietivosť podľa kalibračnej sondy vyše 150cd/m2. Nieviem nakoľko môžem veriť kalibračnej sonde pretože žiaden monitor v bývalej práci 150cd/m2 s max jasom po zahriatí nedosiahol.
Hmm, ja som vždy predpokladal, že je to životnosťou CCFL. Na internáte som mal 2 spolubývajúcich s ASUSmi a obom 2 a pol roka po kúpe stmavlo podsvietenie a malo ružovú farbu.
youtube-dl -FA tohle rozhodně není HTML5.
70% pri VDPAU? To sa mi nezdá. Na slabom ARM mi mpv používa do 10%.
Je to len na jedno jadro (inak by tam nemohla byť hodnota 150%). No aj tak je to moc moc vysoká hodnta. Na allwinneri A20 s vdpau to mpv dá hlboko pod 10% na 1 jadre (pri surových predpripravených h.264 dátach bez demuxera to dokonca ide pod 1%) a to mám pozapínané blbosti ako OSD, takže ešte mixuje obraz s ovládacími prvkami. Povedal by som, že VDPAU buď vôbec nefunguje, alebo je nejak zbastardený vo inak by to muselo žrať podstatne menej.
Na x86 to nemám ako overiť, mám len intel X3100 bez VDPAU. Ak sa pri VDPAU podtaktoval potom sú celé výsledky "benchmarku" irelevantné. Len sa mi zdá divné, že low cost ARM za myslím 8€ či koľko to stojí pri veľkom množstve s frekvenciou 1GHz to zvláda na necelých 10% 1 jadra a druhé je nečinné.
Počkať nie je náhodou VDPAU práve o tom? Nemala by dekódovať h.264 práve nvidia? A áno používam samozrejme hw dekóder cez libvdpau-sunxi (vdpau implementácia pre cedar video dekóder / enkóder) inak by to išlo tak 1-5fps
No veď práve to mi na blogu nesedí. Podľa mňa autor síce tvrdí, že prehráva cez VDPAU, ale tipoval by som, že tam bude mať problém s driverom.
něco starýho jako třeba ta 8600GT co tu někdo zmiňoval toho asi moc nedá...8600 je druhá generace a H.264 dává úplně v pohodě i na 1920x1080 (Blu-Ray ripy) tak s 10%-20% vytížením procesoru (nějakej čas se kopírování dat a správu přehrávače sežrat musí). Osobě vyzkoušeno. Pokud se dívám dobře, tak VP8 nebo VP9 nemá implementovaný ani jeden set, možná proto moc nemá smysl ho cpát přes VDPAU a něco odměřovat protože se to stejně dekóduje na procesoru.
samozřejmě pojede softwarověSamozřejmě. Na to aby se to cpalo do VDPAU by musel mít tuhle volbu v sobě Firefox zakompilovanou a nějak sem ji nepostřehl, takže pokud ji tam nenacpeš skrze nějaký plug-in tak těžko to bude cpát Firefox sám od sebe do VDPAU.
media.hardware-video-decoding.enabled trueMyslel jsem, že zapíná akceleraci přehrávání videa zrovna třeba přes to VDPAU.
Na allwinneri A20 s vdpau to mpv dá hlboko pod 10% na 1 jadre (pri surových predpripravených h.264 dátach bez demuxera to dokonca ide pod 1%) a to mám pozapínané blbosti ako OSD, takže ešte mixuje obraz s ovládacími prvkami.No, vzhledem k tomu, že pokud se grafické jádro krmí oněmi surovými daty (u MPEGu[2,4] to může být, pokud si dobře pamatuju, i nemultiplexovaný elementary stream), tak jediné, co procesor řeší, je režie vstupního zařízení (tj. úložiště a/nebo síťová karta) a přepínání bufferů, protože přesun dat do dekodéru uvnitř grafické karty obstarává DMA engine a věci jako OSD a spol. se dělá přes průhlednou overlay vrstvu taktéž v grafické kartě. Ostatně, s podobnou zátěží zvládnou "přehrávat" (nebo nahrávat) H264 i 200-300MHz ARMy v5 v různých zařízení typu PVR nebo IP kamery.
pc2005
jsem na to mrknul a zjistil, že Firefox ve Windows XP to tahá nejspíš jako mp4/h264, má nastaveno media.mediasource.webm.enabled falsezatímco Firefox v Xubuntu 16.04 to tahá nejspíš jako webm/vp9, má nastaveno
media.mediasource.webm.enabled trueKaždopádně po úpravě parametru kleslo vytížení procesoru při sledování videa ve 360p na cca 90% a obraz se netrhá (ale je to na hraně). Odtud ale můžou pocházet i problémy s případnou akcelerací.
AMD A10-6790K (4x 4GHz), driver radeon, 1080p60 v HTML5 a FF 45.0a2 naprosto plynule. Ale to rozšíření se mi líbí, zkusím
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.