Bug 25994 - [GM45][GLSL] 'return' statement in vertex shader unsupported
Summary: [GM45][GLSL] 'return' statement in vertex shader unsupported
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Eric Anholt
QA Contact:
Depends on:
Blocks: 29044
  Show dependency treegraph
Reported: 2010-01-11 11:57 UTC by Constantin Baranov
Modified: 2010-09-13 13:15 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Xorg.0.log (15.04 KB, text/plain)
2010-01-11 11:57 UTC, Constantin Baranov
dmesg (48.97 KB, text/plain)
2010-01-11 11:58 UTC, Constantin Baranov
intel_gpu_dump.gz (57.77 KB, application/gzip)
2010-01-11 12:00 UTC, Constantin Baranov
lspci.txt (19.36 KB, text/plain)
2010-01-11 12:01 UTC, Constantin Baranov
stellarium.log (3.00 KB, text/plain)
2010-01-11 12:01 UTC, Constantin Baranov
shader.c (1.48 KB, text/plain)
2010-01-14 14:04 UTC, Constantin Baranov
Mortal fragment shader (637 bytes, text/plain)
2010-01-29 14:05 UTC, Constantin Baranov

Description Constantin Baranov 2010-01-11 11:57:07 UTC
Chipset: GM45
Systme architecture: x86_64
xf86-video-intel 2.9.1
xserver 1.7.4
mesa 7.7
libdrm 2.4.17
kernel 2.6.33-rc3-00290-g1b4d40a (commit 1b4d40a517e0657a081d5d63518c4badd31c60ea)
Linux distribution: Gentoo
Machine: Acer Aspire 1410-232G25i
Display connector: LVDS

Reproduce steps:
1. Launch X.
2. Launch Stellarium (I use 0.10.3 trunk version built with Qt 4.6.0)
3. Usually this immediately causes a GPU hang. Rarely I was very lucky
and Stellarium has rendered its scene several times but caused
a GPU hang anyway.
4. X server crashes (see logs), or Stellarium may enter an 'infinite' loop
writing more and more errors from intel_bufmgr_gem.c, leaving display blank.

I tried also glxgears, torcs and neverball. All them works.
Issue is not related with suspend. I reproduce it right after power on.

I have caught this bug also with Linux kernel and 2.6.33-rc3,
with xf86-video-intel 2.10.0 and with xserver 1.7.4 RC 2.
Comment 1 Constantin Baranov 2010-01-11 11:57:49 UTC
Created attachment 32573 [details]
Comment 2 Constantin Baranov 2010-01-11 11:58:13 UTC
Created attachment 32574 [details]
Comment 3 Constantin Baranov 2010-01-11 12:00:32 UTC
Created attachment 32575 [details]
Comment 4 Constantin Baranov 2010-01-11 12:01:08 UTC
Created attachment 32576 [details]
Comment 5 Constantin Baranov 2010-01-11 12:01:25 UTC
Created attachment 32577 [details]
Comment 6 Constantin Baranov 2010-01-12 23:34:13 UTC
I tried to turn KMS off passing i915.modeset=0 to kernel.
Bug still reproducible. I also tried kernels 2.6.31 and 2.6.30.
With 2.6.31 bug appears as described above. With 2.6.30 behavior
is similar (Stellarium hangs at startup, GPU seems hang leaving
no chances to see working graphics without reboot) but no error messages
in dmesg appears. Downgrading mesa from 7.7 to 7.5.2 make no changes.
Comment 7 Constantin Baranov 2010-01-13 13:13:48 UTC
I have tried latest 2.6.33-rc4 kernel. Also I have tried to pass pci=nomsi
option to kernel. Bug appears anyway with the same symptoms.
Comment 8 Constantin Baranov 2010-01-14 14:04:33 UTC
Created attachment 32646 [details]

Latest revisions of Stellarium don't cause the bug anymore.
I've found that this happened after modification of the vertex shader
used in Stellarium. I've extracted the idea of that modification into
the attached file.

The attached program uses simple vertex shader.
The same logic is written in two correct equivalent (I believe)
variants. Both works fine on my desktop with NVIDIA GPU.
But only the first works OK on my laptop with GM45 GPU while
the second immediately causes GPU hang.
Comment 9 Loose Vladimir 2010-01-17 05:47:47 UTC
Chipset: 965GM
System architecture: x86_64
xf86-video-intel 2.9.1
xserver 1.7.4
mesa 7.7
libdrm 2.4.17
kernel 2.6.32-gentoo-r1
Linux distribution: Gentoo
Machine: Dell Vostro A860
Display connector: LVDS

Bug reproduced when running shader.c posted by Constantin Baranov: causes GPU hang (as expected) when running second variant, sometimes causes X server crash.
Comment 10 Constantin Baranov 2010-01-17 15:03:02 UTC
Bug is alive with the latest git versions of libdrm and mesa (w/o gallium).
I doubt about true location of the bug, so I'm CC'ing mesa developers.
Comment 11 Constantin Baranov 2010-01-29 14:05:11 UTC
Created attachment 32915 [details]
Mortal fragment shader

A fragment shader with 'discard' statement also kills GPU.
Discarding the 'discard' line in this source will save GPU.
Comment 12 Loose Vladimir 2010-01-29 15:16:53 UTC
Mortal fragment shader posted by Constantin Baranov reproduces bug on my hardware (see above), causes gpu hung and in most cases X server crash. Without 'discard' line works fine.
Comment 13 Loose Vladimir 2010-03-21 08:51:23 UTC
Happy to say, someone with nickname pino had looked at this bug report and tested shader.c and Mortal fragment shader on his hardware:

Chipset: GM45
System architecture: x86
xserver-xorg-video-intel 2.6.3
xserver 1.7.4
mesa 7.4
libdrm 2.4.5
kernel 2.6.28-11-generic 
Linux distribution: Ubuntu 9.04
Machine: Lenovo G550 model 20023
Display connector: LVDS

As he said, he haven't encountered any bugs during Mortal fragment shader test. 

shader.c with "#if 0" causes X server crash and GPU hang.
Comment 14 Eric Anholt 2010-08-18 21:47:09 UTC
I've added glsl-vs-main-return and glsl-fs-main-return to piglit to test the return from main() behavior.  This is the first time I've seen that used in a shader.  The 965 driver in mesa master now rejects these shaders until we get the codegen fixed up to handle it, so it won't hang.
Comment 15 Ian Romanick 2010-09-13 13:15:53 UTC
commit 4de7a3b76add1940f7316253a619c3728025d9db
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Sep 13 11:05:05 2010 -0700

    i965: Request that returns be lowered in shader main
    Fixes piglit tests glsl-vs-main-return and glsl-fs-main-return.

commit 87708e8c90220cc1997cef9de9b394c04d952be9
Author: Luca Barbieri <luca@luca-barbieri.com>
Date:   Tue Sep 7 02:15:26 2010 +0200

    glsl: call ir_lower_jumps according to compiler options

commit 3361cbac2a883818efeb2b3e27405eeefce60f63
Author: Luca Barbieri <luca@luca-barbieri.com>
Date:   Tue Sep 7 00:24:08 2010 +0200

    glsl: add continue/break/return unification/elimination pass (v2)
    Changes in v2:
    - Base class renamed to ir_control_flow_visitor
    - Tried to comply with coding style
    This is a new pass that supersedes ir_if_return and "lowers" jumps
    to if/else structures.
    Currently it causes no regressions on softpipe and nv40, but I'm not sure
    whether the piglit glsl tests are thorough enough, so consider this
    It can be asked to:
    1. Pull jumps out of ifs where possible
    2. Remove all "continue"s, replacing them with an "execute flag"
    3. Replace all "break" with a single conditional one at the end of the loop
    4. Replace all "return"s with a single return at the end of the function,
       for the main function and/or other functions
    This gives several great benefits:
    1. All functions can be inlined after this pass
    2. nv40 and other pre-DX10 chips without "continue" can be supported
    3. nv30 and other pre-DX10 chips with no control flow at all are better supp
    Note that for full effect we should also teach the unroller to unroll
    loops with a fixed maximum number of iterations but with the canonical
    conditional "break" that this pass will insert if asked to.
    Continues are lowered by adding a per-loop "execute flag", initialized to
    TRUE, that when cleared inhibits all execution until the end of the loop.
    Breaks are lowered to continues, plus setting a "break flag" that is checked
    at the end of the loop, and trigger the unique "break".
    Returns are lowered to breaks/continues, plus adding a "return flag" that
    causes loops to break again out of their enclosing loops until all the
    loops are exited: then the "execute flag" logic will ignore everything
    until the end of the function.
    Note that "continue" and "return" can also be implemented by adding
    a dummy loop and using break.
    However, this is bad for hardware with limited nesting depth, and
    prevents further optimization, and thus is not currently performed.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.