i965/gen6: Enable HiZ by default

Regresses one Piglit test: bugs/fdo10370.

I'm not enabling HiZ for gen7 yet because it causes a mysterious
performance regression.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Use separate stencil whenever possible

For depthstencil renderbuffers, we were using separate stencil only if the
hardware required it. Since the performance gains from HiZ is so high, we
should always use separate stencil if the hardware supports it.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

i965: Implement the actual tables for texture alignment units [v2]

I implemented functions for horizontal/vertical alignment units separately
because I find it easier to read that way...especially with all the
corner-cases.

[chad] Corrected the vertical alignment calculation by checking for
depthstencil formats.

v2:
   - Fix typos in intel_horizontal_texture_alignment_unit():
     s/height/width/ and s/VALIGN/HALIGN.
   - Remove special case for compressed formats in
     intel_get_texture_alignment unit(). Compressed formats are already
     handled in the halign and valign functions.
   - Replace check ``_mesa_is_depth_format(...) ||
     _mesa_is_depthstencil_format(...)`` with explcitit checks against
     GL_DEPTH_COMPONENT and GL_DEPTH_STENCIL.

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

i965/gen6: Set vertical alignment in SURFACE_STATE batch

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Store miptree alignment units in the miptree

This allows us to replace all the calls to
intel_get_texture_alignment_unit() with a single call at miptree creation.

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

intel: Enable HiZ for texture renderbuffers

When a depth texture is first attached to framebuffer, allocate a HiZ
miptree for it.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Resolve buffers in intel_map_renderbuffer()

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Resolve buffers in intel_map_texture_image()

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Mark needed resolves when first enabling HiZ on a miptree

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

i965: Mark that depth buffer needs depth resolve after drawing

After brw_try_draw_prims() emits a batch, mark that the depth buffer needs
a depth resolve if the buffer was written to and if it has an accompanying
HiZ buffer.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Resolve buffers in intelSpanRenderStart

Resolve all buffers that will be mapped by intelSpanRenderStart. This
comprises resolving the depth buffer of each enabled texture and of the
read and draw buffers.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Refactor intelSpanRenderStart

Factor the mapping loops from intelSpanRenderStart() into
intel_span_map_buffers(). This in preparation for the next commit,
which resolves the buffers before mapping.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

i965: Resolve buffers before drawing [v2]

Before emitting primitives in brw_try_draw_prims(), resolve the depth
buffer's HiZ buffer and resolve the depth buffer of each enabled depth
texture.

v2: [anholt] The driver no longer validates drm bo's, so update a comment
    to reflect that.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

i965: Prevent recursive calls to FLUSH_VERTICES [v2]

To do so, we must resolve all buffers on entering a glBegin/glEnd block.
For the detailed explanation, see the Doxygen comments in this patch.

v2:
   - Fix typo: s/enusure/ensure/.
   - In brwPrepareExecBegin(), do the same resolves as done by
     brw_predraw_resolve_buffers().

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

i965/gen6: Manipulate state batches for HiZ meta-ops [v4]

A lot of the state manipulation is handled by the meta-op state setup.
However, some batches need manual intervention.

v2:
   Do not special-case the 3DSTATE_DEPTH_STENCIL.Depth_Test_Enable bit
   for HiZ in gen6_upload_depth_stencil(). The HiZ meta-op sets
   ctx->Depth.Test, just read the value from that.

v3:
   Add a new dirty flag, BRW_STATE_HIZ, for brw_tracked_state. Flag it
   immediately before and after executing the HiZ operation in
   gen6_resolve_slice(). Add the flag to the the dirty bits for the
   following state packets:
      gen6_clip_state
      gen6_depth_stencil_state
      gen6_sf_state
      gen6_wm_state

v4:
   - Add BRW_NEW_STATE_HIZ to the dirty bit table in brw_state_upload.c.
     This is needed for INTEL_DEBUG=state.
   - Align brw dirty bit for gen6_depth_stencil_state.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

i965/gen6: Complete stubs for HiZ buffer resolves

Some state batches also need to be manipulated. That's done in the next
commit.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

i965: Add HiZ operation state to brw_context

brw_context::hiz contains state needed to perform HiZ meta-ops and
indicates if a HiZ operation is currently in progress.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Add resolve functions for renderbuffers

Add the following functions:
   intel_renderbuffer_resolve_hiz
   intel_renderbuffer_resolve_depth

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Add resolve functions for miptrees

Add functions that
   - set a miptree slice as needing a resolve
   - resolve a single slice of a miptree
   - resolve all slices of a miptree

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Add field intel_mipmap_tree::hiz_map

This is a map of miptree slices to needed resolves.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Define struct intel_resolve_map [v2]

This is a map of miptree slices to needed resolves, implemented as
a linked list. A future commit will embed such a list in
intel_mipmap_tree.

If you think I'm crazy to put a list in a miptree, read the Doxygen in
this patch for intel_resolve_map.

v2: [anholt] Move Doxygen from functin prototypes to definitions.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Change signature of HiZ resolve functions

Now that intel_renderbuffer::region has been replaced with a miptree, the
HiZ functions region parameter must be replaced with a miptree parameter.

Change the return type from bool to void.

Rename the 'depth' parameter to 'layer', because it will correspond to
irb->mt_layer.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Remove unused HiZ functions

Remove the following functions:
   i830_hiz_resolve_noop
   i915_hiz_resolve_noop
   brw_hiz_resolve_noop

My original strategy for how intel->vtbl.resolve_*buffer was used has
substantially changed. The above functions are no longer called in the
current strategy.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Replace intel_mipmap_tree::hiz_region with a miptree [v2]

This is required to correctly implement HiZ for mipmapped and
multi-layered textures.

v2: Accomodate refcount fixes in intel_process_dri2_buffer_*() that were
    introduced in v2 of commit
        intel: Replace intel_renderbuffer::region with a miptree [v2]

Reviewed-by: Eric Anholt <eric@anholt>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Replace intel_texture_image::stencil_irb with intel_mipmap_tree::stencil_mt [v3]

For depthstencil textures using separate stencil, we embedded a stencil
buffer in intel_texture_image. The intention was that the embedded stencil
buffer would be the golden copy of the texture's stencil bits. When
necessary, we scattered/gathered the stencil bits between the texture
miptree and the embedded stencil buffer.

This approach had a serious deficiency for mipmapped or multi-layer
textures. Any given moment the embedded stencil buffer was consistent with
exactly one miptree slice, the most recent one to be scattered. This
permitted tests of type A to pass, but broke tests of type B.

Test A:
    1. Create a depthstencil texture.
    2. Upload data into (level=x1,layer=y1).
    3. Read and test stencil data at (level=x1, layer=y1).
    4. Upload data into (level=x2,layer=y2).
    5. Read and test stencil data at (level=x2, layer=y2).

Test B:
    1. Create a depthstencil texture.
    2. Upload data into (level=x1,layer=y1).
    3. Upload data into (level=x2,layer=y2).
    4. Read and test stencil data at (level=x1, layer=y1).
    5. Read and test stencil data at (level=x2, layer=y2).

v2:
   Only allocate stencil miptree if intel->must_use_separate_stencil,
   because we don't make the conversion from must_use_separate_stencil to
   has_separate_stencil until commit
        intel: Use separate stencil whenever possible

v3:
   Don't call ChooseNewTexture in intel_renderbuffer_wrap_miptree() in
   order to determine the renderbuffer format. Instead, pass the format as
   a param to that function.

CC: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Refactor intel_render_texture() [v2]

This is in preparation for properly implementing glFramebufferTexture*()
for mipmapped depthstencil textures. The FIXME comments deleted by this
patch give a rough explanation of what was broken.

This refactor does the following:
   - In intel_update_wrapper() and intel_wrap_texture(), change the
     parameters to prepare to remove functions' dependency on
     gl_texture_image.
   - Move the call to intel_renderbuffer_set_draw_offsets() from
     intel_render_texture() into intel_udpate_wrapper().

Each time I encounter those functions, I dislike their vague names.
(Update which wrapper? What is wrapped? What is the wrapper?). So, while
I was mucking around, I also renamed the functions.

v2:
   In addition to the ``GLenum internal_format`` parameter to
   intel_wrap_miptree(), add a ``gl_format format`` parameter. This
   removes the need to recalculate for the true format from
   internal_format with ChooseNewTextureFormat, which was just weird.

Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Define intel_miptree_check_level_layer()

This is a small helper function that asserts that a given level and layer
are valid for a miptree. I will be extensively using it in the future
miptree HiZ functions.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Remove unneeded params from intel_renderbuffer_set_draw_offset()

Since the renderbuffer tracks the miptree level and layer that it wraps,
the 'tex_image' and 'zoffset' params are no longer needed to calculate the draw
offsets.

Not only are they no longer needed, but their presence would prevent
calculating the renderbuffer draw offsets in situations where there were
no texture image. Such situations will occur during the HiZ meta-op and
during scatter/gather of separate stencil textures.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Track the miptree layer wrapped by a renderbuffer [v2]

TODO: Make v2 for kwg.

Add two fields to intel_renderbuffer:
    mt_level
    mt_layer

Multiple renderbuffers may simultaneously wrap a single texture and each
provide a different view into that texture. [Consider
glFramebufferTextureLayer()].  The new fields indicate which slice of the
miptree is wrapped by the renderbuffer.

The buffer resolve operations, to be introduced in the future, require
these fields in order to resolve the correct slice in the miptree.

To add the fields, it was necessary to replace the type of some function
parameters from gl_texture_image to gl_renderbuffer_attachment.

v2: [kwg] Replace confusing condition `CubeMapFace > 0` with the more
    sensible `Target == GL_TEXTURE_CUBE_MAP`.

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

intel: Kill intel_mipmap_level::nr_images [v4]

For all texture targets except GL_TEXTURE_CUBE_MAP, the 'nr_images' and
'depth' fields of intel_mipmap_level were identical.  In the exceptional
case, nr_images == 6 and depth == 1.

It is simple to determine if a texture is a cube or not, so the presence
of two fields here was not helpful. Worse, it was confusing. When we
eventually implement GL_ARB_texture_cube_map_array, this mess would have
become even more confusing.

This patch removes 'nr_images' and assigns to 'depth' a consistent
meaning: depth is the number of 2D slices at each miplevel.  The exact
semantics of depth varies according to the texture target:
   - For GL_TEXTURE_CUBE_MAP, depth is 6.
   - For GL_TEXTURE_2D_ARRAY, depth is the number of array slices. It is
     identical for all miplevels in the texture.
   - For GL_TEXTURE_3D, it is the texture's depth at each miplevel. Its
     value, like width and height, varies with miplevel.
   - For other texture types, depth is 1.

As a consequence, parameters were removed from the following function
signatures:
    intel_miptree_set_level_info
        Remove 'nr_images'.

    i945_miptree_layout
    brw_miptree_layout_texture
    brw_miptree_layout_texture_array
        Remove 'slices'.

v2:
   - Replace "It's" with "Its".
   - Remove all hunks in intel_fbo.c. The hunks were spurious and sneaked
     in during a rebase.
   - Remove unneeded hunk in intel_tex_map_image_for_swrast(). It was
     a little refactor of the for-loop's upper bound.

v4:
   In intel_miptree_get_image_offset(), document the conditions under
   which different if-branches are taken.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Refactor intel_miptree_copy_teximage()

Extract the body of the inner loop into a new function,
intel_miptree_copy_slice().

This is in preparation for adding support for separate stencil and HiZ to
intel_miptree_copy_teximage(). When copying a slice of a depthstencil
miptree that uses separate stencil, we will also need to copy the
corresponding slice of the stencil miptree. The easiest way to do this
will be to call intel_miptree_copy_slice() recursively. Analogous
reasoning applies to copying a slice of a depth miptree with HiZ.

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

intel: Refactor intel_mipmap_level offsets

Add a new field, intel_mipmap_level::slice, and move the offset fields
into it. Also add some much needed documentation for these fields.

Before this patch, a separate array was allocated for the
intel_mipmap_level::{x,y}_offsets.  This was just silly; it incurred an
extra call to malloc and diminished memory locality.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Replace intel_renderbuffer::region with a miptree [v3]

Essentially, this patch just globally substitutes `irb->region` with
`irb->mt->region` and then does some minor cleanups to avoid segfaults
and other problems.

This is in preparation for
  1. Fixing scatter/gather for mipmapped separate stencil textures.
  2. Supporting HiZ for mipmapped depth textures.

As a nice benefit, this lays down some preliminary groundwork for easily
texturing from any renderbuffer, even those of the window system.

A future commit will replace intel_mipmap_tree::hiz_region with a miptree.

v2:
   - Return early in intel_process_dri2_buffer_*() if region allocation
     fails.
   - Fix double semicolon.
   - Fix miptree reference leaks in the following functions:
       intel_process_dri2_buffer_with_separate_stencil()
       intel_image_target_renderbuffer_storage()

v3:
   - [anholt] Fix check for hiz allocation failure. Replace
     ``if (!irb->mt)` with ``if(!irb->mt->hiz_region)``.

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

intel: Define intel_miptree_create_for_renderbuffer()

This function creates a miptree that is suitable as storage for
a non-texture renderbuffer.

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

intel: Move inline functions from intel_fbo.h to .c

Move the following inline functions:
    intel_get_rb_region
    intel_framebuffer_has_hiz

A future commit will replace the renderbuffer's region with a miptree.
This small refactor will eliminate the need for intel_fbo.h to include
intel_mipmap_tree.h on that commit. I'd like to avoid the situation where
each header transitively includes every other header.

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

intel: Kill intel_framebuffer_get_hiz_region()

The only user of intel_framebuffer_get_hiz_region() was
intel_framebuffer_has_hiz(). So I folded the body of the former into the
latter.

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

intel: Temporarily disable HiZ for textures

A great refactor thrashing begins after this commit for HiZ and separate
stencil.  Removing code for texture HiZ will make that refactoring easier,
because then we don't have to maintain that code during the refactor.

To disable HiZ for textures, I've removed the hook in
intel_update_wrapper() that allocates a HiZ buffer when attaching a depth
texture to a framebuffer.

HiZ was broken for textures anyway, so there's no regression here.

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

intel: Always gather stencil buffer in intel_map_renderbuffer_separate_s8z24()

The function gathered the stencil buffer into the depth buffer only when
the map mode contained the read bit. But we must do the gather even if the
map mode is write-only. If we do not, then, when the depth buffer's stencil
bits are scattered into the stencil buffer by intel_unmap_renderbuffer(),
some of the scattered stencil bits would be invalid.

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

intel: Fix swrast_render_start() for depthstencil buffers with separate stencil

1. Don't map the depthstencil buffer twice

   Place a guard in intel_renderbuffer_map() to prevent a renderbuffer
   from being mapped twice. This happened if a single buffer was attached to
   the framebuffer's depth and stencil attachment points.  (Interestingly,
   because intel_map_renderbuffer_gtt() is idempotent, the double mapping did
   not cause bugs for depthstencil buffers *without* separate stencil).

2. Stop overriding gl_framebuffer::_DepthBuffer,_StencilBuffer

   Normally, if a depthstencil buffer is attached to the framebuffer's
   depth attachment point, then _mesa_update_framebuffer() installs
   a wrapper depth renderbuffer at gl_framebuffer::_DepthBuffer. Ditto for
   the stencil attachment point and gl_framebuffer::_StencilBuffer

   A depthstencil intel_renderbuffer with separate stencil contains hidden
   depth and stencil renderbuffers, which are the *real* renderbuffers. In
   order to force swrast to work, we were installing, in
   brw_update_draw_buffer(), the hidden renderbuffers at
   gl_framebuffer::_DepthBuffer and _StencilBuffer, thus overriding the
   behavior of _mesa_update_framebuffer().  However, now that
   intel_renderbuffer_map() is implemented with MapRenderbuffer(),
   overriding _mesa_update_framebuffer's introduces bugs.  This patch
   removes the override code.

Fixes several Piglit tests on gen7.

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

intel: Don't use special stencil span accessors

The special stencil span accessors, as set by intel_span_init_funcs.
perform software W detiling. Since intel_renderbuffer_map() now uses
MapRenderbuffer, rb->Data points to an *untiled* stencil buffer.

Fixes several Piglit tests on gen7.

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

nvc0: add support for GF119 (NVD9)

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

mesa: initialize stencilMap, Stride if stencilRb==depthRb

mesa: Only update sampler uniforms that are used by the shader stage

Previously a vertex shader that used no samplers would get updated (by
calling the driver's ProgramStringNotify) when a sampler in the
fragment shader was updated.  This was discovered while investigating
some spurious code generation for shaders in Cogs.  The behavior in
Cogs is especially pessimal because it ping-pongs sampler uniform
settings:

    glUniform1i(sampler1, 0);
    glUniform1i(sampler2, 1);
    draw();
    glUniform1i(sampler1, 1);
    glUniform1i(sampler2, 0);
    draw();
    glUniform1i(sampler1, 0);
    glUniform1i(sampler2, 1);
    draw();
    // etc.

ProgramStringNotify is still too big of a hammer.  Applications like
Cogs will still defeat the shader cache.  A lighter-weight mechanism
that can work with the shader cache is needed.  However, this patch at
least restores the previous behavior.

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

mesa: don't map depth+stencil buffer twice in glReadPixels()

In slow_read_depth_stencil_pixels_separate() we might have separate
depth and stencil buffers or a combined buffer.  In the later case,
don't map the buffer twice.  This function is used when the depth
scale/bias pixel transfer values are not the defaults.

Fixes http://bugs.freedesktop.org/show_bug.cgi?id=42963

Reviewed-by: José Fonseca <jfonseca@vmware.com>

i965: Fix inconsistent indentation in brw_gs_emit.c.

glsl: Add missing textureSize(samplerCubeShadow, int) variant.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: do not skip att and spot calculation for infinite light

glspec doesn't say that we should skip the attenuation and spot
calculation for infinite light(Ppli.w == 0). Instead, it gives a same
formula to do the light calculation for both finite light and infinite
light(see page 62 of glspec 2.1.pdf)

Also from the formula (2.4) at page 62 of glspec 2.1.pdf, we can skip
attenuation calculation if Ppli.w == 0.

This would fix all the intel oglc l_sed fail subcases and introduces no
intel oglc regressions.

v2: fix an wrong intendation(comments from Brian).

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Acked-by: Brian Paul <brianp@vmware.com>

mesa: make sure all lighting tables are updated before the computation

Make sure all lighting tables are updated before using the table to
calculate something, say using _SpotExpTable to calculate
_VP_inf_spot_attenuation.

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

mesa: Fix a couple of missed conversion to arrays in format_unpack.

Fixes regression in piglit:
ARB_color_buffer_float/GL_RGBA16F-getteximage
ARB_color_buffer_float/GL_RGBA16F-readpixels
ARB_color_buffer_float/GL_RGBA32F-getteximage
ARB_color_buffer_float/GL_RGBA32F-readpixels

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

mesa: Include R/RG integer textures in _mesa_is_integer_format.

Fixes some spurious GL errors in the upcoming
gl-3.0-required-sized-formats piglit test.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

intel: Fix separate stencil in builtin DRI2 backend

intelAllocateBuffer() was oblivious to separate stencil buffers.  This
patch fixes it to allocate a non-tiled stencil buffer with special pitch,
just as the DDX does.

Without this, any app that attempted to create an EGL surface with stencil
bits would crash. Of course, this affected only environments that used the
builtin DRI2 backend, such as Android and Wayland.

Fixes GLBenchmark2.1 on Android on gen7.

Note: This is a candidate for the 7.11 branch.
Tested-by: Louie Tsaie <louie.tsai@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Fix region dimensions for stencil buffers received from DDX

I changed the dimensions of the stencil buffer's region, as allocated by
the DDX, at xf86-video-intel commit
   commit 3e55f3e88b40471706d5cd45c4df4010f8675c75
   dri: Do not tile stencil buffer
But I forgot to make the analogous update to the Intel DRI2 glue in Mesa.
This patch makes that update.

Surprisingly, the mismatch did not cause any bugs. But the mismatch, if
left unfixed, *would* create bugs in the next commit.

Note: This is a candidate for the 7.11 branch.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Simplify stencil detiling arithmetic

When calculating the y offset needed for detiling window system stencil
buffers, replace the term
   region->height * 2 + region->height % 2 - 1
with
   rb->Height - 1 .

The two terms are incidentally equivalent due to some out-of-date,
incorrect code in the Intel DRI2 glue for DDX. (See
intel_process_dri2_buffer_with_separate_stencil(), line ``buffer_height /=
2;``).

Note: This is a candidate for the 7.11 branch (only the intel_span.c hunk).
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

radeon: use _mesa_readpixels() instead of _swrast_ReadPixels()

i965: use _mesa_readpixels() instead of _swrast_ReadPixels()

mesa: convert unpack functions to operate on an array of values

Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: new BYTE/SHORT_TO_FLOATZ() macros

Rather than redefining the BYTE/SHORT_TO_FLOAT macros, just define new
ones with different names.  These macros preserve zero when converting.

Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: move CEILING() macro into macros.h

Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: remove unused macros in macros.h

Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: consolidate cases in _mesa_components_in_format()

and _mesa_sizeof_packed_type()

Reviewed-by: Eric Anholt <eric@anholt.net>

swrast: fix glReadPixels from texture attachment

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

st/mesa: check for missing VBO in setup_interleaved_attribs()

This fixes a crash with the piglit vbo-too-small test.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

util/draw: replace assertions with conditionals in util_draw_max_index()

Don't assert/die if a VBO is too small.  Return zero instead.  For
debug builds, emit a warning message since this is an unusual situation
that might indicate that there's a bug in the app.

Note that util_draw_max_index() now returns max_index+1 instead of
max_index.  This lets us return zero to indicate that one of the VBOs
is too small to draw anything.

Fixes a failure with the new piglit vbo-too-small test.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

st/mesa: remove most of the ReadPixels code

We can use the core Mesa code for glReadPixels now.  We just have to
validate state and flush the bitmap cache before reading.

st/mesa: remove dependencies on code in st_cb_readpixels.c

st_cb_readpixels.c is going away next.

Acked-by: Eric Anholt <eric@anholt.net>

mesa: remove _swrast_ReadPixels()

We use the code in main/readpix.c now.

Acked-by: Eric Anholt <eric@anholt.net>

mesa: use _mesa_readpixels() as default driver hook

Acked-by: Eric Anholt <eric@anholt.net>

mesa: move swrast ReadPixels code into core Mesa

The swrast ReadPixels code has no dependencies on swrast since moving
to Map/UnmapRenderbuffer().  We'll be able to remove s_readpix.c and
remove the state tracker's glReadPixels code next.

Acked-by: Eric Anholt <eric@anholt.net>

st/mesa: check renderbuffer orientation in st_MapRenderbuffer()

We'll soon be able to use these for a core Mesa implementation of
glReadPixels.

Acked-by: Eric Anholt <eric@anholt.net>

mesa: remove support for software alpha buffers

This was only used by the xlib driver to add an alpha channel to the
front/window color buffer.  This was no longer going to work well with
the move to direct mapping of renderbuffers.

Reviewed-by: Eric Anholt <eric@anholt.net>

xlib: remove xm_image.[ch] files

Reviewed-by: Eric Anholt <eric@anholt.net>

xlib: remove a ton of old xlib driver cruft

The days of 1-bpp, 8-bpp and dithering are long behind us.

Reviewed-by: Eric Anholt <eric@anholt.net>

xlib: use MESA_FORMAT_XRGB8888 for pixmap surfaces

We no longer have software-allocated alpha buffers so we can forget
about the alpha channel.

Reviewed-by: Eric Anholt <eric@anholt.net>

xlib: remove software alpha buffer support

Seldom used and this won't work when we move to using Map/UnmapRenderbuffer
everywhere.  This will let us remove a bunch of core Mesa code too.

Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: replace GLstencil with GLubyte

intel: Fix intel_map_renderbuffer() for depthstencil buffers with separate stencil

For a depthstencil buffer with separate stencil,
intel_renderbuffer::region is null. (The regions are kept in hidden depth
and stencil buffers). Since the region is null, intel_map_renderbuffer()
assumed there was no data and returned a null map pointer, which in turn
was dereferenced (!) by MapRenderbuffer's caller.

This patch fixes intel_map_renderbuffer() to map the hidden depth buffer
through the GTT and return that as the mapped pointer. Also, the stencil
bits are scattered and gathered when needed.

Fixes the following Piglit tests on gen7:
    fbo/fbo-readpixels-depth-formats
    hiz/hiz-depth-read-fbo-d24s8
    hiz/hiz-stencil-read-fbo-d24s8
    EXT_packed_depth_stencil/fbo-clear-formats
    EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-blit
    EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-drawpixels
    EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-readpixels
    EXT_packed_depth_stencil/fbo-depthstencil-GL_DEPTH24_STENCIL8-readpixels-24_8
    EXT_packed_depth_stencil/fbo-depthstencil-GL_DEPTH24_STENCIL8-readpixels-FLOAT-and-USHORT
    EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Fix software detiling of system stencil buffers

If a window system stencil buffer had a region with odd height, then the
calculated y offset needed for software detiling was off by one.  The bug
existed in intel_{map,unmap}_renderbuffer_s8() and in the intel_span.c
accessors.

Fixes the following Piglit tests on gen7:
    general/depthstencil-default_fb-readpixels-24_8
    general/depthstencil-default_fb-readpixels-FLOAT-and-USHORT

Fixes SIGABRT in the following Piglit tests on gen7:
    general/depthstencil-default_fb-blit
    general/depthstencil-default_fb-copypixels
    general/depthstencil-default_fb-drawpixels-24_8
    general/depthstencil-default_fb-drawpixels-FLOAT-and-USHORT

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Fix intel_unmap_renderbuffer_s8()

When gathering the temporary buffer's pixles into the gem buffer, we had
the two buffers juxtaposed. Oops.

Fixes the following Piglit tests on gen7:
   general/GL_SELECT - alpha-test enabled
   general/GL_SELECT - depth-test enabled
   general/GL_SELECT - no test function
   general/GL_SELECT - scissor-test enabled
   general/GL_SELECT - stencil-test enabled

Fixes SIGABRT in Piglit tests EXT_framebuffer_object/fbo-stencil-* on
gen7.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

intel: Refactor intel_map_renderbuffer()

The function already implements 3 cases (map through GTT, blit to
a temporary, and detile stencil buffer to temporary), and a 4th will be
added soon: scatter/gather for depthstencil buffers using separate
stencil.  For sanity's sake, this factors each case out into its own
function.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

ir_to_mesa: don't init unfirom if link failed

Don't call set_unfiform_initializers if link failed, or it would trigger
a GL_INVALID_OPERATION error. That's not an expected behavior of
glLinkProgram function.

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

glsl: Always search for an exact function signature match.

Previously, we would fail to compile the following shader due to a bug
in lazy built-in importing:

    #version 130
    void main() {
        float f = abs(5.0);
        int i = abs(5);
    }

The first call, abs(5.0), would fail to find a local signature, look
through the built-ins, and import "float abs(float)".

The second call, abs(5), would find the newly imported float signature
in the local shader, and settle for that.  Unfortunately, it failed to
search the built-ins for the correct/exact signature, "int abs(int)".

Thus, abs(5) ended up being a float, causing a bizarre type error when
we tried to assign it to an int.

Fixes piglit test builtin-overload-matching.frag.

This is /not/ a candidate for stable branches, as it should only be
possible to trigger this bug using GLSL 1.30's built-in functions that
take integer arguments.  Plus, the changes are fairly invasive.

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

glsl: Split code to generate an ir_call out from match_function_by_name.

match_function_by_name performs two fairly separate tasks:
1. Hunt down the appropriate ir_function_signature for the callee.
2. Generate the actual ir_call (assuming we found the callee).

Both of these are complicated.  The first has to handle exact/inexact
matches, lazy importing of built-in prototypes, different scoping rules
for 1.10, 1.20+, and ES.  Not to mention printing a user-friendly error
message with pretty-printed "maybe you meant this" candidate signatures.

The second has to deal with void/non-void functions, pre-call implicit
conversions for "in" parmeters, and post-call "out" call conversions.

Trying to do both in one function is just too unwieldy.  Time to split.

This patch purely moves the code to generate an ir_call into a separate
function and reindents it.  Otherwise, the code is identical.

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

glsl: Add a new matching_signature() variant that returns exact/inexact.

When matching function signatures across multiple linked shaders, we
often want to see if the current shader has _any_ match, but also know
whether or not it was exact.  (If not, we may want to keep looking.)

This could be done via the existing mechanisms:

   sig = f->exact_matching_signature(params);
   if (sig != NULL) {
      exact = true;
   } else {
      sig = f->matching_signature(params);
      exact = false;
   }

However, this requires walking the list of function signatures twice,
which also means walking each signature's formal parameter lists twice.
This could be rather expensive.

Since matching_signature already internally knows whether a match was
exact or not, we can just return it to get that information for free.

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

r600g: fix the representation of control-flow instructions

We need something that looks like a compiler and not like some hacker
put some functions together. /rant

This is a band-aid for these two problems:
- The R600 and EG control-flow instructions appear in switch statements
  next to each other, causing conflicts when adding new instructions.
- The ALU control-flow instructions are bitshifted by 3 (from CF_INST 26:29
  to CF_INST 23:29, as is defined by r600 ISA) even for EG, where CF_INST
  is 22:29.

To fix this mess, the 'inst' field is bitshifted to the left either by 22, 23,
or 26 (directly in the definitions), such that it can be just or'd when making
bytecode without any shifting. All switch statements have been divided into
two, one for R600 and the other for EG.

Of course, there is a better way to do this, but that is left for future
work.

Tested on RV730 and REDWOOD with no regressions.

v2: minor cleanup as per Alex's comment.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

glsl: Remove resource count checks from ir_to_mesa and st_glsl_to_tgsi

These checks are now performed by the linker.

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

linker: Validate resource usage in the linker

This is also done in ir_to_mesa and st_glsl_to_tgsi, but that code
will be removed soon.

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

linker: Count the number of uniform components used by a shader during linking

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

linker: Count the number of samplers used by a shader during linking

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

meta: Fix restoring of fixed function texture enables.

If they were disabled on entry, and we enabled one (like for
BlitFramebuffer), we wouldn't disable it on the way out.  Retain the
attempted optimization here (don't keep calling to set each bit for
changes that won't matter) by just setting the bits directly with
appropriate flushing.

Fixes misrendering on the second draw of piglit fbo-blit.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

meta: Don't forget to flag state when restoring texobjects.

It's unlikely that we changed the object but no other texture
parameter, but be correct anyway.  Noticed by inspection.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

st/mesa: fix system value to semantic mapping

Broken by addition of SYSTEM_VALUE_VERTEX_ID in
919c53e87a1f6f5322bc1f1486bb3e6b954b00d5.

gallium: add TGSI_SEMANTIC_VERTEXID

r600g: mask write for fake VS export components

r600g: fix op3 & write in merge_inst_groups

r600g: set max max tex/vtx instructions count to 16 for cayman

Cayman is 16 as well.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

r600g: set max tex/vtx instructions count to 16 for evergreen

According to evergreen-isa doc 16 is max value for evergreen.
More than 16 doesn't work for me.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>

radeon: further cleanup of shared code

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

radeon: add some missing FireMV pci ids

Note: this is a candidate for the stable branches.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

mesa/st: Flush stdout after pritingin the GLSL.

Otherwise it gets all garbled with stderr.

glsl: Add missing ';' in action statement.

Addresses the warnings:

  warning: a `;' might be needed at the end of action code
  warning: future versions of Bison will not add the `;'