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

Francisco Jerez currojerez at riseup.net
Tue Jan 14 01:05:47 PST 2014


Tom Stellard <tom at stellard.net> writes:

> On Mon, Jan 13, 2014 at 06:44:15PM +0000, Dorrington, Albert wrote:
>> Tom,
>> 
>> Thanks for your response. I am very interested in implementing this, so any pointers you can provide would be greatly appreciated.
>
> I'm cc'ing Fransisco since he may also have some feedback.
>
> The first step is to build a clover::module object from the binary code.
> When we compile OpenCL C, we use the build_module_llvm() function in
> llvm/invocation.cpp to do this.  This function takes LLVM IR as input
> (stored in the LLVM:Module object) and produces a clover::module as
> output.
>
> With clCreateProgramFromBinary() we build a clover::module by deserializing the
> binary code using the module::deserialize function declared in module.cpp.
> This function expects the binary code to use a specific format, the code that
> is output from Clang/LLVM is not in the expected format which is probably why
> this is crashing for you.
>
> I don't think this format is documented anywhere, but you should
> be able to deduce it by looking through the code in core/module.cpp.
> The challenge is to get Clang/LLVM to produce code in the correct format.
>
> I think the correct way to do this would be to add a new triple,
> something like r600-clover-unknown, and then have the code emitter
> produce clover formatted code when it is passed this triple.  However,
> I would recommend not worrying about the triple for now and just change
> the code emitter to emit clover's format.  Once this is working, then
> we can go back and add the new triple.
>
> Once LLVM is producing the correct format, you will need to find a way
> for clover to communicate to the drivers that the code being
> passed is binary and not whatever its preferred IR is.  One way to do
> this is to add the
>
> enum pipe_shader_ir ir_type;
>
> field to struct pipe_compute_state and use this to tell the drivers what
> kind of IR it has.  You will also need to add the PIPE_SHADER_IR_BINARY
> type to enum pipe_hsader_ir.
>
> Then you will need to implement support for PIPE_SHADER_IR_BINARY in r600g.
> The code for doing this is already their you will just need to add a code
> path which skips over all of the LLVM compilation stages.
>
> Hopefully, this will help get you started.
>

Hi Tom,

I'm not sure if this makes sense to me.  Ideally programs created from
source code and from binary would share the same driver path.  If
there's a way to invoke clang that gets us a native GPU binary in the
clover::module format we should always invoke it that way -- also when
the program is specified using clCreateProgramWithSource().  If we want
to stick to the two-stage compilation approach r600g uses now with a
half-baked LLVM representation, we should expect the input of
clCreateProgramFromBinary() to be in the same format.  Mixing two
program representations depending on the way the program is created
sounds like a recipe for headache to me...

Albert, have you tried creating your binary using a CL client that calls
clBuildProgram() and then extracts the generated code with
clGetProgramInfo(CL_PROGRAM_BINARIES)?  That's the only portable way to
generate a binary for a given CL device, invoking clang manually is not
-- and as you've already realized it's not supposed to work right now.

Thanks.

> When it comes to generating a binary from clang and llvm.  Here is the clang
> invocation I use:
>
> clang -o test.o -target r600-unknown-unknown -mcpu=redwood -integrated-as -c test.cl
>
> Note that this will work only if you uses non-vector types and don't
> use any builtin functions.  To cover all use cases you can use the attached
> shell script to compile the code.
>
> -Tom
>
>> I don't have access to IRC at work (at least I doubt I do) due to firewalls - but I can use the mailing list.
>> 
>> I wasn't entirely sure about the proper clang command line, so I wrote another program which does the online compile, then saves the output away.
>> I think I can produce an appropriate binary now.
>> 
>> I am currently using a Radeon 6670; so I assume it will be: -mcpu=turks
>> 
>> It looks like the LLVM output from clang is identical with either -mcpu=turks or -mcpu=r600.
>> I can't seem to make clang output a binary file. (I figure I'm not using clang correctly)
>> Since I can capture the binary with another C program (I think) I'm not too worried about using clang/llvm directly yet.
>> 
>
>
>
>
>> Thanks!
>> -Al
>>  
>> -----Original Message-----
>> From: Tom Stellard [mailto:tom at stellard.net] 
>> Sent: Monday, January 13, 2014 1:12 PM
>> To: Dorrington, Albert
>> Cc: mesa-dev at lists.freedesktop.org
>> Subject: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation issue
>> 
>> On Thu, Jan 09, 2014 at 12:49:51PM +0000, Dorrington, Albert wrote:
>> > I am not sure if this is the appropriate list on which to ask this question, if not hopefully someone can suggest an alternative.
>> > 
>> > Under Linux, I am attempting to perform an offline compile of an OpenCL kernel example using Clang, and then load that binary using the clCreateProgramWithBinary() function.
>> > 
>> > Unfortunately, while clover is loading the binary, I end up getting a segmentation fault:
>> > 
>> > Program received signal SIGSEGV, Segmentation fault.
>> > proc (v=..., is=...) at core/module.cpp:50
>> > 50            T x;
>> > 
>> > I have pasted the source code I am using below, for both the kernel and the host code.
>> > 
>> > I am compiling with the following commands:
>> > clang -target r600-unknown-unknown -x cl -S -emit-llvm -mcpu=r600 
>> > kernel.cl -o kernel.clbin
>> 
>> I'm surprised that this works, since the r600 GPU does not support OpenCL (Note that R600 is the name of the target and also one of the individual GPUs supported by the compiler).  The  argument of -mcpu= needs to be GPU you are compiling the code for.  So if you have a redwood GPU you would need to pass -mcpu=redwood.
>> 
>> However, the main issue here is that clover does not support
>> clCreateProgramWithBinary() yet.  If you are interested in implementing this, I can give you some pointers.  Just send an email to the list or ping me on irc (nick: tstellar on #radeon @ irc.freednode.net).
>> 
>> -Tom
>> 
>> > clang -g -L/usr/local/lib -lOpenCL offline_host.c -o offline_host
>> > 
>> > I have LLVM/Clang 3.4RC3 installed and Mesa 10.0.1.
>> > 
>> > If anyone has suggestions, or can point me to the appropriate mailing list or documentation,  I'd appreciate it.
>> > 
>> > Thanks!
>> > -Al
>> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140114/52746c1d/attachment-0001.pgp>


More information about the mesa-dev mailing list