Bug 28138

Created attachment 35701 [details]
Failing shader

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)

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.

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.

(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

(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.)

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

correcting the glsl2 compiler dependency

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.

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?

Created attachment 39492 [details]
Screenshot of the game

I'm adding a new screenshot of the game from git master today (a0add04).

RO doesn't look particularly good after 5dc53444c8323c1787dddbe6b67048828df9c684 either

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.

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...)

just you need to fix the shader model 2 mode.

(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