[x265] [PATCH] bug: Making windows cpu mask 64-bits

Steve Borho steve at borho.org
Wed Sep 16 20:38:54 CEST 2015


On 09/15, Pradeep Ramachandran wrote:
> # HG changeset patch
> # User Pradeep Ramachandran <pradeep at multicorewareinc.com>
> # Date 1442332345 -19800
> #      Tue Sep 15 21:22:25 2015 +0530
> # Node ID a103f446053e9992b06e4b522e9fcab62d47ca68
> # Parent  365f7ed4d89628d49cd6af8d81d4edc01f73ffad
> bug: Making windows cpu mask 64-bits
> 
> diff -r 365f7ed4d896 -r a103f446053e source/common/threadpool.cpp
> --- a/source/common/threadpool.cpp	Tue Sep 08 16:38:01 2015 +0530
> +++ b/source/common/threadpool.cpp	Tue Sep 15 21:22:25 2015 +0530
> @@ -473,7 +473,7 @@
>  void ThreadPool::setThreadNodeAffinity(void *numaMask)
>  {
>  #if defined(_WIN32_WINNT) && _WIN32_WINNT >= _WIN32_WINNT_WIN7 
> -    if (SetThreadAffinityMask(GetCurrentThread(), (DWORD_PTR)(*((DWORD*)numaMask))))
> +    if (SetThreadAffinityMask(GetCurrentThread(), (DWORD_PTR)(*((DWORD64*)numaMask))))

why the casts at all, isn't this just (DWORD_PTR)numaMask? Or are there
some crazy little endian pointer tricks being done here?

btw: gotta love Windows data types.. DWORD64? really?

>          return;
>      else
>          x265_log(NULL, X265_LOG_ERROR, "unable to set thread affinity for NUMA node mask\n");
> diff -r 365f7ed4d896 -r a103f446053e source/common/threadpool.h
> --- a/source/common/threadpool.h	Tue Sep 08 16:38:01 2015 +0530
> +++ b/source/common/threadpool.h	Tue Sep 15 21:22:25 2015 +0530
> @@ -85,7 +85,7 @@
>      int           m_numWorkers;
>      void*         m_numaMask; // node mask in linux, cpu mask in windows
>  #if defined(_WIN32_WINNT) && _WIN32_WINNT >= _WIN32_WINNT_WIN7 
> -    DWORD         m_winCpuMask;
> +    DWORD64       m_winCpuMask;

technically, we're copying bits from GROUP_AFFINITY.Mask, which is
defined as type KAFFINITY, which appears to be a mirror for a kernel
variable size. But SetThreadAffinityMask() wants a DWORD_PTR. Honestly,
these win32 APIs are a mess.

digging around and found this:

http://stackoverflow.com/questions/20792975/what-is-the-replacement-for-undocumeneted-windows-kernel-api-kesetaffinitythre

which has no answers. The APIs you really want are only available to
kernel space code.

I also get the impression that if libx265 is compiled for 32bits,
m_winCpuMask should be DWORD.  IE: win64 SetThreadAffinityMask() is
expecting the pointer to reference a DWORD64 but 32bit win32
SetThreadAffinityMask() is expecting a DWORD32.

Hmm.. perhaps we should be using SetThreadGroupAffinity()

-- 
Steve Borho


More information about the x265-devel mailing list