[x265] [PATCH 1 of 2] docs: mention that Windows NUMA APIs require Windows 7 build target

Steve Borho steve at borho.org
Sun Apr 12 05:52:28 CEST 2015


# HG changeset patch
# User Steve Borho <steve at borho.org>
# Date 1428809416 18000
#      Sat Apr 11 22:30:16 2015 -0500
# Node ID 5f15fafe1ff9c42e0a133517371c2e527ae892e0
# Parent  6c5cf7a120f02dd04669b7fba99625ec8405e60e
docs: mention that Windows NUMA APIs require Windows 7 build target

diff -r 6c5cf7a120f0 -r 5f15fafe1ff9 doc/reST/cli.rst
--- a/doc/reST/cli.rst	Sat Apr 11 10:52:23 2015 -0500
+++ b/doc/reST/cli.rst	Sat Apr 11 22:30:16 2015 -0500
@@ -219,12 +219,14 @@
 
 	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.
+	libx265 needs (so long as your compiler is targeting Windows 7 or
+	later -D_WIN32_WINNT=_WIN32_WINNT_WIN7), 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 6c5cf7a120f0 -r 5f15fafe1ff9 doc/reST/threading.rst
--- a/doc/reST/threading.rst	Sat Apr 11 10:52:23 2015 -0500
+++ b/doc/reST/threading.rst	Sat Apr 11 22:30:16 2015 -0500
@@ -34,15 +34,17 @@
 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.
+the NUMA topology and enforce the thread affinity that libx265 needs (so
+long as your compiler is targeting Windows 7 or later
+-D_WIN32_WINNT=_WIN32_WINNT_WIN7), 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
 =============================


More information about the x265-devel mailing list