775753 - Incorrect webgl attribute locations

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect)

Description

[billconan]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11

Steps to reproduce:

Go to this webpage: http://www.eveonline.com/universe/spaceships 
with default firefox settings. A spaceship is visible.

And then go to the about:config page, change 
webgl.prefer-native-gl to true

and check the same webpage again. The spaceship should be gone (become a little dot.)


Actual results:

Go to this webpage: http://www.eveonline.com/universe/spaceships 
with default firefox settings. A spaceship is visible.

And then go to the about:config page, change 
webgl.prefer-native-gl to true

and check the same webpage again. The spaceship should be gone (become a little dot.)


Expected results:

Hello,

I'm an OpenGL engineer from NVIDIA. We recently found that the EVE online spaceship viewer can't work properly on Windows and Linux with both firefox and chrome, if set OpenGL as the renderer. But things can work on Mac firefox and chrome.

here is eve spaceship viewer:

http://www.eveonline.com/universe/spaceships 

If use the Dx renderer, a spaceship should be visible. But if set OpenGL as the renderer, the spaceship will be gone. (It actually won't be gone, but become a very small dot.)

We suspected this is our driver bug. But after debugging, it looks like the driver is rendering wrong geometry data. It renders the surface binormals as the geometry. Because binormal data is ranging from -1 to 1, the spaceship shows as a little dot.

The reason is that, under windows or linux, webGL can't get the correct shader attribute locations.

Here is how the EVE viewer queries for attribute locations:

var p = device.gl.getProgramParameter(l.shaderProgram, device.gl.ACTIVE_ATTRIBUTES); 
for(var f = 0; f < p; ++f) 
{ 
var q = device.gl.getActiveAttrib(l.shaderProgram, f); 
console.log("attribute"+f+" is "+q.name); 
...
} 

It prints this:

attribute0 is a_Binormal 
attribute1 is a_Normal 
attribute2 is a_Position 
attribute3 is a_Tangent 
attribute4 is a_TexCoord 

However, inside our driver, the correct attribute locations should be this:

a_Position 0 
a_Normal 1 
a_Tangent 2 
a_Binormal 3 
a_TexCoord 4 

The spaceship viewer treats attribute 0 as binormal, but really it should be the geometry data.

The same javascript prints different log on Mac firefox:

attribute0 is a_Position 
attribute1 is a_Tangent 
attribute2 is a_Binormal 
attribute3 is a_TexCoord 
attribute4 is a_Normal 

This matches our driver's attribute locations.

It looks like, under windows and Linux, the WebGL renderer lists the attributes in their alphabetical order, rather than based on their location IDs. So it put a_Binormal at first.


To repro this bug:

Go to this webpage: http://www.eveonline.com/universe/spaceships 
with default firefox settings. A spaceship is visible.

And then go to the about:config page, change 
webgl.prefer-native-gl to true

and check the same webpage again. The spaceship should be gone (become a little dot.)


I'm not sure how webgl renderer is implemented inside chrome and firefox. Since this is a bug found with both chrome and firefox, I first filed this to ANGLE, but they believed this could also be a browser bug.

Comment 2

[Kelsey Gilbert [:jgilbert]]

Wow, thanks a lot for this report. Looking at it now.

Comment 3

[Kelsey Gilbert [:jgilbert]]

Attachment: Demonstration of retrieving attrib locations from the list of active attribs

Comment 4

[Kelsey Gilbert [:jgilbert]]

So, this will be fun.
Your testcase actually appears to be incorrect, though quite illustrative of the problem here. This eve example just so happens to work in ANGLE, but is not guaranteed to.

Guaranteed:
location == GetAttribLocation(program, GetActiveAttrib(program, activeAttribIndex).name)

Allowed:
location != activeAttribIndex


Since 'active attribs' must be a dense array of size GetProgramParameter(program, ACTIVE_ATTRIBUTES).
However, 'attribs' themselves can be a *sparse* list of capacity MAX_VERTEX_ATTRIBS.

In the example page I attached above, I use BindAttribLocation to set the location of 'aPosition' to 0, but the location of 'aTexCoord' to 3. However, ACTIVE_ATTRIBUTES naturally tells us there are only two attribs in the program.

info = GetActiveAttrib(program, 0) gives us info about the first active attrib. (which could actually be either 'aPosition' or 'aTexCoord'!) If we, however, call GetAttribLocation(program, info.name), we will see one of:
'aPosition' is at location 0
OR
'aTexCoord' is at location 3
(As an aside, on NV drivers, we will likely see 'aPosition' at active attrib index 0, because 'aPosition' is alphabetically before 'aTexCoord')


So, appears to be a bug in the eve demo.
It is tough to debug this demo, but it seems you already have a debug system working for this. Can you confirm that this is the case?

Comment 6

[billconan]

Yes, I think you are right. I just checked the eve webpage, looks like they have fixed the issue.

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

Marking as WORKSFORME based on comment #6 as well as my own personal verification of the site now working.