Názor k článku Intel prý kvůli Ryzenu posune vydání šestijader Coffee Lake. Mohly by vyjít už v srpnu od Jan Olšan - "Jinak pri encodingu do x264 v avidemuxu je...

"Jinak pri encodingu do x264 v avidemuxu je krasne videt, nakolik je avx pouzito."

Promiň, ale občas mi fakt přijde, že jseš případ "čím míň o problematice vím, tím víc si myslím, že jí rozumím". Nenapadlo tě, že spotřeba se může zvýšit i jinýma věcma? Třeba SSE2-SSE4, optimalizovaný kód v ASM, v kterém je míň bublin a nevyužitých jednotek, hlavně s HT (x264 jede v ručně psaném ASM 50% procesorového času), a silné škálování na všechny jádra?

To, co jsem řekl (5-10% rozdíl s AVX2), se dá ověřit jednoducým benchmarkem, proč to nezkusíš, místo teoretizování? x264 na to má CLI parametr, je to snadný. Můžeš se taky podívat do source kódu, kolik funkcí je pro SSE2-SSE4 a kolik jich má AVX2 verzi.
S x264 jsem docela dost dělal, vývoj sledoval (počítám, že na rozdíl od tebe), dokonce jsem trošku komunikoval i s autory. A na základě toho ti můžu říct, že použití AVX2 je omezené a AVX skoro nulové (x264 ho používá jednak ve výpočtech mbtree, a pak taky používá 3-operand verze SSE instrukcí kvůli mov elimination - ale to je se 128bitovými vektory, takže by to spotřebu nezvyšovalo). Najdeš to i v jejich vlastních komentářích, když zapátráš.

Ale ne, Hnizdo to ví nejlíp, žejo.

P.S. H.264 má transformace 4x4 a 8x8. Macroblock má sice 16x16, ale vštšina operací se dělá se subpartitionama (8x8, 4x8, 4x4). AVC Main/High je navržené tak, aby mu stačila 16bitová aritmetika. No a 128bitový vektor při použití 16bitových integerů má kolik "pozic"? Náhodou osm, přesně tolik, kolik je třeba na jeden řádek v 8x8 bloku. TJ. to, že AVX2 má pro kompresi do AVC/H.264 omezené využití, není náhoda, pro pohodlné psaní ASM funkcí to chce větší bloky. Ty má HEVC (transformace 8x8 - 32x32, partitions podobně, 4x4/4x8 úplně odpadlo) a čirou náhodou se s HEVC (nebo VP9, to je hodně podobné) líp používá AVX2. Skutečně čirou náhodou :D