Hi, I have been looking into what would be needed to modify in clang to support opencl recently, although there is an opencl flag to set in the lang options, it doesn't really seem to do much, so the modifications seem non-trivial (to me at least). I am wondering if this would be useful to continue, and if the changes required would invalidate this work. I also have a patch that gets the clover compiler class working with the api changes in clang. Without the opencl specific modifications, it has effectively turned it into a simplistic c99 compiler, return llvm bytecode. I also have started on some work to get a simple cpu implementation, based on the llvm execution engine, working, though this probably will take a back seat until the compiler is at least half-way correct. Also, am I correct in assuming that the general flow goes: openCL code -> clang -> llvm bytecode -> TGSI -> gallium driver?
Thanks, Jonathan Hamilton On 07/23/10 15:39, Zack Rusin wrote: > On Thursday 22 July 2010 20:33:59 Anthony Waters wrote: >> sounds good, >> >> the patches in >> http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg10561.html >> don't produce any conflicts with the commit from 3/28, they applied >> cleanly into my working copy with a 3 way merge through git am -3 >> >> not sure if this is a concern or not, but after the 3 way merge the >> commit log is not in chronological order anymore > > That doesn't really matter. Just so that I know do you actually have a plan > or > are you just playing around? I'm asking because the reason the Clover > repository is waiting is because the entire codebase will depend on the > infrastructure for GPGPU in Gallium, Clang integration and LLVM code-gen > code. > In the gallium resources branch I've the first crucial part of the changes in > Gallium which is support for buffer reads and gather instructions. Then we'll > need to implement scatter and memory spaces. > TBH anything short of that Gallium/Clang/LLVM infrastructure work is at this > point not very useful because it will just be rewritten later. Actually from > the simpler stuff maybe cleaning up the build system or changing the testing > framework to QtTest would be useful for later. I wouldn't spend any time on > anything but that at this point. > > z > _______________________________________________ > 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
