Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
"Dorrington, Albert" writes: >> -Original Message- >> From: Francisco Jerez [mailto:curroje...@riseup.net] >> Sent: Wednesday, January 15, 2014 10:35 AM >> >> Yeah, well, it's up to the implementation how device-specific the binaries >> are. On r600 they're roughly half-way through the compilation process. If >> that's not satisfactory to you, you could try to get clang to generate >> binaries >> directly in the clover format (or even better, get clover to understand ELF >> object files instead of the non-standard format we use now for serializing >> module objects) and get rid of the two-stage compilation process. That way >> clover will have access to the actual GPU binaries. > > I think getting Clover to understand the ELF format would be useful, and > conform to the OpenCL spec. > Having it be able to output the ELF format from clGetProgramInfo() via the > CL_PROGRAM_BINARIES would be something that would impact the Mesa drivers > significantly; Since it would require moving the final binary generation from > the drivers into the state tracker. > Maybe, but the state tracker should have enough information to do that already (e.g. through the target description in PIPE_COMPUTE_CAP_IR_TARGET), and it would be preferable to mixing device-specific IR and hardware assembly depending on how the program was specified. pgpQ3cDdzzIlh.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
> -Original Message- > From: Francisco Jerez [mailto:curroje...@riseup.net] > Sent: Wednesday, January 15, 2014 10:35 AM > > Yeah, well, it's up to the implementation how device-specific the binaries > are. On r600 they're roughly half-way through the compilation process. If > that's not satisfactory to you, you could try to get clang to generate > binaries > directly in the clover format (or even better, get clover to understand ELF > object files instead of the non-standard format we use now for serializing > module objects) and get rid of the two-stage compilation process. That way > clover will have access to the actual GPU binaries. I think getting Clover to understand the ELF format would be useful, and conform to the OpenCL spec. Having it be able to output the ELF format from clGetProgramInfo() via the CL_PROGRAM_BINARIES would be something that would impact the Mesa drivers significantly; Since it would require moving the final binary generation from the drivers into the state tracker. > > > Is it that much overhead? AFAIK a compliant OpenCL implementation has to > include a compiler anyway, unless you're trying to do embedded profile. Is > that what you have in mind? > We are targeting the embedded profile and since our target is also a real-time environment, there are concerns about how online compiles might affect the environment. -Al ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
"Dorrington, Albert" writes: > Hi Francisco, > > I implemented the patch on my system and rebuilt my two programs. > > Reran my "online compile with save" program to generate a new 'compiled > kernel' and then reran the "load compiled kernel" program; and it worked > without errors, executing the kernel properly. > So, it looks like the Mesa implementation of clCreateProgramWithBinary() now > functions, for the LLVM IR generated code, which is great! > That's awesome, I'll merge it to master shortly. > I have re-read the Khronos OpenCL spec for clGetProgramInfo() and > clCreateProgramWithBinary() to clarify my understanding. > It looks like clGetProgramInfo() can return either IR, a device specific > binary, or both; while clCreateProgramWithBinary() can accept IR and/or a > device specific binary. > Yeah, well, it's up to the implementation how device-specific the binaries are. On r600 they're roughly half-way through the compilation process. If that's not satisfactory to you, you could try to get clang to generate binaries directly in the clover format (or even better, get clover to understand ELF object files instead of the non-standard format we use now for serializing module objects) and get rid of the two-stage compilation process. That way clover will have access to the actual GPU binaries. > For our purposes, we were expecting the device specific binary, not the IR, > so that we would not need to compile, or run LLVM on our target environment. > Is it that much overhead? AFAIK a compliant OpenCL implementation has to include a compiler anyway, unless you're trying to do embedded profile. Is that what you have in mind? > Looks like I need to spend some more time understanding the code and > architecture :) Thanks. > > -Al > > -Original Message- > From: Francisco Jerez [mailto:curroje...@riseup.net] > Sent: Tuesday, January 14, 2014 4:18 PM > > 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. pgplkNShUY8lw.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
Hi Francisco, I implemented the patch on my system and rebuilt my two programs. Reran my "online compile with save" program to generate a new 'compiled kernel' and then reran the "load compiled kernel" program; and it worked without errors, executing the kernel properly. So, it looks like the Mesa implementation of clCreateProgramWithBinary() now functions, for the LLVM IR generated code, which is great! I have re-read the Khronos OpenCL spec for clGetProgramInfo() and clCreateProgramWithBinary() to clarify my understanding. It looks like clGetProgramInfo() can return either IR, a device specific binary, or both; while clCreateProgramWithBinary() can accept IR and/or a device specific binary. For our purposes, we were expecting the device specific binary, not the IR, so that we would not need to compile, or run LLVM on our target environment. Looks like I need to spend some more time understanding the code and architecture :) -Al -Original Message- From: Francisco Jerez [mailto:curroje...@riseup.net] Sent: Tuesday, January 14, 2014 4:18 PM 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
A general FYI for anyone: The mesa-dev archive has a copy of the patch that you can download. http://lists.freedesktop.org/archives/mesa-dev/2014-January/051551.html On Tue, Jan 14, 2014 at 3:29 PM, Dorrington, Albert wrote: > 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" 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
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" 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
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
"Dorrington, Albert" 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
>
diff --git a/src/gallium/state_trackers/clover/api/program.cpp b/src/gallium/state_trackers/clover/api/program.cpp
index 7d060c4..6049209 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -69,7 +69,7 @@ clCreateProgramWithBinary(cl_context d_ctx, cl_uint n,
throw error(CL_INVALID_DEVICE);
// Deserialize the provided binaries,
- auto result = map(
+ std::vector> result = map(
[](const unsigned char *p, size_t l) -> std::pair {
if (!p || !l)
return { CL_INVALID_VALUE, {} };
diff --git a/src/gallium/state_trackers/clover/core/module.cpp b/src/gallium/state_trackers/clover/core/module.cpp
index 040f521..3e3ad99 100644
--- a/src/gallium/state_trackers/clover/core/module.cpp
+++ b/src/gallium/state_trackers/clover/core/module.cpp
@@ -108,6 +108,9 @@ namespace {
proc(S &s, QT &x) {
_proc(s, x.type);
_proc(s, x.size);
+ _proc(s, x.target_size);
+ _proc(s, x.target_align);
+ _proc(s, x.ext_type);
}
};
diff --git a/src/gallium/state_trackers/clover/core/program.cpp b/src/gallium/state_trackers/clover/core/program.cpp
index 6d4a9ba..fb7e8d1 100644
--- a/src/gallium/state_trackers/clover/core/program.cpp
+++ b/src/gallium/state_trackers/clover/core/program.cpp
@@ -26,13 +26,13 @@
using namespace clover;
program::program(context &ctx, const std::string &source) :
- ctx(ctx), _source(source) {
+ has_source(true), ctx(ctx), _source(source) {
}
program::program(context &ctx,
const ref_vector &devs,
const std::vector &binaries) :
- ctx(ctx) {
+ has_source(false), ctx(ctx) {
for_each([&](device &dev, const module &bin) {
_binaries.insert({ &dev, bin });
},
@@ -41,23 +41,25 @@ program::program(context &ctx,
void
program::build(const ref_vector &devs, const char *opts) {
- for (auto &dev : devs) {
- _binaries.erase(&dev);
- _logs.erase(&dev);
- _opts.erase(&dev);
-
- _opts.insert({ &dev, opts });
-
- try {
- auto module = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
-compile_program_tgsi(_source) :
-compile_program_llvm(_source, dev.ir_format(),
- dev.ir_target(), build_opts(dev)));
- _binaries.insert({ &dev, module });
-
- } catch (build_error &e) {
- _logs.insert({ &dev, e.what() });
- throw;
+ if (has_source) {
+ for (auto &dev : devs) {
+ _binaries.erase(&dev);
+ _logs
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
On Tue, Jan 14, 2014 at 10:05:47AM +0100, Francisco Jerez wrote: > Tom Stellard writes: > > > On Mon, Jan 13, 2014 at 06:44:15PM +, 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 fig
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
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. 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 -Original Message- From: Francisco Jerez [mailto:curroje...@riseup.net] Sent: Tuesday, January 14, 2014 4:06 AM To: Tom Stellard; Dorrington, Albert Cc: mesa-dev@lists.freedesktop.org Subject: Re: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation issue Tom Stellard writes: > On Mon, Jan 13, 2014 at 06:44:15PM +, 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 clCr
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
Tom Stellard writes: > On Mon, Jan 13, 2014 at 06:44:15PM +, 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 +, 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
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
On Mon, Jan 13, 2014 at 06:44:15PM +, 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. 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 +, 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 > > 50T 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 li
Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue
Tom, Thanks for your response. I am very interested in implementing this, so any pointers you can provide would be greatly appreciated. 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 +, 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 > 50T 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
