i965: Add comment to explain the weird-looking shadow compares.

This always looks crazy when I stumble across it, until I remember
what the hardware is doing. Describing it ought to short-circuit
that process next time :)

V2: Fix indents to 6 spaces, not 7.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: glClearBuffer() should only clear a single buffer.

glClearBuffer() is currently clearing all active draw color buffers (all
buffers that have not been set to GL_NONE when calling glDrawBuffers) instead
of only clearing the one it receives as parameter. Altough brw_clear()
receives a bit mask indicating the color buffers that should be cleared,
this mask is ignored when calling brw_blorp_clear_color().

This was breaking the 'fbo-drawbuffers-none glClearBuffer' piglit test.

The patch provides the bit mask to brw_blorp_clear_color() so it can limit
clearing to the color buffers present in the mask.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76832
Reviewed-by: Eric Anholt <eric@anholt.net>
mesa: Fix typo in error message

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
egl-static: fix build after recent radeon winsys changes

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
glsl: Fix typo in interface block comment

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
mesa: Extract is_active_attrib() in shaderapi

The rules are about to get a bit more complex to account for
gl_InstanceID and gl_VertexID, which are system values.

Extracting this first avoids introducing duplication.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Consider gl_VertexID and gl_InstanceID active attribs

Fixes piglit's spec/gl-3.2/get-active-attrib-returns-all-inputs.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
gtest: Update to 1.7.0.

This patch fixes gtest build errors on Mac OS X 10.9.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73106
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
ilo: add TOY_OPCODE_DO

We used to give BRW_OPCODE_DO a special meaning, while we should have used
TOY_OPCODE_DO.
ilo: avoid brw_wm_barycentric_interp_mode in compiler

In preparation for genhw.
ilo: add genhw headers

All except genhw.h are generated by https://github.com/olvaffe/envytools/.
intel_chipset.h is deprecated.
ilo: scripted conversion to genhw headers

Hopefully my four hundred line sed script is correct.
ilo: use only defines from genhw headers

Stop including classic driver headers in genhw.h, with some formatting fixes.
ilo: remove unused headers

Remove intel_*.h.  brw_*.h is still needed by the state dumper and
disassembler.
ilo: remove GPE command size estimation

Use size defines from genhw.
ilo: remove GPE state size estimation

Use size defines from genhw.
i965/gen8: add debug code to show FS disasm with jump locations

Copied from similar code in gen8_vec4_generator.cpp.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
r600g/radeonsi: Use caching buffer manager for textures as well

Significantly reduces BO allocation / destruction overhead for transfers,
e.g. measurable via x11perf -shm{ge,pu}t* with glamor.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
i965: Update comments about Z16 being slow.

We've learned a few things since we originally disabled Z16; this attempts
to summarize the issue.  I am no expert on this subject, though, so the
comment may not be totally accurate.

I did some benchmarking on GM45 and Ironlake, and discovered that for
GLBenchmark 2.7 EgyptHD, using Z16 was 3% slower on GM45 (n=15), and
4.5% slower on Ironlake (n=95).  So, we can drop the "on Ivybridge"
aspect of the comment - it's always slower.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>
i965: Disable Z16 in all APIs.

We originally thought that GL 3.0 required GL_DEPTH_COMPONENT16 to map
exactly to Z16.  However, we misread the specification, thanks in part
to LaTeX reordering the tables in the PDF.

Page 180 of the GL 3.0 specification (glspec30.20080923.pdf) says:
"[...] memory allocation per texture component is assigned by the GL to
match the allocations listed in tables 3.16-3.18 as closely as possible.
[...]

Required Texture Formats
[...]
In addition, implementations are required to support the following sized
internal formats.  Requesting one of these internal formats for any
texture type will allocate exactly the internal component sizes and
types shown for that format in tables 3.16-3.17:"

Notably, however, GL_DEPTH_COMPONENT16 does /not/ appear in table 3.16
or table 3.17.  It appears in table 3.18, where the "exact" rule doesn't
apply, and it falls back to the "closely as possible" rule.

The confusing part is that the ordering of the tables in the PDF is:

Table 3.16 (pages 182-184)
Table 3.18 (bottom of page 184 to top of 185)
Table 3.17 (page 185)

Presumably, people saw table 3.16, then saw the table immediately
following with DEPTH_COMPONENT* formats, and assumed it was 3.17.

Based on a patch by Chia-I Wu, but without the driconf option to force
Z16 to be used.  It's not required, and there's apparently no benefit
to actually using it.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>