I attached my project with two examples (sum and device Fortran Projects). ![]() Thanks Steve, finally I was able to compile FortranCL in both x86 and 圆4 (any advantage of using 圆4 instead of x86?). SPIR has only recently been ratified (this January), so it might be a little while before we see anything like this in the wild, but there's definitely a lot of interest in this area and lots of support from some of the key vendors (especially Intel, despite Steve's comments above). The OpenACC work is one step in this direction, and probably has a lot of overlap with such an effort. ![]() Indeed, we already have CUDA FORTRAN, which is essentially the same thing for NVIDIA devices (and is probably implemented on top of PTX, which sits at a similar level in the software stack to SPIR). We are already seeing some high-level programming models starting to target SPIR in order to produce applications that can utilise OpenCL devices, such as C++ AMP, Halide, and the recently announced SYCL standard. This is exactly what Nick is asking about in his original question - will we see a Fortran->SPIR compiler that allows one to write OpenCL kernels in Fortran?įortran is a very popular language, and so I wouldn't be at all surprised if we see one or more efforts to produce a compiler for writing OpenCL kernels using Fortran, built on top of SPIR. This isn't something that developers would use directly, but rather something that would be generated by compiler backends. One of them, which you correctly point out, is to allow developers to ship their OpenCL programs in a portable binary format (LLVM bitcode), instead of shipping their OpenCL C source code with their applications (and yes, "OpenCL C" is the term for the C99-based language defined by the OpenCL standard for writing device programs).Īnother goal, which in my opinion is far more interesting, is having the ability to target SPIR from languages *other* than OpenCL C. SPIR is an LLVM-based intermediate representation which has a number of goals. My advice to you is to ignore SPIR and just use OpenCL directly. (OpenMP 4.0 is another way.) As I noted, you can use OpenCL from Fortran. If your desire is to harness the computational resources of graphics processors in a manufacturer-independent fashion, OpenCL is one way to do that. Maybe I'm missing something, but SPIR seems to make OpenCL more complicated than it needs to be. It looks to me as if SPIR is providing the ability to "precompile" OpenCL code so that you don't have to expose it to whoever uses your application (often OpenCL kernels are read from source files, though there's no requirement to do so.) Typically one writes the computational kernel in the OpenCL language and use calls from the "native" language (C, Fortran, etc.) to "compile" the kernel and then send the kernel and the data to the coprocessor, which executes it and sends the data back. OpenCL is executed natively by graphics processors and coprocessors - it is supported by Intel HD Graphics in recent Intel processors and by Intel Xeon Phi, as well as in graphics processors and accelerators from NVidia and AMD. I have never heard the term "OpenCL C" before, but I admit I am not an expert on OpenCL. I had not heard of SPIR before - this appears to be some sort of intermediary between the programmer and OpenCL - I am somewhat baffled as to what problem it is trying to solve. It's quite possible that I'm missing the big picture here so please feel free to correct whatever I'm not catching. That sounds challenging but not totally infeasible knowing that OpenACC to SPIR is on its way. However, the language semantics must be mappable to SPIR and satisfy the constraints of OpenCL target systems.Īs I understand it that would require replacing, in the SPIR Reference Flow, the OpenCL C to SPIR IR generator by an OpenCL Fortran (?) to SPIR one. ![]() The alternative language could be many things, such as an established language (like FORTRAN), an exotic domain specific language, or a single source programming environment with automatic code partitioning. There is no need to generate OpenCL C as an intermediate. What set of problems is SPIR supposed to solve?Įnable third-party code generation targeting OpenCL platforms without going through OpenCL C:įor example, a compiler for an alternative device language (not OpenCL C) can generate SPIR and have it run on any OpenCL backend that supports the cl_khr_spir extension. I was actually thinking about kernels in Fortran, excerpt from the SPIR FAQ:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |