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:curroje...@riseup.net] Sent: Tuesday, January 14, 2014 4:18 PM To: Dorrington, Albert; Tom Stellard Cc: mesa-dev@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.dorring...@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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
