Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenCL 2.2 CTS: can provide spirv10_2015.11.25.zip to non Khronos members? #1

Closed
oscarbg opened this issue May 19, 2017 · 5 comments
Closed
Assignees

Comments

@oscarbg
Copy link

oscarbg commented May 19, 2017

reading OpenCL-CTS/readme-spir-v-binaries.txt says:

To run the 2.2 conformance tests test suite for the C++ features you need need 
SPIR-V binaries.
can be picked from:
https://cvs.khronos.org/svn/repos/OpenCL/trunk/Khronos/spirv/spirv10_2015.11.25.zip

but that link can't be accessed for a non Khronos user so can upload this file?
I say that because txt file also says this:
Alternatively you can check out and build all of the below repositories.
problem is all this links also are to Khronos members and these projects altough exist on github are missing required branches so note I also asked
SPIRV-LLVM (KhronosGroup/SPIRV-LLVM#218)
and
libclcxx (KhronosGroup/libclcxx#15)
projects on github to be updated..

@kepatil
Copy link
Contributor

kepatil commented May 19, 2017

Thanks for looking. This is most likely a remnant from when the CTS was not made public. I'll get it sorted out.

Meanwhile, please try the CTS framework which should be able to locate and download required stuff automatically.

@kepatil kepatil self-assigned this May 19, 2017
@oscarbg
Copy link
Author

oscarbg commented May 19, 2017

thanks @kepatil..
really didn't try to build the CTS yet..
will try the CTS framework but anyway seems SPIRV-LLVM and libclcxx github projects need to be updated for final OpenCL 2.2 compatibility..

@InBetweenNames
Copy link

@oscarbg The CTS framework contains a buildsystem that takes care of all of that for you. Send me a message if you need help setting it up.

kepatil added a commit that referenced this issue Jul 25, 2017
@kepatil
Copy link
Contributor

kepatil commented Jul 25, 2017

I have added the SPIR-V binaries using LFS and updated the readme to point to the new location, in commit 252b514. Closing the issue.

@kepatil kepatil closed this as completed Jul 25, 2017
@oscarbg
Copy link
Author

oscarbg commented Jul 25, 2017

thanks..

BTW seeing your profile you seem to work for Nvidia so sorry but can't resist asking :-) :
I see traces of SPIR-V on AMD OpenCL driver binary so seems it's working on either adding cl_khr_il_program support to their 2.0 driver or adding full 2.1 support..
so question is if NV, that now provides some preview of OCL 2.0 support, can add cl_khr_il_program extension for SPIR-V support on his CL runtime..
anyway also NV working on C++ OpenCL kernel support for his driver would be nice..

karolherbst pushed a commit to karolherbst/OpenCL-CTS that referenced this issue Feb 24, 2018
Merge PR 1: Cl12 cmake fixes

Adds beignet non-ICD compatibility, fixes a type-o in CONFORMNACE_SUFFIX inherited from upstream Khronos repository, and removes the pre-generated Makefiles in favor of the CMake-generated ones.
gwawiork added a commit to gwawiork/OpenCL-CTS that referenced this issue Apr 2, 2020
…ded_subgroups

Fixes for cl_khr_subgroup_non_uniform_vote and cl_khr_subgroup_ballot extensions
yanfeng3721 added a commit to yanfeng3721/OpenCL-CTS that referenced this issue Apr 20, 2022
* Use macOS 10 in CI (KhronosGroup#1282)

macOS jobs frequently fail. Since macos-11.0 support is considered experimental,
move to macos-10, using macos-latest so we automatically move to 11 when
stable.

See https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

Signed-off-by: Kevin Petit <kevin.petit@arm.com>

* Fix double-release of memory objects (KhronosGroup#1277)

A recent update to the object wrapper classes (KhronosGroup#1268) changed the
behavior of assigning to a wrapper, whereby the wrapped object is now
released upon assignment. A couple of tests were manually calling
clReleaseMemObject and then assigning `nullptr` to the wrapper,
resulting in the wrapper calling clReleaseMemObject on an object that
had already been destroyed.

Co-authored-by: Kévin Petit <kpet@free.fr>
Co-authored-by: James Price <jrprice@google.com>
kbenzie added a commit to kbenzie/OpenCL-CTS that referenced this issue Oct 28, 2022
While testing an OpenCL driver with ThreadSanitizer enabled the
OpenCL-CTS suffers from thread leaks in conversions and bruteforce on
posix systems. This is because `pthread_join` is never called in
`ThreadPool_Exit` for the `pthread_t`s created by the thread pool.
Instead, the threads are only informed to stop waiting on the condition
variable which unblocks the worker thread but does not clean up after
itself.

```
ThreadPool: thread 1 exiting.
ThreadPool: thread 5 exiting.
ThreadPool: thread 4 exiting.
ThreadPool: thread 2 exiting.
ThreadPool: thread 7 exiting.
ThreadPool: thread 0 exiting.
ThreadPool: thread 3 exiting.
ThreadPool: thread 6 exiting.
Thread pool exited in a orderly fashion.
==================
WARNING: ThreadSanitizer: thread leak (pid=2292842)
  Thread T9 (tid=2292855, finished) created by main thread at:
    #0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:969 (libtsan.so.0+0x5ad75)
    KhronosGroup#1 ThreadPool_Init() <null> (test_conversions+0x35b2c)
    KhronosGroup#2 pthread_once ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1449 (libtsan.so.0+0x4057c)
    KhronosGroup#3 GetThreadCount() <null> (test_conversions+0x36262)
    KhronosGroup#4 DoTest(_cl_device_id*, Type, Type, SaturationMode, RoundingMode, _MTdata*) [clone .isra.0] <null> (test_conversions+0x10555)
    KhronosGroup#5 test_conversions(_cl_device_id*, _cl_context*, _cl_command_queue*, int) <null> (test_conversions+0x13226)
    KhronosGroup#6 callSingleTestFunction(test_definition, _cl_device_id*, int, int, unsigned long) <null> (test_conversions+0x2e66d)
    KhronosGroup#7 parseAndCallCommandLineTests(int, char const**, _cl_device_id*, int, test_definition*, int, unsigned long, int) <null> (test_conversions+0x2fb3a)
    KhronosGroup#8 runTestHarnessWithCheck(int, char const**, int, test_definition*, int, unsigned long, test_status (*)(_cl_device_id*)) <null> (test_conversions+0x349d8)
    KhronosGroup#9 main <null> (test_conversions+0xd725)

  And 7 more similar thread leaks.

SUMMARY: ThreadSanitizer: thread leak (OpenCL-CTS/buildbin/conversions/test_conversions+0x35b2c) in ThreadPool_Init()
```

This patch adds global state to keep track of the `pthread_t`s created
by `pthread_create` in `ThreadPool_Init`. The list of `pthread_t`s is
then used by `ThreadPool_Exit` to call `pthread_join` to cleanup the
`pthread_t`s correctly.

A near identical example, and additional explanation, can be found on
[stackoverflow](https://stackoverflow.com/questions/72435574/thread-leak-detected-when-using-condition-variable-instead-of-join-with-pthrea).

On the Windows path, a similar change is not necessary because
`_beginthread` is used which automatically cleans up after itself when
the worker thread function returns.
kbenzie added a commit to kbenzie/OpenCL-CTS that referenced this issue Nov 2, 2022
While testing an OpenCL driver with ThreadSanitizer enabled the
OpenCL-CTS suffers from thread leaks in conversions and bruteforce on
posix systems. This is because `pthread_join` is never called in
`ThreadPool_Exit` for the `pthread_t`s created by the thread pool.
Instead, the threads are only informed to stop waiting on the condition
variable which unblocks the worker thread but does not clean up after
itself.

```
ThreadPool: thread 1 exiting.
ThreadPool: thread 5 exiting.
ThreadPool: thread 4 exiting.
ThreadPool: thread 2 exiting.
ThreadPool: thread 7 exiting.
ThreadPool: thread 0 exiting.
ThreadPool: thread 3 exiting.
ThreadPool: thread 6 exiting.
Thread pool exited in a orderly fashion.
==================
WARNING: ThreadSanitizer: thread leak (pid=2292842)
  Thread T9 (tid=2292855, finished) created by main thread at:
    #0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:969 (libtsan.so.0+0x5ad75)
    KhronosGroup#1 ThreadPool_Init() <null> (test_conversions+0x35b2c)
    KhronosGroup#2 pthread_once ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1449 (libtsan.so.0+0x4057c)
    KhronosGroup#3 GetThreadCount() <null> (test_conversions+0x36262)
    KhronosGroup#4 DoTest(_cl_device_id*, Type, Type, SaturationMode, RoundingMode, _MTdata*) [clone .isra.0] <null> (test_conversions+0x10555)
    KhronosGroup#5 test_conversions(_cl_device_id*, _cl_context*, _cl_command_queue*, int) <null> (test_conversions+0x13226)
    KhronosGroup#6 callSingleTestFunction(test_definition, _cl_device_id*, int, int, unsigned long) <null> (test_conversions+0x2e66d)
    KhronosGroup#7 parseAndCallCommandLineTests(int, char const**, _cl_device_id*, int, test_definition*, int, unsigned long, int) <null> (test_conversions+0x2fb3a)
    KhronosGroup#8 runTestHarnessWithCheck(int, char const**, int, test_definition*, int, unsigned long, test_status (*)(_cl_device_id*)) <null> (test_conversions+0x349d8)
    KhronosGroup#9 main <null> (test_conversions+0xd725)

  And 7 more similar thread leaks.

SUMMARY: ThreadSanitizer: thread leak (OpenCL-CTS/buildbin/conversions/test_conversions+0x35b2c) in ThreadPool_Init()
```

This patch adds global state to keep track of the `pthread_t`s created
by `pthread_create` in `ThreadPool_Init`. The list of `pthread_t`s is
then used by `ThreadPool_Exit` to call `pthread_join` to cleanup the
`pthread_t`s correctly.

A near identical example, and additional explanation, can be found on
[stackoverflow](https://stackoverflow.com/questions/72435574/thread-leak-detected-when-using-condition-variable-instead-of-join-with-pthrea).

On the Windows path, a similar change is not necessary because
`_beginthread` is used which automatically cleans up after itself when
the worker thread function returns.
bashbaug pushed a commit that referenced this issue Nov 8, 2022
While testing an OpenCL driver with ThreadSanitizer enabled the
OpenCL-CTS suffers from thread leaks in conversions and bruteforce on
posix systems. This is because `pthread_join` is never called in
`ThreadPool_Exit` for the `pthread_t`s created by the thread pool.
Instead, the threads are only informed to stop waiting on the condition
variable which unblocks the worker thread but does not clean up after
itself.

```
ThreadPool: thread 1 exiting.
ThreadPool: thread 5 exiting.
ThreadPool: thread 4 exiting.
ThreadPool: thread 2 exiting.
ThreadPool: thread 7 exiting.
ThreadPool: thread 0 exiting.
ThreadPool: thread 3 exiting.
ThreadPool: thread 6 exiting.
Thread pool exited in a orderly fashion.
==================
WARNING: ThreadSanitizer: thread leak (pid=2292842)
  Thread T9 (tid=2292855, finished) created by main thread at:
    #0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:969 (libtsan.so.0+0x5ad75)
    #1 ThreadPool_Init() <null> (test_conversions+0x35b2c)
    #2 pthread_once ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1449 (libtsan.so.0+0x4057c)
    #3 GetThreadCount() <null> (test_conversions+0x36262)
    #4 DoTest(_cl_device_id*, Type, Type, SaturationMode, RoundingMode, _MTdata*) [clone .isra.0] <null> (test_conversions+0x10555)
    #5 test_conversions(_cl_device_id*, _cl_context*, _cl_command_queue*, int) <null> (test_conversions+0x13226)
    #6 callSingleTestFunction(test_definition, _cl_device_id*, int, int, unsigned long) <null> (test_conversions+0x2e66d)
    #7 parseAndCallCommandLineTests(int, char const**, _cl_device_id*, int, test_definition*, int, unsigned long, int) <null> (test_conversions+0x2fb3a)
    #8 runTestHarnessWithCheck(int, char const**, int, test_definition*, int, unsigned long, test_status (*)(_cl_device_id*)) <null> (test_conversions+0x349d8)
    #9 main <null> (test_conversions+0xd725)

  And 7 more similar thread leaks.

SUMMARY: ThreadSanitizer: thread leak (OpenCL-CTS/buildbin/conversions/test_conversions+0x35b2c) in ThreadPool_Init()
```

This patch adds global state to keep track of the `pthread_t`s created
by `pthread_create` in `ThreadPool_Init`. The list of `pthread_t`s is
then used by `ThreadPool_Exit` to call `pthread_join` to cleanup the
`pthread_t`s correctly.

A near identical example, and additional explanation, can be found on
[stackoverflow](https://stackoverflow.com/questions/72435574/thread-leak-detected-when-using-condition-variable-instead-of-join-with-pthrea).

On the Windows path, a similar change is not necessary because
`_beginthread` is used which automatically cleans up after itself when
the worker thread function returns.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants