r600g: Add support for GL_ARB_texture_buffer_range

Reviewed-by: Marek Olšák <maraeo@gmail.com>
intel: Move the max_gtt_map_object_size estimation to intel_context.

We need know this in order to decide what tiling mode to use.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
intel: Refactor code in intel_miptree_choose_tiling().

This reduces the nesting level slightly, and in my opinion, makes it a
bit easier to follow.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
intel: Fall back to X-tiling when larger than estimated aperture size.

If a region is larger than the estimated aperture size, we map/unmap it
by copying with the BLT engine.  Which means we can't use Y-tiling.

Fixes Piglit max-texture-size and tex3d-maxsize, which regressed in my
recent change to use Y-tiling by default on Gen6+.  This was due to a
botched merge conflict resolution.

v2: Return a mask of valid tilings from intel_miptree_select_tiling.
    This allows us to avoid the X-tiling fallback if Y-tiling is actually
    mandatory.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
egl/x11: Fix initialisation of swap_interval

The EGLConfig attributes EGL_MIN/MAX_SWAP_INTERVAL were incorrectly set to
0 and 0. This prevented clients from setting the swap interval to a
reasonable value, like 1 or 2.

Swap interval worked correctly in Mesa 9.0. The commit below introduced
the bug.

    commit 7e9bd2b2ed35a440a96362417100a7e43715d606
    Author: Eric Anholt <eric@anholt.net>
    Date:   Tue Sep 25 14:05:30 2012 -0700
	egl: Add support for driconf control of swapinterval.

Note: This is a candidate for the 9.1 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63078
[chadv: Wrote commit message]
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
st/mesa: fix UBO offsets.

Reported and tested by degasus on #radeon.

Note: This is a candidate for the 9.1 branch

Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon/winsys: add uvd ring support to winsys v3

Separated from UVD patch for clarity.

v2: sync with next tree for 3.10
v3: as pointed out by Andreas Bool check for drm minor >= 32

http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.com>
radeon/uvd: add UVD implementation v5

Just everything you need for UVD with r600g and radeonsi.

v2: move UVD code to radeon subdir, clean up build system additions,
    remove an unused SI function, disable tiling on SI for now.
v3: some minor indentation fix and rebased
v4: dpb size calculation fixed
v5: implement proper fall-back in case the kernel doesn't support UVD,
    based on patches from Andreas Boll but cleaned up a bit more.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
glsl: Fix (and validate) comment above glsl_type::name.

The comment above glsl_type::name claimed that it could sometimes be
NULL.  This was wrong--it is never NULL.  Many error handling paths
would segfault if it were.

Fix the comment and add assertions to validate that it really is never
NULL.
i965: Rename backend_visitor::prog to shader_prog.

The next patch is going to change the type of vec4_visitor::vp from
struct gl_vertex_program * to struct gl_program *, and rename it.  The
sensible name to change it to is vec4_visitor::prog.  However, prog is
already used in backend_visitor (which vec4_visitor derives from).
Since backend_visitor::prog is of type struct gl_shader_program *, it
makes sense to rename it to shader_prog.
i965/vs: Make type of vec4_visitor::vp more generic.

The vec4_visitor functions don't use any VS specific data from
vec4_visitor::vp.  So rename it to "prog" and change its type from
struct gl_vertex_program * to struct gl_program *.  This will allow
the code to be re-used for geometry shaders.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

v2: Use the name "prog" rather than "p".
i965: Generalize computation of VUE map in preparation for GS.

This patch modifies the arguments to brw_compute_vue_map() so that
they no longer bake in the assumption that we are generating a VUE map
for vertex shader outputs.  It also makes the function non-static so
that we can re-use it for geometry shader outputs.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965/vs: Remove brw_vs_prog_data pointer from brw_vs_compile.

In patches that follow, we'll be splitting structs brw_vs_prog_data
and brw_vs_compile into a vec4-generic base struct and a VS-specific
derived struct (this will allow the vec4-generic code to be re-used
for geometry shaders).  Having brw_vs_compile point to
brw_vs_prog_data makes it difficult to do this cleanly.

Fortunately most of the functions that use brw_vs_compile (those in
the vec4_visitor class) already have access to brw_vs_prog_data
through a separate pointer (vec4_visitor::prog_data).  So all we have
to do is use that pointer consistently, and plumb prog_data through
the few remaining functions that need access to it.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965/vs: split brw_vs_compile into generic and VS-specific parts.

This will allow the generic parts to be re-used for geometry shaders.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965/vs: split brw_vs_prog_key into generic and VS-specific parts.

This will allow the generic parts to be re-used for geometry shaders.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965/vs: split brw_vs_prog_data into generic and VS-specific parts.

This will allow the generic parts to be re-used for geometry shaders.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

v2: Put urb_read_length and urb_entry_size in the generic struct.
i965/vs: Make vec4_vs_visitor class derived from vec4_visitor.

This patch just creates the derived class; later patches will migrate
VS-specific functions and data structures from the base class into the
derived class.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965/vs: Make some vec4_visitor functions virtual.

This patch makes the following vec4_visitor functions virtual, since
they will need to be implemented differently for vertex and geometry
shaders.  Some of the functions are renamed to reflect their generic
purpose, rather than their VS-specific behaviour:

- setup_attributes
- emit_attribute_fixups (renamed to emit_prolog)
- emit_vertex_program_code (renamed to emit_program_code)
- emit_urb_writes (renamed to emit_thread_end)

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965/vs: Add virtual function make_reg_for_system_value().

The system values handled by vec4_visitor::visit(ir_variable *) are
VS-specific (vertex ID and instance ID).  This patch moves the
handling of those values into a new virtual function,
make_reg_for_system_value(), so that this VS-specific code won't be
inherited by geomtry shaders.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965/vs: move ARB_vertex_program functions to vec4_vs_visitor.

This patch moves functions from vec4_visitor to vec4_vs_visitor that
deal with ARB (assembly) vertex programs.  There's no point in having
these functions in the base class since we don't intend to support
assembly programs for the GS stage.  The following functions are
moved:

- setup_vp_regs
- get_vp_dst_reg
- get_vp_src_reg

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>