On Tue, Jan 14, 2014 at 10:05:47AM +0100, Francisco Jerez wrote: > 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... >
Hi Fransisco, I never really considered this, but I think it makes sense. Someone would still need to modify the LLVM backend to output clover's binary format, but once that is done, we could drop the two-stage compilation approach, and just pass binary code directly to the driver. I think this would actually be easier than what I described. > 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. > If you do it this way, the 'binary' will be LLVM bytecode. I'm assuming you want the actual machine code. -Tom > 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 > >> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
