On Mon, Aug 18, 2014 at 1:38 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 18.08.2014 19:05, schrieb Connor Abbott: >> On Mon, Aug 18, 2014 at 12:38 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> On Mon, Aug 18, 2014 at 12:25 PM, Connor Abbott <cwabbo...@gmail.com> wrote: >>>> On Mon, Aug 18, 2014 at 11:47 AM, Jose Fonseca <jfons...@vmware.com> wrote: >>>>> On 18/08/14 14:21, Marek Olšák wrote: >>>>> Once these are in place, all development effort to go on to >>>>> improving/leveraging the new IR. We could deprecate TGSI when it would >>>>> have >>>>> few users. >>>> >>>> Also, switching to LLVM, NIR, or some other IR that uses SSA (or at >>>> least modifying TGSI to support it) seems like something that's really >>>> necessary for the Gallium folks. Soon, considering most backends >>>> already use SSA in one form or another, the situation will look like: >>>> >>>> GLSL IR -> NIR -> NIR with SSA -> optimizations -> NIR without SSA -> >>>> TGSI -> backend without SSA -> backend with SSA >>>> >>>> So backends would have to duplicate the into-SSA logic and every >>>> shader would have to pay the penalty of being converted out of and >>>> then back into SSA thanks to TGSI not supporting it. >>> >>> Looking at it another way, perhaps we should just accept that backends >>> will want to do their own things, and try to minimize the damage by >>> doing >>> >>> GLSL IR -> transport ir -> backend >>> >>> Are you envisioning a world where every backend uses NIR, and uses >>> some sort of shared register allocation/spilling/etc logic, >>> configurable instruction lists, pluggable with lowering passes? By >>> then you've invented LLVM... >>> >>> -ilia >> >> No, I expect that backends will still want to do their own register >> allocation/spilling/scheduling etc. - and besides for that, NIR >> supports structured control flow, swizzles and writemasks, modifiers >> (abs, negate, saturate), etc. natively in the IR instead of something >> that's tacked on or something that drivers have to do themselves. So >> no, I'm not re-inventing LLVM. On the other hand, it's entirely >> possible for backends to add their own backend-specific opcodes and >> intrinsics, and thereby be able to do some amount of lowering and >> optimization in NIR. Another reason that backends might want to accept >> NIR is so that they can give NIR passes more precise information on >> e.g. when to do if-conversion. Again, this is all speculative though - >> we'll have to do more of the work before we can find out how we want >> to use NIR beyond what originally wrote it to be, which was a way to >> do common optimizations that we couldn't do in GLSL IR. >> >> Connor > > I guess having the "typical" gpu features (vec4 representation along > with swizzles, writemasks, modifiers) in the IR is nice, though I'm > beginning to wonder if it's all that useful. Obviously, it maps really > well to "old" gpus (like r300) and old-style shaders using lots of vec4 > (the human-readable assembly is going to be much nicer if you have vec4 > support) but ultimately it seems most newer archs are scalar (or rather, > their vectors are not along the instruction level axis). Something like > Mali gpus being an exception rather than the norm. Even things like r600 > need to do their own vliw-ication anyway. > In any case, for gallium I'm pretty indifferent to shader IR actually, > as long as things keep working... Just keep in mind though while tgsi > might not be the optimal solution, there's significant precedence for > this kind of low level shader language (since even d3d10 follows that > model, though I can't tell how happy the IHVs are with it...). But if > NIR benefits glsl compiler on its own that looks all good to me, it's > just an area I'm not really familiar with.
FWIW, we use AMDIL internally: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/AMD_Intermediate_Language_(IL)_Specification_v2.pdf http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/documentation/amd-app-documentation/ Alex > > btw do you have some example of how a shader looks printed out? I'm too > lazy to play with it myself... > > Roland > > _______________________________________________ > 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
