progtx / sycl-gtx Goto Github PK

In README.md, the link to sycl.tech is malformed, resulting in a GitHub 404.

The specification requires host fallback when there is no OpenCL device available. I see some options how this may be implemented, however I believe it would take a lot of work.

What needs to be done:

• Partitioning of work-groups
  • Work-item synchronization
• Computing inside data reference
  • Would first require #2 to be implemented
  • This computation does not always have to occur, but how to achieve that?
• Other hidden features ...

Control flow macros (e.g. SYCL_THEN) cause unwanted indentation of the code after being used. This is an issue in Visual Studio, I don't know about other IDEs.

This would require carrying type information in the data reference class, most likely a template parameter.

e.g. prevent int3 * int8 from being valid.

At the moment, this would only cause an error on kernel compilation (during SYCL runtime), but it would be preferable to cause an error at C++ compile time.

I have built SYCL-GTX in my machine, but all tests that need to create queue by cl::sycl::queue myQueue or cl::sycl::queue myQueue(device_selector) throw cl::sycl::exception.
Then, I catch the exception in try {} catch{}, the result is SYCL_ERROR_CODE_DOES_NOT_EXIST. I am pretty sure the problem is due to the creation of cl::sycl::queue.
I go through the source code of queue.h and queue.cpp, found all constructors of queue require to create context firstly, so I try to print messages using debug() in the constructors of context, but I did not see any message output in terminal except the same error.

If I try to create queue using queue myQueue(), it even can not pass the compilation. the error was reported as there are no member function of queue.

Besides, I also tried to compile those test source codes directly by GCC and repeated the above procedures. All of them passed compilation, but they give the same error when executing.

Maybe the problem occurs when linking libsycl-gtx.a with libOpenCL.so? Or I made some mistakes when installing SCYL-GTX even though I did not see any error when installing it? Or it may because the compatibility of OpenCL version and GCC version?

my test environment is:
GCC: 7.5.0
OS: Ubuntu 18.04
OpenCL version: 3.0 (Actually, libOpenCL.so was built when I built DPC++ from source code, so its version is quite late.)

Get rid of the command_group class.
Already started with the introduction of the handler class: efeb82e

Entire SYCL runtime needs to be made thread-safe. I haven't done any testing, but I am certain that multiple threads would cause problems.

Much of the work on synchronization (#13) between command groups (latest commit 654ed42) didn't produce the expected results, as due to a lack of understanding, kernels weren't launched asynchronously, so synchronization did not help.

I wanted to do this with OoO queue execution, but I don't think I can really on that, as the OpenCL implementation is apparently optional. A better course of action seems to be to use a different queue for each command group. In most cases one command group contains one kernel, so this ensures asynchronous execution. What we then also need is synchronization between command groups, which is already in pretty good condition.

According to final specification (2015-05-08):
2.5.6 Error handling
3.3.5.3 Queue error handling
3.4.2.2 Buffer Synchronization Rules
3.4.3.2 Image Synchronization Rules
3.6.1 Error Handling Rules

Already mentioned in #6

Parts to implement per §2.5.5:

• ⚠️ Buffer destruction
  • ✅ Wait on events in destructor
  • 🔴 #9, copying, smart pointers
• ✅ Accessor construction
  • ✅ Device accessors
    • Through #14
  • ✅ Host accessors
• ✅ Command group enqueue
  • #14
• ⚠️ Interaction with OpenCL synchronization operations
  • I'm not sure what this is supposed to entail with regard to buffer and image. Maybe mutex?
  • ⚠️ handler_event from queue.
• ✅ Queue destruction
• ⚠️ Context destruction
  • Not high priority, problems with copies and moves.
• ⚠️ SYCL event objects
  • 🔴 #9

When running test3 (latest commit de86da8) with size of the square matrices (N) above 1024x1024 an exception is thrown.

Tested on Windows 8.1 using Visual Studio 2013.

Default device information (as defined in da381e4):
Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
OpenCL C 1.2
FULL_PROFILE
OpenCL 1.2 (Build 76413)
3.0.1.10878

Example exception when debugging:
Unhandled exception at 0x57F1EEFB (cpu_device32.dll) in sycl-gtx.exe: 0xC0000005: Access violation writing location 0x07E10040.

At the same time Output Window contains:
'CPU Runtime': Failed to enable the low-fragmentation heap with LastError 87. If running from debugger you need to set environment variable _NO_DEBUG_HEAP=1

However, setting _NO_DEBUG_HEAP=1 is not the solution.

Hi Peter,

I found it takes more time when compiling an OpenCL program using clCompileProgram() and clLinkProgram() separately compared to only using clBuildProgram().

Are there some reasons to use the two-step compilation, not the one-step compilation, when building an OpenCL program in SYCL-GTX?

Any response would be appreciated a lot!

Param traits need to be completely reworked in order to support the new info enums.

I try to install sycl-gtx, I read your Readme.md file, but in this file you don't provide any explanation about the installation steps.

I execute the following commands:
mkdir build
cmake ..
This is th output of cmake:
rokiatou@rokiatou:~/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build$ cmake ..
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Found OpenMP: -fopenmp
-- Configuring done
-- Generating done
-- Build files have been written to: /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build

I can see, the commande
find_package(OpenCL REQUIRED)
at line 11 of CMakelist.txt is not executed, so OpenCL was not located.
My OpenCL headers and libs are in /usr/local/cuda/
I have not any problem to compile and execute a OpenCL projects.

After running cmake, I run make, this is the output:

rokiatou@rokiatou:~/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build$ make VERBOSE=1
/usr/local/bin/cmake -H/home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master -B/home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build/CMakeFiles /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build' make -f sycl-gtx/CMakeFiles/sycl-gtx.dir/build.make sycl-gtx/CMakeFiles/sycl-gtx.dir/depend make[2]: Entering directory /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build'
cd /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/sycl-gtx /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build/sycl-gtx /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build/sycl-gtx/CMakeFiles/sycl-gtx.dir/DependInfo.cmake --color=
make[2]: Leaving directory /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build' make -f sycl-gtx/CMakeFiles/sycl-gtx.dir/build.make sycl-gtx/CMakeFiles/sycl-gtx.dir/build make[2]: Entering directory /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build'
[ 2%] Building CXX object sycl-gtx/CMakeFiles/sycl-gtx.dir/source/device_selector.cpp.o
cd /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build/sycl-gtx && /usr/bin/c++ -I/home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/sycl-gtx/sycl-gtx -I/home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/sycl-gtx/include -std=gnu++11 -o CMakeFiles/sycl-gtx.dir/source/device_selector.cpp.o -c /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/sycl-gtx/source/device_selector.cpp
In file included from /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/sycl-gtx/include/SYCL/device_selector.h:5:0,
from /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/sycl-gtx/source/device_selector.cpp:1:
/home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/sycl-gtx/include/SYCL/info.h:6:19: fatal error: CL/cl.h: No such file or directory
#include <CL/cl.h>
^
compilation terminated.
make[2]: *** [sycl-gtx/CMakeFiles/sycl-gtx.dir/source/device_selector.cpp.o] Error 1
make[2]: Leaving directory /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build' make[1]: *** [sycl-gtx/CMakeFiles/sycl-gtx.dir/all] Error 2 make[1]: Leaving directory /home/rokiatou/Documents/Thèse/sycl_kronos/different_implementation_of_sycl/sycl-gtx-master/build'
make: *** [all] Error 2

I started by using the default compiler on my machine (gcc 4.8), however it doesn't support the -fdiagnostics-color option:
Scanning dependencies of target sycl-gtx [ 3%] Building CXX object sycl-gtx/CMakeFiles/sycl-gtx.dir/source/context.cpp.o c++: error: unrecognized command line option ‘-fdiagnostics-color’
I then switched to clang 3.6, but I ended up with the following error:
sycl-gtx/sycl-gtx/include/CL/detail/debug.h:90:12: error: call to deleted constructor of 'debug' return debug("SYCL warning: ", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sycl-gtx/sycl-gtx/include/CL/detail/debug.h:60:3: note: 'debug' has been explicitly marked deleted here debug(const debug& copy) = delete;
I then switched back to gcc, after to commenting out the offending option in color_diagnostics.cmake, but ended up with another instance of the deleted constructor error:
sycl-gtx/sycl-gtx/source/command_group.cpp: In member function ‘void cl::sycl::detail::command_group::flush(cl::sycl::vector_class<_cl_event*>)’: sycl-gtx/sycl-gtx/source/command_group.cpp:102:22: error: use of deleted function ‘debug::debug(debug&&)’ auto d = debug(); ^ In file included from sycl-gtx/sycl-gtx/include/CL/access.h:3:0, from sycl-gtx/sycl-gtx/include/CL/command_group.h:5, from sycl-gtx/sycl-gtx/source/command_group.cpp:1: sycl-gtx/sycl-gtx/include/CL/detail/debug.h:58:3: note: ‘debug::debug(debug&&)’ is implicitly deleted because the default definition would be ill-formed: debug(debug&& move) = default;

In accordance with the final specification

Separating the build command into compile and link in 063cc7e caused the operation order to be invalid - buffers were only initialized after the kernel arguments have been set. This lead to segfaults.

Copying buffer should not block as done in fa7f1ad (related issue #1). Instead, enqueuing a buffer copy needs to set up events and the runtime needs to check for these events if the operation is complete. The specification is clear on when the checks need to occur (§2.5.5 Synchronization).