docs: Set llvmpipe and softpipe note only for MSAA.

Right now, in mesamatrix.net, the footnote is set so that it seems to be
for all the features, while actually it only applies to MSAA.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
freedreno/ir3: don't pass consts to madsh.m16 in MOD logic

madsh.m16 can't handle a const in src1, make sure to unconst it

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
nv50: remove ancient map of rt formats

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
i965: Fix missing CACHE_NEW_WM_PROG in 3DSTATE_PS_EXTRA.

brw->wm.prog_data is covered by CACHE_NEW_WM_PROG, not
BRW_NEW_FRAGMENT_PROGRAM.  So, we should listen to it.

However, I believe that BRW_NEW_FRAGMENT_PROGRAM is sufficient to cover
all the necessary cases - CACHE_NEW_WM_PROG happens in a subset of
cases.  So, the code being wrong shouldn't have triggered bugs.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965: Create prog_data temporary variables in PS state upload code.

prog_data->foo is a bit more readable than brw->wm.prog_data->foo.
The local variable definition is also a great location to put the
obligatory /* CACHE_NEW_WM_PROG */ comment.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965/fs: Handle derivative quality decisions in the front-end.

Kristian noted that there's very little use of brw_wm_prog_key in the
generator, and that it basically just generates what it's told, without
caring about what stage it's handling.

One exception to this is derivative handling.  When handling dFdxCoarse
and dFdxFine, we packed an enum value in a second source register,
explicitly telling the generator what to do.  For dFdx, we specified an
enum value of "please use the hint", then checked the program key in the
generator level code.

A natural method is to define separate FS_OPCODE_DD[XY]_{COARSE,FINE}
opcodes, and have the front-end (which already decides what IR to
generate based on the program key) decide which dPdx/dPdy should
correspond to.  This consolidates the decision making in one place.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/fs: Pass key->render_to_fbo via src1 of FS_OPCODE_DDY_*.

This means the generator doesn't have to look at the key, which is a
little nicer - we're pretty close to no key dependencies at all.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Use brw_wm_prog_data::uses_kill, not gl_fragment_program::UsesKill

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Set prog_data->uses_kill if simulating alpha test via discards.

When using MRT on Gen4-5, we have to simulate GL's alpha test feature
by emitting discards in the fragment shader.  In this case, it makes
sense to set prog_data->uses_kill, which means the fragment shader may
kill pixels via the discard mechanism.

This saves us from having to look an extra key value in a couple of
places, including in the generator.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
mesa: Considers GL_DEPTH_STENCIL_ATTACHMENT a valid argument for FBO invalidation under GLES3

In GLES3, GL_DEPTH_STENCIL_ATTACHMENT is a valid attachment point for the family of functions
that invalidate a framebuffer object (e.g, glInvalidateFramebuffer, glInvalidateSubFramebuffer).
Currently, a GL_INVALID_ENUM error is emitted for this attachment point.

Fixes 21 dEQP test failures under 'dEQP-GLES3.functional.fbo.invalidate.*'.
mesa: Enables GL_RGB and GL_RGBA unsized internal formats for OpenGL ES 3.0

GL_RGB and GL_RGBA are valid internal formats on a GLES3 profile. See
"Table 1. Unsized Internal Formats" at
https://www.khronos.org/opengles/sdk/docs/man3/html/glTexImage2D.xhtml.

Fixes 2 dEQP tests:
- dEQP-GLES3.functional.state_query.internal_format.rgb_samples
- dEQP-GLES3.functional.state_query.internal_format.rgba_samples
mesa: Returns zero samples when querying GL_NUM_SAMPLE_COUNTS when internal format is integer

In GLES3, multisampling is not supported for signed and unsigned integer
internal formats. See https://www.khronos.org/opengles/sdk/docs/man3/docbook4/xhtml/glGetInternalformativ.xml.

Fixes 19 dEQP tests under 'dEQP-GLES3.functional.state_query.internal_format.*'.
mesa: Recompute LegalTypesMask if the GL API has changed

The current code computes ctx->Array.LegalTypesMask just once,
however, computing this needs to consider ctx->API so we need
to make sure that the API for that context has not changed if
we intend to reuse the result.

The context API can change, at least, if we go through
_mesa_meta_begin, since that will always force
API_OPENGL_COMPAT until we call _mesa_meta_end. If any
operation in between these two calls triggers a call to
update_array_format, then we might be caching a value for
LegalTypesMask that will not be right once we have called
_mesa_meta_end and restored the context API.

Fixes the following 179 dEQP tests in i965:
dEQP-GLES3.functional.vertex_arrays.single_attribute.strides.fixed.*
dEQP-GLES3.functional.vertex_arrays.single_attribute.normalize.fixed.*
dEQP-GLES3.functional.vertex_arrays.single_attribute.output_types.fixed.*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.static_draw.*fixed*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.stream_draw.*fixed*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.dynamic_draw.*fixed*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.static_copy.*fixed*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.stream_copy.*fixed*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.dynamic_copy.*fixed*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.static_read.*fixed*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.stream_read.*fixed*
dEQP-GLES3.functional.vertex_arrays.single_attribute.usages.dynamic_read.*fixed*
dEQP-GLES3.functional.vertex_arrays.multiple_attributes.input_types.3_*fixed2*
dEQP-GLES3.functional.draw.random.{2,18,28,68,83,106,109,156,181,191}
glsl: Don't allow gl_FragData[i], with i>0 in GLES shaders

The OpenGL ES Shading Language specification describes the
values that may be output by a fragment shader. These are
gl_FragColor and gl_FragData[0]. Multiple render targets
are not supported in GLES.

Fixes dEQP test:
  * dEQP-GLES3.functional.shaders.fragdata.invalid_assign_to_1
glsl: invariant qualifier is not valid for shader inputs in GLSL ES 3.00

GLSL ES 3.00 spec, chapter 4.6.1 "The Invariant Qualifier",

    Only variables output from a shader can be candidates for invariance. This
    includes user-defined output variables and the built-in output variables.
    As only outputs can be declared as invariant, an invariant output from one
    shader stage will still match an input of a subsequent stage without the
    input being declared as invariant.

This patch fixes the following dEQP tests:

dEQP-GLES3.functional.shaders.qualification_order.variables.valid.invariant_interp_storage_precision
dEQP-GLES3.functional.shaders.qualification_order.variables.valid.invariant_interp_storage
dEQP-GLES3.functional.shaders.qualification_order.variables.valid.invariant_storage_precision
dEQP-GLES3.functional.shaders.qualification_order.variables.valid.invariant_storage
dEQP-GLES3.functional.shaders.qualification_order.variables.invalid.invariant_interp_storage_precision_invariant_input
dEQP-GLES3.functional.shaders.qualification_order.variables.invalid.invariant_interp_storage_invariant_input
dEQP-GLES3.functional.shaders.qualification_order.variables.invalid.invariant_storage_precision_invariant_input
dEQP-GLES3.functional.shaders.qualification_order.variables.invalid.invariant_storage_invariant_input

No piglit regressions observed.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
glsl: don't allow invariant qualifiers for interface blocks in GLSL ES

From GLSL ES 3.0, chapter 4.3.7 "Interface Blocks", page 38:

"GLSL ES 3.0 does not support interface blocks for shader inputs or outputs."

and from GLSL ES 3.0, chapter 4.6.1 "The invariant qualifier", page 52.

"Only variables output from a shader can be candidates for invariance. This
includes user-defined output variables and the built-in output variables. As
only outputs can be declared as invariant, an invariant output from one shader
stage will still match an input of a subsequent stage without the input being
declared as invariant."

From GLSL ES 1.0, chapter 4.6.1 "The invariant qualifier", page 37.

"Only the following variables may be declared as invariant:
* Built-in special variables output from the vertex shader
* Varying variables output from the vertex shader
* Built-in special variables input to the fragment shader
* Varying variables input to the fragment shader
* Built-in special variables output from the fragment shader."

This patch fixes the following dEQP tests:

dEQP-GLES3.functional.shaders.declarations.invalid_declarations.invariant_uniform_block_2_vertex
dEQP-GLES3.functional.shaders.declarations.invalid_declarations.invariant_uniform_block_2_fragment

No piglit regressions.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
glsl: A shader cannot redefine or overload built-in functions in GLSL ES 3.00

Create a new search function to look for matching built-in functions by name
and use it for built-in function redefinition or overload in GLSL ES 3.00.

GLSL ES 3.0 spec, chapter 6.1 "Function Definitions", page 71

"A shader cannot redefine or overload built-in functions."

In case of GLSL ES 1.0 spec, chapter 6.1 "Function Definitions", page 54

"Function names can be overloaded. This allows the same function name to be
used for multiple functions, as long as the argument list types differ. If
functions’ names and argument types match, then their return type and
parameter qualifiers must also match. Function signature matching is based on
parameter type only, no qualifiers are used. Overloading is used heavily in the
built-in functions. When overloaded functions (or indeed any functions) are
resolved, an exact match for the function's signature is sought. This includes
exact match of array size as well. No promotion or demotion of the return type
or input argument types is done. All expected combination of inputs and
outputs must be defined as separate functions."

So this check is specific to GLSL ES 3.00.

This patch fixes the following dEQP tests:

dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_vertex
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_fragment
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function_vertex
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function_fragment

No piglit regressions.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
main/glsles: return two minor digits for SHADING_LANGUAGE_VERSION

For OpenGL ES 3.0 spec, the minor number for SHADING_LANGUAGE_VERSION is always
two digits, matching the OpenGL ES Shading Language Specification release
number. For example, this query might return the string "3.00".

This test fixes the following dEQP test:

   dEQP-GLES3.functional.state_query.string.shading_language_version

No piglit regression observed.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>