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

--- Comment #2 from Alexander Sabourenkov screwdriver@lxnt.info 2011-10-31 07:50:58 PDT --- core did not fit: >3000K size

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

--- Comment #4 from Alexander Sabourenkov screwdriver@lxnt.info 2011-11-01 15:27:29 PDT --- The workaround did not help r600g. Same black screen. In addition, the non-llvm swrast draws point sprites 60 pixels in size instead of requested 16 (my original shaders get texture sub-image size via varyings too), plus it draws solid-black-textured point sprites as single pixels. r600c (as of Oct 27 git, just before being axed) works though.

Not knowing whether any given black screen is a bug, or legitimate undefined behaviour that just happens to work on some other renderer is driving me mad.

I managed to cut down the test case to bare minimum.

Usage:

./testbed <shaderset> <mesadriver>

shaderset is either "working" or "failing" - loads similarly named shaders.

"working" shader set does texture sampling in fragment shader "failing" shader set does texture sampling in vertex shader and passes the color as a varying vec4.

mesadriver is: hw - default, LIBGL_ALWAYS_SOFTWARE and LIBGL_DRIVERS_PATH unset. hw-alt - use .so from dri-alternates (x64-86 hardcoded, sorry). sw - LIBGL_ALWAYS_SOFTWARE=y sw-alt - as above, but use .so from dri-alternates.

For the Oct 27 git these map to r600g, r600c, swrast, llvmpipe on my box.

Of those:

"failing" llvmpipe - works as intended, vertical colored bars (composed of 16x16 point sprites), one sprite is dark green - left unpainted intentionally. "working" llvmpipe - same (ok) "failing" DRI - ok "working" DRI - ok "failing" r600g - all sprites black "working" r600g - all sprites black "failing" old-swrast - single pixels instead of 16x16, but looks like color is right "working" old-swrast - same as "failing"

The hardware is rv770 9440.

I'd say there's a problem with r600g and a different one with old swrast.

There's also intermittent display corruption mainly on areas in xterm redrawn (but not those that get scrolled up) immediately after launching the testcase.

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

--- Comment #6 from Alexander Sabourenkov screwdriver@lxnt.info 2011-11-01 17:31:52 PDT --- Created attachment 53028 --> https://bugs.freedesktop.org/attachment.cgi?id=53028 xterm corruption screenshot

xterm corruption screenshot, got it right after I first run those shaders:

#version 120 #line 2 0

uniform float posz; uniform float width; attribute vec2 posn;

varying float idx;

void main() { vec2 posn2 = posz*posn; idx = posn2.x/width; gl_Position = gl_ModelViewProjectionMatrix*vec4(posn2.x, posn2.y, 0.0, 1.0); gl_PointSize = posz; } #version 120 #line 2 0 uniform sampler2D ansi;

varying float idx;

void main() { vec2 pc = gl_PointCoord; gl_FragColor = texture2D(ansi, vec2(0.5, 0)); }

- got grey screen as expected, and then reset fragment shader back to

#version 120 #line 2 0 uniform sampler2D ansi;

varying float idx;

void main() { vec2 pc = gl_PointCoord; gl_FragColor = texture2D(ansi, vec2(idx, 0)); }

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

--- Comment #8 from Alexander Sabourenkov screwdriver@lxnt.info 2011-11-01 17:54:54 PDT --- Created attachment 53029 --> https://bugs.freedesktop.org/attachment.cgi?id=53029 piglit test case for the problem

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

Alexander Sabourenkov screwdriver@lxnt.info changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #53030|0 |1 is obsolete| |

--- Comment #10 from Alexander Sabourenkov screwdriver@lxnt.info 2011-11-01 18:40:05 PDT --- Created attachment 53031 --> https://bugs.freedesktop.org/attachment.cgi?id=53031 piglit test case for the problem as a patch

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

--- Comment #12 from Vadim ptpzz@yandex.ru 2011-11-01 21:56:03 PDT --- Created attachment 53033 --> https://bugs.freedesktop.org/attachment.cgi?id=53033 [PATCH] r600g: take into account PSIZE output for spi mapping

Does this patch help?

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

--- Comment #14 from Claudio Freire klaussfreire@gmail.com 2012-02-25 14:26:24 PST --- I experience a similar situation with Ironlake and Mesa 8.0.1, only with far more complex shaders.

Apparently, in these shaders, all varyings get bogus data on the fragment shader.

The only workaround I can find is passing that data through the built-in varying in gl_TexCoord, although that's quite suboptimal for other drivers so I would prefer not to.