GLESv1 and GLESv2 have their own dispatch.h and remap_helper.h.  These
headers are only used by api_exec_es1.c and api_exec_es2.c in core mesa.
Move the rules to generate them from glapi to core mesa.

Reviewed-by: Brian Paul <brianp@vmware.com>

[olv: updated after reviewing to fix SCons build]

glapi_gen.mk is supposed to be included by glapi users to simplify
header generation.  This commit also makes es1api, es2api, and
shared-glapi use it.

Reviewed-by: Brian Paul <brianp@vmware.com>

[olv: updated after reviewing to prefix all variables in glapi_gen.mk by
 glapi_gen]

glapi/gen-es/ defines two sets of GLAPI XMLs for OpenGL ES 1.1
(es1_API.xml) and 2.0 (es2_API.xml) respectively.  They are used to
generate dispatch.h and remap_helper.h for GLES.  Together with
gl_and_es_API.xml, we have to maintain three sets of GLAPI XMLs.

This commit makes dispatch.h and remap_helper.h for GLES be generated
from gl_and_es_API.xml.

Reviewed-by: Brian Paul <brianp@vmware.com>

add gl_api::filter_functions and gl_function::filter_entry_points to
filter out unwanted functions and entry points.

Reviewed-by: Brian Paul <brianp@vmware.com>

Move the list of entry points belong to GLES from mapi_abi.py to a new
file.

Until we figure out how to describe the APIs an entry point belongs to
in the XML file, and how to handle the case where an entry point others
alias is missing in some APIs, this is an easier solution than
maintaining another two sets of XMLs in glapi/gen-es/.

Reviewed-by: Brian Paul <brianp@vmware.com>

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>

Remove the 'f' suffix from a float literal.
    - .float 0.0f+1.0
    + .float 1.0

This fixes the following compile error with clang:
    error: unexpected token in directive
    .float 0.0f+1.0
              ^

Note: This is a candidate for the stable branches.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chad Versace <chad@chad-versace.us>

This doesn't really make any difference because all the colormasks
are the same upon context set-up, but it makes more sense.

Fixes piglit hiz-depth-stencil-test-fbo-d0-s8 crash.
See http://bugs.freedesktop.org/show_bug.cgi?id=37907

NOTE: This is a candidate for the 7.11 branch.

Optional parallel rendering of spans using OpenMP.
Initial implementation for aa triangles. A new option for scons is
also provided to activate the openmp support (off by default).

Signed-off-by: Brian Paul <brianp@vmware.com>

After copy buffer on preGEN6, it is necessary to wait for the blit to
complete before returning data to the user.

This should fix the piglit test: copy_buffer_coherency (pre-GEN6).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This is a GLSL 1.3 feature, but also used by MLAA.

Signed-off-by: Lauri Kasanen <cand@gmx.com>

"reg" was set in only one case, virtual GRFs pre register allocation,
and would be unset and have hw_reg set after allocation.  Since we
never bothered with looking at virtual GRF number after allocation
anyway, just use the same storage and avoid confusion.

Besides separating out a logical step of the giant register allocator
function, this now communicates a bunch of the allocator information
through entries in brw_context, which will make this code partially
reusable for caching the expensive allocator setup.

It's fewer pointers to track, and when we start caching the register
set, should be algorithmically better in the cache hit case (lookup in
a byte-per-register array, instead of a linear walk through
desctiption of register classes to find how to translate that class).

This was a debugging aid at one point -- virtual grf 0 should never be
allocated, and it would be used if undefined register access occurred
in codegen.  However, it made the confusing register allocation code
even more confusing by indexing things off of 1 all over.

That code I wrote was impenetrable, and hard to write the first time.
This makes things a lot more obvious.

Fixes StarCraft 2 and Fallout 3 in Wine.

Signed-off-by: Brian Paul <brianp@vmware.com>

At least one of the invariants verified by IR validation concerns the
relative ordering of toplevel constructs in the IR: references to
global variables must come after the declarations of those global
variables.

Since linking affects the ordering of toplevel constructs in the IR,
it's possible that a bug in the linker will cause invalid IR to be
generated, even if all the pre-linked shaders are valid.  (In fact,
such a bug was fixed by the previous commit.)

Bugs like this are easily masked by further optimization passes,
particularly inlining.  So to make them easier to track down, this
patch addes an IR validation step right after linking, and before
final optimization occurs.  The validation only occurs on debug
builds.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

When link_functions.cpp adds a new function to the final linked
program, it needs to add it after any global variable declarations
that the function refers to, otherwise the IR will be invalid (because
variable declarations must occur before variable accesses).  The
easiest way to do that is to have the linker emit functions to the
tail of the final linked program.

The linker used to emit functions to the head of the final linked
program, in an effort to keep callees sorted before their callers.
However, this was not reliable: it didn't work for functions declared
or defined in the same compilation unit as main, for diamond-shaped
patterns in the call graph, or for some obscure cases involving
overloaded functions.  And no code currently relies on this sort
order.

No Piglit regressions with i965 Ironlake.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

process_array_type() contains an assertion to verify that no IR
instructions are generated while processing the expression that
specifies the size of the array.  This assertion needs to happen
_after_ checking whether the expression is constant.  Otherwise we may
crash on an illegal shader rather than reporting an error.

Fixes piglit tests array-size-non-builtin-function.vert and
array-size-with-side-effect.vert.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Rearranged the logic for converting the ast for a function call to
hir, so that we constant fold before emitting any IR.  Previously we
would emit some IR, and then only later detect whether we could
constant fold.  The unnecessary IR would usually get cleaned up by a
later optimization step, however in the case of a builtin function
being used to compute an array size, it was causing an assertion.

Fixes Piglit test array-size-constant-relational.vert.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38625

The ast-to-hir conversion needs to emit function signatures in two
circumstances: when a function declaration (or definition) is
encountered, and when a built-in function is encountered.

To avoid emitting a function signature in an illegal place (such as
inside a function), emit_function() checked whether we were inside a
function definition, and if so, emitted the signature before the
function definition.

However, this didn't cover the case of emitting function signatures
for built-in functions when those built-in functions are called from
inside the constant integer expression that specifies the length of a
global array.  This failed because when processing an array length, we
are emitting IR into a dummy exec_list (see process_array_type() in
ast_to_hir.cpp).  process_array_type() later checks (via an assertion)
that no instructions were emitted to the dummy exec_list, based on the
reasonable assumption that we shouldn't need to emit instructions to
calculate the value of a constant.

This patch changes emit_function() so that it emits function
signatures at toplevel in all cases.

This partially fixes bug 38625
(https://bugs.freedesktop.org/show_bug.cgi?id=38625).  The remainder
of the fix is in the patch that follows.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

opt_dead_functions contained a shortcut to skip processing the first
function's body, based on the assumption that IR functions are
topologically sorted, with callees always coming before their callers
(therefore the first function cannot contain any calls).

This assumption turns out not to be true in general.  For example, the
following code snippet gets translated to IR that violates this
assumption:

    void f();
    void g();
    void f() { g(); }
    void g() { ... }

In practice, the shortcut didn't cause bugs because of a coincidence
of the circumstances in which opt_dead_functions is called:

(a) we do inlining right before dead function elimination, and
    inlining (when successful) eliminates all calls.

(b) for user-defined functions, inlining is always successful, because
    previous optimization passes (during compilation) have reduced
    them to a form that is eligible for inlining.

(c) the function that appears first in the IR can't possibly call a
    built-in function, because built-in functions are always emitted
    before the function that calls them.

It seems unnecessarily fragile to have opt_dead_functions depend on
these coincidences.  And the next patch in this series will break (c).
So I'm reverting the shortcut.  The consequence will be a slight
increase in link time for complex shaders.

This reverts commit c75427f4c8.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This reverts an unnecessary part of commit 4683529048 and fixes misrendering
and an assertion failure in Cogs.

Fixes freedesktop.org bug 39888.

Reviewed-by: Brian Paul <brianp@vmware.com>

If there are any cases left where the st thinks that RGBA -> BGRA
will swap components, it will get what it deserves.

Now the GPU's 2D engine goes unused. What a shame.

validate_program relies on validate_shader_program to fill in errMsg;
empirically, there exist cases where that doesn't happen.

While tracking those down may be worthwhile, initializing the string so
we don't try to ralloc_strdup random garbage also seems wise.

Fixes issues caught by valgrind while running some test case.

NOTE: This is a candidate for stable release branches.

Reviewed-by: Chad Versace <chad@chad-versace.us>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

This is a port of commit 4c7e215c7b to glsl_to_tgsi.

This is a port of commit 62722d9 to glsl_to_tgsi, with minor aesthetic
changes (moved the declaration and assignment of new_inst inside the if block).

DRI2 will throw BadRequest for this when the client is not local, but
DRI2 is an implementation detail and not something callers should have
to know about.  Silently swallow errors in this case, and just propagate
the failure through DRI2Connect's return code.

Note: This is a candidate for the stable release branches.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28125
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>

Fixes a regression in codegen quality for ff_fragment_shader
conversion to GLSL -- glean texCombine produces 7.5% fewer Mesa IR
instructions.

This fixes the remaining regression from ff_fragment_shader in Mesa IR
instruction count, to now being a 1.9% win overall.

This looks just like the VS dump for now.