[Bf-cycles] Opencl on AMD GPUs

[Nazim Mer]

Dear Blenderheads,
Hope all is well.
i got someone to have a look at cycles from the AMD developer forum.
THIS IS WHAT THEY DID:
Source:(http://devgurus.amd.com/message/1286178#1286178)
--------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------
*Hi Nazim,*
* *
*I am able to compile the "kernel.cl" and create a kernel object
(clCreateKernel) for "kernel_ocl_path_trace".*
*I see that one of the kernels is commented in "kernel.cl"
(kernel_ocl_shader). Hope this is intended.*
* *
* *
*I am on a windows 7 64-bit system with AMD Cayman GPU.*
*But the application is 32-bit only.*
*AMD APP 2.8 (32-bit) is installed on my machine*
*The driver version I see in device manager is 9.2.0.0*
*The driver packaging version I see in AMD control center is
9.002-120928m-xxxxxxxx*
*Catalyst version 12.10*
* *
* *
*While compiling kernel.cl, the maximum memory usage of the application was
~525MB.*
*How much memory do you have on your machines?*
*I will post the exact code snippets that I used in the next post.*
* *
*Best Regards,*
*Work Item 6*
*.......................................................................*
Here is a copy of the host code that I used to compile in Windows using
Visual Studio 2010. Note that OCL is a helper C++ class that I use for
internal use. It just avoids the hassle of complex initialization.

#include <Windows.h>
#include <WinBase.h>
#include <ocl.hpp>
#include <iostream>

int main()
{
     ocl::platform_t platformType = ocl::platform_t::amd;
     ocl::device_t deviceType = ocl::device_t::gpu;

     ocl O(platformType, deviceType);

     HANDLE fileHandle = CreateFile("kernel.cl", GENERIC_READ,
FILE_SHARE_READ, NULL,
                                             OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
     HANDLE mapHandle = CreateFileMapping(fileHandle, NULL, PAGE_READONLY,
0, 0, NULL);
     LPVOID fileContent = MapViewOfFile(mapHandle, FILE_MAP_READ, 0, 0, 0);
     DWORD size = GetFileSize(fileHandle, NULL);

      cl_int err = O.buildKernel((const char*)fileContent,
"kernel_ocl_path_trace", "-I." );
      std::cout << "Build Kernel Returned " << err << std::endl;
      return 0;

 .................................................................................
The buildKernel in OCL wrapper does this:
{
    int err;
    char* buildLog = NULL;
    size_t buildLogSize = 0;

    program = clCreateProgramWithSource(context, 1, &kernelString, NULL,
&err);
    if(err != CL_SUCCESS)
    {
        #ifndef PRINT_MUTE
            std::cerr << " ocl: couldn't create program from the provided
kernel string " << err << std::endl;
        #endif
        return err;
    }

    err = clBuildProgram(program, 1, &device_id, buildOptions, NULL, NULL);
    if(err != CL_SUCCESS)
    {
        clGetProgramBuildInfo(program, device_id, CL_PROGRAM_BUILD_LOG, 0,
NULL, &buildLogSize);
        buildLog = (char*)(::malloc)(buildLogSize+1);

        #ifndef PRINT_MUTE
            std::cerr << " ocl: Failed to build program executable Build
log Size:" << buildLogSize << "\tBuild Log:\n";
        #endif
        clGetProgramBuildInfo(program, device_id, CL_PROGRAM_BUILD_LOG,
buildLogSize, buildLog, NULL);
        #ifndef PRINT_MUTE
            std::cerr << buildLog << std::endl;
        #endif
        ::free(buildLog);;
        return err;
    }

    kernel = clCreateKernel(program, kernelFuncName, &err);
    if ( (!kernel) || (err != CL_SUCCESS) )
    {
        #ifndef PRINT_MUTE
            std::cerr << "ocl: kernel could not be created " << err <<
std::endl;
        #endif
        return err;
    }
    return err;
}

 .............................................................................................
Hi Nazim,

Since the peak memory consumption is 512MB, this can be a problem
if your application has already loaded a lot of memory (in the form of
images or frames or any others).
As a workaround, Consider compiling the OpenCL program at start of day --
before loading any images or frames or whatever. Once the compilation is
done,
the memory consumption goes back to normal and hence you will have enough
memory to do your other operations....This can be a workaround.

Best Regards,
WorkItem 6

------------------------------------------------------------------------------------------------------------------------------------------------------------

I hope that this is in favor of all parties involved with cycles(mostly
brecht and his vision on cycles, developers, and AMD GPU card owners ).

Kind Regards,

Nazim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130108/208711eb/attachment.htm