Hi, I'm using OpenCL on Windows 10 and a Radeon RX580 card (8GB VRAM). I tried to allocate two buffers with 4GB to use in a kernel, but at this size, all I get is 0.0. I double checked address bits and it is 64 and there is nothing else running on the card (well, the OS is still running). I also tried to leave a percentage of each buffer free (like 5%) to see if it improved but nothing changed. Can anyone give me a hint please? Thanks
EDIT: Ok, situation is even worse than I though. I allocated three buffers, with 2720145896 bytes each. I then did buffer C = A value + B value (all of them are int*). Buffer B value is always 0 in the kernel, even If I copy manually other values. It looks like a serious driver bug (same kernel works on Intel and Nvidia cards). Btw, using 19.4.1 driver.
Solved! Go to Solution.
I just tested this now with Radeon Software Version 19.6.2 and it works! Glad it got fixed.
PS: Edited the test case to reflect the newest test.
Ok, managed to write a test case. Based on the code of OpenCL-examples/main.cpp at master · Dakkers/OpenCL-examples · GitHub , I wrote a new version with my exact problem. Running as is gives the wrong results, smaller buffers work though.
#include <CL/cl.hpp>
#include <cassert>
#include <iostream>
#include <vector>int main() {
std::vector<cl::Platform> platforms;
cl::Platform::get(&platforms); if (platforms.size() == 0) {
std::cout << " No platforms found. Check OpenCL installation!\n";
return 1;
} cl::Platform defaultPlatform = platforms[0];
std::cout << "Using platform: " << defaultPlatform.getInfo<CL_PLATFORM_NAME>()
<< "\n"; std::cout << "Getting devices..."; std::vector<cl::Device> devices;
defaultPlatform.getDevices(CL_DEVICE_TYPE_ALL, &devices);
if (devices.size() == 0) {
std::cout << " No devices found. Check OpenCL installation!\n";
return 1;
} std::cout << "Done!" << std::endl; for (std::size_t i = 0; i < devices.size(); ++i) {
std::cout << "Device " << i << " - " << devices.getInfo<CL_DEVICE_NAME>() << std::endl;
} cl::Device defaultDevice = devices[0];
std::cout << "Using device: " << defaultDevice.getInfo<CL_DEVICE_NAME>() << "\n"; std::cout << "Creating context..."; cl::Context context({ defaultDevice }); std::cout << "Done!" << std::endl; cl::Program::Sources sources;
const std::string kernelSource =
"void kernel sumBuffers(global const unsigned long* A, "
" global const unsigned long* B, global unsigned long* C) {\n"
"\n"
" unsigned long taskIndex = get_global_id(0);\n"
" C[taskIndex] = A[taskIndex] + B[taskIndex];\n"
"}"; std::cout << "Building kernel..."; sources.push_back({ kernelSource.c_str(), kernelSource.length() });
cl::Program program(context, sources);
if (program.build({ defaultDevice }) != CL_SUCCESS) {
std::cout << "Error building: "
<< program.getBuildInfo<CL_PROGRAM_BUILD_LOG>(defaultDevice)
<< std::endl;
exit(1);
} std::cout << "Done!" << std::endl; const std::size_t totalBytes = 2600000000;
std::cout << "Buffer bytes: " << (totalBytes / 1e6) << " MB" << std::endl;
const std::size_t totalSize = totalBytes / sizeof(std::size_t);
std::vector<std::size_t> numbers(totalSize, 0);
for (std::size_t i = 0; i < totalSize; ++i)
numbers = static_cast<cl_ulong>(i); std::cout << "Allocating buffers..."; cl::Buffer bufferA(context, CL_MEM_READ_ONLY | CL_MEM_ALLOC_HOST_PTR, sizeof(std::size_t) * totalSize, nullptr);
std::cout << "A done! ";
cl::Buffer bufferB(context, CL_MEM_READ_ONLY | CL_MEM_ALLOC_HOST_PTR, sizeof(std::size_t) * totalSize, nullptr);
std::cout << "B done! ";
cl::Buffer bufferC(context, CL_MEM_WRITE_ONLY | CL_MEM_ALLOC_HOST_PTR, sizeof(std::size_t) * totalSize, nullptr); std::cout << "Done! Allocated " << (3 * (totalBytes / 1e6)) << " MB of buffers!" << std::endl;
std::cout << "Running..."; cl::CommandQueue queue(context, defaultDevice);
queue.enqueueWriteBuffer(bufferA, CL_TRUE, 0, sizeof(std::size_t) * totalSize, numbers.data());
queue.enqueueWriteBuffer(bufferB, CL_TRUE, 0, sizeof(std::size_t) * totalSize, numbers.data()); cl::Kernel sumBuffers(program, "sumBuffers");
sumBuffers.setArg(0, bufferA);
sumBuffers.setArg(1, bufferB);
sumBuffers.setArg(2, bufferC); queue.enqueueNDRangeKernel(sumBuffers, 0, totalSize, 32); std::cout << "Done!" << std::endl;
std::cout << "Verifying results..."; queue.enqueueReadBuffer(bufferC, CL_TRUE, 0, sizeof(std::size_t) * totalSize, numbers.data());
for (std::size_t i = 0; i < totalSize; ++i) {
if (numbers != i * 2) {
std::cout << "Verification failed! result #" << i << ", " <<
numbers << " != " << (i * 2) << " (expected)." << std::endl; return 0;
}
} std::cout << "Good! First 10 numbers: " << std::endl;
for (std::size_t i = 0; i < 10; ++i) {
std::cout << numbers << std::endl;
} return 0;
}
Looks like buffer allocation is failing when buffer size is large (may be greater than the predefined limits). Please check the error code during buffer allocation.
Also, please check the clinfo output to know the memory limits. For example, check the parameters like: "Max memory allocation", "Global memory size", "Constant buffer size" etc. These limits also can be queried using clGetDeviceInfo API with appropriate parameter name.
By the way, could you please share the clinfo output?
Thanks
dipak wrote:
Looks like buffer allocation is failing when buffer size is large (may be greater than the predefined limits). Please check the error code during buffer allocation.
Also, please check the clinfo output to know the memory limits. For example, check the parameters like: "Max memory allocation", "Global memory size", "Constant buffer size" etc. These limits also can be queried using clGetDeviceInfo API with appropriate parameter name.
By the way, could you please share the clinfo output?
Thanks
Sure, there you go:
Number of platforms 2
Platform Name AMD Accelerated Parallel Processing
Platform Vendor Advanced Micro Devices, Inc.
Platform Version OpenCL 2.1 AMD-APP (2766.5)
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_amd_event_callback cl_amd_offline_devices
Platform Host timer resolution 100ns
Platform Extensions function suffix AMD
Platform Name AMD Accelerated Parallel Processing
Platform Vendor Advanced Micro Devices, Inc.
Platform Version OpenCL 2.1 AMD-APP (2766.5)
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_amd_event_callback cl_amd_offline_devices
Platform Host timer resolution 100ns
Platform Extensions function suffix AMD
Platform Name AMD Accelerated Parallel Processing
Number of devices 1
Device Name Ellesmere
Device Vendor Advanced Micro Devices, Inc.
Device Vendor ID 0x1002
Device Version OpenCL 2.0 AMD-APP (2766.5)
Driver Version 2766.5
Device OpenCL C Version OpenCL C 2.0
Device Type GPU
Device Board Name (AMD) Radeon RX 580 Series
Device Topology (AMD) PCI-E, 01:00.0
Device Profile FULL_PROFILE
Device Available Yes
Compiler Available Yes
Linker Available Yes
Max compute units 36
SIMD per compute unit (AMD) 4
SIMD width (AMD) 16
SIMD instruction width (AMD) 1
Max clock frequency 1366MHz
Graphics IP (AMD) 8.0
Device Partition (core)
Max number of sub-devices 36
Supported partition types None
Supported affinity domains (n/a)
Max work item dimensions 3
Max work item sizes 1024x1024x1024
Max work group size 256
Preferred work group size (AMD) 256
Max work group size (AMD) 1024
Preferred work group size multiple 64
Wavefront width (AMD) 64
Preferred / native vector sizes
char 4 / 4
short 2 / 2
int 1 / 1
long 1 / 1
half 1 / 1 (cl_khr_fp16)
float 1 / 1
double 1 / 1 (cl_khr_fp64)
Half-precision Floating-point support (cl_khr_fp16)
Denormals No
Infinity and NANs No
Round to nearest No
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add No
Support is emulated in software No
Single-precision Floating-point support (core)
Denormals No
Infinity and NANs Yes
Round to nearest Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add Yes
Support is emulated in software No
Correctly-rounded divide and sqrt operations Yes
Double-precision Floating-point support (cl_khr_fp64)
Denormals Yes
Infinity and NANs Yes
Round to nearest Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add Yes
Support is emulated in software No
Address bits 64, Little-Endian
Global memory size 8589934592 (8GiB)
Global free memory (AMD) 8337577 (7.951GiB)
Global memory channels (AMD) 8
Global memory banks per channel (AMD) 16
Global memory bank width (AMD) 256 bytes
Error Correction support No
Max memory allocation 4244635648 (3.953GiB)
Unified memory for Host and Device No
Shared Virtual Memory (SVM) capabilities (core)
Coarse-grained buffer sharing Yes
Fine-grained buffer sharing Yes
Fine-grained system sharing No
Atomics No
Minimum alignment for any data type 128 bytes
Alignment of base address 2048 bits (256 bytes)
Preferred alignment for atomics
SVM 0 bytes
Global 0 bytes
Local 0 bytes
Max size for global variable 3820172032 (3.558GiB)
Preferred total size of global vars 8589934592 (8GiB)
Global Memory cache type Read/Write
Global Memory cache size 16384 (16KiB)
Global Memory cache line size 64 bytes
Image support Yes
Max number of samplers per kernel 16
Max size for 1D images from buffer 134217728 pixels
Max 1D or 2D image array size 2048 images
Base address alignment for 2D image buffers 256 bytes
Pitch alignment for 2D image buffers 256 pixels
Max 2D image size 16384x16384 pixels
Max 3D image size 2048x2048x2048 pixels
Max number of read image args 128
Max number of write image args 64
Max number of read/write image args 64
Max number of pipe args 16
Max active pipe reservations 16
Max pipe packet size 4244635648 (3.953GiB)
Local memory type Local
Local memory size 32768 (32KiB)
Local memory syze per CU (AMD) 65536 (64KiB)
Local memory banks (AMD) 32
Max number of constant args 8
Max constant buffer size 4244635648 (3.953GiB)
Preferred constant buffer size (AMD) 16384 (16KiB)
Max size of kernel argument 1024
Queue properties (on host)
Out-of-order execution No
Profiling Yes
Queue properties (on device)
Out-of-order execution Yes
Profiling Yes
Preferred size 262144 (256KiB)
Max size 8388608 (8MiB)
Max queues on device 1
Max events on device 1024
Prefer user sync for interop Yes
Profiling timer resolution 1ns
Profiling timer offset since Epoch (AMD) 1555853844300732100ns (Sun Apr 21 10:37:24 2019)
Execution capabilities
Run OpenCL kernels Yes
Run native kernels No
Thread trace supported (AMD) Yes
Number of async queues (AMD) 2
Max real-time compute queues (AMD) 2
Max real-time compute units (AMD) 8
SPIR versions 1.2
printf() buffer size 4194304 (4MiB)
Built-in kernels (n/a)
Device Extensions cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_gl_sharing cl_khr_gl_depth_images cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_spir cl_khr_subgroups cl_khr_gl_event cl_khr_depth_images cl_khr_mipmap_image cl_khr_mipmap_image_writes cl_amd_liquid_flash cl_amd_planar_yuv
About the buffers, In my code I checked them and no errors were reported. This code I pasted was just a small reproducible test case. Also, my code takes into account the max memory and allocation sizes.
Yes, as per the clinfo output, the memory limits don't seem to be a problem here. I ran the above code on my Carrizo laptop with 19.4.1 and it worked fine. In my case, some of the memory limits are even lower than yours.
One point to note though. In the above example, global work size (i.e. 680036474) is not evenly divisible by local work group size (i.e. 32). It is a restriction in OpenCL 1.2 but not in OpenCL 2.0. So please ensure that you are using the headers and runtime accordingly.
Thanks.
By the way, if you have identified any API or a code block that does not seem be working as expected, please let us know. It would be helpful to report the problem.
Thanks.
Yeah, the example also works in two other cards of mine (Geforce ones, running on OpenCL 1.2). On my real code, the execution is also multiple of the workgroup size, but that didn't change anything. The feature that isn't working as expected is exactly this code. The buffer B (or A maybe), doesn't show as anything other than 0. And this code was only reproductible on the RX580. I tried 3 different drivers and nothing worked. I still believe this is a bug in the driver.
Thank you for share the above information. Yes, the issue might be specific to that setup. Because, as I said earlier, the same code worked fine with 19.4.1 on my Carrizo laptop. I will report it to concerned team. However I need below additional information.
1. Did you try any other AMD card? If yes, please share your observation and the setup information.
Also please mention the OpenCL SDK that you are using.
2. If the code is working fine for any other condition such as smaller buffer size etc., please share the details.
3.
You said "The buffer B (or A maybe), doesn't show as anything other than 0. "
Where did you check the values - inside kernel or after enqueueWriteBuffer call?
I would suggest you to put some debugging code around the OpenCL APIs and see if you can identify any problematic code region (for example, values of buffer B is OKAY after enqueueWriteBuffer but it may WRONG inside the enqueueNDRangeKernel )
4. From clinfo output, I see two platforms are there. If possible, please remove any non-AMD platform and test it again.
Btw, I hope you download the driver from here: https://www.amd.com/en/support/graphics/radeon-500-series/radeon-rx-500x-series/radeon-rx-580x
Thanks.
Sorry for not replying early, I'm just really busy at work these days.
1) Haven't tried another AMD card, only NVIDIA and Intel ones (I don't have another one to test with).
2) The code works fine if I pick buffers waaaay smaller than maximum allocation size, like 1GB ones.
3) I checked the values after the kernel execution, with the kernel result. Both buffers A and B are the same, so C should have the sum of them, but it only contains a single value (which is either from A or from B). Like I said, with smaller buffers, everything Just Works.
4) I have only one platform. I have no idea why clinfo picked two.
Yes, I downloaded the driver from official AMD page.
Thank you for the above inputs. I'll report it to the concerned team.
Thanks.
Thank you for your patience. From the concerned team's feedback, the above issue seems to be due to an OS limitation that causes an error before submitting the kernel. Below is the detailed feedback shared by the team.
"The error observed is an OS limitation. Win10 doesn't allow for more than half of host memory to be resident. This limitation is applied to the entire system, not just the currently running process, since the allocated memory is not page-able. Because of this, we have no reliable way to determine how much host memory we are allowed to allocate, so our recommendation for now is to manually limit the size of the allocations (e.g. with 16GB of RAM to not allocate more than 8GB). In future we should properly propagate the errors, since currently during clEnqueueNDRangeKernel we encounter an error before submitting the kernel, so we quit the dispatch. This way the user will know an error happened in the OpenCL runtime instead of observing wrong kernel results."
Thanks.
That doesn't make sense at all. I allocated 3 buffers with 2GB each. My total system memory is 16GB, and 6GB isn't even half of that. Also, that code works with other vendor cards so it shouldn't be a OS limitation.
Hi,
There a 2 things in my mind:
1. set the environment variables properly! By default it is not allowed to eat all the ram. Here are some helpful info -> https://forum.ethereum.org/discussion/15917/claymores-miner-environment-variables
So the allocation percent values must be 100. And for you, the 64bit ptr is important as well.
2. if you are going to access more than 2GB ram randomly(*) in your kernel, you should also tweak the "GPU load" settings in the Radeon Settings application -> change it from "graphics" to "compute"!
* for large sequential memory accesses, both options are good.
I just tested this now with Radeon Software Version 19.6.2 and it works! Glad it got fixed.
PS: Edited the test case to reflect the newest test.
Thank you for the confirmation.