このページの全ては誤っているかもしれません。[[x264関連の記事に関して]]を読んでください。

!!!x264-changelog-jp r2300-r2399

r2300-r2399のchangelogの日本語訳。その他のリビジョンと注意事項については[[x264-changelog-jp]]へどうぞ。

前:[[x264-changelog-jp r2200-r2299]] - 次:[[x264-changelog-jp r2400-r2499]]

最近は全くと言っていいほどdiffを見ていないため、速報とか暫定訳とか仮訳とか書いてなくとも色々怪しいです。

!x264r2358
//MASTER
{{bq
commit 9e941d1fabb2de4b15f169057a07dc395307d2ce
Author: Anton Mitrofanov
Date:   Mon Aug 26 21:20:31 2013 +0400

Fix masked access violation in KERNEL32

Caused crashes under gdb in Windows and might cause other unknown problems.
}}

{{bq
KERNEL32内でのmasked access violationを修正。

Windowsでgdb配下においてクラッシュを引き起こし、その他の何がしかの問題を起こしていたかもしれない。
}}

!x264r2357
{{bq
commit e61d9f9d3d77584136a591e01cebecbd7547a43b
Author: Hiroki Taniura
Date:   Sun Aug 25 01:18:57 2013 +0900

Fix GPAC support on Windows
}}

{{bq
Windows上でのGPACのサポートを修正。
}}
ビルドにのみ影響。

!x264r2356
{{bq
commit a1d3d17239e94a82ab261a071384295406bd8587
Author: Henrik Gramner
Date:   Sun Aug 11 19:50:42 2013 +0200

Windows Unicode support

Windows, unlike most other operating systems, uses UTF-16 for Unicode strings while x264 is designed for UTF-8.

This patch does the following in order to handle things like Unicode filenames:
* Keep strings internally as UTF-8.
* Retrieve the CLI command line as UTF-16 and convert it to UTF-8.
* Always use Unicode versions of Windows API functions and convert strings to UTF-16 when calling them.
* Attempt to use legacy 8.3 short filenames for external libraries without Unicode support.
}}

{{bq
Windows Unicodeサポート。

x264はUTF-8向けに設計されているが、他のほとんどのオペレーティングシステムと異なり、WindowsはUnicode文字列にUTF-16を使用する。

このパッチはUnicodeファイル名を扱うために以下の様なことを行う:
* 内部的に文字列をUTF-8として保持する。
* CLIコマンドラインをUTF-16として取得しそれをUTF-8に変換する。
* 常にUnicodeバージョンのWindows APIを使用し、呼び出し時に文字列をUTF-16に変換する。
* Unicodeサポートのない外部ライブラリに対しては、古い8.3の短いファイル名を使用しようと試みる。
}}
X264_BUILD 138。

!x264r2355
{{bq
commit 3155f69090354bcb63479d6f8875c55bb8b3f783
Author: Kieran Kunhya
Date:   Sat Jul 20 18:47:59 2013 +0100

AVC-Intra support

This format has been reverse engineered and x264's output has almost exactly
the same bitstream as Panasonic cameras and encoders produce. It therefore does
not comply with SMPTE RP2027 since Panasonic themselves do not comply with
their own specification. It has been tested in Avid, Premiere, Edius and
Quantel.

Parts of this patch were written by Jason Garrett-Glaser and some reverse
engineering was done by Joseph Artsimovich.
}}

{{bq
AVC-Intraのサポート。

この形式はリバースエンジニアリングされたもので、x264の出力はPanasonicのカメラやエンコーダーが作り出すものとほとんど同じビットストリームである。そのため、Panasonic自身が彼らの仕様に適合しないのと同様、これはSMPTE RP2027に適合しない。これはAvid, Premire, Eius, そしてQuantelでテストされている。

このパッチは部分的にJason Garrett-Glaserにより書かれ、リバースエンジニアリングの幾分かはJoseph Artsimovichにより行われた。
}}

X264_BUILD 137。

オプションに--avcintra-compatが追加。intraフレームだけで構成する、主に映像編集向けの形式。

!x264r2354
{{bq
commit b690d473359b4ac7f8e72244af67014cc41b7953
Author: Henrik Gramner
Date:   Mon Jul 8 12:06:42 2013 -0700

Transparent hugepage support

Combine frame and mb data mallocs into a single large malloc.
Additionally, on Linux systems with hugepage support, ask for hugepages on
large mallocs.

This gives a small performance improvement (~0.2-0.9%) on systems without
hugepage support, as well as a small memory footprint reduction.

On recent Linux kernels with hugepage support enabled (set to madvise or
always), it improves performance up to 4% at the cost of about 7-12% more
memory usage on typical settings..

It may help even more on Haswell and other recent CPUs with improved 2MB page
support in hardware.
}}

{{bq
Transparent hugepageのサポート。

フレームとmbデータのmallocを一つの大きなmallocに統合。
加えて、hugepageのサポートのあるLinuxシステムでは、大きなmallocにおいてhugepageに問い合わせる。

これはメモリフットプリントの小さな減少と共に、hugepageのサポートがないシステムで小さな性能向上（〜0.2-0.9%）をもたらす。

hugepageサポートが有効化されている最近のLinuxカーネルにおいては、典型的な設定で7-12%のメモリ消費量を増加させるのと引き換えに、最大4%程度、性能を向上させる。

ハードウェアによる、改善された2MBのページサポートがあるHaswellや他の最近のCPUでは、より有効だろう。
}}

メモリ管理の速度的コストを低減する実装。
hugepageがどういったものであるかの説明がないためにわかりづらいが、これはソフトウェア的なメモリ管理のコストと、ハードウェア的なメモリ管理のコストの両面で有用な変更になる。

ソフトウェア的な面から言うと、C言語上でメモリを確保するmallocというのは、内部的に排他処理やリスト管理が必要であるため、基本的でありながら''速度的コストの高い処理''である。
ので、どうせ使用することがわかっているメモリであれば、細かいサイズで複数回mallocを呼ぶよりも、一括して確保してしまえば効率がいい。
また、mallocされた領域の管理コストもmallocの回数が多ければ多いほど高く付く。

ハードウェア的な面から言うと、CPUはCPUで、プロセスが論理的なメモリ空間（32bitなら4GiBの空間）内のどこをどのくらい実際に使用しているか、というのを管理し、物理メモリと対応付けている。
その管理はバイト単位ではなく''ページ単位で行っており（ページング）、1ページが4KiB''（12bitのアドレス空間）である。
4KiBのページ群をフラットに管理すると効率が悪いため、x86-64ではページ番号として扱う36bit（64bitの総アドレス空間 - 無効16bit - ページ内オフセットの12bitアドレス空間）を9bitごとに4つに分け、さらに階層化がなされている。
つまりあるメモリにアクセスしようとした場合、上位から9bit分ずつの''テーブルを4回参照して(PTE)''4KiBのページに辿り着く。

が、現在の巨大なメモリ空間では4KiBは小さすぎて、これまた効率が悪い。
そこで登場するのがhugepageで、考え方としては上記の階層のうち最下層を無視して、12+9=21bit空間、つまり''2MiBで1ページ''としてしまう。
こうすると、3回の参照でページまで辿り着くことができ、PTEとそのキャッシュであるTLEアクセスの省力化となる。
また、2MiBのページを一体に扱うことで、フレームバッファなどの「メモリブロック中のどこかを参照する場合は、その中の他の場所も参照する可能性が高い」メモリにおいて、その一部が4KiBごとにフラグメントしてしまう可能性も排除できる。

ただし、メモリを大きな単位で（大雑把に）扱うようになるため、2MiBがフルに活用されない場合は「CPU的には割り当て済みだけと実際には使われない」半端な領域ができる。
このため、''hugepageの仕組みは速度と容量のトレードオフ''となる。
全てのページが2MiBではあまりに非効率であるため、実際には従来の4KiBページとhugepageは共存し、確保するメモリサイズによって使い分けられる。組み込みシステムではよくある仕組みだ。

hugepageは以前には特殊な仕掛けを使用し、ソフトウェア側でも意識してコードを書く必要があったが、LinuxがネイティブにサポートしたことでTransparent（透過的）、つまり殆ど意識すること無く使用可能になった。

ソフトウェア面の工夫と、ハードウェアの機能・特性の活用という2面から、使用するメモリをまとめて大きなブロックとして扱おうというのがこのパッチになる。

!x264r2353
{{bq
commit 0a6825c6fe9ee5d2ded73e8c43be3e6dfd6a7658
Author: Henrik Gramner
Date:   Fri Jul 5 21:15:54 2013 +0200

x86: SSSE3 implementation of pixel_sad_x3 and pixel_sad_x4
}}

{{bq
x86: pixel_sad_x3とpixel_sad_x4のSSSE3実装。 
}}

!x264r2352
{{bq
commit ac5d88116e39bab7a63050ce62bedd5d543902ca
Author: Henrik Gramner
Date:   Fri Jul 5 21:15:49 2013 +0200

x86: Faster AVX2 pixel_sad_x3 and pixel_sad_x4
}}

{{bq
x86: AVX2 pixel_sad_x3とpixel_asd_x4を高速化。
}}

!x264r2351
{{bq
commit 348f1b7f91319d0ac059a2067dc5c9f539df5889
Author: Diogo Franco (Kovensky)
Date:   Tue Jul 23 22:17:44 2013 -0300

configure: Support cygwin64
}}

{{bq
configure: cygwin64をサポート。
}}
ビルドにのみ影響。

!x264r2350**STABLE**
//STABLE
{{bq
commit 3361d59a0a83dcb8b321cc0eb8e6ba68ca49c7d4
Author: Derek Buitenhuis
Date:   Fri Aug 9 13:39:27 2013 -0400

x86inc: Check for __OUTPUT_FORMAT__ having a value of "x64"

This is also a valid value for WIN64.
}}

{{bq
x86inc: __OUTPUT_FORMAT__が"x64"の値を持つかをチェック。

これはWIN64でも有効な値である。
}}
ビルドにのみ影響。

!x264r2349
{{bq
commit f3d9a5839978125fa3f95b38460f8c8854feec24
Author: Anton Mitrofanov
Date:   Tue Jul 23 14:11:50 2013 -0700

Fix cases in which intra refresh allowed prediction from disallowed pixels
}}

{{bq
intra refreshが、許可されないピクセルからの予測を許可してしまっていたケースを修正。
}}

!x264r2348
{{bq
commit 88cff5ab9b6f3be1bb2edc5dd9f753dcc2b987e5
Author: Anton Mitrofanov
Date:   Wed Aug 7 01:56:34 2013 +0400

Fix a few minor bugs found with a static analyzer
}}

{{bq
静的解析ツールで発見されたいくつかの小さなバグを修正。
}}

!x264r2347
{{bq
commit 613548f7f9655504cd8fdf0f00ccf2df9e9768eb
Author: Jason Garrett-Glaser
Date:   Fri Jul 12 16:07:35 2013 -0700

Fix AVX2 detection bug with "limit CPUID" enabled in BIOS
}}

{{bq
BIOSで"limit CPUID"が有効にされている場合のAVX2の検出バグを修正。
}}

!x264r2346
{{bq
commit 0c738e30ec025f0effdb62802685fce40cf20057
Author: Henrik Gramner
Date:   Fri Jul 5 21:15:43 2013 +0200

x86: Remove X264_CPU_SSE_MISALIGN functions

Prevents a crash if the misaligned exception mask bit is cleared for some reason.

Misaligned SSE functions are only used on AMD Phenom CPUs and the benefit is miniscule.
They also require modifying the MXCSR control register and by removing those functions
we can get rid of that complexity altogether.

VEX-encoded instructions also supports unaligned memory operands. I tried adding AVX
implementations of all removed functions but there were no performance improvements on
Ivy Bridge. pixel_sad_x3 and pixel_sad_x4 had significant code size reductions though
so I kept them and added some minor cosmetics fixes and tweaks.
}}

{{bq
x86: X264_CPU_SSE_MISALIGN関数を削除。

何がしかの理由でmisaligned exception mask bitがクリアされていた場合のクラッシュを防ぐ。

Misaligned SSE関数はAMD Phenom CPUでのみ使用され、その利得は非常に小さい。
それらはMXCSRコントロールレジスタを修正することも要求するが、それら関数を削除することでその複雑性も共に取り除くことができる。

VEX-encoded命令は非アラインメモリオペランドもサポートする。全ての削除された関数のAVX実装を追加しようと試みたが、Ivy Bridge上では全く性能の向上がなかった。しかしpixel_sad_x3とpixel_sad_x4には有意なコードサイズの減少があったため、それらは保持することとし、いくつかの小さなコスメティックスと調整を追加した。
}}
X264_BUILD 136。

!x264r2345
{{bq
commit f0c1c53d58420d209f0fb7b63e49125ab1c85aa7
Author: Jason Garrett-Glaser
Date:   Thu Jun 20 15:51:39 2013 -0700

Tweak i16x16-delta-quant-avoidance code

Don't omit the delta quant if it'd raise the quantizer to do so; this fixes
a rare flickering issue caused by deblocking.
}}

{{bq
i16x16-delta-quant-avoidanceのコードを調整。

delta quantを省略することによりquantizerを上昇させる場合には省略しない; これはデブロックにより引き起こされる稀なflickering問題を修正する。
}}

FIXME: コードを見たほうが良さそうだが時間がない。

!x264r2344
{{bq
commit 23ef03667f4218c8bed152b177eb5e66e9781687
Author: Jason Garrett-Glaser
Date:   Sun Jun 9 09:06:27 2013 -0700

x86: faster AVX2 iDCT, AVX deblock_luma_h, deblock_luma_h_intra
}}

{{bq
x86: AVX2 iDCT, AVX deblock_luma_h, deblock_luma_h_intraを高速化。
}}

!x264r2343
{{bq
commit 4d24facd4170c6bed3f5205381b6fe2f2974bed3
Author: Lucien
Date:   Mon Jun 17 18:28:09 2013 +0000

Add new color primaries, transfer characteristics, matrix coefficients
}}

{{bq
新たなcolor primary, transfer characteristics, matrix coefficientsを追加。
}}
X264_BUILD 135。

今のところ使用する機会は少ないかもしれないが、HEVCで主に使われるであろうbt2020などが追加になっている。

!x264r2342
{{bq
commit 8c8b46f1fbcf1c4b684afff9160d074077909965
Author: Jason Garrett-Glaser
Date:   Fri May 31 17:01:29 2013 -0700

Add "--stitchable" option for segmented encoding

Stops x264 from attempting to optimize global stream headers, ensuring that
different segments of a video will have identical headers when used with
identical encoding settings.
}}

{{bq
segmentエンコーディングのために"--stitchable"オプションを追加。

x264がglobal stream headerを最適化しようとするのを止め、ビデオの異なるsegmentが、同一のエンコーディング設定において、同一のヘッダを持つように保証する。
}}
X264_BUILD 134。

同じヘッダを持っていれば、ヘッダ領域を除いたバイトデータを単に後ろに結合するだけで連続再生可能なデータとなる（ちょっと語弊があるけど）。それをstitchableと呼んでいる。x264を使用したシステムを組む場合、そうできたほうが便利なケースがあるので用意されたのだろう。

同じ意味を持つヘッダでも、ビット単位で同一でないと、解析して意味を考慮しないと同一性を保証できないため、muxerにとっては負担となる。このオプションを指定すればヘッダが同一であることを簡単に確認できるので、扱いやすい。

!x264r2341
{{bq
commit e4ac506d2cbeceb7d1cbe02e2e69dac6ac57975a
Author: Jason Garrett-Glaser
Date:   Thu Jun 27 08:29:06 2013 -0700

Interface: if vbv-maxrate < bitrate, set bitrate = vbv-maxrate

This probably makes more sense to the user than setting vbv-maxrate = bitrate,
as before.
}}

{{bq
インターフェース: vbv-maxrate < bitrate の場合、 bitrate = vbv-maxrate とする。 

以前のように vbv-maxrate = bitrate とするよりもユーザーにとって妥当だろう。
}}

!x264r2340
{{bq
commit 11d2203c5b1d8d64f7b647b5f01e212eb97aab12
Author: Anton Mitrofanov
Date:   Tue May 28 05:02:42 2013 -0700

OpenCL cosmetics
}}

{{bq
OpenCLのコスメティックス。
}}

!x264r2339
{{bq
commit 585324fee380109acd9986388f857f413a60b896
Author: Anton Mitrofanov
Date:   Tue Jun 18 00:16:33 2013 +0400

Fix possible crash when writing very large filler NALUs

Bitstream-reallocation function didn't handle the case of filler.
}}

{{bq
とても大きなfiller NALUを書き込もうとする際にクラッシュする可能性を修正。

Bitstream-reallocation関数はfillerのケースを扱っていなかった。
}}

!x264r2338
{{bq
commit 8be78d3df47a43cfd8dde047026e7f238030e253
Author: Loren Merritt
Date:   Mon Jun 17 11:27:09 2013 -0700

Fix build with PIC on some systems
}}

{{bq
いくつかのシステムにおけるPICビルドの修正。
}}
ビルドにのみ影響。

!x264r2337
{{bq
commit f45158c6f20007ef8f17059dfc084c5b35b74f44
Author: Henrik Gramner
Date:   Sun Jun 2 18:41:17 2013 +0200

Fix potential misaligment crash in AVX2 denoise_dct
}}

{{bq
AVX2 denoise_dctにおける潜在的な非アラインによるクラッシュを修正。
}}

!x264r2336
{{bq
commit d5dbf461bbb4564b5aeb2c88f3b42e38a60dafc1
Author: Anton Mitrofanov
Date:   Tue May 28 01:48:15 2013 +0400

Fix building with compilers without inline asm support

Also fix crash in high bit depth builds compiled with unaligned stack.
}}

{{bq
inline asmをサポートしないコンパイラでのビルドを修正。

また、非アラインスタックでの高ビット深度ビルドにおけるクラッシュを修正。
}}

!x264r2335
{{bq
commit 3af33c98a60a62bf9dee9ccb0f2475b8124a5354
Author: Anton Mitrofanov
Date:   Wed May 22 22:43:59 2013 +0400

Fix compilation with OpenCL on MacOS X

Also fix crash in the case of OpenCL error during encoding.
}}

{{bq
MacOS X上でのOpenCL付きコンパイルを修正。

また、エンコード中にOpenCLエラーが発生した場合のクラッシュを修正。
}}

!x264r2334
//MASTER
{{bq
git-id : a3ac64b8b467eea1264c0053022893bc84b2e9a2
Author : Anton Mitrofanov
Date: Mon May 6 22:51:11 2013 +0400

OpenCL support improvement/refactoring

Autoload the OpenCL library so that it's not required to run an openCL-enabled
build of x264.

Update X264_BUILD, which should have been changed with the first patch.
}}

{{bq
OpenCLサポートの改善・リファクタリング。

OpenCLのライブラリを自動読み込みすることでopenCL-enabledでビルドされたx264を実行する必要がなくなった。

最初のパッチで変更されるべきだったのだが、X264_BUILDを更新。
}}
X264_BUILD 133。

!x264r2333
{{bq
git-id : c47347c01eb4d9933e2d9705f44707dbb396f611
Author : Jason Garrett-Glaser
Date: Thu May 16 13:51:37 2013 -0700

x86: shave a few instructions off AVX deblock
}}

{{bq
x86: AVX deblockからいくらかの命令を削減。
}}

!x264r2332
{{bq
git-id : b547a4ea1169411610855002db9a8182b1e73314
Author : Henrik Gramner
Date: Tue May 14 18:57:40 2013 +0200

x86: AVX2 dequant_4x4_dc
}}

{{bq
x86: AVX2 dequant_4x4_dc。
}}

!x264r2331
{{bq
git-id : 907573d3f7873b7600cc94d1e287d52628e11766
Author : Henrik Gramner
Date: Tue May 14 18:53:12 2013 +0200

x86: AVX2 high bit-depth dequant
}}

{{bq
x86: AVX2高ビット深度逆量子化。
}}

!x264r2330
{{bq
git-id : 442c6a420f8727d2f4087e9f3f317fb1774b9262
Author : Jason Garrett-Glaser
Date: Thu May 9 17:20:05 2013 -0700

x86-64: 64-bit variant of AVX2 hpel_filter

~5% faster than 32-bit.
}}

{{bq
x86-64: AVX2 hpel_filterの64-bit版。

32-bitより〜5%速い。
}}

!x264r2329
{{bq
git-id : 26a6451591cd7cd25fcfeeacee3850e5dd7a7f7e
Author : Henrik Gramner
Date: Mon May 6 18:41:24 2013 +0200

x86: AVX2 high bit-depth denoise_dct

28->15 cycles

Also reorder instructions to use fewer registers, 3 cycles faster on Ivy Bridge with 64-bit Windows.
}}

{{bq
x86: AVX2高ビット深度denoise_dct。

28→15サイクルに。

また、使用レジスタをより少なくするために命令順を変更し、64-bit WindowsでのIvy Bridgeで3サイクル高速化。
}}

!x264r2328
{{bq
git-id : db95d6af63bec7839b3d3e1f2eb67b8689dc8170
Author : Henrik Gramner
Date: Sat May 4 18:48:58 2013 +0200

x86: AVX2 high bit-depth quant

quant_4x4: 13->6 cycles
quant_4x4_dc: 14->8 cycles
quant_8x8: 47->24 cycles
quant_4x4x4: 48->25 cycles
}}

{{bq
x86: AVX2高ビット深度量子化。

quant_4x4: 13→6サイクルに。
quant_4x4_dc: 14→8サイクルに。
quant_8x8: 47→24サイクルに。
quant_4x4x4: 48→25サイクルに。
}}

!x264r2327
{{bq
git-id : 327386f70836507cb44266e5d71bd1d744fe3d78
Author : Jason Garrett-Glaser
Date: Wed May 1 14:32:11 2013 -0700

x86: AVX2 add16x16_idct_dc

27 -> 19 cycles
}}

{{bq
x86: AVX2 add16x16_idct_dc。

27→19サイクルに。
}}

!x264r2326
{{bq
git-id : c82db4ed07d4a69a84ac99d5e79e32f61141494f
Author : Jason Garrett-Glaser
Date: Mon Apr 29 16:16:54 2013 -0700

x86: faster AVX2 quant_4x4x4

10->9 cycles
}}

{{bq
x86: AVX2 quant_4x4x4を高速化。

10→9サイクルに。
}}

!x264r2325
{{bq
git-id : b79f4a6e460b00c85f0ee67b03299bf1d15dd48c
Author : Jason Garrett-Glaser
Date: Sat Apr 27 21:03:32 2013 -0700

x86: AVX2 intra_sad_x3_8x8c

30->22 cycles
}}

{{bq
x86: AVX2 intra_sad_x3_8x8c。

30→22サイクルに。
}}

!x264r2324
{{bq
git-id : 2c0bca3f798e20133f61c3517202942e873e00d6
Author : Henrik Gramner
Date: Sun Apr 28 11:11:03 2013 +0200

x86: AVX2 high bit-depth intra_sad_x3_8x8

43->24 cycles
}}

{{bq
x86: AVX2高ビット深度intra_sad_x3_8x8。

43→23サイクルに。
}}

!x264r2323
{{bq
git-id : b2c30e1a470181b591619b211ae0342e9cc8aac9
Author : Jason Garrett-Glaser
Date: Wed Apr 24 14:22:15 2013 -0700

x86: AVX2 deblock strength

30->18 cycles
}}

{{bq
x86: AVX2 deblock strength。

30→18サイクルに。
}}

!x264r2322
{{bq
git-id : 37edf16c1955cfc9d2843024af0fa7aa6268ad90
Author : Henrik Gramner
Date: Wed May 1 17:42:48 2013 +0200

x86: Faster high bit-depth intra_sad_x3_4x4

20->16 cycles on Ivy Bridge
}}

{{bq
x86: 高ビット深度intra_sad_x3_4x4を高速化。

Ivy Bridge上で20→16サイクルに。
}}

!x264r2321
{{bq
git-id : a9ed051f2bc73c9bfeff006d7328bd2bc99ce147
Author : Jason Garrett-Glaser
Date: Tue Apr 30 17:36:46 2013 -0700

x86: faster SSSE3 hpel

~7% faster using the pmulhrsw trick from mc_chroma.
}}

{{bq
x86: SSSE3 hpelを高速化。

mc_chroma由来のpmulhrswのトリックを使用し〜7%高速化。
}}

!x264r2320
{{bq
git-id : 9373d5fa6e7a5cc5bcc756125cbc2e7fe058ea43
Author : Jason Garrett-Glaser
Date: Mon Apr 29 14:22:23 2013 -0700

x86-64: faster SSSE3 trellis

~2% faster trellis.
}}

{{bq
x86-64: SSSE3 trellisを高速化。

trellisが〜2%高速に。
}}

!x264r2319
{{bq
git-id : 2a716040eb8b89efd92ea61ab08ecc41bf0b8623
Author : Jason Garrett-Glaser
Date: Thu May 2 17:10:26 2013 -0700

x86: 32-byte align the stack if possible

Avoids the need for manual 32 byte array alignment on compilers that support
-mpreferred-stack-boundary.
}}

{{bq
x86: 可能ならスタックを32-byteアラインするように。

-mpreferred-stack-boundaryをサポートするコンパイラ上で、手動での配列の32byteアラインメントを不要にする。
}}

!x264r2318
{{bq
git-id : eefaff1128ea9eb8dcd6796957ca5e56727337b8
Author : Henrik Gramner
Date: Sat May 11 23:39:09 2013 +0200

x86inc: Utilize the shadow space on 64-bit Windows

Store XMM6 and XMM7 in the shadow space in functions that clobbers them.
This way we don't have to adjust the stack pointer as often,
reducing the number of instructions as well as code size.
}}

{{bq
x86inc: 64-bit Windowsにおいてシャドウスペースを活用するように。

XMM6とXMM7を頻繁に叩く関数で、それらをシャドウスペースに格納する。
この方法によってスタックポインタを頻繁に調整する必要がなくなり、コードサイズと共に命令数を削減できる。
}}

!x264r2317
{{bq
git-id : b4be6e56629cf8fdcf53adc6b879969d8f6760b3
Author : Henrik Gramner
Date: Fri May 3 23:06:10 2013 +0200

x86: Don't use explicitly aligned versions of SAD on AVX CPUs

On modern CPUs movdqu isn't slower than movdqa when used on aligned data and using the same code in both cases saves cache.

This was already done for the high bit-depth AVX2 implementation but the aligned version still exists as dead code so remove that.
}}

{{bq
x86: AVX CPUでSADの明示的なアラインのバージョンを使用しないようにした。

現代的なCPUでは、アラインされたデータ上で使用された場合に、movdquはmovdqaより遅くはなく、両方のケースで同じコードを使うことはキャッシュの節約になる。

これは高ビット深度AVX2実装では既に行われていたが、アラインバージョンはデッドコードとして存在してしまうため、それを削除した。
}}
少し前にUtVideoの作者さんがこの辺りに関してツイートしていたような。
と思ってMentionしたら、[或るプログラマの一生 &#187; SSE の整数ロードストア命令のベンチマーク|http://umezawa.dyndns.info/wordpress/?p=3836]の記事を教えて頂いたので興味ある方は是非どうぞ。

!x264r2316
{{bq
git-id : 99f553ec300d928d23522304ebf4818574b85ed3
Author : Henrik Gramner
Date: Fri May 3 20:18:03 2013 +0200

x86: Add missing initializations for high bit-depth sad_aligned
}}

{{bq
x86: 高ビット深度sad_alignedに対して不足していた初期化を追加。
}}

!x264r2315
{{bq
git-id : 42f2f78a05985a49fea0fb1bff050c95257810bb
Author : Jason Garrett-Glaser
Date: Mon May 13 16:52:18 2013 -0700

x86: add Jaguar CPU detection
}}

{{bq
x86: JaguarのCPU検出を追加。
}}

!x264r2314
{{bq
git-id : f12a17f5ecde41148256cb0c132cb31ac6602f3e
Author : Henrik Gramner
Date: Tue May 7 17:21:03 2013 +0200

x86inc: Remove .rodata kludges

The Mach-O bug was fixed in yasm 0.8.0 and we don't support versions that old.

a.out was superseded by ELF on sane systems a few decades ago.
}}

{{bq
x86inc: .rodataの暫定対処を削除。

Mach-0バグはyasm 0.8.0で修正されており、そのような古いバージョンを我々はサポートしない。

a.outはまともなシステムでは数十年前にELFに取って代わられている。
}}

!x264r2313
{{bq
git-id : c3b166a6cf55afaeea5bbc94ebb275b92efbd3d8
Author : Henrik Gramner
Date: Sat May 4 16:21:32 2013 +0200

checkasm: Use 64-bit cycle counters

Prevents overflows that can occur in some cases.
}}

{{bq
checkasm: 64-bitのサイクルカウンタを使用。

いくつかのケースで起こりうるオーバーフローを抑止。
}}

!x264r2312
{{bq
git-id : e943696e98ba9a75f5100c5692e39708ff2cc422
Author : Henrik Gramner
Date: Fri May 10 13:55:32 2013 +0200

checkasm: Fix stack alignment bug
}}

{{bq
checkasm: スタックアラインメントのバグを修正。
}}

!x264r2311
{{bq
git-id : b1749e204d14087a768990e8bfe964d343e0b9a9
Author : Jason Garrett-Glaser
Date: Wed May 8 10:48:41 2013 -0700

Fix invalid memcpy in sliced-threads

Likely didn't actually break in practice, but memcpy with src==dst
is incorrect.
}}

{{bq
sliced-threadsでの無効なmemcpyを修正。

実際には壊れてはいなかったようだが、src==dstであるmemcpyは不正である。
}}
src領域とdst領域が重なる場合の仕様は規格上未定義動作のはず。

!x264r2310
//HOTFIX
{{bq
git-id : 76a5c3a19f97cd34b65aeff050de4042b054bc65
Author : Jason Garrett-Glaser
Date: Mon Apr 29 12:14:01 2013 -0700

Fix two bugs in slice-min-mbs and slices-max

Slices-max broke slice-max-size when slice-max wasn't used.
Slice-min-mbs broke in rare cases near the end of a threadslice.
}}

{{bq
slice-min-mbsとslices-maxの2つのバグを修正。

Slices-maxはslice-maxが使われていない場合のslice-max-sizeを壊していた。
Slice-min-mbsはthreadsliceの終わり付近で稀に壊れていた。
}}

!x264r2309
//MASTER
{{bq
git-id : 3b1f1f71459b54b976588b871edc7f459b4d0434
Author : Jason Garrett-Glaser
Date: Thu Apr 4 18:00:23 2013 -0700

x86: SSSE3 LUT-based faster coeff_level_run

~2x faster coeff_level_run.
Faster CAVLC encoding: {1%,2%,7%} overall with {superfast,medium,slower}.
Uses the same pshufb LUT abuse trick as in the previous ads_mvs patch.
}}

{{bq
x86: 表引きベース(LUT-based)のより高速なSSSE3 coeff_level_run。

coeff_level_runを〜2倍高速化。
CAVLCエンコーディングを高速化: 全体で{superfast,medium,slower}に対しそれぞれ{1%,2%,7%}高速。
以前のads_mvsパッチ内のものと同じpshufb LUTの（正統でない）トリックを使用。
}}
r2287と同じで、CAVLCではほぼ必ず通るパスのため、着実に高速化する。

!x264r2308
{{bq
git-id : c05bf544b659510b9008c1037fd8887e8917d30c
Author : Jason Garrett-Glaser
Date: Mon Mar 25 14:03:37 2013 -0700

x86-64: BMI2 cabac_residual functions
}}

{{bq
x86-64: BMI2 cabac_residual関数。
}}

!x264r2307
{{bq
git-id : 437f808579754b5674fb6183331e8ca9bcf53647
Author : Jason Garrett-Glaser
Date: Wed Mar 20 15:08:35 2013 -0700

x86: SSSE3 ads_mvs

~55% faster ads in benchasm, ~15-30% in real encoding.
~4% faster "placebo" preset overall.
}}

{{bq
x86: SSSE3 ads_mvs。

benchasmでadsが〜55%高速化、実際のエンコーディングでは〜15-30%程度。
"placebo"プリセットにおいて全体で〜4%高速化。
}}

!x264r2306
{{bq
git-id : 2ad961f2d6fc681db6fc87f2c0ca68ff2a00e65e
Author : Henrik Gramner
Date: Tue Apr 16 23:27:53 2013 +0200

x86: AVX2 pixel_ssd_nv12_core
}}

{{bq
x86: AVX2 pixel_ssd_nv12_core。
}}

!x264r2305
{{bq
git-id : 40406b804105964d6b5abea38833d69f6d617815
Author : Henrik Gramner
Date: Tue Apr 16 23:27:50 2013 +0200

x86: AVX2 high bit-depth pixel_ssd
}}

{{bq
x86: AVX2高ビット深度pixel_ssd。
}}

!x264r2304
{{bq
git-id : c2852be748c66f1ff25f38133d5efbd6059bed6c
Author : Henrik Gramner
Date: Tue Apr 16 23:27:46 2013 +0200

x86: AVX2 high bit-depth pixel_sad_x3/pixel_sad_x4

Also reduce the number of xmm registers used by sse2/ssse3 pixel_sad_x3.
}}

{{bq
x86: AVX2高ビット深度pixel_sad_x3/pixel_sad_x4

また、sse2/ssse3 pixel_sad_x3で使用されるxmmレジスタの数を削減。
}}

!x264r2303
{{bq
git-id : fa9dcd02ea386e46314eb0c518b0b5763ef73c80
Author : Henrik Gramner
Date: Tue Apr 16 23:27:43 2013 +0200

x86: AVX2 high bit-depth vsad
}}

{{bq
x86: AVX2高ビット深度vsad。
}}

!x264r2302
{{bq
git-id : 567d03619b0af415362454eb20066e0167266a43
Author : Henrik Gramner
Date: Tue Apr 16 23:27:39 2013 +0200

x86: AVX2 high bit-depth pixel_sad

Also use loops instead of duplicating code; reduces code size by ~10kB with
negligible effect on performance.
}}

{{bq
x86: AVX2高ビット深度pixel_sad。

また、コードを複製せずループを使うようにした; 性能に些細な影響があるもののコードサイズを〜10kB削減。
}}

!x264r2301
{{bq
git-id : 6cc9f169844cc84a7da8cc4fbf08a3f5dea86c63
Author : Henrik Gramner
Date: Tue Apr 16 23:27:35 2013 +0200

x86: AVX2 high_bit_depth pixel_avg2, get_ref, mc_copy_w16, mc_luma

Also reduce the number of xmm registers used by mc_copy_* to avoid
saving and restoring xmm6 and xmm7 on 64-bit Windows.
}}

{{bq
x86: AVX2高ビット深度pixel_avg2、get_ref、mc_copy_w16、mc_luma。

また、64-bit Windows上でxmm6とxmm7の保存・復元を避けるために、mc_copy_*で使用されるxmmレジスタの数を削減した。
}}
レジスタの保存に関することは以前にも書いた気がするのだけれども。

多くのCPUでは、普通はCPUメーカーが定める、ABIと呼ばれる''決まり事''があり、プログラミング言語の種類に関わらず、一般的に守るべきこととされている。そのうちでも例えば、「関数の戻り値はEAXで返すよ」などの関数呼び出しに関するものを、''「呼出規約」''と呼ぶ。

ほとんどのレジスタが同じ機能を持ち、ほとんどの命令が全てのレジスタに適用出来る、新しめの''フラットな''構成のRISC CPUでは、ABIの一部を敢えて守らないことも不可能ではない。が、各種ライブラリのバイナリとの互換性がなくなるので、道は踏み外さないのが普通だ。
そして歴史あるCISCのx86では、''ABIを前提に作られている命令''もあるので、実質的に守らざるを得なかったりもする。

その呼出規約には、関数を呼ぶ側で、「呼んだら内容が上書きされる可能性がある」レジスタが定められている。
例えば上記「関数の戻り値はEAXで返すよ」の規則では、EAXは戻り値に使われるので、当然上書きされる。もし関数を呼ぶ側が、''関数呼び出し前のEAXの内容を、関数呼び出し後も使いたい''のなら、それは関数呼び出し前に、メモリ等に別途保存（退避）しておかねばならない。

その逆に、関数を呼ぶ側では、退避しておかなくてもよいレジスタも定められている。すると、呼び出される関数は、もしそのレジスタを自関数内で使用したいのであれば、自分で''レジスタ上書き前に退避し、レジスタ使用後に復元''しなければない。

これは当然無駄なメモリアクセスとなり、SIMD化できるようなものでもないので、避けられるなら避けるのが最も効率が良い。

!x264r2300
{{bq
git-id : c3711285a6dd1343197ac3e53bb95acf99c6cb42
Author : Henrik Gramner
Date: Tue Apr 16 23:27:32 2013 +0200

x86: AVX2 nal_escape

Also rewrite the entire function to be faster and drop the AVX version which is no longer useful.
}}

{{bq
x86: AVX2 nal_escape。

また、関数全体を書きなおし、もう有用ではないAVXバージョンをドロップした。
}}

----

前:[[x264-changelog-jp r2200-r2299]] - 次:[[x264-changelog-jp r2400-r2499]]