Basic gpu test failed in ubuntu 16.04 [AMD memory caps] #167
Comments
|
Thanks for reporting. We will have a look and get back to you ASAP |
|
The log of clinfo is as follows, [Number of platforms: 1 Platform Name: AMD Accelerated Parallel Processing |
|
Hi @GauthamPughaz, I can see where in the code that this error is being thrown from, but I don't really understand why. If you don't mind, it might be useful to try the more simple tests from the SDK we maintain: https://github.com/codeplaysoftware/computecpp-sdk mkdir build && cd build
cmake ../samples -DCOMPUTECPP_PACKAGE_ROOT_DIR=/path/to/computecpp/install
make -j4
ctestIt'd be really helpful to us if you did have a look at this, though I appreciate it's a pain when things don't "just work". |
|
Yea I have done what you said. The log for that is, gautham@gautham-dell:~/computecpp-sdk/build$ ctest 5% tests passed, 20 tests failed out of 21 Total Test time (real) = 2.34 sec The following tests FAILED: |
|
Hi @GauthamPughaz, thanks for that. It looks like nothing that uses SYCL is working which is quite confusing! I'd really appreciate it if you could try the following code to see what the underlying error is: #include <CL/sycl.hpp>
#include <iostream>
int main() {
try {
cl::sycl::queue q;
} catch(cl::sycl::cl_exception& e) {
std::cout << e.what() << "\n";
std::cout << "Error: " << e.get_cl_error() << ": " << e.get_cl_error_message();
}
return 0;
}This should print out exactly what error code is being returned by the clCreateCommandQueue() function. It is very rare for this to fail, so I'd be very interested to know what's going on! Many thanks, EDIT: I've added the missing SYCL header, because I foolishly forgot it! |
|
Sorry for this question. How and where to run this as this requires sycl.hpp header file. |
|
Whoops, you're right! I think the easiest thing would be to edit one of the samples in the SDK, such that the body of the code is replaced with that - the hello world sample is very simple. I've included a patch that you could apply to the SDK. Simply copy the contents to a file in the root of the directory, then: git apply testing-queues.patch
cd build
make hello_world
hello_world/hello_worldI've actually compiled and run it this time, though it passes without error for me! Sorry for getting that wrong earlier. diff --git a/samples/hello_world/hello_world.cpp b/samples/hello_world/hello_world.cpp
index 2f65f49..20e8fa8 100644
--- a/samples/hello_world/hello_world.cpp
+++ b/samples/hello_world/hello_world.cpp
@@ -34,42 +34,11 @@
* (as determined by the SYCL implementation) whose only function is to
* output the canonical "hello world" string. */
int main() {
- /* Selectors determine which device kernels will be dispatched to.
- * Try using a host_selector, too! */
- cl::sycl::default_selector selector;
-
- /* Queues are used to enqueue work.
- * In this case we construct the queue using the selector. Users can create
- * their own selectors to choose whatever kind of device they might need. */
- cl::sycl::queue myQueue(selector);
- std::cout << "Running on "
- << myQueue.get_device().get_info<cl::sycl::info::device::name>()
- << "\n";
-
- /* C++ 11 lambda functions can be used to submit work to the queue.
- * They set up data transfers, kernel compilation and the actual
- * kernel execution. This submission has no data, only a "stream" object.
- * Useful in debugging, it is a lot like an std::ostream. The handler
- * object is used to control the scope certain operations can be done. */
- myQueue.submit([&](cl::sycl::handler& cgh) {
- /* The stream object allows output to be generated from the kernel. It
- * takes three parameters in its constructor. The first is the maximum
- * output size in bytes, the second is how large [in bytes] the total
- * output of any single << chain can be, and the third is the cgh,
- * ensuring it can only be constructed inside a submit() call. */
- cl::sycl::stream os(1024, 80, cgh);
-
- /* single_task is the simplest way of executing a kernel on a
- * SYCL device. A single thread executes the code inside the kernel
- * lambda. The template parameter needs to be a unique name that
- * the runtime can use to identify the kernel (since lambdas have
- * no accessible name). */
- cgh.single_task<class hello_world>([=]() {
- /* We use the stream operator on the stream object we created above
- * to print to stdout from the device. */
- os << "Hello, World!\n";
- });
- });
-
+ try {
+ cl::sycl::queue q;
+ } catch(cl::sycl::cl_exception& e) {
+ std::cout << e.what() << "\n";
+ std::cout << "Error: " << e.get_cl_code() << ": " << e.get_cl_error_message();
+ }
return 0;
} |
|
Got it, the log is shown below. terminate called after throwing an instance of 'cl::sycl::cl_exception' |
|
Is this sufficient? |
|
Hi, sorry for not responding. This is a really bizarre error which doesn't make a lot of sense to me. There is barely any ComputeCpp code running at this point when the program crashes. Are you running in some kind of virtual environment, like a docker container, or something else maybe? |
|
No, not anything like that. Is there any other way to debug this?. |
|
My /usr/local/computecpp/ directory contains the following folders |
|
I repeated the process from step one and I checked it with a test, it failed again. The log for that fail of basic gpu test. |
|
I'm sorry I'm being slow on this, it is just that this is rather tricky to debug. What this is saying is that the queue creation part of ComputeCpp is failing, but this is a very simple, basic operation. Could you try this modified patch again on the SDK to see if there's a difference in output? After this the only thing I can think to try is plain OpenCL code. The difference here is that I've asked it to use a default selector. The behaviour ideally should be the same but it looks like it might be slightly different - I guess we can see what happens. Thanks for sticking with this! diff --git a/samples/hello_world/hello_world.cpp b/samples/hello_world/hello_world.cpp
index 2f65f49..20e8fa8 100644
--- a/samples/hello_world/hello_world.cpp
+++ b/samples/hello_world/hello_world.cpp
@@ -34,42 +34,12 @@
* (as determined by the SYCL implementation) whose only function is to
* output the canonical "hello world" string. */
int main() {
- /* Selectors determine which device kernels will be dispatched to.
- * Try using a host_selector, too! */
- cl::sycl::default_selector selector;
-
- /* Queues are used to enqueue work.
- * In this case we construct the queue using the selector. Users can create
- * their own selectors to choose whatever kind of device they might need. */
- cl::sycl::queue myQueue(selector);
- std::cout << "Running on "
- << myQueue.get_device().get_info<cl::sycl::info::device::name>()
- << "\n";
-
- /* C++ 11 lambda functions can be used to submit work to the queue.
- * They set up data transfers, kernel compilation and the actual
- * kernel execution. This submission has no data, only a "stream" object.
- * Useful in debugging, it is a lot like an std::ostream. The handler
- * object is used to control the scope certain operations can be done. */
- myQueue.submit([&](cl::sycl::handler& cgh) {
- /* The stream object allows output to be generated from the kernel. It
- * takes three parameters in its constructor. The first is the maximum
- * output size in bytes, the second is how large [in bytes] the total
- * output of any single << chain can be, and the third is the cgh,
- * ensuring it can only be constructed inside a submit() call. */
- cl::sycl::stream os(1024, 80, cgh);
-
- /* single_task is the simplest way of executing a kernel on a
- * SYCL device. A single thread executes the code inside the kernel
- * lambda. The template parameter needs to be a unique name that
- * the runtime can use to identify the kernel (since lambdas have
- * no accessible name). */
- cgh.single_task<class hello_world>([=]() {
- /* We use the stream operator on the stream object we created above
- * to print to stdout from the device. */
- os << "Hello, World!\n";
- });
- });
-
+ try {
+ cl::sycl::default_selector ds;
+ cl::sycl::queue q(ds);
+ } catch(cl::sycl::cl_exception& e) {
+ std::cout << e.what() << "\n";
+ std::cout << "Error: " << e.get_cl_code() << ": " << e.get_cl_error_message();
+ }
return 0;
} |
|
terminate called after throwing an instance of 'cl::sycl::cl_exception' |
|
While building in my second attempt, out of 300 tests only 47 passed. |
|
OK. I don't understand what's happening here. This is the function that's failing: https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/clGetPlatformIDs.html I suppose I should explain a little. ComputeCpp discovers all the different OpenCL platforms available on the system through this function. If it doesn't work... there's nothing we can do. Are you sure you have installed a driver on your system that is properly supported on your hardware? I had a look at the available driver downloads for your hardware, and the only one available is the (now rather old) Crimson driver. AMD GPUPRO supports some mobile chips (like the R9 M300 series for example) but not the R9 M200 cards. ComputeCpp requires OpenCL 1.2 and OpenCL SPIR 1.2 to run - if your system can't support that, we can't run. (This would explain why so many tests fail - those that attempt to instantiate any kind of device or queue will fail rapidly.) |
|
Ok, thank you so much. One final query, is the command export COMPUTE=:0 required for my setup, since it was listed for ubuntu 14.04 and not for 16.04. |
|
It's one GPU. The M265X is, to some greater or lesser extent, a rebranded 8850M, from what I can tell. Export COMPUTE=:0 means "use the first device on the system". If you don't have any other devices, it shouldn't change anything. (@lukeiwanski might be able to add more on that point.) |
|
@GauthamPughaz no you don't need |
|
Ok, thank you. |
|
Any update on this? I'm facing exactly the same issue with ComputeCpp 0.3.3 (tried both dev/eigen_mehdi and dev/amd_gpu branches). The output from clinfo is: Number of platforms: 1 Platform Name: AMD Accelerated Parallel Processing and the one from computecpp_info: ComputeCpp Info (CE 0.3.3) Toolchain information: GLIBC version: 2.23 Device Info: Discovered 1 devices matching: Device 0: Device is supported : UNTESTED - Vendor not tested on this OS If you encounter problems when using any of these OpenCL devices, please consult I've also run a simple test compiled from https://laanwj.github.io/assets/2016/05/06/opencl-ubuntu1604/devices.c and the output is:
I would be more than happy to help finding a solution. |
|
I've also tried with the hello_world example above, and the output is just: Error: [ComputeCpp:RT0407] Failed to create OpenCL command queue After some tests I found out that the clCreateCommandQueue call fails with error code CL_OUT_OF_HOST_MEMORY |
|
Hi @davide-maestroni , As the documentation on this page suggests, a general failure to allocate resources on the host is what causes CL_OUT_OF_HOST_MEMORY. Quick Googling returns some information, if not fixes: |
|
Thanks @DuncanMcBain, I actually had the same suspect, that is the issue was related to the AMD drivers. I was just hoping you had a better understanding of the problem. I also filed an issue to the Codeplay guys. Let's see what they have to say. |
|
I am a Codeplay guy! I'm sorry, I should have answered there as well, but thought it better to leave it on a public forum. In short: I'm the one who answers those issues too, and I still have no idea 😄 While AMD are pushing their RoCM and Hipify technologies, I think it would be beneficial if they still supported OpenCL on a variety of hardware. Unfortunately, the only Mxxx AMD hardware we have in the company is an older chip, too old to use the new drivers (I tried, it doesn't boot if you use them). Would you be able to pass on this program to AMD? I might be able to attach a plain OpenCL program that creates a queue in the same way if they want an OpenCL repro case (I'd be surprised if this were an artifact of the way that ComputeCpp was doing things). You could try this: https://github.com/HandsOnOpenCL/Exercises-Solutions. It should work "out of the box" and also fail in the same way! |
|
@davide-maestroni (and @GauthamPughaz) if you read the second of those links you see there's an alleged solution. I suppose computecpp should have no problems exporting EDIT: https://bugs.freedesktop.org/show_bug.cgi?id=102491#c5 |
lukeiwanski
changed the title
|
@GauthamPughaz is that still an issue? or can it be closed? |
|
On Fri, 9 Mar 2018 at 4:19 AM, Luke Iwanski ***@***.***> wrote:
@GauthamPughaz <https://github.com/gauthampughaz> is that still an issue?
or can it be closed?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#167 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AK2b5j4tVa7IIfQyGlufFvRVyfWq_0TKks5tcbWTgaJpZM4Pz_sM>
.
Hi Lukeiwanaki,
Its still an issue and I didn’t get any solutions so far when I searched
for it.
|
|
.... Did you read/try what I posted? |
|
@mirh The solution from your post really works, thanks a lot ! For people who didn't read it: Add this to your ~/.bashrc file: |
When I run the following command
bazel test -c opt --config=sycl --test_output=all //tensorflow/python/kernel_tests:basic_gpu_test
the following log is displayed,
And my computecpp_info result is as follows,
ComputeCpp Info (CE 0.3.2)
Toolchain information:
GLIBC version: 2.23
GLIBCXX: 20160609
This version of libstdc++ is supported.
Device Info:
Discovered 1 devices matching:
platform :
device type :
Device 0:
Device is supported : UNTESTED - Vendor not tested on this OS
CL_DEVICE_NAME : Capeverde
CL_DEVICE_VENDOR : Advanced Micro Devices, Inc.
CL_DRIVER_VERSION : 2442.7
CL_DEVICE_TYPE : CL_DEVICE_TYPE_GPU
If you encounter problems when using any of these OpenCL devices, please consult
this website for known issues:
https://computecpp.codeplay.com/releases/v0.3.2/platform-support-notes
I don't know where it is going wrong.
The text was updated successfully, but these errors were encountered: