[LLVMdev] Questions about GPU code generation/ VS development
o.j.sivart at gmail.com
o.j.sivart at gmail.com
Fri Jul 23 06:02:25 PDT 2010
On 23/07/2010, at 7:25 PM, Daan Nijs wrote:
> Hey everyone,
> I've been working for a while on a virtual machine/DSL (for lack of a more precise term) specialised for graphics. I hope to allow domain specific optimizations, eg folding together post-processing passes, or automatic LODing for procedural textures. I'm planning to make the renderer itself to be defined at runtime, to allow foward rendering, deferred rendering, raytracing, or a combination of all 3. Of course, this is lot to chew on, so for now it's more of a proof of concept than anything production-ready.
> Due to my unfamiliarity with LLVM, I do have some broad questions though. If somebody can answer, or just point me to the relevant documentation/code, I would be very grateful.
> Right now I use my own code to schedule between the GPU code (OpenCL and GLSL), and to generate the GPU code. In fact, I only use LLVM to generate the CPU side code.
> 1. Which steps would it take to implement an OpenCL/GLSL backend to LLVM? What is the level of vector integration in the core? Is there already some work done in this direction I could look at/reuse?
> 2. Would it make sense to use LLVM to drive the whole compilation process, considering I will operate on high level concepts, eg convolutions, frequency analysis, error metrics? Or should I do break down these things first and then use LLVM for the lower level code?
> 3. ATM I'm using VS2008 as my environment, and LLVM from head. Timewise, am I shooting myself in the foot? I'm hesitant to switch to another platform, as I have a lot of experience with VS, but I'm unsure how well the LLVM support stacks up to Mac/Linux support.
I'm on linux for development, but all of my colleagues are on VS2005. We have been on LLVM 2.7 ever since it's release as we need a stable platform because we are not only working on our own ongoing internal R&D in the longer term but also have products shipping to customers from the short term onward. Apart from lots of innocent, but annoying, warnings coming out on windows, we have seen no execution errors from LLVM apart from a few bugs which are not windows specific but rather cross-platform (and all of which are fixed on LLVM trunk). In these cases we have our own internal patches applied until LLVM 2.8 is released. If you have no other good reason to want to move from windows to linux then I would say that our experience demonstrates that LLVM in itself provides no justification either way, so choose on your own other merits in terms of other things whether you are happy on windows or not. Or in fact choose based on what your customer expects.
> 4. I'm using my own custom 3d engine, which should have it's routines called dynamically. Does this mean I have to run CLang on it to make it callable from LLVM generated code, or should I just be able to call it as as external code?
> I apologize in advance if some of these questions are basic or too broad, I recently hit a bit of a brick wall designing the guts of the system, and would love to benefit from the opinion of experienced LLVM users. Thank you for your time.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev