Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 155258 From Dust graphical corruption
Starred by 5 users Reported by, Oct 11 2012 Back to list
Status: Verified
Closed: Nov 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Sign in to add a comment
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.26 Safari/537.11

Steps to reproduce the problem:
1. Launch the game
2. Launch any map
3. Observe the graphical corruption

What is the expected behavior?
You should see a wonderful exotic landscape.

What went wrong?
Graphics are corrupted as shown on the attached screenshot.

WebStore page:

Did this work before? N/A 

Chrome version: 23.0.1271.26  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)

No pb with Chrome 22. No recent updates were made on the game.
From Dust - Graphical Corruption.png
1.8 MB View Download
Comment 1 by, Oct 19 2012
Labels: -Feature-Apps Feature-Plugins-Pepper Feature-GPU
The same bugs occured with different hardware configuration. Moreover, when testing with "--use-gl=desktop" it works perfectly so I guess something broke recently in angle.
Please note that a graphical glitch is also visible in the menu. 
From Dust - Bug Menu.png
450 KB View Download
Labels: Mstone-23 ReleaseBlock-Stable
Status: Assigned
John, can you please have a look?  Could these be related to the shader problems in  issue 153105  ? 
For what it's worth, it doesn't repro for me it the latest canary.  jairbubbles@ would you mind trying it in chrome canary as it may help us figure out whether it's an issue with your particular setup (gpu, driver, etc) or ANGLE? 

I'm going to try 23 beta next.
I can reproduce this issue in 23.0.1271.26, landscape looks all choppy and broken. works fine 22.0.1229.79. 
1.3 MB View Download
1.3 MB View Download
Labels: -Type-Bug Type-Regression
On subsequent runs, it does appear broken in canary too.  I'm not sure what happened the first time around.  I confirmed on two systems so it's unlikely to be a GPU / driver issue.

Bisecting chrome builds may help a lot here to identify which ANGLE roll (if it is indeed an ANGLE issue) did it.

Labels: Action-BisectNeeded
ok, we will get the bisect info. this game does not play in chromium build though. so we can't use the bisect tool.

 manual bisect needed. and the cl range will expect be be a little bigger. 
looks like I used a m21 chromium last time, the m22 and up chromium does play this game. will get the bisect window shortly ..
regression window is :

You are probably looking for a change made after 155297 (known good), but no lat
er than 155310 (first known bad).
Labels: -Action-BisectNeeded
r155305 angle roll is what we looking for
Comment 13 by, Oct 24 2012
ok looks like angle rolled

from 1267 to 1274 so somewhere in there?
I've bisected ANGLE and found revision 1271 to be the cause. The issue still presents itself with HEAD (1320).

Revision 1271 eliminated the use of the D3DX library for retrieving shader constant information (i.e. GLSL uniforms). But aside from one minor issue that immediately got fixed in revision 1272, there were no regressions in the WebGL Conformance Test Suite 1.0.2 nor any other known issues with this patch in any application tested since.

However, note that this patch changes the order of uniforms. It is perfectly valid for GL to list the uniforms in any order, but if an application wrongfully expects a certain ordering then it will not render correctly. I've quickly tested this hypothesis on From Dust by reversing the order of uniform (which again resulted in no WebGL CTS regressions): the game's graphical glitches looked different with this new uniform order.

Hence I believe this to be an application bug.
Ok we'll look into it. Thx for regressing the issue !
Comment 16 Deleted
Comment 18 by, Oct 25 2012
Labels: Merge-Approved
we have an angle revert for this. 
Labels: -Merge-Approved Merge-Merged
The latest canary that includes the revert seems to run "From Dust" fine (although you need to override the gpu blacklist because of a different bug).

We should be fine if we point the M23 branch to the ANGLE chrome_23 branch.

Let's keep this bug open though as we want to figure out what to do for M24.  jairbubbles@ is your code making any assumptions about the order of uniform locations (e.g. them being in a lexicographic order) in the shader?  
Comment 21 by, Oct 26 2012
Labels: -Mstone-23 -ReleaseBlock-Stable Mstone-24
awesome ty. removing blocker and movin bug to m24.
@vangelis I'm not the graphic programmer in charge but it seems we do make an asumption only for uniforms inside a structure. If I understand correctly changing that would be a lot of work for us.
We'll still need to remove the D3DX library from ANGLE eventually... if this is going to change the order of uniform locations in a way that's still spec-compliant we might have no choice. @jairbubbles can you check with or add the relevant graphics programmer to this thread? We don't want to break From Dust of course, but we need a path forward. Thanks,
Colt, we narrowly escaped this for M23 but it will come back in 24 unless the content is fixed to not be making assumptions about the shader uniform locations. How do we proceed? 
 Issue 161041  has been merged into this issue.
Comment 26 by, Nov 21 2012
Hi, I worked on the original "from dust" game and also worked on the GLES2 port. Just to say that I gonna start looking at this issue as soon as possible, probably tomorrow. (I just changed computer and have to reinstall all stuff actually).
That's great, please let us know how this goes!
Comment 28 by, Nov 23 2012
I integrated angle r1270 then r1272 into original code (no other changes) and confirm that the issue is related to the change about uniforms to D3D registers mapping. The rendering is corrupted because angle sets uniforms that stands for D3D register that overlaps. During the ZPass, the struct with instance data is declared as 6*16 bytes but the last 32 bytes are unused but glGetUniformLocation does not return -1. Then angle first writes c5 that is the unpack scale (would be c7 if all member of the first struct had been used but instance color is rarely useful during ZPass ;) ) but right after angle is ovewriting it by setting c0 to c5 as if the struct had not been stripped in shader.

// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
// Parameters:
//   float4 _VS_CompressedPosParamo_x_c54_x_vs;
//   struct
//   {
//       float4 _m_matWorldViewProjo_x_offset_0_x_vs[4];
//       float4 _f3_ExtraParamo_x_offset_16_x_vs;
//       float4 _f4_ExtraColoro_x_offset_20_x_vs;
//   } _VS_Object_paramo_x_c0_x_vs;
//   float2 dx_HalfPixelSize;
// Registers:
//   Name                               Reg   Size
//   ---------------------------------- ----- ----
//   _VS_Object_paramo_x_c0_x_vs        c0       4
//   dx_HalfPixelSize                   c4       1
//   _VS_CompressedPosParamo_x_c54_x_vs c5       1

So so far for me there is a problem with angle's glGetActiveUniform that returns instance color and other optionnal instance parameter as being used (maybe because it's a part of a struct?). I think that before r1270 we were setting these uniforms for nothing (we just had an ASSERT in code for -1 == location and it never happenned ) and angle just ignored them. If glGetActiveUniform only returned the uniforms used, I think it would fix the bug. 
Project Member Comment 29 by, Nov 28 2012
The following revision refers to this bug:

r169961 | | 2012-11-28T16:23:09.037240Z

Changed paths:

Roll ANGLE r1389:1394

BUG= 155258 

Review URL:
Labels: -Merge-Merged ReleaseBlock-Stable
We're seeing weird light effects on Laura Croft, too... might be related?

has the whole page flickering blue...

John can you check if that's fixed with this roll?
I think the Lara Croft issue is unrelated to this. It seems like it's timing-related somehow.
OK, splitting that out into  issue 163262 
Labels: Merge-Requested
Comment 35 by, Nov 29 2012
jbauman: Is this fixed in canary? could you please verify?
I was able to launch dust game on chrome 25.0.1338.0 (Official Build 170140) today's build. it did freeze the first time at the Breath, tribe dance. at 2nd try, I was able to launch and play dust game, graphic all looked fine through the game.

Comment 37 by, Nov 29 2012
jbauman: about c#36, why does it freeze the first time?
No, idea; I haven't seen it freeze before. It has to download a bunch of content, so if it happens to have an error then that could cause problems. I doubt that this patch would cause freezes like that.
Comment 39 by, Nov 29 2012
Labels: -Merge-Requested Merge-Approved
Please remember to fix the DEPS in
Project Member Comment 40 by, Nov 29 2012
Labels: -Merge-Approved merge-merged-1312
The following revision refers to this bug:

r31255 | | 2012-11-29T21:20:53.250857Z

Status: Fixed
Project Member Comment 42 by, Nov 29 2012
The following revision refers to this bug:

r170253 | | 2012-11-29T22:14:58.883647Z

Changed paths:

Merge 169961 - Roll ANGLE r1389:1394

BUG= 155258 

Review URL:
Review URL:
Status: Verified
verified on beta build 24.0.1312.32
Project Member Comment 44 by, Mar 9 2013
Labels: -Feature-Plugins-Pepper -Type-Regression -Feature-GPU -Mstone-24 Type-Bug-Regression Cr-Internals-GPU Cr-Content-Plugins-Pepper M-24
Project Member Comment 45 by, Apr 5 2013
Labels: Cr-Blink
Project Member Comment 46 by, Apr 6 2013
Labels: Cr-Internals-Plugins
Project Member Comment 47 by, Apr 6 2013
Labels: -Cr-Content-Plugins-Pepper Cr-Internals-Plugins-Pepper
Sign in to add a comment