r300-gallium, radeon-gallium: Nuke gb_pipes from orbit.

See the previous commit for an explanation. This is just all the support code
for GB_TILE_CONFIG.

r300-gallium: Don't set GB_TILE_CONFIG (in userspace.)

This accompanies kernel patches that make GB_TILE_CONFIG's various members
completely controlled in DRM.

GB_TILE_CONFIG has the following controls:
 - The number of GB (pixel) pipes enabled
 - The size and style of tiling
 - Subpixel precision (either 1/12 or 1/16)

Per airlied and glisse, userspace and kernel will now agree (always) on
a subpixel precision of 1/12, and tiling will always be kernel-controlled.

r300-gallium: Clean up more invariant state.

GA_ENHANCE is now the kernel's problem.

r300-gallium: Update XXX.

Lops work fine as long as HW TCL is off. (I think I know why.)

r300-gallium: Correct default MSPOS.

Per agd5f.

r300-gallium: vs: Fix vert shader init.

Makes the last three commits suck much less. :3

r300-gallium: r500-fs: Enable depth writes, kinda.

Should work, but doesn't. Hm.

r300-gallium: Comment out useless debugging code.

Those parts are nearly solid compared to the shaders.

r300-gallium: vs: Dupe tokens, better debug, count spurious insts.

r300-gallium: Die on bad texture formats.

Odds are good that we'll die later anyway, so we might as well do it before
we start dancing on random memory.

r300-gallium: Update floating-point params too.

Even though we *can* render 10,000-pixel-wide lines, let's not advertise it.

r300-gallium: Update screen caps.

Anisotropic filtering should work, and OQ is broken.

intel-gallium: Fix trace_drm integration.

Compile-tested only, sorry.

Create common trace_drm code, add to radeon_winsys.

r300-gallium: Various cleanups leftover from before.

BEGIN/END_CS pair, a few asserts, and a slightly more correct VTE setup.

gallium: remove occlusion_count flag from depth-stencil state

Drivers can just keep track of whether they are within a query
by monitoring the begin/end query callbacks.  The flag adds no
information beyond that.

Only softpipe was examining this flag -- it has been fixed up
and retested with demos/arbocclude.

gallium-intel: Enable trace driver

trace: Export enabled status

trace: Unwrap buffer in texture_blanket

trace: If either shader is disabled don't draw

trace: Put shaders on a list in the context

trace: Move state dump functions to tr_dump_state.[c|h]

intel: Don't complain on falling back from PBO fastpaths.

Instead, stash the debug info under the handy debug flag.

Bug #20053

mesa: Mark FBOs with compressed color attachments as FBO-incomplete.

Both EXT_fbo and ARB_fbo agree on this.  Fixes a segfault in the metaops
mipmap generation in Intel for SGIS_generate_mipmap of S3TC textures in
Regnum Online.

Bug #21654.

gallium-intel: Build with scons

st/egl: Use proper Makefile

i915: Fix 945 cube map layout for the small mipmaps along the bottom.

Bug #21691.

i915: Use Stencil.Enabled instead of Stencil._Enabled in DrawBuffers.

The _Enabled field isn't updated at the point that DrawBuffers is called,
and the Driver.Enable() function does the testing for stencil buffer
presence anyway.

bug #21608 for Radeon

i915: Only use the new 945 cube layout for compressed textures.

The docs actually explain this, but not in a terribly clear manner.
This nearly fixes the piglit cubemap testcase, except that something's
going wrong with the nearest filtering at 2x2 sizes in the testcase.
Looks good by visual inspection, though.

Bug #21692

i965: Fix varying payload reg assignment for the non-GLSL-instructions path.

I don't have a testcase for this, but it seems clearly wrong.

i965: Fix register allocation of GLSL fp inputs.

Before, if the VP output something that is in the attributes coming into
the WM but which isn't used by the WM, then WM would end up reading subsequent
varyings from the wrong places.  This was visible with a GLSL demo
using gl_PointSize in the VS and a varying in the WM, as point size is in
the VUE but not used by the WM.  There is now a regression test in piglit,
glsl-unused-varying.

intel: Use FRONT_AND_BACK for StencilOp as well.

intel: Use GL_FRONT_AND_BACK for stencil clearing.

This comes from a radeon-rewrite fallback fix, but may also fix stencil
clear failure when the polygon winding mode is flipped.

r300-gallium: Correct VTE setup for surface_fill, make surface_copy emit right.

i965: fix 1D texture borders with GL_CLAMP_TO_BORDER

With 1D textures, GL_TEXTURE_WRAP_T should be ignored (only
GL_TEXTURE_WRAP_S should be respected).  But the i965 hardware
seems to follow the value of GL_TEXTURE_WRAP_T even when sampling
1D textures.

This fix forces GL_TEXTURE_WRAP_T to be GL_REPEAT whenever 1D
textures are used; this allows the texture to be sampled
correctly, avoiding "imaginary" border elements in the T direction.

This bug was demonstrated in the Piglit tex1d-2dborder test.
With this fix, that test passes.

i965: send all warnings through _mesa_warning()

One warning message:
   drm_i915_getparam: -22

was still being sent to fprintf().  This causes all Piglit tests to fail,
even with MESA_DEBUG=0.

Using _mesa_warning() to emit the message allows the general Mesa controls
for messages like this to be applied.

r300-gallium: Clean up outdated comments.

r300-gallium: Space accounting for textures.

Merge branch 'mesa_7_5_branch'

intel: added null ptr check

Fixes segfault in context tear-down when glClear was never called.

docs: GL_APPLE_vertex_array_object for Gallium drivers and Intel DRI drivers

intel: enable GL_APPLE_vertex_array_object

No special driver changes are needed for this extension.

st/mesa: enable GL_APPLE_vertex_array_object for gallium drivers

Merge branch 'mesa_7_5_branch'

Conflicts:

src/mesa/main/arrayobj.c
src/mesa/main/arrayobj.h
src/mesa/main/context.c

intel: create a private gl_array_object for intel_clear_tris(), fix bug 21638

gl_array_object encapsulates a set of vertex arrays (see the
GL_APPLE_vertex_array_object extension).
Create a private gl_array_object for drawing the quad for intel_clear_tris()
so we don't have to worry about the user's vertex array state.
This fixes the no-op glClear bug #21638 and removes the need to call
_mesa_PushClientAttrib() and _mesa_PopClientAttrib().

mesa: delete array objects before buffer objects during context tear-down

The former may point to the later.

mesa: clean-up vertex array object VBO unbinding and delete/refcounting

Don't really delete vertex array objects until the refcount hits zero.
At that time, unbind any pointers to VBOs.
(cherry picked from commit 32b851c80792623195069d7a41a5808cff3b2f6f)

mesa: reference counting for gl_array_object

Every kind of object that can be shared by multiple contexts should be
refcounted.
(cherry picked from commit 1030bf0ded2a88a5e27f7a4d393c11cfde3d3c5a)

i965: enable additional code in emit_fb_write()

Not 100% sure this is right, but the invalid assertion is fixed...

i965: increase BRW_EU_MAX_INSN

i965: comment

r300-gallium: add missing semicolon

Yeah, that was stupid

r300-gallium: duplicate tokens in create_fs_state

This was all phoenix64's idea. Credit goes to him

progs/trivial: update .gitignore with new binaries

intel: Skip the DRI2 renderbuffer update when doing Viewport on an FBO.

intel: Map write-only buffer objects through the GTT when possible.

This looks to be a win of a few percent in cairogears with new vbo code,
thanks to not polluting caches.

i915: Fix driver after HW glGenerateMipmap commit.

swrast: update/restore the opt_sample_rgb/rgba_2d() functions

glXChooseVisual: Only consider fbconfig if we can get the corresponding visual.

This can fail, e.g. when XLIB_SKIP_ARGB_VISUALS=1 is set.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524794 and
http://bugs.freedesktop.org/show_bug.cgi?id=21600 .

Test either GL_FRONT_LEFT or GL_FRONT for front-buffer rendering

For non-stereo visuals, which is all we support, we treat
GL_FRONT_LEFT as GL_FRONT.  However, they are technically different,
and they have different enum values.  Test for either one to determine
if we're in front-buffer rendering mode.

This fix was suggested by Pierre Willenbrock.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 2085cf24628be7cd297ab0f9ef5ce02bd5a006e2)

Merge branch 'mesa_7_5_branch'

Conflicts:

Makefile
src/mesa/main/version.h

st: do proper refcounting for framebuffer surfaces

trivial: destroy window upon exit

r300-gallium: unbreak build

r300-gallium: Setup surface in r300_surface_copy.

I haven't tested, but this may unbreak surface copies.

r300-gallium: Cleanup some compile warnings.

r300-gallium: Cleanup PSC for HW TCL.

Still dies in assert, but at least it's not my assert anymore. :3

radeon-gallium: Forgot a typedef.

radeon-gallium: Support new info ioctls in addition to classic getparams.

This makes non-hybrid kernels like newttm from drm-next-radeon work
while avoiding breakage with Fedora/Ubuntu/etc.

mesa: updated comments for _mesa_generate_mipmap()

i965: handle extended swizzle terms (0,1) in get_src_reg()

Fixes failed assertion in progs/glsl/twoside.c (but still wrong rendering).

mesa: better handling/printing of driver-specific opcodes, register files

Drivers such as i965 define extra instruction opcodes and register files.
Improve the program printing code to handle those opcodes/files better.

mesa: Fixed a texture memory leak

The current texture for any particular texture unit is given an additional
reference in update_texture_state(); but if the context is closed before
that texture can be released (which is quite frequent in normal use, unless
a program unbinds and deletes the texture and renders without it to force
a call to update_texture_state(), the memory is lost.

This affects general Mesa; but the i965 is particularly affected because
it allocates a considerable amount of additional memory for each allocated
texture.

(cherry picked from master, commit c230767d6956b63a2b101acb48f98823bb5dd31a)

mesa: added more gallium Makefiles to tarball list

gallium: replace lib with $(LIB_DIR)

radeon-gallium: Clean up some of the BO counting logic.

r300-gallium: vs: Make imms work, cleanup some of the switches.

r300-gallium: Start VS dumper.

r300-gallium: vs: Add SLT, clean up MAX.

This should be all the opcodes for basic TCL.

r300-gallium: vs: Add MAX.

r300-gallium: vs: Add scalar setup, RSQ.

Icky icky icky icky. Icky icky, icky icky. Icky.

r300-gallium: vs: Add writemasks.

r300-gallium: Fix bad cast. Space accounting completely works now.

Boy, is my face red. :C

r300-gallium, radeon: BO handling fixes, some useful asserts.

radeon-gallium: Shut up Valgrind.

r300-gallium, radeon: A couple cleanups.

Trying to track down goddamn bugs. :C

r300-gallium: Finish space accounting.

Still broken...

i965: improve debug logging

Looking for memory leaks that were causing crashes in my environment
in a situation where valgrind would not work, I ended up improving
the i965 debug traces so I could better see where the memory was
being allocated and where it was going, in the regions and miptrees
code, and in the state caches.  These traces were specific enough
that external scripts could determine what elements were not being
released, and where the memory leaks were.

I also ended up creating my own backtrace code in intel_regions.c,
to determine exactly where regions were being allocated and for what,
since valgrind wasn't working.  Because it was useful, I left it in,
but disabled and compiled out.  It can be activated by changing a flag
at the top of the file.

i965: fix memory leak in context/renderbuffer region management

A temporary change to the intelMakeCurrent() function to make
it work with frame buffer objects causes the static regions
associated with the context (the front_region, back_region,
and depth_region) to take on an additional reference, with
no corresponding release.  This causes a memory leak if a
program repeatedly creates and destroys contexts.

The fix is the corresponding hack, to unreference these
regions when the context is deleted, but only if the
framebuffer objects are still present and the same
regions are still referenced within.

Both sets of code have comment blocks referring to each
other.

i965: fix segfault on low memory conditions

When out of memory (in at least one case, triggered by a longrunning
memory leak), this code will segfault and crash.  By checking for the
out-of-memory condition, the system can continue, and will report
the out-of-memory error later, a much preferable outcome.

mesa: Fixed a texture memory leak

The current texture for any particular texture unit is given an additional
reference in update_texture_state(); but if the context is closed before
that texture can be released (which is quite frequent in normal use, unless
a program unbinds and deletes the texture and renders without it to force
a call to update_texture_state(), the memory is lost.

This affects general Mesa; but the i965 is particularly affected because
it allocates a considerable amount of additional memory for each allocated
texture.

intel: Add a metaops version of glGenerateMipmapEXT/SGIS_generate_mipmaps.

In addition to being HW accelerated, it avoids the incorrect
(black) rendering of the mipmaps that SW was doing in fbo-generatemipmap.
Improves the performance of the mipmap generation and drawing in
fbo-generatemipmap by 30%.

intel: Put the constant texcoords used in metaops into a vbo.

Make this be its own function for setup/teardown of the binding of these
texcoords.  No performance difference in the engine demo (I just felt dirty
not using a VBO for this), and I think it should be more resilient to
interference from current GL state.

mesa: omit files that were removed from git

mesa: set version to 7.5-rc1

i965: const qualifiers

mesa: raise MAX_VARYING (number of shader varying vars) to 16

16 is the limit for now because of various 32-bit bitfields.

mesa: assertions to check for too many vertex outputs or fragment inputs

glsl: check number of varying variables against the limit

Link fails if too many varying vars.

mesa: issue warning for out of bounds array indexes