[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