[Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Dorrington, Albert]

Hi Francisco,

I'd be glad to try the patch out, unfortunately it was blocked by our mail server rules.
If you can resend the file, and set the extension to ".allow" it should get through our mail server fine.

Thanks!
-Al

-----Original Message-----
From: Francisco Jerez [mailto:currojerez at riseup.net] 
Sent: Tuesday, January 14, 2014 4:18 PM
To: Dorrington, Albert; Tom Stellard
Cc: mesa-dev at lists.freedesktop.org
Subject: RE: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation issue

This e-mail message contained a file attachment that was blocked per Lockheed Martin Corporate Information Security Requirements.  Certain file types are being blocked from entering Lockheed Martin in order to minimize risk to Corporate computing and information resources. 

If a business need exists and you must receive this file, alternate methods have been approved for use by Corporate Information Security for receipt and review of files/attachments.  For more information and options for handling blocked attachments, visit E-mail Attachment Security, at
    http://protection.global.lmco.com/protection/isafe/topics.e-attachments.cfm

The current list of allowed attachment types is located at:  
    http://protection.global.lmco.com/protection/awareness/e-msging/allowed_attachments.cfm

If additional assistance is required, please contact the Lockheed Martin Service Desk at 1-800-435-7063.

======================================================================
"Dorrington, Albert" <albert.dorrington at lmco.com> writes:

> Hi Tom and Francisco,
>
> When I tried to use Clang from the command line to produce binaries, all I could get was the LLVM IR code, so I adapted my test program to produce a binary using clGetProgramInfo().
> (I have been following code examples in book 'OpenCL Programming 
> Guide')
>
> I have been stepping through the existing code in this area, using GDB, for the past few days, trying to get the binary to load successfully, and I have also stepped through the code behind clCreateProgramWithSource() -  so I have started getting familiar with the process that is going on.
>
> I thought, if I generated the binary using clGetProgramInfo() after clBuildProgram() that the binary would be in the same format as would be needed.
>
> So far, I have run into two main issues.
> The first is, if there is only one kernel in the binary, it seems that clCreateProgramWithBinary() thinks there are two, due to (I think) an issue with the range() processing.
> In the debugger I see a second pair of binary/length fields in the result map, and when the 'return new program()' call is made at the end of clCreateProgramWithBinary() I get a SegFault after the first (only) binary is deserialized.
>
> So, I added a second kernel function to the CL program, and I am able to get through clCreateProgramWithBinary() without crashing, but quickly ran into a second issue.
>
> My code currently calls in the order:
> 	clCreateProgramWithBinary();
> 	clBuildProgram();
> 	clCreateKernel();
> 	
> The clCreateKernel() call fails with a -46/Invalid Kernel Name; stepping through the debugger, I believe I can see the two loaded kernels, however I cannot find the names in what was loaded.
>
> For now, I don't need Clang/LLVM to produce the binary without Mesa/Clover, I am fine with Mesa/Clover producing the binary.
>

Hi Albert, can you give the attached patch a try?  It fixes a couple of issues I've found in the clCreateProgramWithBinary path.  Let me know if it helps.

Thanks.

> Tom, from what you wrote below, it sounds like the clBuildProgram() implementation may only be expecting IR code and not a binary input?
>
> Since getting this to function is related to my current assignment at work, I do have a lot of time I can spend on this task.
>
> Thanks!
> -Al
>