Tom Stellard <t...@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:t...@stellard.net] >> Sent: Monday, January 13, 2014 1:12 PM >> To: Dorrington, Albert >> Cc: mesa-dev@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 >>
pgporxipkY9D1.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev