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