egl_dri2: call dri2_add_configs_for_visuals after extensions set

dri2_add_config makes decisions based on NOK_texture_from_pixmap so
it needs to be enabled before calling dri2_add_configs_for_visuals.

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
dri: set yInverted default to GL_TRUE

yInverted is used by EGL_NOK_texture_from_pixmap to indicate that
window system rendering is y-inverted compared to OpenGL texture
representation. This extension is only known to be used with X11
window system where sane default is GL_TRUE.

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

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
st/egl: Flush resources before presentation

Fixes wayland regression on r600g due to fast clear introduced by commit
edbbfac6.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
st/mesa: always prefer pipe->clear over clear_with_quad (v2)

v2: clear depth and stencil together
st/mesa: check depth and stencil writemask before clearing
st/mesa: use sRGB formats for MSAA resolving if destination is sRGB

Copied from the i965 driver, including the big comment.

Cc: 9.2 10.0 <mesa-stable@lists.freedesktop.org>
mesa: handle GL_NONE draw buffers correctly in glClear

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: bind NULL colorbuffers as specified by glDrawBuffers

An example why it is required:

    Let's say there's a fragment shader writing to gl_FragData[0..1].
    The user calls: glDrawBuffers(2, {GL_NONE, GL_COLOR_ATTACHMENT0});

    That means gl_FragData[0] is unused and gl_FragData[1] is written
    to GL_COLOR_ATTACHMENT0.

st/mesa was skipping the GL_NONE draw buffer, therefore gl_FragData[0]
was written to GL_COLOR_ATTACHMENT0, which was wrong.

This commit fixes it, but drivers must also be fixed not to crash when
binding NULL colorbuffers. There is also a new set of piglit tests for this.

The MSAA state also had to be fixed not to crash when reading fb->cbufs[0].

Reviewed-by: Brian Paul <brianp@vmware.com>
gallium/util: easy fixes for NULL colorbuffers

Reviewed-by: Brian Paul <brianp@vmware.com>
radeonsi: handle NULL colorbuffers correctly

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
r600g: handle NULL colorbuffers correctly on Evergreen
r600g: handle NULL colorbuffers correctly on R600-R700
r600g: fix glClearBuffer by handling PIPE_CLEAR_COLORi flags correctly

also restructure the code
i965: Ensure that all necessary state is re-emitted if we run out of aperture.

Prior to this patch, if we ran out of aperture space during
brw_try_draw_prims(), we would rewind the batch buffer pointer
(potentially throwing some state that may have been emitted by
brw_upload_state()), flush the batch, and then try again.  However, we
wouldn't reset the dirty bits to the state they had before the call to
brw_upload_state().  As a result, when we tried again, there was a
danger that we wouldn't re-emit all the necessary state.  (Note: prior
to the introduction of hardware contexts, this wasn't a problem
because flushing the batch forced all state to be re-emitted).

This patch fixes the problem by leaving the dirty bits set at the end
of brw_upload_state(); we only clear them after we have determined
that we don't need to rewind the batch buffer.

Cc: 10.0 9.2 <mesa-stable@lists.freedesktop.org>

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Convert piles of foreach_iter to the newer foreach_list macro.

foreach_iter and exec_list_iterators have been deprecated for some time now;
we just hadn't ever bothered to convert code to the newer foreach_list
and foreach_list_safe macros.

In these cases, we aren't editing the list, so we can use foreach_list
rather than foreach_list_safe.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Convert piles of foreach_iter to foreach_list_safe.

In these cases, we edit the list (or at least might be), so we use the
foreach_list_safe variant.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Replace foreach_iter and iter.remove() with foreach_list_safe.

foreach_list_safe allows you to safely remove the current node.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Cast ir_call parameters to ir_rvalue, not ir_instruction.

A function call's parameters are always rvalues.  ir_rvalue may not
always be a subclass of ir_instruction in the future, so we should use
the right one.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Statically cast parameter exec_node to ir_variable.

Formal function parameters are always ir_variable objects, not an
arbitrary ir_instruction.  So there's no need to dynamically cast here.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Use a new foreach_two_lists macro for walking two lists at once.

When handling function calls, we often want to walk through the list of
formal parameters and list of actual parameters at the same time.
(Both are guaranteed to be the same length.)

Previously, we used a pattern of:

   exec_list_iterator 1st_iter = <1st list>.iterator();
   foreach_iter(exec_list_iterator, 2nd_iter, <2nd list>) {
      ...
      1st_iter.next();
   }

This was awkward, since you had to manually iterate through one of
the two lists.

This patch introduces a foreach_two_lists macro which safely walks
through two lists at the same time, so you can simply do:

   foreach_two_lists(1st_node, <1st list>, 2nd_node, <2nd list>) {
      ...
   }

v2: Rename macro from foreach_list2 to foreach_two_lists, as suggested
    by Ian Romanick.

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