Aries device has red/blue channels swapped

NEW
Unassigned

Status

Firefox OS
GonkIntegration
P1
normal
3 years ago
2 years ago

People

(Reporter: drs, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug)

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:-)

Details

(Whiteboard: [spark])

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
[Blocking Requested - why for this release]:

From :vlad,

> Yeah, this looks like the z3c has the red/blue channels swapped; specifically, 
> likely the RB_SWAPPED flag on the texture host for webgl is incorrect for the 
> device (and its hwcomposer etc)...

This is pretty bad, and it's making some WebGL-based demos almost unusable.
(Reporter)

Comment 1

3 years ago
Vlad, could you provide anymore info on this?

Mike, I'm not sure who can help us with this. Could you point us in the right direction?
Flags: needinfo?(vladimir)
Flags: needinfo?(mwu)
Launch HexGL on the device, colors are incorrect.  Haven't looked into it more deeply than that.
Flags: needinfo?(vladimir)
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #2)
> Launch HexGL on the device, colors are incorrect.  Haven't looked into it
> more deeply than that.

That's pretty strange, I did used HexGL to play with the device in the early days of the port, and I clearly do not remember seeing weird colors (and I fixed a similar issue back in the time on Nexus S).
Created attachment 8604940 [details]
IMG_0002.jpg
Created attachment 8604941 [details]
IMG_0003.jpg
Created attachment 8604942 [details]
IMG_0004.jpg

Comment 7

3 years ago
Do we still need RB_SWAPPED? I fixed an issue with our EGL configuration selection not taking the byteorder of the native surface into account a while back (bug 1026776) which might help with this. We shouldn't need to mess around with swapping RB channels..
Flags: needinfo?(mwu)
(Reporter)

Comment 8

3 years ago
Mike, this seems to still be an issue. See http://fxos.github.io/sechelt/ on an Aries/Shinano vs. desktop.
Flags: needinfo?(mwu)

Comment 9

3 years ago
Discussed on IRC. It looks like it's not a RB swap issue, but I'm not entirely sure what it is.
Flags: needinfo?(mwu)
(Reporter)

Comment 10

3 years ago
Diego, Kevin, since you guys are working on VR, any idea what the issue here is? Right now, the mountains in the Sechelt demo are neon green on the Aries:
http://mozvr.com/projects/sechelt/
Flags: needinfo?(kgrandon)
Flags: needinfo?(dwilson)
(Reporter)

Updated

3 years ago
Flags: needinfo?(dwilson) → needinfo?(dmarcos)
This is not my area of expertise.
I don't really have an idea here, but according to comment 9, it sounds like either Mike or Jeff might know.

Mike, Jeff - Can you tell us what next steps here would be, or who would be able to look into this?
Flags: needinfo?(mwu)
Flags: needinfo?(kgrandon)
Flags: needinfo?(jgilbert)

Updated

3 years ago
Flags: needinfo?(mwu)
(In reply to Michael Wu [:mwu] from comment #7)
> Do we still need RB_SWAPPED? I fixed an issue with our EGL configuration
> selection not taking the byteorder of the native surface into account a
> while back (bug 1026776) which might help with this. We shouldn't need to
> mess around with swapping RB channels..

This code is probably failing through to the code below it. If this was not intentional, we should include an assert regardless of whether it's a problem here.

IIRC there's no specced way to check the order of channels otherwise in EGL. If we want to the case where format matching fails, we need to support R/B swap.
Flags: needinfo?(jgilbert)

Comment 14

3 years ago
(In reply to Jeff Gilbert [:jgilbert] from comment #13)
> This code is probably failing through to the code below it. If this was not
> intentional, we should include an assert regardless of whether it's a
> problem here.
> 
> IIRC there's no specced way to check the order of channels otherwise in EGL.
> If we want to the case where format matching fails, we need to support R/B
> swap.

FWIW, this was not a RB swap issue. It's some issue with the shaders - not sure what.

As for the EGL config, there's a fallthrough for the EGL configuration, but I think it should actually just fail if it can't match the format. That's what Android does IIRC - it has no plan B for when the normal EGL config selection doesn't work. But, it doesn't seem very important either way.
Next steps are someone with a device digging in and making a reduced testcase for this issue, or just root-causing it.
(Reporter)

Comment 16

3 years ago
(In reply to Jeff Gilbert [:jgilbert] from comment #15)
> Next steps are someone with a device digging in and making a reduced
> testcase for this issue, or just root-causing it.

Who can do that?
Flags: needinfo?(jgilbert)
I don't know.
Flags: needinfo?(jgilbert) → needinfo?(milan)
The shader that's drawing the ship is using high precision floating point precision:

precision highp float;

I highly suspect this code in the fragment shader (#8 that loads):

if( enableDiffuse ) {
#ifdef GAMMA_INPUT
vec4 texelColor = texture2D( tDiffuse, vUv );
texelColor.xyz *= texelColor.xyz;
gl_FragColor = gl_FragColor * texelColor;

If you comment out all of the post processing effects up to this assignment, the colors are still bad, and it's the first assignment to gl_FragColor.

The canvas editor seems broken for remote debugging (trying to see when this shader was invoked)

Changing the quality settings at the app launch screen doesn't change the misapplied textures.
What's an Aries device? Sounds like Vlad has access to it, he may be the best person to investigate this further.
Flags: needinfo?(milan)
(Reporter)

Comment 20

3 years ago
(In reply to Milan Sreckovic [:milan] from comment #19)
> What's an Aries device? Sounds like Vlad has access to it, he may be the
> best person to investigate this further.

Yes, Vlad has one. Vlad, could you investigate this?
Flags: needinfo?(vladimir)
(Reporter)

Comment 21

3 years ago
We're going to just remove Sechelt from our build instead, since it's not working very well.
blocking-b2g: spark+ → -
Whiteboard: [spark] → [spark][webvr]
If it's not an RB swap issue, and general WebGL content runs (which it does, such as the Unity demos) then it's going to be something specific to the individual shaders and/or the specific code -- not a platform issue.
Flags: needinfo?(vladimir)

Updated

2 years ago
Whiteboard: [spark][webvr] → [spark]
You need to log in before you can comment on or make changes to this bug.