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.
Bude se srovnávat i výkon grafiky při ruzných napájecích limitech? Zajímají mne hlavně extrémy - nejvíc přiškrcená při chodu na baterii (a výdrž při hraní k tomu) a max. výkon při připojení adaptéru.
Jinak dneska vyšly čerstvé chipset drivery, nebude nutné současné výsledky přetestovat?
https://www.techpowerup.com/325012/amd-ryzen-chipset-drivers-6-07-22-037...
Něco můžu zkusit, ale těch režimů napájení je tam víc, ale nejsou moc extrémní, strop je totiž 28W.
Drivery čipové sady mám ve verzi 6.07.10.130, retest na tomto notebooku nejspíš dělat nebudu, není tam nějaký super zásadní rozdíl, spíš bude srovnání s nějakým úplně jiným notebookem.
To TDP je zastropované, protože výrobce NTB podle toho dimenzoval chlazení? Nebo je tam jiný důvode?
Je to tenký notebook, 11mm včetně víka, takže i těch 28W je vlastně zázrak :)
9mm surface pro neni prikonem jinak - system draw. 28W neni dneska nic na tenke telo
Oni se rok co rok aktualizuji prirodni zakony podle pozadavku IT HW firem?
Už před 5 lety měl Acer ve 2-v-1 "vodní chlazení" a uchladil 2x větší TDP než konkurence. Na druhé straně jsem viděl 2-v-1 Toshiba, kde nebyl na Atomu žádný pasiv, jen trvale běžící větráček. Takže slabý výkon a hluk.
Tam asi bude lehce patrny cenovy rozdil tech 2 produktu. Z Jirkova komentu mam pocit jako by se neco zasadniho v prubehu poslednich let zmenilo. Zadnej zavratnej vynalez v oblasti materialu sem nezaznamenal ani zadne revolucni chlazeni. Tak by me zajimalo proc to predtim neslo a dnes to jde.
Jistě je tam cenovej rozdíl. Ale skutečné náklady jsou dost odděleně od prodejní ceny.
No kdysi jsem viděl chlazení kusem "alobalu" na CPU, tam stačilo zaměstnancům nařídit, že si budou k obědu kupovat čokoládu místo rejže...
Jinak máš pravdu, úsporná opatření se pokud není dostatečný tlak konkurence na ceně neprojeví, zato každé vylepšení většinou násobně. Pokud není unifikované, tak samozřejmě rozpustit náklady na vývoj je také potřeba, takže to není jen o tom že výroba stojí o $ víc...
Budou dotestovány meteor laky, nebo už to necháte být a půjdete spíš po lunarech a arrow lake mobile?
Když nějaký Meteor Lake seženu, tak ho chci samozřejmě přidat také.
Šlo by vyzkoušet provozovat hru s affinitou pouze na 5c jádra, zda se tím docílí vyšší efektivity s pozitivním dopadem na velikost TDP budgetu pro iGPU (vyšší FPS)?
V některé z recenzích bylo vidět možnost nastavení velikosti framebufferu iGPU až na velikost 24GB v Adrenaline ovladačích. Je toto maximem obecně pro Strix Point či pouze pro osazení ntb s 32GB RAM?
Malá jádra jsou od toho, aby šetřila peněženku uživateli / křemík výrobci.
Intel jim sice říká "efficient core" ale efektivní je jen ta úspora křemíku.
Spotřeba nikoli.
Očekávat vyšší FPS je dost bláhové, když mají menší cache a menší takty.
Snížit TDP pro CPU a přidat takty iGPU je dobrá myšlenka.
Ale tohle má AMD vymakaný už přes 10 let = těžko se tam najde prostor pro optimalizaci.
FPS u her na ntb bez dGPU jsou většinou značně limitované právě silou iGPU(průchodností RAM), jádra Zen5c je v cílových 60++FPS výkonově patrně brzdit nebudou. Pokud by výkon kódu hry byl efektivnější na "E" jádrech mohlo by zbýt více energie pro iGPU (podstatné asi zvlášť u modelu s redukovaným TDP 28W). Za pokus (x-minut bechmarku) by to možná stálo.
60FPS považuji za hratelné.
Ale nesmí se to sekat.
Co způsobuje propady FPS?
Moc nehraju, myslím že GPU čeká na CPU.
IMHO pomalé CPU s malou cache způsobuje lagování.
Takže teoreticky to FPS zvedne, ale praktický zážitek bude horší.
Otestovat by to jistě bylo zajímavé. Jen mě vytáčí, jak se mýtus o úsporných e-core drží.
Věřím, že mu nevěříte, ale někdo by si Váš post mohl vyložit špatně.
Tady preci nejde o viru, ale stupen poznani (na testy v tomto smeru jsem zatim nenarazil). Pokud v pripade hry CPU utilizace (mnozstvi vypoctu herni logiky, 3D enginu a IO) nepresahne moznosti Zen5c jader (zadani pro GPU je pripraveno vcas, pripravenost zadani drive s vyuzitim Zen5 nemusi prinaset FPS vyhodu) je to jen o tom jakym zpusobem je to vykonano energeticky nejvyhodneji (navic delsi doba pripravy rozklada energ. zatez v case, proti provedeni s pomoci Zen5 jader).
Napriklad pokud vezmeme energeticky nejvyhodnejsi reseni pro MT je to vysoky pocet Zen4c jader relativne konzervativne taktovanych.
Samozřejmě je značný rozdíl v implementaci mezi Intelem a AMD. Tím že přímý přístup na sběrnici mezi jádry u intelu mají jen ta velká, protože malá jsou v klastru po čtyřech, tam narůstají latence. Nic takového u AMD není, takže ano něco by asi mohlo mít smysl testovat, ale zrovna ve hře budou mít jádra stejné architektury s větší L3 cache a současně i vyšším stropem taktu vždy navrch. A energeticky ta čtyři jádra i s vyšším taktem budou úspornější než těch osm.
Anandtech nameral vysoke latencie medzi jadrami u Strix Point. 2x vyssie nez u 7950X. Autor tam pise ze spravi analyzu a porovna male a velke jadra so Zen4, kde bol len jeden CCX ale Strix ma 2 CCX. Ale do RAM zrejme bude latencia rovnaka.
https://www.anandtech.com/show/21485/the-amd-ryzen-ai-hx-370-review/3
https://www.anandtech.com/show/17585/amd-zen-4-ryzen-9-7950x-and-ryzen-5...
To může být a speciálně když jde o chiplety. Ale já psal o jádrech na jednom čipu, jen prostě tím, jak jsou dobastlená k tem velkým. Intel nemůže na té sběrnici udělat víc zastávek, protože tím by se zhoršila i komunikace mezi těmi velkými jádry. Proto musí malá dávat po čtyřech místo jednoho velkého. Mohli by zavést stejný systém jako u Xeonů, ale nechtějí, stejně jako nechtěli AVX-512 v desktopu velmi dlouho.
I proto jsem navrhoval běh hry pouze na Zen5c (osm jader by mělo hře stačit) a ta nebude muset trpět penalizací latencí mixu jader Zen5+Zen5c. Viz odkazy na AnandTech výše.
Jenže pro tu rychlejší odezvu se ten takt hodí. A druhá věc, hry milují cache a to z toho prostého důvodu, že velká cache zvyšuje šanci, že to data nebude muset procesor až do z hlediska latence pomalé RAM, ale může je spíš najít nekde blíž a tedy rychleji. Pokud se navíc ukáže, že ZEN5 ve variantě s obří cache nebude omezen na 5 GHz... Ale to jsem odbočil. Celý koncept stojí na tom, že velká jádra s velkou cache a vyšším taktem jsou na to málo fakt singlecore zátěž a nebo na velké aplikace a hry, kterým stačí méně jader, pokud jsou výkonná a na vše ostatní jsou c jádra.
Ta velká cache bude mít význam pro dosahovaní vysokých FPS, pro relativně slabé iGPU cílící typicky na 60FPS+ nebude CPU bottleneck.
Ve skutečnosti velká cache pomáhá hlavně plynulosti a v minimech...
HUB naměřil průměrný vliv +15% pro FPS avg a +22% pro FPS 1% min u 5800X3D versus 5800X, takže nejde jen o ty "hlavně".
https://youtu.be/sw97hj18OUE?t=652
https://youtu.be/sw97hj18OUE?t=733
No u AMD to vypadá, že se podařilo oboje. Když testovali 8500G tak jim vycházelo 70-85% výkonu při 50-75% spotřebě.
Proto jdou C primárně do ntb a epyc, zatímco desktop zatím má mít jen velká jádra.
Samozřejmě budou případy, kde bude plné jádro mít výhodu větší cache a C bude ztrácet, což může být případ spousty her...
Takže někde se větší limit pro igpu může pozitivně projevit, jinde může být i vliv negativní, když hra bude závislá na vysokém ST.
To asi záleží na konkrétní hře, ale taktovací frekvence malých jader jsou značně nižší.
Framebuffer lze modifikovat skrze MyASUS utilitku, ale jinak si to dynamicky bere co je třeba z RAM + tam je podpora VGM.
Pro většinu uživatelů nemá moc smysl tu alokaci VRAM měnit, automatika nastaví 384 MB a zbytek se bere dynamicky z RAM.
Dovolim si nesouhlasit. Nastaveni vice ram pro igpu v biosu je velmi uzitecne. Hra pak rovnou nacte dostetek zdroju a nedochazi k propadum fps pri docitani z disku behem hrani. A treba tmbenchmark tanku (WoT) nejde bez nastaveni dostatku pameti ani prepnout na vyssi detaily, protize si mysli, ze vic pameti priste neni.
Skutecne ma ten notebook zapojen operacni pameti ve Quad-Channel-u?
Podporuje Strix Point i Windows 10?
Da se v UEFI vypnout skupina velkych/malych jader?
DDR5 se hlásí jako Quad-Channel i když je systém osazen 2 moduly.
Je to velká změna proti předchůdcům DDR4-3-2.
Modul/chip DDR5 snad používá dvojnásobný počet kanálů (poloviční sířky) proti DDR4. V některých případech se z toho údajně (dle inženýra AMD) dá profitovat z hlediska dosažitelné průměrné latence (nezávislost jednotlivých kanálů?).
Protože out-of-order vykonávání je dnes již tak komplexní, že potřebuješ pracovat s mnoha místy v paměti pro různé vzdálené instrukce v kódu. takže aby se nečekalo na RAM.
Přistupovat současně do čtyř oblastí v RAM proti dvěma má své výhody.
Tam jde o to jak často se dnes chodí pouze pro 32 bitů paměti.
Vzhledem k tomu o kolik je u DDR5 vyšší takt, i při 32 bitech má ten jeden kanál téměř takovou datovou propustnost, jako měly DDR4 na 64 bitech.
Nejde o rychlost, ale o latenci a čekání operací v out-of-order vykonávání.
Jasně že, to se při 4. současných přístupech proti dvěma zlepší.
Sirka pametove zbernice je 32bitu to ano, ale nikdy se neprenasi 1 transfer. Typicky se prenasi cela cache-line (64 byte), coz na 64 bit DDR4 pameti bylo BL8 - burst length 8. Tim, jak jdou frekvence u DDR5 vejs ale pameti nejsou rychlejsi v pristupu, tak se za stejnou dobu da udelat 32b * BL16 = stejnych 64 byte.
A vedle pak mate druhy identicky kanal, ktery pak zdvojnasobuje pocet "iops" do pameti (s par omezenima, napr. ze pametove kanaly nesdili stejny pametovy prostor).
Prakticky se to u vicekanalovych reseni resi stylem interleaved - tj. co 64B blok, to vzdy jinej kanal a spoleha se na to, ze statisticky budou data ulozena rovnomerne, resp. pri mnoha procesech nebude pak zadnej kanal vytezovan presprilis.
DDR5 DIMM a SODIMM mají šířku 64-bitů jako DDR4, ale připojené do řadiče je to v režimu 2x32-bit, tedy je to quad-channel, ale kratší šířky sběrnic.
Oficiálně to Windows 10 nepodporuje, v desktopu to provozovat půjde, u notebooků je to horší. A nebo prostě Linux.
UEFI tohoto ASUSu je dost omezené a Zen5/Zen5c tam přepínat nejde.
Karaš Svorka chválim Vás!, že ste konečne vypočul Tralalákove volanie po otestovaní CPU-Z 64-bit benchmark v17.01 aj ako All-Cores, ale hlavne čo ponúka verzia 2.09 a 2.10 aj samostatné klastre v prípade AMD Zen 5 a Zen 5c a prípade Intel P.cores / E-cores.
AMD Ryzen AI 9 HX 370 12C/24T
All-cores
• 7 353
• 762
8x Zen5c
• 5 294
• 519
4x Zen5
• 3 598
• 770
Prikládám mnou otestované all-in-one PC s LCD s Intel Core i5 13500H (4P + 8E / 16T)
All Cores
• 6 737
• 753,4
P-Cores
• 3 821,7
• 754
E-Cores
• 3 015,8
• 399,3
zdroj: https://www.techpowerup.com/forums/attachments/cpu_z_2_09_i5_13500h-jpg....
P.S. škoda, že nemáme takto otestovaný aj desktopový AMD Ryzen 5 8500G s 2x Zen4 a 4x Zen4c, takže ak nejaký diskutér Ním disponuje tak neváhajte otestovať.
Pre porovnanie prikladám diskutémom na techpowerup fóre otestovaný Intel Core i5 14600KF:
All Cores
• 901,4
• 10 501,8
P-Cores
• 900,7
• 6 873,9
E-Cores
• 3 674
• 459,7
zdroj: https://www.techpowerup.com/forums/threads/share-your-cpuz-benchmarks.21...
P.S.S. samozrejme uvidíme čo so Zen5c v tomto teste spravia nové E-Cores Skymont v Lunar Lake resp. mobilných či dektopových Arrow Lake...
Mi přijde dost zvláštní, že u toho Intelu jsou ty výsledky tak blízko, allcore vs součet P+E... Tam bych předpokládal že pro všechna jádra zaúřaduje powerlimit, zvláště u té mobilní varianty by tak měly být vyšší dílčí výsledky, nebo nižší ten celkový.
Na Phoronix je 8500g docela podrobně testováno v různých kombinacích zapnutých jader ve výpočetních testech pod Linuxem https://www.phoronix.com/review/amd-zen4-zen4c-scaling/5
Já si dovolím komentář sám za sebe: pro mě je důležitý jak samotný výkon, tak nízký příkon. Vezmu-li to z pohledu konkurence, není důvod navyšovat výkon, daleko přínosnější se mi jeví ukázat, že x86 dokáže totéž co ARM, tedy dlouhý běh a nízkou spotřebu protože, a to si přiznejme, ten vysoký dlouhodobý výkon využije mizivé procento uživatelů. Co je podstatné, je to bez "podvůdků" typu koprocesory u Applu.
Všechny ty koprocesory má i x86 - výpočty na iGPU, maticové počty na CPU, videokodeky a se zpožděním i neurální koprocesor (na úkor výkonnější iGPU).
Většinou se na nich ve světě x86_64 nestaví "benchmark success stories" jako například u ProRes v AS. Hrubý universální vypočetní výkon CPU/GPU je to co se počítá.
Ta pointa je ještě jinde. Tam kde ARM má 4x 128 bit vektory a prakticky vždy i nižší takt, je výhodnější to doplnit koprocesorem, protože navýšení toho hrubého výkonu není až taková sranda. Ale ZEN5 s 4x 512 bit vekteory, byť ty jednotky nejsou z hlediska úplně instrukcí stejné, má jasně navrch. Ale to u ALU dělá i ten ARM.
Apple má užší uživatelskou základnu než obecné PC, takže může spolupracovat s různými skupinami profesionálů a dobře si spočítat, co do křemíku přidat a co ne. K čemu ti je 2-3x výkonější CPU, když se bude video trhat a výdrž na baterii při práci bude poloviční?
Pořád to ale znamená jisté omezení a kdyby se na PC objevil nějaký nový kodek a rychle získával oblibu, jsou v háji, protože nemůžou tak pružně reagovat. Vektrorové jednotky nebo GPU nejsou tak efektivní, ale mají obrovskou flexibilitu.
Vektorové jednotky a GPU má Mac taky. A pokud je např. nový kodek náročný, tak stejně musíš čekat na další generaci CPU i u x86, aby to jelo plynule. Profesionál si nedrží počítač 8 let a neluští z křišťálové koule, co bude na konci života počítače potřebovat. Jakmile se mu nový stroj zaplatí, tak přejde na aktuální aktualizovanou generaci. A starý ještě dobře prodá, protože neztrácí tolik na ceně.
A proto jsem srovnával vektory ARM Macu a x86-64 u ZEN5. To AMD je má 4x širší.
4x128bit má ve 128bit vektorech podobný výkon jako 1x512bit. Těch vícebitových výpočtů zas tolik není, často se pouští na GPU nebo na maticovém koprocesoru (technicky interně vykonává na těch 128bit jednotkách, ale není tam režie vykonávání kódu aplikace, která by ručně řešila tyto operace - podobně např. Zilog počítal 8bit operace na 4bit ALU).
Ale AMD má 4x 512. Něco ti trošku uniklo. Ano 4 bit CPU spočítá i 128 bit v plovoucí řádové čárce. Ale jak rychle?
To spíš tobě uniklo. Jedno Zen 5 jádro CPU má jednu AVX-512 jednotku. Stejně jako Intely. Jen některé serverové Intely mají dvě AVX-512 jednotky:
https://www.hwcooling.net/en/amd-confirms-zen-5-details-6-alus-full-perf...
"However, GCC confirms that Zen 5 contains 512-bit SIMD units for the first time in AMD processor history. These units will supports processing most AVX-512 instructions in a single cycle, whereas Zen 4 has 256-bit units like the Zen 2 and Zen 3 cores (which could only do 256-bit AVX2) before it."
"This SIMD expansion in Zen 5 seems to correspond to the addition of a second port for Floating-point store operations. However, the FP store units are apparently still 256-bit wide, so 512-bit operations are performed by combining the two units."
AVX-512 vytvořili chytrým sloučením dvou AVX2 jednotek + další sada registrů pro ně. Takže tu máme Apple s 4x128bit, Zen4 s 2x256bit a Zen5 s 1x512bit. Tj, v 64bit a 128bit operacích jsou stejně rychlé, ale Zen 4 a 5 nabízí nativní a o něco rychlejší operace s 256 resp. 512bit vektory. Ty se ale zas tak často nepoužívají a dají se emulovat na nižších vektorech (se ztrátou výkonu, menší či větší podle typu operace).
U Apple je limit na 128bit dán tím, že (zatím?) nechce implementovat SVE. Zůstává mu tak Neon, který je 128bit na arm64 (AArch64).
Oni to v článcích popisovali i česky, ale OK. AMD rozhodně nemá jednu 512 bit jednotku, která nic jiné neumí a k tomu 256 bit AVX jako Intel. V tom se právě dost liší.
Však je to vysvětlené i v mé citaci. A nepotřebuju na to přeložené články, kde se zanáší další nejasnosti ;-)
Přímo z toho textu: Jednotka FPU (která ale zejména zpracovává i SIMD instrukce), zdá se, nemá přidané pipeline navíc proti Zenu 3 a 4, v FPU zřejmě opět bude čtveřice pipeline pro různé operace. GCC ale potvrzuje, že Zen 5 má poprvé fyzicky 512bitové SIMD jednotky. Podporuje tak zpracování většiny instrukcí AVX-512 v jediném cyklu, zatímco Zen 4 má jednotky 256bitové jako jádra Zen 2 a Zen 3 (která uměla jen 256bitové AVX2).
Pro ty co neví. ZEN4 (ale taky 2 a 3) měl 4 256 bit jednotky.
2x FMUL / FMA a 2x FADD. Ale obě shodně umí jednodušší operace. Podobným způsobem fungují ty zmiňované ALU, všechny umí základ a jen nekteré třeba násobení - jen příklad. A celý rozdíl, když nebudeme rozebírat další části, je v tom, že ZEN 5 má tyto jednotky 2x širší.
Je to jednoduché, klidně to ber jako black box. Kolik AVX-512 instrukcí udělá Zen 5 za 1 cykl? Jednu, slovy jednu. Navíc pomocná pseudojednotka FADD je zlomek tranzistorů oproti násobičce/děličce. SLouží tam k vykrytí průtahů (např. to dělení).
Není to z mé hlavy, ale lepší rozbor jsemnečetl:
FPU: Nejsilnější SIMD na trhu a doteď nejlepší implementace AVX-512
Nicméně, toto platí pro čtení a zápisy do základní aritmeticko-logické části. Jednotka FPU a SIMD, která má své vlastní registry, je poněkud vydělená (toto „koprocesorové“ řešení teď už v novém jádru Lion Cove používá i Intel, který měl dlouho ALU a FPU unifikovanou) a má schopnost provádět jen dvě čtení či dva zápisy. U čtení jsou podporována až dvě 512bitová čtení (přičemž 512 bitů je šířka registru instrukcí AVX-512), protože datové šířky cest do L1 datové cache byly zdvojnásobené. Zápisy lze provést dva 256bitové nebo 128bitové za cyklus, nebo jeden 512bitový za cyklus.
Toto rozšíření a tím zdvojnásobení datové propustnosti mezi jádrem a L1 cache je samozřejmě uděláno proto, že AMD u Zenu 5 upgradovalo pipeline v jednotce SIMD/FPU. Ty byly od Zenu 2 až po Zen 4 s šířkou 256 bitů, takže uměly provést jednu instrukci AVX nebo AVX2 jedním průchodem, ale Zen 4, který už uměl i AVX-512 s 512bitovou šířkou, je musel počítat dvěma průchody. Zen 5 rozšířil jednotky na dvojnásobnou 512bitovou šířku. To znamená, že počet operací SSEx a AVX/AVX2 možných za cyklus se sice nezměnil, ale instrukcí AVX-512 může jádro provést dvojnásobek. Takže při využívání instrukcí AVX-512 v programech bude možné ze Zenu 5 dostat vyšší výkon.
Počet pipeline zřejmě zůstal stejný a je jich šest, nicméně ne všechny mají všechny schopnosti a část provádí instrukce jako load/store nebo konverze. Instrukcí FMA nebo floating-point násobení dokáže jádro provést dvě za cyklus (včetně 512bitových AVX-512), floating-point sčítání (FADD) lze udělat také dvě. Ovšem jednoduché celočíselné SIMD operace, jako je sčítání, jsou možné čtyři za cyklus. Změna k lepšímu je také, že instrukce FADD mají latenci dva cykly místo dřívějších tří.
Až šest operací za takt lze provést, pokud jde o kombinaci násobení/FMA, sčítání a load/store operací. Není to tedy tak, že by Zen 5 (a podobně Zen 4 před ním) měl šest pipeline, z nichž každá by byla „všehoschopná“.
Tady https://news.ycombinator.com/item?id=40559368 (hledej "multiply") se dočítám, že skutečně má dvě 512bit násobičky/děličky na jádro, takže udělá dvě AVX-512 instrukce za cykl (pozor, je tam ještě inicializační latence). Nicméně je to procesor, který ještě nevyšel, takže uvidíme, s čím pak zareaguje konkurence (a taky po jaké době budou ty procesory dostupné v zařízeních - navíc se dočítám, že mobilní CPU budou mít polovičně široké jednotky, takže jich se "dvě AVX-512 instrukce za cykl" týkat nebude).
PS: Neuvedl jsi zdroj.
Ta jedna platila u ZEN4, protože ji musel dělat na dva průchody. V zásadě, když je to dobře napsané a vektorové část může udělat vedle sebe intrukce tak, že vytíží všechny 4 jednotky... Ale to se asi běžně nestává. Universální jednotky sice jsou výkonnější, ale taky dražší.
Ty ostatní jednotky jsou jen, "aby řeč nestála". Dělají věci okolo, aby throughput té hlavní (v Zen 5 dvou násobiček) byl 1 instrukce/1 cykl.
Neřekl bych to přímo tak. Oni ty jednotky když přidávají další, tak sledují v reálném kódu četnost různých typů instrukcí, takže proto třeba ALU nejsou všechny stejné a je jedno zda jde o x86 nebo ARM. Mohli by je dát stejné, ale je to plýtvání křemíkem.
Tak Apple zatím vede v podpoře HEVC pri 10 a 12 bitech a 4:2:2, pripadne ProRes a Log. H265 10bit 4:2:2 je tvurci oblíbený formát, nataciho jak drahe tak i velice levne kamery. Zvládá to jen Intel od 11. generace a jejich dGPU. Nejeden tvurce, dlouholetý PCckar přešel na Mac. Místo hovada desktopu ma maly notebook, tissi, skladnejsi a cenove neni vyrazne za jinou cenu, i když, kdyz tě to zivi, tak cena není klíčová.
Většina profesionálních cinema kamer staví na proprietárních RAW formátech (.R3D, ArriRaw, B-RAW). Silné počítače s vysokým počtem CPU jader (případně výkonným GPU) mohou zvládat to na co Apple nemá vestavěné řešeni a na co mu universální síla jeho CPU/GPU ani po letech nestačí.
https://youtu.be/iN0COHoXxak?si=0rJv8bn1UhpO4M0m
Mohou, ale stejně nezvládnou. Pro kameru za 20 tisíc USD + doplňky si kup Mac Pro a certifikovanou kartu do něj.
Netušil jsem, že taková certifikovaná karta pro MacPro 2023 vůbec existuje. Kde se dá o ní něco bližšího dozvědět?
https://support.apple.com/en-us/101988
Vždyť tam přímo Apple píše, že vestavěný Media Engine v Apple Silicon (M2 Ultra) přesahuje výkon jejich karty Afterburner? Z hlediska šíře podporovaných formátů nic nepřidává (podporuje jen ProRes a ProRes RAW).
https://support.apple.com/cs-cz/101662
To je obecný "PCčkový" slot, kam si můžeš dát cokoli (akorát na dGPU není implementováno rozšíření PCIe protokolu v Apple Silicon).
Já to pochopil tak, že znáte přímo nějaké konkrétní řešení. Moje chyba.
V této úrovni toho průmyslu je to všechno provázané a ven nemají moc důvod něco říkat.
Tady to je právě pojato docela rozumně, pokud se s tím dokáže srovnat systém a přidělovat procesy na správná jádra... C jádro zvládne podávat rozumný výkon při 2-3W, ale tím jak si to zachovává širokou konektivitu, tak dost podstatnou část energie sežere IF, PCIE, řadiče RAM... Takže pro ty ultra mobilní zařízení by to chtělo křemík ořezaný na kost.
A ty koprocesory neberu jako podvod, pokud mají na starosti velmi často užívané činnosti (třeba kodéry videa jsou dobře investovaný křemík) , tak v přenosných zařízeních za cenu určitého navýšení plochy a ceny mají své opodstatnění, pokud dokáží dost podstatně navýšit efektivitu a výdrž, ale aby tam zase nebyly na každou obskurnost, kterou člověk využijte "maximálně třikrát za deset let"...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.