Bug 28138 - [G45] Regnum Online, sparkling in in-game rendering
[G45] Regnum Online, sparkling in in-game rendering
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
git
Other All
: medium normal
Assigned To: Carl Worth
http://www.regnumonline.com.ar/
:
Depends on: 29786
Blocks: 29044
  Show dependency treegraph
 
Reported: 2010-05-16 11:18 UTC by Sven Arvidsson
Modified: 2013-02-22 22:04 UTC (History)
0 users

See Also:


Attachments
Screenshot of the bug (800.54 KB, image/png)
2010-05-16 11:18 UTC, Sven Arvidsson
Details
Failing shader (2.26 KB, text/plain)
2010-05-16 11:18 UTC, Sven Arvidsson
Details
shader failing to preprocess (844 bytes, text/plain)
2010-08-18 13:18 UTC, Sven Arvidsson
Details
shader with #line 0 (2.65 KB, text/plain)
2010-08-19 03:19 UTC, Sven Arvidsson
Details
Shader with unexpected PRAGMA (1.10 KB, text/plain)
2010-08-23 11:39 UTC, Sven Arvidsson
Details
Screenshot of current state of game (123.43 KB, image/jpeg)
2010-09-03 15:07 UTC, Sven Arvidsson
Details
Screenshot of the game (38.37 KB, image/jpeg)
2010-10-17 11:37 UTC, Sven Arvidsson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Arvidsson 2010-05-16 11:18:26 UTC
Created attachment 35700 [details]
Screenshot of the bug

The game Regnum Online does not render correctly if shaders is used. 

By dumping the shaders used by the game I think I found the one causing the problem, it's at least the only one failing to compile:

/* Compile status: fail */
/* Log Info: */
Error: Array index out of bounds (index=0 size=0)
Error: Array index out of bounds (index=1 size=0)

Shaders doesn't work with the game with Mesa 7.7, 7.8 have the same bug as this one, so it's not a regression.

It's possible to run the game with a fixed function pipeline too, so this isn't too big a problem.

The game requires signing up, but doesn't cost anything to play.

System environment:
-- chipset: G45 / ICH10R
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- Machine or mobo model: Asus P5Q-EM
-- Display connector: DVI
-- xf86-video-intel: 58b089febceca1e915607bb723ee658aaa9dbed3
-- xserver: 1.8.1
-- mesa: 0b94c05c2827336e2abf46629590edf05a6b3f64
-- drm: a3305b076c005e0d3bd55da0214e91413cf65b48
-- kernel: 2.6.34-rc6
Comment 1 Sven Arvidsson 2010-05-16 11:18:56 UTC
Created attachment 35701 [details]
Failing shader
Comment 2 Eric Anholt 2010-05-18 20:41:01 UTC
GLSL2 is on track to fixing this, and this shader desperately wants the optimization it will bring.

GLSL2 currently chokes on:

- preprocessor (cworth is working on this)
- auto promotion of int to float in 1.20 (will be easy to fix)
- missing builtins (kwg is working on this)
Comment 3 Sven Arvidsson 2010-08-18 13:18:48 UTC
Created attachment 37963 [details]
shader failing to preprocess

After the glsl2 merge, Regnum Online segfaults on start. Looks like all shaders fail to preprocess, and all with the same error: "preprocessor error: Invalid tokens after #". Possibly the same as bug 29654?

I'm attaching the first of the failing shaders.
Comment 4 Sven Arvidsson 2010-08-19 03:19:31 UTC
Created attachment 37971 [details]
shader with #line 0 

With bd7853768dd7ad52604e3b636ae71dacaa7352fe the segfault is gone, but characters are not rendered in game. 

Looks like a lot of shaders still fails to preprocess when "#line 0" is used. I'm attaching one of the failing shaders.
Comment 5 Carl Worth 2010-08-23 10:51:56 UTC
(In reply to comment #4)
> Looks like a lot of shaders still fails to preprocess when "#line 0" is used.
> I'm attaching one of the failing shaders.

I've just pushed fixes out to Mesa master to fix this part of the bug (see below).

Can someone please verify for me if the other issues for this bug are all fixed now? Otherwise this bug could be reassigned to whomever is working on a remaining issue.

-Carl
Comment 6 Carl Worth 2010-08-23 10:52:34 UTC
(In reply to comment #5)
> I've just pushed fixes out to Mesa master to fix this part of the bug (see
> below).

Here's the text I meant to include in the above comment:

commit eab206510fc76407ee8b18aacafadd0d5406e483
Author: Carl Worth <cworth@cworth.org>
Date:   Mon Aug 23 09:35:24 2010 -0700

    glcpp: Update generated glcpp-lex.c for the last two changes.
    
    This fixes both "#line 0" and "#line XXX YYY" as described in the two
    most recent commits.

commit c2280e63817238bb969b20605c7d8dab4ddf1721
Author: Carl Worth <cworth@cworth.org>
Date:   Mon Aug 23 09:31:42 2010 -0700

    glcpp: Fix handling of "#line 0"
    
    The existing DECIMAL_INTEGER pattern is the correct thing to use when
    looking for a C decimal integer, (that is, a digit-sequence not
    starting with 0 which would instead be an octal integer).
    
    But for #line, we really want to accept any digit sequence, (including
    "0"), and always interpret it as a decimal constant. So we add a new
    DIGITS pattern for this case.
    
    This should fix the compilation failure noted in bug #28138
    
    	https://bugs.freedesktop.org/show_bug.cgi?id=28138
    
    (Though the generated file will not be updated until the next commit.)
Comment 7 Sven Arvidsson 2010-08-23 11:39:26 UTC
Created attachment 38107 [details]
Shader with unexpected PRAGMA

Thanks for working on this! 

There's one more error, eight fragment shaders all report the same syntax error, I'm attaching one of them.

 0:12(1): error: syntax error, unexpected PRAGMA, expecting IN_TOK or VARYING
Comment 8 Gordon Jin 2010-08-25 17:27:33 UTC
correcting the glsl2 compiler dependency
Comment 9 Sven Arvidsson 2010-08-30 14:44:43 UTC
Now with pragma support added, there are no compile errors and the game starts up. Game models are invisible, but it could be another instance of bug 29676.
Comment 10 Sven Arvidsson 2010-09-03 15:07:00 UTC
Created attachment 38412 [details]
Screenshot of current state of game

(In reply to comment #9)
> Now with pragma support added, there are no compile errors and the game starts
> up. Game models are invisible, but it could be another instance of bug 29676.

Not bug 29676 it seems.

Currently RO has progressed a bit, the player character is visible now, but lightning and textures are still off. 

Other drivers, llvmpipe, r300g, is rendering even less, so I guess this could still be something in the compiler?
Comment 11 Sven Arvidsson 2010-10-17 11:37:27 UTC
Created attachment 39492 [details]
Screenshot of the game

I'm adding a new screenshot of the game from git master today (a0add04).
Comment 12 Eric Anholt 2010-12-23 02:40:46 UTC
RO doesn't look particularly good after 5dc53444c8323c1787dddbe6b67048828df9c684 either
Comment 13 Eric Anholt 2011-01-17 17:22:51 UTC
character screen fixed with:

commit e4be665bbddcb6ddfd7b9b13f01152a97097b35c
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Jan 17 16:02:58 2011 -0800

    i965: Fix dead pointers to fp->Parameters->ParameterValues[] after realloc.
    
    Fixes texrect-many regression with ff_fragment_shader -- as we added
    refs to the subsequent texcoord scaling paramters, the array got
    realloced to a new address while our params[] still pointed at the old
    location.

in-game rendering is still a mess with undefined register access it looks like.
Comment 14 Kenneth Graunke 2012-02-17 15:32:44 UTC
I've just pushed a workaround to the VBO module to make it ignore invalid out-of-bounds ranges in glDrawRangeElements, which should fix a lot of models flickering in and out of view with Regnum Online's shader-based renderer.

I'm not sure what this bug is tracking at this point, but Regnum should be working better now.  (See also 40361, 41152, 44701, and 45214...)
Comment 15 Pablo 2012-03-21 08:38:35 UTC
just you need to fix the shader model 2 mode.
Comment 16 Carl Worth 2013-02-22 22:04:12 UTC
(In reply to comment #14)
> I'm not sure what this bug is tracking at this point, but Regnum should be
> working better now.  (See also 40361, 41152, 44701, and 45214...)

Yes, several different issues have already been raised and resolved within
this one bug report.

I'm going to close this one as fixed. If other bugs in Regnum Online remain,
please feel free to raise them as new bug reports, and we'll try to stick
with one-bug-report-for-one-bug as much as possible.

Thanks, all!

-Carl