Re: [Mesa-dev] [PATCH 0/4] glsl: Builtins, now!
Kenneth Graunkewrites: > Hello, > > This series reworks the GLSL compiler to inline built-in functions > immediately, at compile time, rather than importing prototypes and > linking against an extra shader later on. > > Without this, compile time optimizations are nearly useless. For example, > trying to use a dot product would generate: > >(call dot ...) > > which would not be turned into > >(expression dot ...) > > until link time, when we actually import the functions, and finally inline. > > Function calls are opaque, and most optimization passes freak out and bail > when they see them. For example, loop unrolling wouldn't happen at compile > time at all if a loop contains a built-in function call. This is pretty bad. > > Most built-in functions turn into opcodes, or tiny expression trees. > It makes sense to simply inline them immediately. Some are larger > (such as atan). But we eventually inline them all today anyway, so > I don't see any downside to doing it sooner rather than later. > > Ian recently sent out a patch series that adds a lot of flags for > "do this optimization anyway, but only for built-ins", in an attempt > to clean up this (call ...) mess. I think this series should also > solve those problems, but it deletes a bunch of code, rather than > adding more code. > > The downside is that the shader-db statistics aren't great today, > but I don't think there's a lot we can do about that. This changes > the optimization order significantly. Overall, the difference was > pretty small, so I think I'm OK with it. FWIW, I like this series a lot. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] glsl: Builtins, now!
On 09/21/2016 10:20 PM, Kenneth Graunke wrote: > Hello, > > This series reworks the GLSL compiler to inline built-in functions > immediately, at compile time, rather than importing prototypes and > linking against an extra shader later on. > > Without this, compile time optimizations are nearly useless. For example, > trying to use a dot product would generate: > >(call dot ...) > > which would not be turned into > >(expression dot ...) > > until link time, when we actually import the functions, and finally inline. > > Function calls are opaque, and most optimization passes freak out and bail > when they see them. For example, loop unrolling wouldn't happen at compile > time at all if a loop contains a built-in function call. This is pretty bad. > > Most built-in functions turn into opcodes, or tiny expression trees. > It makes sense to simply inline them immediately. Some are larger > (such as atan). But we eventually inline them all today anyway, so > I don't see any downside to doing it sooner rather than later. > > Ian recently sent out a patch series that adds a lot of flags for > "do this optimization anyway, but only for built-ins", in an attempt > to clean up this (call ...) mess. I think this series should also > solve those problems, but it deletes a bunch of code, rather than > adding more code. That explains why you sent an R-b on a few patches and said nothing about the rest. I was wondering. :) > The downside is that the shader-db statistics aren't great today, > but I don't think there's a lot we can do about that. This changes > the optimization order significantly. Overall, the difference was > pretty small, so I think I'm OK with it. > > Thoughts? > > --Ken > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] glsl: Builtins, now!
Hello, This series reworks the GLSL compiler to inline built-in functions immediately, at compile time, rather than importing prototypes and linking against an extra shader later on. Without this, compile time optimizations are nearly useless. For example, trying to use a dot product would generate: (call dot ...) which would not be turned into (expression dot ...) until link time, when we actually import the functions, and finally inline. Function calls are opaque, and most optimization passes freak out and bail when they see them. For example, loop unrolling wouldn't happen at compile time at all if a loop contains a built-in function call. This is pretty bad. Most built-in functions turn into opcodes, or tiny expression trees. It makes sense to simply inline them immediately. Some are larger (such as atan). But we eventually inline them all today anyway, so I don't see any downside to doing it sooner rather than later. Ian recently sent out a patch series that adds a lot of flags for "do this optimization anyway, but only for built-ins", in an attempt to clean up this (call ...) mess. I think this series should also solve those problems, but it deletes a bunch of code, rather than adding more code. The downside is that the shader-db statistics aren't great today, but I don't think there's a lot we can do about that. This changes the optimization order significantly. Overall, the difference was pretty small, so I think I'm OK with it. Thoughts? --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev