On Tue, Sep 11, 2012 at 11:12:49PM +0200, Vincent wrote: > Hi, > > I'm currently working on a glsl to llvm pass that generates LLVM IR from > glsl tree for drivers that ships with a LLVM backend. The current code > is located here : http://cgit.freedesktop.org/~vlj/mesa in branch > glsl-to-llvm3. It is still a work in progress (I'm not fully satisfied > by some factorisation and coding style is not consistant atm) > > I'm testing it against evergreen at the moment thus namespace are r600 > oriented (all the intrinsics are prefixed with llvm.AMDGPU. or > llvm.R600.). However I'm trying to make it as driver agnostic as > possible.
The r600 backend uses way too many intrinsics, and most of them could be replaced with either one or a sequence of LLVM IR instructions. However, there are several things that must be represented by intrinsics. These include texture instructions, shader inputs, shader outputs, and possibly others. I think if this front end is used by multiple backends, it will be important to come up with some standard intrinsic definitions that backends can share. Ideally GLSL->LLVM would not need to use any target-specific intrinsics. > This pass does not try to optimise the code : it does not generate MAD > instructions, it does not propagate constant, it does not eliminate dead > code like glsl-to-tgsi does. I chose to leave this to LLVM own pass. On > the other hand, I try to make the result code as close as possible from > the glsl tree : it preserves vector structure (tgsi to llvm does not), > it does not convert boolean to int... This allows to find some bugs in > the backend that were hidden by glsl-to-tgsi but could appear with a > futur OpenCl support. I think it makes sense to leave most of the optimizations to LLVM, and it is really nice to be able to preserve type information from the frontend. This will make a lot of things in the backend much easier. > On the other hand r600 backend does not like vectorised input : it > generates much more MOV instruction than necessary. I've narrowed the > issue : the COPY llvm internal instructions is lowered to 4 MOV even if > following instruction overwrite some registers, and the store output > instruction fixes the exported register, which is not optimal wrt > register coalescing pass. > Unfortunately, LLVM 3.1 won't coalesce copies from physical to virtual registers or vice-versa. This is a reason why it would be good to move the import/export instructions into the backend, so we can avoid emulating them with physical live-in and live-out registers. > So far I managed to get something like 200 regressions on 7000 passing > tests in piglit, but recent changes (ie moving the interpolation logic > inside backend) added 100 others regressions in current trunk, because > of failing front/back face color issue I'm working on. > Very nice! It sounds like you have made really good progress. > However I meet some "standardisation" issue at the moment. I work with a > single driver that has its own constraint and feature. > For instance, I use a single intrinsic to export everything : > llvm.AMDGPU.store.output. However there are some special outputs like > vertex position and pixel color. I'm planning to add a > llvm.AMDGPU.store.position and llvm.AMDGPU.store.color. Transform and > Feedback also needs a similar special intrinsic. > As I mentioned above, if this will be used by multiple backends, it makes sense to rename the intrinsics to something like llvm.mesa.store.position. > I'd like to request your feedback and suggestion on my work. > Glsl-to-llvm does not calls any gallium function and can also be used by > classic dri drivers. I don't know what is the current status of the > recently announced llvm i965 compiler, I don't know if it has already > its own glsl-to-llvm pass or not. If not, it would be really great if > this pass was also shared by i965, as the more drivers use it, the more > reliable it is. > It would be great to have this shared by multiple targets. I'd be interested to here what Intel's plans are regarding an LLVM front-end. -Tom _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
