__DRIimage: version 5, add new formats and createSubImage

The additions in version 5 enables creating EGLImages for different planes
of a YUV buffer.  createImageFromName is still used to create the containing
__DRIimage, and createSubImage can then be used no that __DRIimage to create
__DRIimages that correspond to the y, u, and v planes (__DRI_IMAGE_FORMAT_R8)
or the uv planes (__DRI_IMAGE_FORMAT_RG88) for formats such as NV12 where
the u and v components are interleaved.  Packed formats such as YUYV etc
doesn't require any special treatment, we just sample those as a regular
ARGB texture.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
intel: Add support for new __DRIimage formats
intel: Add offset field to miptree

This lets us specify an offset into the bo where the miptree starts,
which will let us set up a texture for a single plane in a planar buffer.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
intel: Implement __DRIimage::createSubImage and bump supported version to 5

We use the new miptree offset to pick out the sub-image when we bind
the EGLImage to a texture.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
wayland-drm: Pass struct wl_drm_buffer to the driver

We're going to extend this to support multi-plane buffers, so pass this
to the driver so it can access the details.
wayland-drm: Add protocol to create planar buffers
egl: Add EGL_WAYLAND_PLANE_WL attribute

This lets us specify the plane to create the image for for multiplanar
wl_buffers.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
mapi: Move GL_NV_draw_buffers extension to es_EXT.xml

We don't generate public entrypoints for GLES extensions, so move the
GL_NV_draw_buffers definition from ARB_draw_buffers.xml to es_EXT.xml.
When the extension is defined in ARB_draw_buffers.xml, we end up with a
public entry point for it, but no prototype, which gives an error when
compiled with --disable-asm and --disable-shared-glapi.

Instead, just move the GLES extension to es_EXT.xml so this doesn't happen.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
i965/msaa: Move {rt,tex}_interleaved into blorp program key.

On Gen6, MSAA buffers always use an interleaved layout and non-MSAA
buffers always use a non-interleaved layout, so it is not strictly
necessary to keep track of the layout of the texture and render target
surfaces in the blorp program key.  However, it is cleaner to do so,
since (a) it makes the blorp compiler less dependent on implicit
knowledge about how the GPU pipeline is configured, and (b) it paves
the way for implementing compressed multisampled surfaces in Gen7.

This patch won't cause any redundant compiles, because the layout of
the texture and render target surfaces depends on other parameters
that are already in the blorp program key.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/msaa: Add an enum to describe MSAA layout.

From the Ivy Bridge PRM, Vol 1 Part 1, p112:

    There are three types of multisampled surface layouts designated
    as follows:
      - IMS Interleaved Multisampled Surface
      - CMS Compressed Mulitsampled Surface
      - UMS Uncompressed Multisampled Surface

Previously, the i965 driver only used IMS and UMS formats, and
distinguished beetween them using the boolean
intel_mipmap_tree::msaa_is_interleaved.  To facilitate adding support
for the CMS format, this patch replaces that boolean (and other
booleans derived from it) with an enum
INTEL_MSAA_LAYOUT_{IMS,CMS,UMS}.  It also updates the terminology used
in comments throughout the driver to match the IMS/CMS/UMS terminology
used in the PRM.  CMS layout is not yet used.

The enum has a fourth possible value, INTEL_MSAA_LAYOUT_NONE, which is
used for non-multisampled surfaces.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/msaa: Allocate MCS buffer when CMS MSAA is in use.

To implement Gen7's CMS MSAA layout, we need an extra buffer, the MCS
(Multisample Control Surface) buffer.  This patch introduces code for
allocating and deallocating the buffer, and storing a pointer to it in
the intel_mipmap_tree struct.

No functional change, since the CMS layout is not enabled yet.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/msaa: Add CMS MSAA settings to brw_structs.h.

Previously the DWORD used to control the CMS MSAA layout was just a
pad value, because we didn't use it.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/msaa: Set SURFACE_STATE properly when CMS MSAA is in use.

When a buffer using Gen7's CMS MSAA layout is bound to a texture or a
render target, the SURFACE_STATE structure needs to point to the MCS
buffer and to indicate its pitch.  This patch updates the functions
that emit SURFACE_STATE to handle CMS layout properly.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/msaa: Add CMS-related sampler messages to brw_defines.h.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/msaa: Add CMS support to blorp.

This patch updates the blorp engine to properly handle the case where
the surface being textured from uses Gen7's CMS MSAA layout.  The
following changes were necessary:

- Before reading color values from the surface, we need to read from
  the MCS buffer using the ld_mcs sampler message.  This is done by
  the mcs_fetch() function, and the result is stored in the mcs_data
  register.  This only needs to be done once per pixel, since the MCS
  value is shared between all samples belonging to a pixel.

- When reading color values from the surface, we need to use the
  ld2dms sampler message instead of the ld2dss message, and we need to
  provide the value read from the MCS buffer as an argument.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/msaa: Enable CMS layout on Gen7 for the formats that support it.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Add support for AVG instruction.

From the Ivy Bridge PRM, Vol4 Part3 p152:

    "The avg instruction performs component-wise integer average of
    src0 and src1 and stores the results in dst. An integer average
    uses integer upward rounding. It is equivalent to increment one to
    the addition of src0 and src1 and then apply an arithmetic right
    shift to this intermediate value."
i965/msaa: Modify manual_blend() to avoid unnecessary loss of precision.

When downsampling from an MSAA image to a single-sampled image, it is
inevitable that some loss of numerical precision will occur, since we
have to use 32-bit floating point registers to hold the intermediate
results while blending.  However, it seems reasonable to expect that
when all samples corresponding to a given pixel have the exact same
color value, there will be no loss of precision.

Previously, we averaged samples as follows:

    blend = (((sample[0] + sample[1]) + sample[2]) + sample[3]) / 4

This had the potential to lose numerical precision when all samples
have the same color value, since ((sample[0] + sample[1]) + sample[2])
may not be precisely representable as a 32-bit float, even if the
individual samples are.

This patch changes the formula to:

    blend = ((sample[0] + sample[1]) + (sample[2] + sample[3])) / 4

This avoids any loss of precision in the event that all samples are
the same, by ensuring that each addition operation adds two equal
values.

As a side benefit, this puts the formula in the form we will need in
order to implement correct blending of integer formats.
i965/msaa: Fix integer downsampling on Gen7.

When downsampling an integer-format buffer on Gen7, we need to use the
"avg" instruction rather than the "add" instruction, to ensure that we
don't overflow the range of 32-bit integers.  Also, we need to use the
proper register type (BRW_REGISTER_TYPE_D or BRW_REGISTER_TYPE_UD) for
intermediate color data and for writing to the render target.

Note: this patch causes blorp to use the proper register type for all
operations (downsampling, upsampling, and ordinary blits).  Strictly
speaking, this is only necessary for downsampling, because the other
operations exclusively use MOV instructions on the color data.  But
it's simpler to use the proper register type in all cases.
i965/msaa: Optimize manual_blend() for compressed multisampled surfaces.

When downsampling a compressed multisampled surface, we can take a
shortcut to downsample any pixels that are were covered by a single
primitive.  In this case, the first color value we fetch is the
correct final color for the downsampled pixel, so we can skip the rest
of the downsampling operation.