Bug 20319 - Mesa 7.5-devel implementation error: i915_program_error: bad opcode
Summary: Mesa 7.5-devel implementation error: i915_program_error: bad opcode
Status: CLOSED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-25 17:15 UTC by Anders Juel Jensen
Modified: 2009-08-24 12:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
patch to produce more debug output (493 bytes, patch)
2009-03-03 07:02 UTC, Brian Paul
Details | Splinter Review
Patch to give even more debug output (550 bytes, patch)
2009-03-03 10:10 UTC, Johannes Engel
Details | Splinter Review
patch for bad opcode on i915 (623 bytes, patch)
2009-03-03 23:03 UTC, haihao
Details | Splinter Review

Description Anders Juel Jensen 2009-02-25 17:15:17 UTC
Hi guys.

OS: Slackware 12.1 with linux-2.6.29-rc6-git3 not using KMS
GCC: 4.2.3

I was trying to give the entire stack a spin according to: http://wiki.x.org/wiki/Development/git

That is to say, I am running the latest git of everything. The only thing that didn't compile cleanly was xf86-video-intel, but i hand copied the header file hackaround for EXA (i use UXA, so that shouldn't be a problem, right?) which is being proposed on their mailing list right now.

Ok, so the thing starts nicely, and everything appears to be working, until i try to launch compiz, where i get:

macavity@rogue:~$ compiz --replace --sm-disable --ignore-desktop-hints ccp
Mesa 7.5-devel implementation error: i915_program_error: bad opcode
Please report at bugzilla.freedesktop.org

This makes the system slow as cold molasses.. as in, it takes 10-15 seconds for things to react when i click on them.

Observe that I am prepared to run through as many hoops as you need me to. Eg, if you show me how to hook gdb to whatever you need to produce additional info, I will do it pronto (what opcode is it?).

Attached is my Xorg.0.log of the session, but it doesn't look particular usefull.

Do you need my kernel config too?
Comment 1 Tobias Jakobi 2009-02-26 08:00:26 UTC
Confirming this. Just checked out mesa git master and build the normal DRI drivers. Using them lets this error message pop up (tried wine with two games, both now run VERY slow).

I don't know how to build gallium.
Comment 2 Eric Anholt 2009-02-27 20:28:25 UTC
Bisected to:

commit f2c023291a1f2887294d2aac504f8b82857ad092
Author: Brian Paul <brianp@vmware.com>
Date:   Sun Feb 22 15:43:29 2009 -0700

    mesa: move a bunch of compiler-related stuff into new compiler.h header
    
    This trims down and cleans up imports.h and glheader.h quite a bit.

with clean rebuilds on each side of the commit.
Comment 3 Brian Paul 2009-02-28 08:54:05 UTC
My 915 isn't set up right now.  I'm not sure how my commit could have caused this particular regression.  Can someone find the value of 'inst->Opcode' there?

Or, call _mesa_print_program(&program->Base) to see the whole program?
Comment 4 Johannes Engel 2009-03-03 01:04:26 UTC
If you can tell me how to patch glxgears.c to obtain that output, I can give it to you.
Comment 5 Brian Paul 2009-03-03 07:02:40 UTC
Created attachment 23472 [details] [review]
patch to produce more debug output

Can you apply this patch to Mesa and recompile?  It should produce more info for debugging/fixing this.  Though, someone else has indicated the bad opcode is OPCODE_NOP.  I'm not sure where that would be coming from.

Anyway, send me the output from running with this patch.  Thanks.
Comment 6 Johannes Engel 2009-03-03 07:18:29 UTC
That does not look too complicated. Here is the output of glxgears:

Bad opcode = 0
# Fragment Program/Shader
  0: MOV OUTPUT[1], INPUT[1];
  1: END
Comment 7 Brian Paul 2009-03-03 09:05:35 UTC
That's weird, how can we be getting a bad opcode if there's only two instructions which are both trivially supported?  Someone's just going to have to step through this with a debugger.
Comment 8 Johannes Engel 2009-03-03 10:10:03 UTC
Created attachment 23480 [details] [review]
Patch to give even more debug output

Using this patch on top of your last one I get the following output:
Opcode is 43
Opcode is 0
Mesa 7.5-devel implementation error: i915_program_error: bad opcode
Please report at bugzilla.freedesktop.org
Bad opcode = 0
# Fragment Program/Shader
  0: MOV OUTPUT[1], INPUT[1];
  1: END

Did the definition of OPCODE_END somehow vanish?
Comment 9 Johannes Engel 2009-03-03 10:14:31 UTC
No, wrong guess, OPCODE_END is 25. Is there any opcode with value 0?
Comment 10 Brian Paul 2009-03-03 10:23:12 UTC
OPCODE_NOP==0 (see src/mesa/shader/prog_instruction.h)

Comment 11 Vinson Lee 2009-03-03 15:40:54 UTC
I see the bad opcode i915_program_error with glxgears as well using git/master.

I also see the bad opcode i915_program_error with Mesa-7.5-devel-20090224 but not with Mesa-7.5-devel-20090209. This contradicts the suggested faulty commit mentioned in comment #2, which came after Mesa-7.5-devel-20090224.
Comment 12 Vinson Lee 2009-03-03 15:43:49 UTC
(In reply to comment #11)
> 
> I also see the bad opcode i915_program_error with Mesa-7.5-devel-20090224 but
> not with Mesa-7.5-devel-20090209. This contradicts the suggested faulty commit
> mentioned in comment #2, which came after Mesa-7.5-devel-20090224.
> 

Correction. The commit mentioned in comment #2 is in Mesa-7.5-devel-20090224 so it can still be at fault.
Comment 13 haihao 2009-03-03 23:03:06 UTC
Created attachment 23503 [details] [review]
patch for bad opcode on i915

This problem is caused by FEATURE_MESA_program_debug. It is defined when gcc handles struct prog_instruction for texenvprogram.c but it isn't defined when gcc handles struct prog_instruction for i915_fragprog.c.  Adjusting the order of some header files for i915_fragprog.c can fix this bad opcode issue. However it seems the rendering on 915 is incorrect, it should be broken by something.
Comment 14 Johannes Engel 2009-03-04 01:00:55 UTC
That indeed solves the bad opcode! Thanks for spotting this.
glxgears for some reason though shows a white background and freezes the system (mouse pointer still moving, but no reaction whatsoever) after about 15 secs.
But I suppose that is a different bug.
Comment 15 Brian Paul 2009-03-04 07:01:59 UTC
Yes, that explains it.  A simpler fix is to include mfeatures.h in prog_instruction.h  I've committed that change 
(945dcbfca62b9b57340caccc1b8286b2f3e743bc)

If that fixes the original bug for you, please close this bug and open a new one describing the rendering errors.
Comment 16 Anders Juel Jensen 2009-03-12 08:59:01 UTC
The commit to master fixes this. Bug squashed.
Comment 17 Adam Jackson 2009-08-24 12:31:53 UTC
Mass version move, cvs -> git


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.