fImageTargetTexture2DOES(LOCAL_GL_TEXTURE_2D, 0) failed

RESOLVED FIXED in mozilla17

Status

()

Core
Graphics: Layers
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: sotaro, Assigned: jgilbert)

Tracking

Trunk
mozilla17
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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

5 years ago
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.
(Reporter)

Updated

5 years ago
OS: Windows 7 → Gonk
Hardware: x86_64 → ARM
(Reporter)

Updated

5 years ago
Depends on: 745137
(Assignee)

Comment 2

5 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 3

5 years ago
Rather, glEGLImageTargetTexture2D(GL_TEXTURE_2D, 0) would appear to be required to generate an INVALID_OPERATION, since 0 is not a valid EGLImage.
(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.
(Assignee)

Comment 5

5 years ago
Created attachment 643598 [details] [diff] [review]
Create a dummy texture to detach from the EGLImage
Assignee: nobody → jgilbert
Status: NEW → ASSIGNED
Attachment #643598 - Flags: review?(cbrocious)
Attachment #643598 - Flags: review?(cbrocious) → review+

Comment 6

5 years ago
Created attachment 643938 [details] [diff] [review]
patch
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.
Attachment #643938 - Flags: review+
* attachment 643598 [details] [diff] [review]

Comment 9

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

Updated

5 years ago
Attachment #643598 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/872fb700953b
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
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.
(In the current m-c state of GLContextProviderEGL.cpp BindExternalBuffer binds to EXTERNAL but UnbindExternalBuffer binds to 2D)
(Assignee)

Comment 13

4 years ago
(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.
(Reporter)

Comment 14

4 years ago
(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.
You need to log in before you can comment on or make changes to this bug.