glsl: Reject C-style initializers with unknown types.

_mesa_ast_set_aggregate_type walks through declarations initialized with
C-style aggregate initializers and stops when it runs out of LHS
declarations or RHS expressions.

In the example

   vec4 v = {{{1, 2, 3, 4}}};

_mesa_ast_set_aggregate_type would not recurse into the subexpressions
(since vec4s do not contain types that can be initialized with an
aggregate initializer) to set their <constructor_type>s. Later in ::hir
we would dereference the NULL pointer and segfault.

If <constructor_type> is NULL in ::hir we know that the LHS and RHS
were unbalanced and the code is illegal.

Arrays, structs, and matrices were unaffected.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
r300g/swtcl: fix geometry corruption by uploading indices to a buffer

The splitting of a draw call into several draw commands was broken, because
the split sometimes took place in the middle of a primitive. The splitting
was supposed to be dealing with the case when there are more indices than
the maximum size of a CS.

This commit throws that code away and uses a real index buffer instead.

https://bugs.freedesktop.org/show_bug.cgi?id=66558

Cc: mesa-stable@lists.freedesktop.org
r300g/swtcl: fix a lockup in MSAA resolve

Cc: mesa-stable@lists.freedesktop.org
Revert "r300g: allow HiZ with a 16-bit zbuffer"

This reverts commit 631c631cbf5b7e84e42a7cfffa1c206d63143370.

https://bugs.freedesktop.org/show_bug.cgi?id=66921

Cc: mesa-stable@lists.freedesktop.org
llvmpipe: support sRGB framebuffers

Just use the new conversion functions to do the work. The way it's plugged
in into the blend code is quite hacktastic but follows all the same hacks
as used by packed float format already.
Only support 4x8bit srgb formats (rgba/rgbx plus swizzle), 24bit formats never
worked anyway in the blend code and are thus disabled, and I don't think anyone
is interested in L8/L8A8. Would need even more hacks otherwise.
Unless I'm missing something, this is the last feature except MSAA needed for
OpenGL 3.0, and for OpenGL 3.1 as well I believe.

v2: prettify a bit, use separate function for packing.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
i965: Cite the Ivybridge PRM for SFID enum values.

The Ivybridge PRM adds new SFIDs and lists them in a different volume
than Sandybridge, so it's worth adding a reference.

I also removed the BSpec reference, as the section it referred to
was moved somewhere, and I couldn't find it.  This leaves one Haswell
SFID without a citation, but we can add one once the PRMs are out.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Cite the Ivybridge PRM for why the fake MRF range is what it is.

The exact text is in the public docs, so we should cite those.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Cite the Ivybridge PRM for DP message descriptor fields.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Cite the 965 PRM for "the data cache is the sampler cache".

Presumably, this comment exists to justify the usage of
I915_GEM_DOMAIN_SAMPLER for this relocation.  At one point, this was
necessary to ensure that the right flushing was done to keep caches
coherent.  These days, the kernel just flushes everything, so I don't
think it matters.

Still, the comment is interesting, so leave it in place.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Delete "the data cache is the sampler cache" comments on Gen7+.

I cut and pasted these comments from the Gen4 code during Ivybridge
enabling, and didn't understand what they meant at the time.

The data cache is NOT the same as the sampler cache on Ivybridge.
The sampler cache has L1 and L2 caches in addition to the L3 cache,
while data port messages to the "data cache" hit L3 directly.

This means that the sampler domain is technically wrong, but we stopped
caring about read/write domains quite a while ago.  The kernel just
flushes all the caches at the end of each batchbuffer, and our render to
texture code flushes the sampler caches when necessary.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Cite the Ivybridge PRM for multisample surface format notes.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Cite the Sandybridge PRM for Gen7 stencil pitch requirements.

Sadly, the Ivybridge PRM can't be cited, as it is missing the relevant
text for some reason.  However, the Sandybridge PRM has the text Chad
originally quoted, and the modern BSpec has the same text.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Cite the Ivybridge PRM for VS PIPE_CONTROL workarounds.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Update workaround flush comments for Gen6 3DSTATE_VS.

Unfortunately, the workaround text never made it into the Sandybridge
PRM, so we still have to refer to the BSpec.

It also wasn't obvious why we needed this workaround at all, since we
don't currently do VS passthrough - but BLORP can turn off the VS.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Cite the Ivybridge PRM for 3DSTATE_URB_* programming.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Remove old BSpec reference from BLORP's 3DSTATE_WM/PS packets.

The Sandybridge code had a citation for the range of the "Maximum Number
of Threads" field, and the Ivybridge code just mentioned the "BSpec" in
general.  That's documented in the obvious place, so people can find it
without a spec reference.

The real value of the comment is to say "we tried zero, and it exploded,
so program it to a valid number even if pixel shading is off."

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Refer people to brw_tex_layout.c rather than the BSpec.

brw_tex_layout.c sets up the align_w/h fields, and has all the
appropriate spec references already.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Cite the Ivybridge PRM for 3DSTATE_CLEAR_PARAMS notes.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965/Gen4: Zero extra coordinates for ir_tex

We always emit U,V,R coordinates for this message, but the sampler gets
very angry if we pass garbage in the R coordinate for at least some
texture formats.

Fill the remaining coordinates with zero instead.

Fixes broken rendering on GM45 in Source games, and in VDrift.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65236

NOTE: This is a candidate for stable branches.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
osmesa: link against static libglapi library too to get the gl exports

This should fix missing symbols in a osmesa built against shared glapi
osmesa build. All opengl exports were missing that are defined in the
static glapi, so link against both to fix this.

This is a candidate for the stable series.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47824
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>