[Mesa-dev] [PATCH 00/56] Die copy-and-paste code, die
mattst88 at gmail.com
Tue Jul 19 19:43:20 UTC 2016
On Tue, Jul 19, 2016 at 12:24 PM, Ian Romanick <idr at freedesktop.org> wrote:
> After seeing Dave's series to add support GL_ARB_shader_gpu_int64 and
> thinking about adding support for 8- and 16-bit integers, I decided
> that something had to be done about the cut-and-paste madness that is
> ir_constant_expression.cpp. I decided to take a page from Jason's book
> and generate it from a machine description of the expressions. The
> result is this series.
> You may notice from some of the earlier patches in this series that I
> started this work over a year ago. The previous work was an attempt to
> generate opt_algebraic.cpp which was ultimately abandonded. It may be
> worth picking that up again.
> I haven't done *anything* for SCons, so hopefully Jose or someone can
> help out there.
> All of this is available at:
> Other possible follow-up work:
> - A few expressions don't have constant evaluation support. I don't
> think I've seen a real shader use any of these, so there's a reason
> we haven't "missed" them.
> - frexp_sig
A program could do something crazy like
float array[int(frexp(42.0, exp))];
in which case we'd need to handle this.
> - frexp_exp
exp is an "out" parameter of frexp(), so it can't be used for things
like sizing an array.
> - vote_any
> - vote_all
> - vote_eq
These are trivial. For constant inputs, any/all return the argument,
and vote_eq returns true.
> - imul_high
> - carry
> - borrow
Same story as frexp_exp.
> - Generate validation code for expressions. A few times while
> developing this series I had questions about what the IR actually
> supported. In quite a few cases the IR support is different from
> what GLSL supports. I would often look to ir_validate.cpp to answer
What can you say... often GLSL is stupid. :)
Really though, we have some intentional differences like allowing
vector versions of logical operations.
I'll start reviewing.
More information about the mesa-dev