[x265-commits] [x265] doc: document behavior of POSIX builds without libnuma (r...
Steve Borho
steve at borho.org
Tue Apr 7 23:01:54 CEST 2015
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
More information about the x265-commits
mailing list