[x265-commits] [x265] doc: document behavior of POSIX builds without libnuma (r...

[Steve Borho]

details:   http://hg.videolan.org/x265/rev/0f85153181a8
branches:  
changeset: 10115:0f85153181a8
user:      Steve Borho <steve at borho.org>
date:      Tue Apr 07 14:38:42 2015 -0500
description:
doc: document behavior of POSIX builds without libnuma (refs #117)
Subject: [x265] readme: point release download link towards videolan

details:   http://hg.videolan.org/x265/rev/3e416dec8024
branches:  
changeset: 10116:3e416dec8024
user:      Steve Borho <steve at borho.org>
date:      Tue Apr 07 16:00:39 2015 -0500
description:
readme: point release download link towards videolan

diffstat:

 doc/reST/cli.rst       |   9 +++++++++
 doc/reST/threading.rst |  13 +++++++++++++
 readme.rst             |   2 +-
 3 files changed, 23 insertions(+), 1 deletions(-)

diffs (61 lines):

diff -r a72f08e05ab9 -r 3e416dec8024 doc/reST/cli.rst
--- a/doc/reST/cli.rst	Tue Apr 07 18:36:17 2015 +0530
+++ b/doc/reST/cli.rst	Tue Apr 07 16:00:39 2015 -0500
@@ -217,6 +217,15 @@ Performance Options
 	:option:`--frame-threads`.  The pools are used for WPP and for
 	distributed analysis and motion search.
 
+	On Windows, the native APIs offer sufficient functionality to
+	discover the NUMA topology and enforce the thread affinity that
+	libx265 needs, but on POSIX systems it relies on libnuma for this
+	functionality. If your target POSIX system is single socket, then
+	building without libnuma is a perfectly reasonable option, as it
+	will have no effect on the runtime behavior. On a multiple-socket
+	system, a POSIX build of libx265 without libnuma will be less work
+	efficient. See :ref:`thread pools <pools>` for more detail.
+
 	Default "", one thread is allocated per detected hardware thread
 	(logical CPU cores) and one thread pool per NUMA node.
 
diff -r a72f08e05ab9 -r 3e416dec8024 doc/reST/threading.rst
--- a/doc/reST/threading.rst	Tue Apr 07 18:36:17 2015 +0530
+++ b/doc/reST/threading.rst	Tue Apr 07 16:00:39 2015 -0500
@@ -2,6 +2,8 @@
 Threading
 *********
 
+.. _pools:
+
 Thread Pools
 ============
 
@@ -31,6 +33,17 @@ for data locking. If a job becomes block
 expected to drop that job so the worker thread may go back to the pool
 and find more work.
 
+On Windows, the native APIs offer sufficient functionality to discover
+the NUMA topology and enforce the thread affinity that libx265 needs,
+but on POSIX systems it relies on libnuma for this functionality. If
+your target POSIX system is single socket, then building without libnuma
+is a perfectly reasonable option, as it will have no effect on the
+runtime behavior. On a multiple-socket system, a POSIX build of libx265
+without libnuma will be less work efficient, but will still function
+correctly. You lose the work isolation effect that keeps each frame
+encoder from only using the threads of a single socket and so you incur
+a heavier context switching cost.
+
 Wavefront Parallel Processing
 =============================
 
diff -r a72f08e05ab9 -r 3e416dec8024 readme.rst
--- a/readme.rst	Tue Apr 07 18:36:17 2015 +0530
+++ b/readme.rst	Tue Apr 07 16:00:39 2015 -0500
@@ -3,7 +3,7 @@ x265 HEVC Encoder
 =================
 
 | **Read:** | Online `documentation <http://x265.readthedocs.org/en/default/>`_ | Developer `wiki <http://bitbucket.org/multicoreware/x265/wiki/>`_
-| **Download:** | `releases <http://bitbucket.org/multicoreware/x265/downloads/>`_ 
+| **Download:** | `releases <http://ftp.videolan.org/pub/videolan/x265/>`_ 
 | **Interact:** | #x265 on freenode.irc.net | `x265-devel at videolan.org <http://mailman.videolan.org/listinfo/x265-devel>`_ | `Report an issue <https://bitbucket.org/multicoreware/x265/issues?status=new&status=open>`_
 
 `x265 <https://www.videolan.org/developers/x265.html>`_ is an open