Add support for glEGLImageTargetTexture2DOES

[elima]

Description

I want to use RenderDoc to debug Wolvic browser and the web apps running on it. This is a VR-enabled browser and in my case I'm running on a Huawei Mate 40E phone with Huawei VR Glass Kit (6dof).

I installed RenderDoc v1.21 and followed Android setup guide.

When I launch Wolvic from RenderDoc, I see an overlay image that reads:

Capturing OpenGLES.
Captures disabled.
Unsupported function used:
 - glEGLImageTargetTexture2DOES

and no frames are captured.

The function in question was introduced in OES_EGL_image_external extension, a fairly old one. I'm not sure whether this API is popular or not, or if there are specific technical reasons why it hasn't been supported in RenderDoc.

RenderDoc is an invaluable tool for us to debug gfx issues and improving performance in general. Please consider adding support for this API.

Environment

• RenderDoc version: 1.21 (built from 98a93408)
• Operating System: HarmonyOS 2.0.0
• Graphics API: OpenGL-ES 3.0

[H0nok4]

Same issues here

[Squareys]

Hey @baldurk, or any contributor who has capacity to work on this: is there a way to fund the development around this issue? Feel free to reach out.

[baldurk]

Speaking only for myself, I already work full time on RenderDoc so I don't take on any additional funded work.

[Squareys]

@baldurk I did not expect you to have the capacity yourself, great to hear you are well funded!

Do you have any suggestion for contributors who might want to pick this up as contract work? If you know one or two who have the capacity, feel free to tag them here!

[mlknz]

It blocks me from capturing project on Unreal Engine. Also I noticed, that Mali Graphics Analyzer faces same issue.

[Squareys]

@Zorro666, you seem very active lately and might know the repo well. If you'd be interested in getting sponsored to handle this issue, feel free to reach out.

[Squareys]

Note: We found someone for this, thank you! (baldurk, apologies for the frequent comments.)

Original message

Sorry for pinging things thread once again, this is fairly important to us. We are still looking for someone willing do paid work to solve this issue! Tagging potentially interested previous contributors @tuxerr @lfedorov @apazylbe. In case someone already tried to [reach out](mailto:jonathan.hale@wonderlandengine.com?subject=RenderDoc%20Issue%202726), feel free to ping here, just in case it went to the spam folder. Otherwise you can try reaching out [on Linked](https://www.linkedin.com/in/squareys/) or [twitter](https://twitter.com/squareys).

[baldurk]

OK that's enough @Squareys, do not comment on this issue again. Your last comment was only 5 days ago, I'm not going to tolerate spam from you.

You've made your feature request and you've made it clear that you would be willing to fund development if anyone is interested. If someone is they will get in touch, but this github repository is not an appropriate place to continually advertise. On top of that directly pinging people with no direct affiliation with the project is rude and inconsiderate.

[zleisure]

@baldurk Same issues here about glEGLImageTargetTexture2DOES no support

[H0nok4]

Use old version like v1.13 solved my problem , you can try it too

[zleisure]

It's working, thank you! @H0nok4

[caogtaa]

Same issue here. Error disappears in RenderDoc v1.13, but application crash if doing capture.

[baldurk]

Please do not make empty "+1" comments. The feature request has been made and understood, there is no need or value in making extra comments that simply repeat the request. You can react with a :+1: to the original post if you want to indicate your interest and watch this issue for updates.

[baldurk]

Replicating my comment from PR #2845 which is relevant here:

From email discussion this extension is extremely badly designed to an extent that I had not fully appreciated, in particular that external textures are considered an entirely separate fundamental type of texture of the degree that they are accessed via a different type in shaders. As opposed to every other graphics API and several other supported GL extensions where they are normal textures, but created/initialised in a different way to perform the import operation.

This forces an implementation as this PR begins to do that must add support for this fake texture type throughout the GL backend and possibly further into the API abstraction (either with unknown real type or N different new fake types of texture to account for the actual types), as well as using external platform-specific APIs (which are likely unreliable on Android) for creating the textures on replay. The only other alternative that would be to somehow transform the captured commands and patch the use of external textures in shaders into normal textures, which can likely never be done robustly.

The conclusion I've come to is that this means a significant amount of implementation cost and maintenance burden which I do not feel is justified by the value of supporting this extension. While this is not a final written-in-stone decision that can never be reconsidered, I do not see a path forward where there would be an implementation of this extension that I would consider acceptable given the current situation. Since I also do not see that situation significantly changing, for now I consider this feature not something I ever plan to implement or support. Of course since RenderDoc is open source anyone is welcome to make whatever changes they wish locally, but this is not something I will accept upstream.

This is not a unique circumstance, there are a number of GL extensions which are not supported due to the cost of implementation and maintenance not being outweighed by the value of supporting them, and indeed there are a handful of things that are legal in core GL which are simply not supported and never will be due to them being extremely bad design decisions in GL and being far too costly or problematic to be worth supporting.

If your program depends on this extension in a minor way, such as using it for optional externally read textures for display from another system, the only suggestion I have is to add a path where you can detect that the extension is not supported and read black or some other dummy value. While not technically 100% legal you could leave the samplers in the shaders and they will read black if they are unbound and this will likely work with RenderDoc.

If your program depends on this extension significantly such that the lack of those textures will break significant parts of rendering I'm afraid I don't have any suggestion for an alternative beyond having a path that doesn't require the extension.

If someone is able to come up with a solution which is low implementation & maintenance cost and does meaningfully support this extension then please file a PR or contact me with the concept. Since I don't see a way that this is possible due to the bad design of the underlying extension, I am closing this feature request.

[1558287830]

Hey @baldurk, or any contributor who has capacity to work on this: is there a way to fund the development around this issue? Feel free to reach out.

for android platform, support this feature I think is very difficult without the support by device company such like oculus/pico/huawei ， since In android, the EGLImageKHR actually is a GraphicBuffer , renderdoc need to lock Graphicbuffer , get GraphicBuffer content and size when capturing. but,

1. GraphicBuffer interface is not open for app, even you can get the interface by hook, there still so many selinux issue
2. the implement about GraphicBuffer is different between SOC Vendor, some GraphicBuffer format is private such like yuv420_ubwc, so the GraphicBuffer size could not calc by height/weight/stride, there still a meta data inside it, the calc size interface is in hal-gralloc, so you need the access to call this interface.

some device company like oculus、pico， they fork a renderdoc branch to development, I think you can ask your needs in there official development webside

thanks

[MaxVerevkin]

Replicating my comment from PR #2845 which is relevant here:

From email discussion this extension is extremely badly designed to an extent that I had not fully appreciated, in particular that external textures are considered an entirely separate fundamental type of texture of the degree that they are accessed via a different type in shaders. As opposed to every other graphics API and several other supported GL extensions where they are normal textures, but created/initialised in a different way to perform the import operation. ... The conclusion I've come to is that this means a significant amount of implementation cost and maintenance burden which I do not feel is justified by the value of supporting this extension.

Does this apply to glEGLImageTargetRenderbufferStorageOES too?

[baldurk]

Please do not comment on old issues that have been closed.

If you are encountering a bug or are requesting a feature please open a new issue. You can reference this issue if you wish, but opening a new issue prevents any confusion of accidentally linking two unrelated issues and means that each issue can be handled in a clean process.