[Mesa-dev] Mesa (master): mesa/st: Fix pipe_framebuffer_state:: height for PIPE_TEXTURE_1D_ARRAY.

Submitted by Jose Fonseca on April 24, 2014, 11:31 a.m.

Details

Message ID 2049438350.7218572.1398339095511.JavaMail.root@vmware.com
State New
Headers show

Not browsing as part of any series.

Commit Message

Jose Fonseca April 24, 2014, 11:31 a.m.
----- Original Message -----
> On 24.04.2014 03:12, Jose Fonseca wrote:
> > Module: Mesa
> > Branch: master
> > Commit: fd92346c53ed32709c7b56ce58fb9c9bf43ce9a8
> > URL:
> > https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3Dfd92346c53ed32709c7b56ce58fb9c9bf43ce9a8&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=XOFDALlPDjLntm1Qs4okrzKRXQoXq3jonmJqsdohb6E%3D%0A&s=27ef6f50a2586caf483f351b5e80126e886087d89d0f98c9d777a6e8e80a229e
> > 
> > Author: José Fonseca <jfonseca@vmware.com>
> > Date:   Thu Apr  3 15:56:46 2014 +0100
> > 
> > mesa/st: Fix pipe_framebuffer_state::height for PIPE_TEXTURE_1D_ARRAY.
> > 
> > This prevents buffer overflow w/ llvmpipe when running piglit
> > 
> >   bin/gl-3.2-layered-rendering-clear-color-all-types 1d_array single_level
> >   -fbo -auto
> > 
> > v2: Compute the framebuffer size as the minimum size, as pointed out by
> > Brian;  compacted code;  ran piglit quick test list (with no
> > regressions.)
> 
> This commit broke the piglit test drawbuffer-modes for me with radeonsi:
> 
> ../../../src/mesa/state_tracker/st_atom_framebuffer.c:153:update_framebuffer_state:
> Assertion `framebuffer->width != (2147483647 * 2U + 1U)' failed.
> Apr 24 16:38:02 kaveri kernel: [26036.258250] traps:
> drawbuffer-mode[6292] trap int3 ip:7f50e6f52526 sp:7ffffcc82640 error:0
> zsh: trace trap  DISPLAY=:1
> /home/daenzer/src/piglit-git/piglit/bin/drawbuffer-modes -auto
> 
> The test was previously passing.

It passes here with llvmpipe, and I don't have radeonsi machine.

It really shouldn't happen.  The only way this assertion could fail is if the framebuffer had no color/depth-stencil surfaces.  What's the contents of *framebuffer, and what's the backtrace?

Anyway, it's easy to workaround it -- the attached patch should avoid it --, but it's sweeping dirt under the rug.  I suspect something else might have gone bad.


Jose

Patch hide | download patch | download mbox

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 8791168..2b47fc2 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -725,7 +725,7 @@  static void lp_exec_default(struct lp_exec_mask *mask,
        * default (or could do switch analysis at switch start time instead).
        */
       unsigned opcode = bld_base->instructions[bld_base->pc - 1].Instruction.Opcode;
-      boolean ft_into = (opcode != TGSI_OPCODE_BRK ||
+      boolean ft_into = (opcode != TGSI_OPCODE_BRK &&
                          opcode != TGSI_OPCODE_SWITCH);
       /*
        * If it is not last statement and there was no fallthrough into it,
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c
index 8fbc58f..285e5cf 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -200,7 +200,7 @@  llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param)
    case PIPE_CAP_VERTEX_COLOR_CLAMPED:
       return 1;
    case PIPE_CAP_GLSL_FEATURE_LEVEL:
-      return 140;
+      return 150;
    case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
       return 0;
    case PIPE_CAP_COMPUTE:
diff --git a/src/gallium/state_trackers/dri/sw/drisw.c b/src/gallium/state_trackers/dri/sw/drisw.c
index 6f50b05..18cd11a 100644
--- a/src/gallium/state_trackers/dri/sw/drisw.c
+++ b/src/gallium/state_trackers/dri/sw/drisw.c
@@ -46,6 +46,8 @@ 
 #include "dri_context.h"
 #include "dri_drawable.h"
 
+const __DRIextension **__driDriverGetExtensions_swrast(void);
+
 DEBUG_GET_ONCE_BOOL_OPTION(swrast_no_present, "SWRAST_NO_PRESENT", FALSE);
 static boolean swrast_no_present = FALSE;
 
@@ -397,7 +399,7 @@  drisw_create_buffer(__DRIscreen * sPriv,
  *
  * DRI versions differ in their implementation of init_screen and swap_buffers.
  */
-const struct __DriverAPIRec driDriverAPI = {
+static const struct __DriverAPIRec swrast_driver_api = {
    .InitScreen = drisw_init_screen,
    .DestroyScreen = dri_destroy_screen,
    .CreateContext = dri_create_context,
@@ -410,13 +412,25 @@  const struct __DriverAPIRec driDriverAPI = {
    .CopySubBuffer = drisw_copy_sub_buffer,
 };
 
-/* This is the table of extensions that the loader will dlsym() for. */
-PUBLIC const __DRIextension *__driDriverExtensions[] = {
+static const struct __DRIDriverVtableExtensionRec swrast_vtable = {
+   .base = { __DRI_DRIVER_VTABLE, 1 },
+   .vtable = &swrast_driver_api,
+};
+
+static const __DRIextension *swrast_driver_extensions[] = {
     &driCoreExtension.base,
     &driSWRastExtension.base,
     &driCopySubBufferExtension.base,
     &gallium_config_options.base,
+    &swrast_vtable.base,
     NULL
 };
 
+PUBLIC const __DRIextension **__driDriverGetExtensions_swrast(void)
+{
+   globalDriverAPI = &swrast_driver_api;
+
+   return swrast_driver_extensions;
+}
+
 /* vim: set sw=3 ts=8 sts=3 expandtab: */
diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c b/src/gallium/state_trackers/glx/xlib/xm_api.c
index bb2dd8e..7836c61 100644
--- a/src/gallium/state_trackers/glx/xlib/xm_api.c
+++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
@@ -899,10 +899,23 @@  XMesaContext XMesaCreateContext( XMesaVisual v, XMesaContext share_list,
     *
     *     "The default value for GLX_CONTEXT_PROFILE_MASK_ARB is
     *     GLX_CONTEXT_CORE_PROFILE_BIT_ARB."
+    *
+    * The spec also says:
+    *
+    *     "If version 3.1 is requested, the context returned may implement
+    *     any of the following versions:
+    *
+    *       * Version 3.1. The GL_ARB_compatibility extension may or may not
+    *         be implemented, as determined by the implementation.
+    *       * The core profile of version 3.2 or greater."
+    *
+    * and because Mesa doesn't support GL_ARB_compatibility, the only chance to
+    * honour a 3.1 context is through core profile.
     */
    attribs.profile = ST_PROFILE_DEFAULT;
-   if ((major > 3 || (major == 3 && minor >= 2))
-       && ((profileMask & GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB) == 0))
+   if (((major > 3 || (major == 3 && minor >= 2))
+        && ((profileMask & GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB) == 0)) ||
+       (major == 3 && minor == 1))
       attribs.profile = ST_PROFILE_OPENGL_CORE;
 
    c->st = stapi->create_context(stapi, xmdpy->smapi, &attribs,
diff --git a/src/gallium/targets/dri-swrast/swrast_drm_api.c b/src/gallium/targets/dri-swrast/swrast_drm_api.c
index a8973fd..1c04e17 100644
--- a/src/gallium/targets/dri-swrast/swrast_drm_api.c
+++ b/src/gallium/targets/dri-swrast/swrast_drm_api.c
@@ -62,4 +62,18 @@  fail:
    return NULL;
 }
 
+void foo (void);
+const void **__driDriverGetExtensions_swrast(void);
+
+void
+foo (void)
+{
+   __driDriverGetExtensions_swrast();
+}
+
+PUBLIC const void **__driDriverGetExtensions_swrast(void)
+{
+   assert(0);
+   return NULL;
+}
 /* vim: set sw=3 ts=8 sts=3 expandtab: */
diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c b/src/mesa/state_tracker/st_atom_framebuffer.c
index a17417c..e79d2d9 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -148,10 +148,13 @@  update_framebuffer_state( struct st_context *st )
 #endif
 
    /* _mesa_test_framebuffer_completeness refuses framebuffers with no
-    * attachments, so this should never happen.
+    * attachments, so this should never happen, but apparently it does with
+    * piglit/bin/drawbuffer-modes on radeonsi.
     */
-   assert(framebuffer->width  != UINT_MAX);
-   assert(framebuffer->height != UINT_MAX);
+   if (framebuffer->width == UINT_MAX)
+      framebuffer->width = 0;
+   if (framebuffer->height == UINT_MAX)
+      framebuffer->height = 0;
 
    cso_set_framebuffer(st->cso_context, framebuffer);
 }

Comments

Jose,

Your assertions are disabled or something else is. The test binds a
framebuffer which has no attachments. You can do that with the default
framebuffer, so the FBO completeness rules don't apply here.

There is also GL_ARB_framebuffer_no_attachments, which allows it for
FBOs, though Mesa doesn't support it yet.

Marek

On Thu, Apr 24, 2014 at 1:31 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
>
>
> ----- Original Message -----
>> On 24.04.2014 03:12, Jose Fonseca wrote:
>> > Module: Mesa
>> > Branch: master
>> > Commit: fd92346c53ed32709c7b56ce58fb9c9bf43ce9a8
>> > URL:
>> > https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3Dfd92346c53ed32709c7b56ce58fb9c9bf43ce9a8&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=XOFDALlPDjLntm1Qs4okrzKRXQoXq3jonmJqsdohb6E%3D%0A&s=27ef6f50a2586caf483f351b5e80126e886087d89d0f98c9d777a6e8e80a229e
>> >
>> > Author: José Fonseca <jfonseca@vmware.com>
>> > Date:   Thu Apr  3 15:56:46 2014 +0100
>> >
>> > mesa/st: Fix pipe_framebuffer_state::height for PIPE_TEXTURE_1D_ARRAY.
>> >
>> > This prevents buffer overflow w/ llvmpipe when running piglit
>> >
>> >   bin/gl-3.2-layered-rendering-clear-color-all-types 1d_array single_level
>> >   -fbo -auto
>> >
>> > v2: Compute the framebuffer size as the minimum size, as pointed out by
>> > Brian;  compacted code;  ran piglit quick test list (with no
>> > regressions.)
>>
>> This commit broke the piglit test drawbuffer-modes for me with radeonsi:
>>
>> ../../../src/mesa/state_tracker/st_atom_framebuffer.c:153:update_framebuffer_state:
>> Assertion `framebuffer->width != (2147483647 * 2U + 1U)' failed.
>> Apr 24 16:38:02 kaveri kernel: [26036.258250] traps:
>> drawbuffer-mode[6292] trap int3 ip:7f50e6f52526 sp:7ffffcc82640 error:0
>> zsh: trace trap  DISPLAY=:1
>> /home/daenzer/src/piglit-git/piglit/bin/drawbuffer-modes -auto
>>
>> The test was previously passing.
>
> It passes here with llvmpipe, and I don't have radeonsi machine.
>
> It really shouldn't happen.  The only way this assertion could fail is if the framebuffer had no color/depth-stencil surfaces.  What's the contents of *framebuffer, and what's the backtrace?
>
> Anyway, it's easy to workaround it -- the attached patch should avoid it --, but it's sweeping dirt under the rug.  I suspect something else might have gone bad.
>
>
> Jose
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
No idea why I can't see it here then. My assertions are fine (assert(0) triggers).

Does my patch fix it? If so I'll push it, and strip the comment about being unexpected.

Jose

----- Original Message -----
> Jose,
> 
> Your assertions are disabled or something else is. The test binds a
> framebuffer which has no attachments. You can do that with the default
> framebuffer, so the FBO completeness rules don't apply here.
> 
> There is also GL_ARB_framebuffer_no_attachments, which allows it for
> FBOs, though Mesa doesn't support it yet.
> 
> Marek
> 
> On Thu, Apr 24, 2014 at 1:31 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
> >
> >
> > ----- Original Message -----
> >> On 24.04.2014 03:12, Jose Fonseca wrote:
> >> > Module: Mesa
> >> > Branch: master
> >> > Commit: fd92346c53ed32709c7b56ce58fb9c9bf43ce9a8
> >> > URL:
> >> > https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3Dfd92346c53ed32709c7b56ce58fb9c9bf43ce9a8&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=XOFDALlPDjLntm1Qs4okrzKRXQoXq3jonmJqsdohb6E%3D%0A&s=27ef6f50a2586caf483f351b5e80126e886087d89d0f98c9d777a6e8e80a229e
> >> >
> >> > Author: José Fonseca <jfonseca@vmware.com>
> >> > Date:   Thu Apr  3 15:56:46 2014 +0100
> >> >
> >> > mesa/st: Fix pipe_framebuffer_state::height for PIPE_TEXTURE_1D_ARRAY.
> >> >
> >> > This prevents buffer overflow w/ llvmpipe when running piglit
> >> >
> >> >   bin/gl-3.2-layered-rendering-clear-color-all-types 1d_array
> >> >   single_level
> >> >   -fbo -auto
> >> >
> >> > v2: Compute the framebuffer size as the minimum size, as pointed out by
> >> > Brian;  compacted code;  ran piglit quick test list (with no
> >> > regressions.)
> >>
> >> This commit broke the piglit test drawbuffer-modes for me with radeonsi:
> >>
> >> ../../../src/mesa/state_tracker/st_atom_framebuffer.c:153:update_framebuffer_state:
> >> Assertion `framebuffer->width != (2147483647 * 2U + 1U)' failed.
> >> Apr 24 16:38:02 kaveri kernel: [26036.258250] traps:
> >> drawbuffer-mode[6292] trap int3 ip:7f50e6f52526 sp:7ffffcc82640 error:0
> >> zsh: trace trap  DISPLAY=:1
> >> /home/daenzer/src/piglit-git/piglit/bin/drawbuffer-modes -auto
> >>
> >> The test was previously passing.
> >
> > It passes here with llvmpipe, and I don't have radeonsi machine.
> >
> > It really shouldn't happen.  The only way this assertion could fail is if
> > the framebuffer had no color/depth-stencil surfaces.  What's the contents
> > of *framebuffer, and what's the backtrace?
> >
> > Anyway, it's easy to workaround it -- the attached patch should avoid it
> > --, but it's sweeping dirt under the rug.  I suspect something else might
> > have gone bad.
> >
> >
> > Jose
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=RULLBmspV%2FpvJCiH4ZxCXIP%2FITVv2C6OyBMgUQAngNQ%3D%0A&s=bb527a54ec5fdfa60c0f5778f0636ba272b41a081c4fe9c8eead8019ab0f43d6
> >
>
The patch fixes the issue, but it also contains some unrelated drisw changes.

Marek

On Thu, Apr 24, 2014 at 2:37 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
> No idea why I can't see it here then. My assertions are fine (assert(0) triggers).
>
> Does my patch fix it? If so I'll push it, and strip the comment about being unexpected.
>
> Jose
>
> ----- Original Message -----
>> Jose,
>>
>> Your assertions are disabled or something else is. The test binds a
>> framebuffer which has no attachments. You can do that with the default
>> framebuffer, so the FBO completeness rules don't apply here.
>>
>> There is also GL_ARB_framebuffer_no_attachments, which allows it for
>> FBOs, though Mesa doesn't support it yet.
>>
>> Marek
>>
>> On Thu, Apr 24, 2014 at 1:31 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> On 24.04.2014 03:12, Jose Fonseca wrote:
>> >> > Module: Mesa
>> >> > Branch: master
>> >> > Commit: fd92346c53ed32709c7b56ce58fb9c9bf43ce9a8
>> >> > URL:
>> >> > https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3Dfd92346c53ed32709c7b56ce58fb9c9bf43ce9a8&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=XOFDALlPDjLntm1Qs4okrzKRXQoXq3jonmJqsdohb6E%3D%0A&s=27ef6f50a2586caf483f351b5e80126e886087d89d0f98c9d777a6e8e80a229e
>> >> >
>> >> > Author: José Fonseca <jfonseca@vmware.com>
>> >> > Date:   Thu Apr  3 15:56:46 2014 +0100
>> >> >
>> >> > mesa/st: Fix pipe_framebuffer_state::height for PIPE_TEXTURE_1D_ARRAY.
>> >> >
>> >> > This prevents buffer overflow w/ llvmpipe when running piglit
>> >> >
>> >> >   bin/gl-3.2-layered-rendering-clear-color-all-types 1d_array
>> >> >   single_level
>> >> >   -fbo -auto
>> >> >
>> >> > v2: Compute the framebuffer size as the minimum size, as pointed out by
>> >> > Brian;  compacted code;  ran piglit quick test list (with no
>> >> > regressions.)
>> >>
>> >> This commit broke the piglit test drawbuffer-modes for me with radeonsi:
>> >>
>> >> ../../../src/mesa/state_tracker/st_atom_framebuffer.c:153:update_framebuffer_state:
>> >> Assertion `framebuffer->width != (2147483647 * 2U + 1U)' failed.
>> >> Apr 24 16:38:02 kaveri kernel: [26036.258250] traps:
>> >> drawbuffer-mode[6292] trap int3 ip:7f50e6f52526 sp:7ffffcc82640 error:0
>> >> zsh: trace trap  DISPLAY=:1
>> >> /home/daenzer/src/piglit-git/piglit/bin/drawbuffer-modes -auto
>> >>
>> >> The test was previously passing.
>> >
>> > It passes here with llvmpipe, and I don't have radeonsi machine.
>> >
>> > It really shouldn't happen.  The only way this assertion could fail is if
>> > the framebuffer had no color/depth-stencil surfaces.  What's the contents
>> > of *framebuffer, and what's the backtrace?
>> >
>> > Anyway, it's easy to workaround it -- the attached patch should avoid it
>> > --, but it's sweeping dirt under the rug.  I suspect something else might
>> > have gone bad.
>> >
>> >
>> > Jose
>> > _______________________________________________
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=RULLBmspV%2FpvJCiH4ZxCXIP%2FITVv2C6OyBMgUQAngNQ%3D%0A&s=bb527a54ec5fdfa60c0f5778f0636ba272b41a081c4fe9c8eead8019ab0f43d6
>> >
>>
Oop. Please ignore that. I forgot to specify the filename when producing the diff.

Jose

----- Original Message -----
> The patch fixes the issue, but it also contains some unrelated drisw changes.
> 
> Marek
> 
> On Thu, Apr 24, 2014 at 2:37 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
> > No idea why I can't see it here then. My assertions are fine (assert(0)
> > triggers).
> >
> > Does my patch fix it? If so I'll push it, and strip the comment about being
> > unexpected.
> >
> > Jose
> >
> > ----- Original Message -----
> >> Jose,
> >>
> >> Your assertions are disabled or something else is. The test binds a
> >> framebuffer which has no attachments. You can do that with the default
> >> framebuffer, so the FBO completeness rules don't apply here.
> >>
> >> There is also GL_ARB_framebuffer_no_attachments, which allows it for
> >> FBOs, though Mesa doesn't support it yet.
> >>
> >> Marek
> >>
> >> On Thu, Apr 24, 2014 at 1:31 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
> >> >
> >> >
> >> > ----- Original Message -----
> >> >> On 24.04.2014 03:12, Jose Fonseca wrote:
> >> >> > Module: Mesa
> >> >> > Branch: master
> >> >> > Commit: fd92346c53ed32709c7b56ce58fb9c9bf43ce9a8
> >> >> > URL:
> >> >> > https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3Dfd92346c53ed32709c7b56ce58fb9c9bf43ce9a8&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=XOFDALlPDjLntm1Qs4okrzKRXQoXq3jonmJqsdohb6E%3D%0A&s=27ef6f50a2586caf483f351b5e80126e886087d89d0f98c9d777a6e8e80a229e
> >> >> >
> >> >> > Author: José Fonseca <jfonseca@vmware.com>
> >> >> > Date:   Thu Apr  3 15:56:46 2014 +0100
> >> >> >
> >> >> > mesa/st: Fix pipe_framebuffer_state::height for
> >> >> > PIPE_TEXTURE_1D_ARRAY.
> >> >> >
> >> >> > This prevents buffer overflow w/ llvmpipe when running piglit
> >> >> >
> >> >> >   bin/gl-3.2-layered-rendering-clear-color-all-types 1d_array
> >> >> >   single_level
> >> >> >   -fbo -auto
> >> >> >
> >> >> > v2: Compute the framebuffer size as the minimum size, as pointed out
> >> >> > by
> >> >> > Brian;  compacted code;  ran piglit quick test list (with no
> >> >> > regressions.)
> >> >>
> >> >> This commit broke the piglit test drawbuffer-modes for me with
> >> >> radeonsi:
> >> >>
> >> >> ../../../src/mesa/state_tracker/st_atom_framebuffer.c:153:update_framebuffer_state:
> >> >> Assertion `framebuffer->width != (2147483647 * 2U + 1U)' failed.
> >> >> Apr 24 16:38:02 kaveri kernel: [26036.258250] traps:
> >> >> drawbuffer-mode[6292] trap int3 ip:7f50e6f52526 sp:7ffffcc82640 error:0
> >> >> zsh: trace trap  DISPLAY=:1
> >> >> /home/daenzer/src/piglit-git/piglit/bin/drawbuffer-modes -auto
> >> >>
> >> >> The test was previously passing.
> >> >
> >> > It passes here with llvmpipe, and I don't have radeonsi machine.
> >> >
> >> > It really shouldn't happen.  The only way this assertion could fail is
> >> > if
> >> > the framebuffer had no color/depth-stencil surfaces.  What's the
> >> > contents
> >> > of *framebuffer, and what's the backtrace?
> >> >
> >> > Anyway, it's easy to workaround it -- the attached patch should avoid it
> >> > --, but it's sweeping dirt under the rug.  I suspect something else
> >> > might
> >> > have gone bad.
> >> >
> >> >
> >> > Jose
> >> > _______________________________________________
> >> > mesa-dev mailing list
> >> > mesa-dev@lists.freedesktop.org
> >> > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=RULLBmspV%2FpvJCiH4ZxCXIP%2FITVv2C6OyBMgUQAngNQ%3D%0A&s=bb527a54ec5fdfa60c0f5778f0636ba272b41a081c4fe9c8eead8019ab0f43d6
> >> >
> >>
>