meta: Add default precision qualifier to all fragement shaders

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

glsl: Add default precision qualifiers for ES builtins

Once the compiler proplerly checks for default precision qualifiers,
these shaders will cease to compile.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

glsl: Remove extra "types" from error message

Send it straight to the Department of Redundancy Department.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Make the VS binding table as small as possible.

For some reason, we didn't use this information even though the VS
backend has computed it (albeit poorly) for ages.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/vs: Rework binding table size calculation.

Unlike the FS, the VS backend already computed the binding table size.
However, it did so poorly: after compilation, it looked to see if any
pull constants/textures/UBOs were in use, and set num_surfaces to the
maximum surface index for that category.  If the VS only used a single
texture or UBO, this overcounted by quite a bit.

The shader time surface was also noted at state upload time (during
drawing), not at compile time, which is inefficient.  I believe it also
had an off by one error.

This patch computes it accurately, while also simplifying the code.

It also renames num_surfaces to binding_table_size, since num_surfaces
wasn't actually the number of surfaces used.  For example, a VS that
used one UBO and no other surfaces would have set num_surfaces to
SURF_INDEX_VS_UBO(1) == 18, rather than 1.  A bit of a misnomer there.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/vs: Plumb brw_vec4_prog_data into vec4_generator().

This will be useful for the next commit.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Make the FS binding table as small as possible.

Computing the minimum size was easy, and done at compile-time for no
extra overhead here.  Making the binding table smaller wastes less batch
space.

Adding the CACHE_NEW_WM_PROG dirty bit isn't strictly necessary, since
other atoms depend on it and flag BRW_NEW_SURFACES.  However, it's best
to add it for clarity and safety.  It shouldn't add any new overhead.

v2: Use binding_table_size, rather than max_surface_index.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs: Track the binding table size in brw_wm_prog_data.

By tracking the maximum surface index used by the shader, we know just
how small we can make the binding table.

Since it depends entirely on the shader program, we can just compute
it once at compile time, rather than at binding table emit time (which
happens during drawing).

v2: Store binding_table_size, rather than max_surface_index, for
    consistency with the VS (which needs to be able to represent 0
    surfaces).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Use SURF_INDEX_DRAW() for drawbuffer binding table indices.

SURF_INDEX_DRAW() has been the identity function since the dawn of time,
and both the shader code and binding table upload code relied on that,
simply using X rather than SURF_INDEX_DRAW(X).

Even if that continues to be true, using the macro clarifies the code.

The comment about draw buffers needing to be first in order for
headerless render target writes to work turned out to be wrong; with
this change, SURF_INDEX_DRAW can be changed to arbitrary indices and
everything continues working.

The confusion was over the "Render Target Index" field in the FB write
message header.  If it were a binding table index, then RT 0 would have
to be at index 0 for headerless FB writes to work.  However, it's
actually an index into the blend state table, so there's no problem.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Paul Berry <stereotype441@gmail.com>

i965: Shorten sampler loops in key setup.

Now that we have the number of samplers available, we don't need to
iterate over all 16.  This should be particularly helpful for vertex
shaders.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Make sampler counts available for the entire drawing operation.

Previously, we computed sampler counts when generating the SAMPLER_STATE
table.  By computing it earlier, we should be able to shorten a bunch of
loops.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Split the brw_samplers atom into separate FS/VS stages.

This allows us to avoid uploading the VS sampler state table if only the
fragment program changes.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Upload separate VS and FS sampler state tables.

Now, each shader stage has a sampler state table that only refers to the
samplers actually used by that problem.  This should make the VS table
non-existant or very small.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Make upload_sampler_state_table a virtual function.

This allows us to coalesce the brw_samplers and gen7_samplers atoms.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Upload separate per-stage sampler state tables.

Also upload separate sampler default/texture border color entries.

At the moment, this is completely idiotic: both tables contain exactly
the same contents, so we're simply wasting batch space and CPU time.

However, soon we'll only upload data for textures actually /used/ in
a particular stage, which will usually make the VS table empty and
very likely eliminate all redundancy.  This is just a stepping stone.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Un-hardcode border color table from update_sampler_state().

Like the previous patch, this simply pushes direct access to brw->wm up
one level in the call chain.  Rather than passing the whole array, we
just pass a pointer to the correct spot in the array, similar to what we
do for the actual sampler state structure.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Un-hardcode border color table from upload_default_color.

When we begin uploading separate sampler state tables for VS and FS,
we won't be able to use &brw->wm.sdc_offset[ss_index].  By passing it in
as a parameter, we push the problem up to the caller.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Split sampler count variable to be per-stage.

Currently, we only have a single sampler state table shared among all
stages, so we just copy wm.sampler_count into vs.sampler_count.

In the future, each shader stage will have its own SAMPLER_STATE table,
at which point we'll need these separate sampler counts.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Re-enable global copy propagation.

I believe the data flow analysis actually works now, and it should be
safe to re-enable global copy propagation.  It even does things now.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Fix computation of livein.

Since the initial value for livein is an overestimation (0xffffffff),
it's extremely likely that it will shrink, which means we can't simply
OR in new bits - we need to fully recompute it based on the current
liveout values.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Fully recompute liveout at each step.

Since we start with an overestimation of livein (0xffffffff), successive
steps can actually take away values.  This means we can't simply OR in
new liveout values; we need to recompute it from scratch at each
iteration of the fixed-point algorithm.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Skip the initial block when updating livein/liveout.

The starting block always has livein = 0 and liveout = copy.  Since we
start with real data, not estimates, there's no need to refine it with
the fixed point algorithm.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Drop unnecessary and incorrect liveout initialization.

The previous commit properly initialized liveout.  This previous
(and incorrect) initialization is no longer necessary.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Properly initialize the livein/liveout sets.

Previously, livein was initialized to 0 for all blocks.  According to
the textbook, it should be the universal set (~0) for all blocks except
the one representing the start of the program (which should be 0).

liveout also needs to be initialized to COPY for the initial block.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Use the COPY set in the calculation for liveout.

According to page 360 of the textbook, the proper formula for liveout
is:

CPout(n) = COPY(i) union (CPin(i) - KILL(i))

Previously, we omitted COPY.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Simplify liveout calculation.

Excluding the existing liveout bits is a deviation from the textbook
algorithm.  The reason for doing so was to determine if the value
changed, which means the fixed-point algorithm needs to run for another
iteration.

The simpler way to do that is to save the value from step (N-1) and
compare it to the new value at step N.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Create the COPY() set for use in copy propagation dataflow.

This is the "COPY" set from Muchnick's textbook, which is necessary
to do the dataflow algorithm correctly.

v2: Simplify initialization based on Paul Berry's observation that
    out_acp contains exactly what needs to be in the COPY set.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Rename setup_kills() to setup_initial_values().

Although this function currently only initializes the KILL set, it will
soon initialize other data flow sets as well.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Separate the updating of liveout/livein.

To compute the actual liveout/livein data flow values, we start with
some initial values and apply a fixed-point algorithm until they settle.

Previously, we iterated through all blocks, updating both liveout and
livein together in one pass.  This is awkward, since computing livein
for a block requires knowing liveout for all parent blocks.  Not all
of those parent blocks may have been processed yet.

This patch separates the two.  First, we update liveout for all blocks.
At iteration N of the fixed-point algorithm, this uses livein values
from iteration N-1.  Secondly, we update livein for all blocks.  At
step N, this uses the liveout information we just computed (in step N).

This ensures each computation has a consistent picture of the data,
rather than seeing an random mix of data from steps N-1 and N depending
on the order of the blocks in the CFG data structure.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Rename "cont" to "progress" in dataflow algorithm.

This variable indicates that the fixed-point algorithm made changes to
the data at this step, so it needs to run for another iteration.

"progress" seems a nicer name for that.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Switch to a do-while loop in copy propagation dataflow.

The fixed-point algorithm needs to run at least once, so a do-while loop
is more natural.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Skip global copy propagation step.

The dataflow analysis used for global copy propagation is severely
broken, and I believe it doesn't actually do anything.  Fixing it will
require a lot of changes, each of which might break things.

Once all the fixes land, we can re-enable this.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

vl/buffers: consistent use on VL_MAX_SURFACES

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

st/vdpau: drop unnecessary variable prof

Any decent compiler will do this for us, although doing this
will make grepping through the code alot easier.

v2: In both mixer and query interface
v3: rebase

Reviewed-by: Christian König <christian.koenig@amd.com> [v1]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

vl/idct: cleanup all idct buffers

Code should loop through and cleanup the three (VL_NUM_COMPONENTS) idct
buffers, rather than doing the first one three times.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

vl/buffer: add sanity check after CALLOC_STRUCT

Check if we have successfully allocated memory.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

st/xvmc: exit gracefully if we fail to create video buffer

Free any allocated memory and return BadAlloc if create_video_buffer()
has failed to create a buffer.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

st/vdpau: don't try to create video buffer when the format is FORMAT_NONE

Not seen in the wild yet, but seems like a reasonable thing to do.
[suggested by Christian]

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

vdpau/vl 422 chroma width/height mix up

I was looking into some minor 422 issues/discrepencies I noticed long
ago using vdpau on my rv790.

I noticed that there is code that is halving height rather than width -
422 is full height AFAIK.

Making the changes below doesn't actually make any noticable difference
to what I was looking into.

Maybe there are more but here's three I've found so far

Reviewed-by: Christian König <christian.koenig@amd.com>

radeonsi: Ensure fmask_format is initialized in release builds.

Fixes "Uninitialized scalar variable" defect reported by Coverity.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

i965: STATIC_ASSERT that there aren't too many BRW_NEW_* flags.

We are getting close to the maximum number of BRW_NEW_* bits that can
be stored in brw->state.dirty.brw without overflowing 32 bits, and
geometry shaders are going to add more.  Add a STATIC_ASSERT so that
we will be alerted when we need to switch to 64 bits.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

vl: add entrypoint to is_video_format_supported

Signed-off-by: Christian König <christian.koenig@amd.com>

vl: add entrypoint to get_video_param

Signed-off-by: Christian König <christian.koenig@amd.com>

vl: rename pipe_video_decoder to pipe_video_codec

Signed-off-by: Christian König <christian.koenig@amd.com>

vl: rename enum pipe_video_codec to pipe_video_format

Signed-off-by: Christian König <christian.koenig@amd.com>

vl: use a template for create_video_decoder

Signed-off-by: Christian König <christian.koenig@amd.com>

glsl: don't eliminate texcoords that can be set by GL_COORD_REPLACE

Tested by examining generated TGSI shaders from piglit/glsl-routing.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Henri Verbeet <hverbeet@gmail.com>
Tested-by: Henri Verbeet <hverbeet@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

nv50: allow non-nv12 buffers to be created, just pass them through to vl

Since we expose non-NV12 formats as supported when there is no decoer
profile selected, make sure that those formats are actually allowed to
be allocated.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

dri: Choose a decent global driNConfigOptions.

Previously, we were asserting that each driver specified an NConfigOptions
exactly equal to the number of options they supplied, leading to frequent
bugs when people would forget to adjust the value when adjusting driver
options.  Instead, just overallocate the table by a bit and leave sanity
checking to the assert in findOption().

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Improve comments for driver hooks in intel_buffer_object.c.

Consistently using a "The ___ driver hook." line at the the top of each
function's comment block makes it easy to see at a glance what function
is being implemented.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Split intel_upload code out into a separate file.

This code upload performs batched uploads via a BO.  By moving it out to
a separate file, intel_buffer_objects.c only provides the core buffer
object functionality.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Move GL_APPLE_object_purgeable functionality into a new file.

GL_APPLE_object_purgeable creates a mechanism for marking OpenGL objects
as "purgeable" so they can be thrown away when system resources become
scarce.  It specifically applies to buffer objects, textures, and
renderbuffers.

The intel_buffer_objects.c file provides core functionality for GL
buffer objects, such as MapBufferRange and CopyBufferSubData.  Having
texture and renderbuffer functionality in that file is a bit strange.

The 2010 copyright on the new file is because Chris Wilson first added
this code in January 2010 (commit 755915fa).

v2: Actually remember to call the new dd table setup function.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

radeonsi: fix feature support reporting

broken by 21d9a1b5ef51ce449e9a82641d0d605c5448b41c

clover: Fix linkage of libOpenCL

Clover needs the option component of llvm.

Reviewed-by: Tom Stellard <tom@stellard.net>
Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>

radeonsi: require LLVM 3.4 for MSAA

radeonsi: don't make scanout resources linear except for cursors

The surface allocator understands the scanout flag just fine.

This seems to improve performance for Ubuntu Unity on top of st/xorg
and it fixes the cursor.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: remove useless code from tex_fetch_args

The array slice has already been added to "address".

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: disable unbound colorbuffers

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: port texture improvements from r600g

This started as an attempt to add support for MSAA texture transfers and
MSAA depth-stencil decompression for the DB->CB copy path.
It has gotten a bit out of control, but it's for the greater good.

Some changes do not make much sense, they are there just to make it look
like the other driver.

With a few cosmetic modifications, r600_texture.c can be shared with
a symlink.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: implement texture fetching for compressed MSAA textures (v2)

v2: use resource slots 16..31 for FMASK textures

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: add FMASK texture binding slots and resource setup (v2)

v2: bind FMASK textures to shader resource slots 16..31

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: implement FMASK decompression for MSAA texturing

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: scanout buffers cannot be a destination of MSAA resolve

Resolving to scanout buffers just doesn't work.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: implement MSAA colorbuffer compression for rendering

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: implement uncompressed MSAA texturing

This is glBlitFramebuffer support for MSAA surfaces as required by GL 3.0
and texturing as required by GL 3.2 and GL_ARB_texture_multisample.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: disable alpha-to-coverage for integer colorbuffers

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: implement GL_SAMPLE_ALPHA_TO_ONE

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: implement uncompressed MSAA rendering and color resolving

This is basic MSAA support which should work with most apps.
Some features are missing, those will be implemented by other commits.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: add flexible shader descriptor management and use it for sampler views

It moves all sampler view descriptors to a buffer.
It supports partial resource updates and it can also unbind resources
(required for FMASK texturing).

The buffer contains all sampler view descriptors for one shader stage,
represented as an array. On top of that, there are N arrays in the buffer,
which are used to emulate context registers as implemented by the previous
ASICs (each array is a context).

This uses the RCU synchronization approach to avoid read-after-write hazards
as discussed in the thread:
"radeonsi: add FMASK texture binding slots and resource setup"

CP DMA is used to clear the descriptors at context initialization and to copy
the descriptors from one context to the next.

v2: - use PKT3_DMA_DATA on CIK (I'll test CIK later)
    - turn the bool CP DMA parameters into self-explanatory flags
    - add a nice simple API for packet emission to radeon_winsys.h
    - use 256 contexts, 128 causes texture corruption in openarena

radeonsi/compute: Let the state tracker do all the flushing

It shouldn't be necessary to call radeon_winsys::cs_flush() from
radeonsi_launch_grid(), because the state tracker is responsible for
flushing the pipeline at the appropriate time.  The current behavior is
also wrong, because radeonsi_launch_grid() submits packets to the
compute ring, but when the state tracker calls pipe->flush() everything
is submitted to the graphics ring.  This has the potential to create a
race condition.

The downside of removing this flush is that the compute dispatch packets
will be sent to the graphics ring rather than the compute ring.
In the future we will need to come up with a way to detect 'compute'
command streams and submit them to the appropriate ring.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>

i965: Dump more information about batch buffer usage.

Previously, INTEL_DEBUG=bat would dump messages like:

intel_mipmap_tree.c:1643: Batchbuffer flush with 456b used

This only reported the space used for command packets, and didn't
report any information on the space used for indirect state.

Now it dumps:

intel_context.c:366: Batchbuffer flush with 6128b (pkt) + 4288b (state)
= 10416b (31.8%)

This conveniently shows the breakdown of space used for packets vs.
state, as well as the percentage of batchbuffer space.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Add Gen7 depth stall flushes before disabling depth in BLORP.

We emit these before configuring depth in the normal path, or actually
using the depth buffer in BLORP - we just failed to emit them when
disabling depth altogether.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Add Gen6 depth stall flushes before disabling depth in BLORP.

We emit these before configuring depth in the normal path, or actually
using the depth buffer in BLORP - we just failed to emit them when
disabling depth altogether.

On Sandybridge, this also requires the post_sync_nonzero flush.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Don't copy propagate bitcasts with source modifiers.

Previously, copy propagation would cause bitcast_f2u(abs(float)) to
be performed in a single step, but the application of source modifiers
(abs, neg) happens after type conversion, leading to incorrect results.

That is, for bitcast_f2u(abs(float)) we would in fact generate code to
do abs(bitcast_f2u(float)).

For example, whereas bitcast_f2u(abs(float)) might result in a register
argument such as
   (abs)g2.2<0,1,0>UD

v2: Set interfered = true and break in register_coalesce instead of
    returning false.

Reviewed-by: Paul Berry <stereoytpe441@gmail.com>

i965: Emit MOVs for neg/abs.

Necessary to avoid combining a bitcast and a modifier into a single
operation. Otherwise if safe, the MOV should be removed by
copy-propagation or register coalescing.

With this and the next patch, there are only four changes in shader-db:
all a single extra instruction. The code does something like
   mov a.w, -b.x
and copy propagation doesn't work because it only handles no-op
swizzles. Seems acceptable, given the known limitation of our copy
propagation.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereoytpe441@gmail.com>

i965/blorp: Add support for single sample scaled blit with bilinear filter

Currently single sample scaled blits with GL_LINEAR filter falls
back to meta path. Patch removes this limitation in BLORP engine
and implements single sample scaled blit with bilinear filter.
No piglit, gles3 regressions are observed with this patch on Ivybridge.

V2: Use "sample" message to utilize the linear filtering functionality
built in to hardware.
V3: Define a bool variable (bilinear_filter) to handle the conditions
for GL_LINEAR blits.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/blorp: Define a function to clamp texture coordinates

New function clamp_tex_coords() clamps the texture coordinates
to texture boundaries.  This function will also be utilized later
for the BLORP implementation of single-sample scaled blit with
bilinear filter.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/blorp: Use more appropriate variable names

When we talk about both multi-sample and single-sample scaled blits,
rect_grid_{x1, y1} are more appropriate variable names as compared
to sample_grid_{x1, y1}. There are no functional changes in this patch.
It just prepares for the BLORP implementation of single-sample scaled
blit with bilinear filter.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

meta: Fix blitting a framebuffer with renderbuffer attachment

This patch fixes a case of framebuffer blitting with renderbuffer
as color attachment and GL_LINEAR filter. Meta implementation of
glBlitFrambuffer() converts source color buffer to a texture and
uses it to do the scaled blitting in to destination buffer. Using
the exact source rectangle to create the texture does incorrect
linear filtering along the edges. This patch makes the changes to
extend the texture edges by one pixel in x, y directions. This
ensures correct linear filtering.
It fixes failing piglit fbo-attachments-blit-scaled-linear test.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
CC: "9.2" <mesa-stable@lists.freedesktop.org>
CC: "9.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

nv50: add vp3/vp4 support for mpeg2/vc1

h264/mpeg4 remain disabled for pre-nvc0, there's some minor
bug/difference which causes the decoding to hang after some frames.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

nv50: separate video logic from noalloc

The upcoming vp3 logic will want the video layout, but allocated by the
miptree.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

nv30: remove no-longer-used formats from table

Commit 14ee790df77 removed the formats from the vtxfmt_table but forgot
to also update the info_table.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 and 9.1" <mesa-stable@lists.freedesktop.org>

mesa: Update the BGRA vertex array error handling

The error code was changed from INVALID_VALUE to INVALID_OPERATION
in OpenGL 3.3. We should also generate an error when size is BGRA
and normalized is FALSE.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs: Fix Sandybridge regressions from SEL optimization.

Sandybridge is the only platform that supports an IF instruction
with an embedded comparison.  In this case, we need to emit a CMP
to go along with the SEL.

Fixes regressions in Piglit's glsl-fs-atan-3, fs-unpackHalf2x16,
fs-faceforward-float-float-float, isinf-and-isnan fs_basic, and
isinf-and-isnan fs_fbo.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68086
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: lu hua <huax.lu@intel.com>

i965: Force X-tiling for 128 bpp formats on Sandybridge.

128 bpp formats are not allowed to be Y-tiled on any architectures
except Gen7.

+11 Piglits on Sandybridge (mostly regression fixes since the
switch to Y-tiling).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63867
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64261
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

mesa/vbo: Fix handling of attribute 0 in non-compatibilty contexts

It is only in OpenGL compatibility-style contexts where generic
attribute 0 and GL_VERTEX_ARRAY have a bizzare, aliasing relationship.
Moreover, it is only in OpenGL compatibility-style contexts and OpenGL
ES 1.x where one of these attributes provokes the vertex.  In all other
APIs each implicit call to glArrayElement provokes a vertex regardless
of which attributes are enabled.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Robert Bragg <robert@sixbynine.org>
Cc: "9.0 9.1 9.2" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55503
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66292
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67548

draw: handle nan clipdistance

If clipdistance for one of the vertices is nan (or inf) then the
entire primitive should be discarded.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

i915,i965: Fix memory leak in try_pbo_upload (v2)

Fixes "Resource leak" defect reported by Coverity.
Tested on Haswell, no Piglit regressions.

v2: Apply to i965, not just i915. (chadv)

CC: "9.2, 9.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

gallivm: revert accidentally commited hunk

That magic wasn't meant to be commited, need to work on some proper fix.

gallivm: do per-sample depth comparison instead of doing it post-filter

Doing the comparisons pre-filter is highly recommended by OpenGL (and d3d9)
and definitely required by d3d10.
This actually doesn't do it pre-filter but more "in-filter" as otherwise
need to push the comparisons even further down into fetch code and this
also trivially allows using a somewhat cheaper lerp.
Doing it pre-filter would actually have some performance advantage for UNORM
formats (because the comparisons should be done in texture format, we'd only
need to convert the shadow ref coord to texture format once, but in turn would
save converting the per-sample texture values to floats) but this gets a bit
messy as this has implications for border color handling as well (which needs
to be done prior to depth comparisons, hence would also need to convert border
color to texture format too or use some other tricks like doing separate border
color / shadow ref comparison and simply using that result directly when doing
border replacement).
Should make no difference for nearest filtering, and performance for linear
filtering should be mostly the same too (essentially have one more comparison
instruction per sample, and replace the sub/mul/add lerp with a sub/and/and/add
special "lerp" which all in all shouldn't be much of a difference).

v2: get rid of old code completely

Reviewed-by: Zack Rusin <zackr@vmware.com>

radeonsi: Pixel shaders pre-load one more SGPR

Acked-by: Marek Olšák <maraeo@gmail.com>

radeonsi: TGSI_SEMANTIC_CLIPVERTEX doesn't use any parameters

radeonsi: Don't export unused clip distance vectors from vertex shader

E.g. the Source engine seems to always write to gl_ClipVertex, but normally
doesn't enable any GL_CLIP_DISTANCEn states. This change removes some
irrelevant parts from the generated vertex shader code in such cases.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

radeonsi: Don't leave gaps between position exports from vertex shader

If the vertex shader exports clip distances but not point size, use
position exports 1/2 instead of 2/3 for the clip distances. Fixes
geometry corruption in that case.

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

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

llvmpipe: fix stencil bug if we have both stencil and depth tests

This is a very well hidden bug found by accident (only the fixed glean
tstencil2 test so far seems to hit it).
We must use new mask with combined s_pass values and orig_mask values
for zpass/zfail stencil ops, otherwise both the sfail op and one of
zpass/zfail op are applied (probably not hit in most tests because
some of the ops tend to be KEEP usually).

Note: this is a candidate for the 9.2 branch.

Reviewed-by: Zack Rusin <zackr@vmware.com>

st/mesa: use new float comparison opcodes if native integers are supported

Should get rid of some float-to-int conversions (with negation).
No piglit regressions (with llvmpipe).

v2: fix bogus formatting spotted by Brian.

Reviewed-by: Brian Paul <brianp@vmware.com>

nvc0: move video param and format support functions to nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

nvc0: move firmware loading functions to nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

nvc0: move some of the simpler decoder functions into nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

nvc0: move vp param filling logic into nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>