Re: [Mesa-dev] [PATCH 0/4] glsl: Builtins, now!

2016-09-22 Thread Eric Anholt
Kenneth Graunke  writes:

> 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!

2016-09-22 Thread Ian Romanick
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!

2016-09-21 Thread Kenneth Graunke
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