774530 - fImageTargetTexture2DOES(LOCAL_GL_TEXTURE_2D, 0) failed

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Sotaro Ikeda [:sotaro]]

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:

In bug 745137, apply attachment 633219 [details] [diff] [review] on my hardware(MSM8960).


Actual results:

following function call failed on my hardware(MSM8960) with "GL_INVALID_OPERATION" log print.
 - sEGLLibrary.fImageTargetTexture2DOES(LOCAL_GL_TEXTURE_2D, 0);



Expected results:

sEGLLibrary.fImageTargetTexture2DOES() function calls should not fail.

Comment 1

[Andreas Gal :gal]

I think a silicon vendor suggested that we instead of 0 use a mini texture with dimensions (1,1). The driver has an early out of the image is 0 and the old image isn't unlocked or freed.

Comment 2

[Kelsey Gilbert [:jgilbert]]

The meaning of glEGLImageTargetTexture2D(GL_TEXTURE_2D, 0) doesn't appear to be defined by the spec. 

It looks like this code is trying to 'disconnect' a GLTexture from an EGLImage, but there's no way to do this except by respecifying the texture.

Comment 3

[Kelsey Gilbert [:jgilbert]]

Rather, glEGLImageTargetTexture2D(GL_TEXTURE_2D, 0) would appear to be required to generate an INVALID_OPERATION, since 0 is not a valid EGLImage.

Comment 4

[Cody Brocious [:Daeken]]

(In reply to Andreas Gal :gal from comment #1)
> I think a silicon vendor suggested that we instead of 0 use a mini texture
> with dimensions (1,1). The driver has an early out of the image is 0 and the
> old image isn't unlocked or freed.

This is what I'm doing with the Thebes cross-process texture sharing in the platform-demo-mc branch (and hopefully mainline soon).  It's working well, with none of the corruption and stability issues we saw previously.

Comment 5

[Kelsey Gilbert [:jgilbert]]

Attachment: Create a dummy texture to detach from the EGLImage

Comment 6

[Andreas Gal :gal]

Attachment: patch

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 643938 [details] [diff] [review]
patch

r+ on refactoring and incorporation of bug 774530.  I have no idea what this is doing otherwise.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

* attachment 643598 [details] [diff] [review]

Comment 9

[Andreas Gal :gal]

http://hg.mozilla.org/integration/mozilla-inbound/rev/872fb700953b

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/872fb700953b

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

Is this known to have actually worked? Here the

    mGLContext->fBindTexture(LOCAL_GL_TEXTURE_2D, texture);

call in UnbindExternalBuffer fails with GL_INVALID_OPERATION (on Otoro) because it is illegal to bind a texture to a different texture target than it had been previously bound to (EXTERNAL != 2D).

As this is failing for me I am still wondering how to properly implement this, which I need in bug 833128.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

(In the current m-c state of GLContextProviderEGL.cpp BindExternalBuffer binds to EXTERNAL but UnbindExternalBuffer binds to 2D)

Comment 13

[Kelsey Gilbert [:jgilbert]]

(In reply to Benoit Jacob [:bjacob] from comment #12)
> (In the current m-c state of GLContextProviderEGL.cpp BindExternalBuffer
> binds to EXTERNAL but UnbindExternalBuffer binds to 2D)

Indeed, by spec this should be an INVALID_OPERATION. It's not possible to dissociate an external GL texture from its EGLImage short of deleting the texture.

Comment 14

[Sotaro Ikeda [:sotaro]]

(In reply to Benoit Jacob [:bjacob] from comment #11)
> Is this known to have actually worked? Here the

I did not checked if the patch worked. But I just checked in recent FirefoxOS on unagi. The function is still called.