Asynchronous texture upload？

[guodong chen]

Read some of the discussion on this forum.

As it turns out that angle is not thread-safe, I originally intended to create a shared context and upload textures in an additional thread. Is this operation not possible with angle?

[Geoff Lang]

It is currently backend dependent if ANGLE is thread safe. Many of our backends do context virtualization for improved performance and bug workarounds which disallows multi-threading.

Only Vulkan is 100% safe to multithread right now.

On Sun, Jul 9, 2023 at 10:41 PM guodong chen <chenguodo...@gmail.com> wrote:

Read some of the discussion on this forum.

As it turns out that angle is not thread-safe, I originally intended to create a shared context and upload textures in an additional thread. Is this operation not possible with angle?

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/bd16be29-5038-4fc7-9534-4336a223d43dn%40googlegroups.com.

[Ken Russell]

Which ANGLE backends/platforms are most important for your application's multithreading support?

To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/CA%2BPGBXtV_%3DnHomiPJhcxM-8iXMhvK%2B2RzdcLaE_u59xm6T-qhA%40mail.gmail.com.

[guodong chen]

metal and vulkan back ends are what I need right now. I wonder if the metal back end can upload textures using multiple threads.

Looking at the previous discussion, it seems like vulkan should be OK

[Shahbaz Youssefi]

Yeap, Vulkan should be ok. As Geoff mentioned above, the other backends are not ok.

By the way, please remember to use sync objects to synchronize between the texture uploads and the main thread. We noticed an app in the past that missed this.

[Ken Russell]

Please feel free to watch/star/comment on https://bugs.chromium.org/p/angleproject/issues/detail?id=7575 .

To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/2c8c0272-348e-4183-820e-4c27afeba4cen%40googlegroups.com.

[guodong chen]

 thanks

glTextureImage2D is really too slow at the moment, it seems that there is no good solution other than vulkan

[guodong chen]

@Kenneth Russell 

I looked at the google bugs link you gave me carefully and I'm a little confused now, if metal is it safe for me to call glflush after uploading it in another thread?

[guodong chen]

In my understanding, I am in an io thread. I simply upload the texture without doing drawcall, and I call glFlush() as soon as the upload is complete.

The id of the texture is then passed through a message queue to the rendering thread, which maintains the texture's lifecycle.

Is it safe to do this?

[Shahbaz Youssefi]

What you described is **not** safe, for multiple reasons. Least of which is that glFlush() is allowed to do nothing at all.

What you need instead of glFlush is glFenceSync(), followed by a glWaitSync() on the rendering thread.

[guodong chen]

Of course, I can use glFenceSync instead of glFlush.

But if that's the case, and I'm using metal as the back end, isn't that a safe way to use multithreading

[guodong chen]

https://bugs.chromium.org/p/angleproject/issues/detail?id=6844&q=metal%20thread&can=2

"

Metal back-end's current design of serialized command buffers has faults. Multi-threading won't work properly. For example in this scenario:
- thread 1 (context 1):
- command buffer 1 (currently each GL context owns one command buffer):
- do some GL commands.
- thread 2 (context 2):
- command buffer 2:
- do some GL commands.
- some synchronizations which require the thread to wait for command buffer 1 to finish. However it is unaware that command buffer 1 is not yet committed (that command buffer is owned by thread 1) -> stuck waiting forever. That can happen if thread 1 doesn't do any back-buffer swapping or only does some resources loading (no draw calls or FBO read-back). In that case, the GL commands on thread 1 are only batched into the command buffer 1 and it is never committed to GPU.

The work-around for this case is calling `glFinish` on thread 1 to commit the command buffer 1 to GPU.
However, I think the better way is re-factoring and re-designing the command buffers management in the Metal back-end (perhaps Apple engineers could help in this case).

"

In this post, I see a recommendation to use glflush to guarantee multithreading in the case of the metal backend. My understanding is that since the metal queue itself is thread-safe, this operation should also be thread-safe

[Shahbaz Youssefi]

The metal backend is not thread-safe yet. I strongly discourage using it in a threaded environment anyway by hacking things. If glFlush "makes it work", it's by coincidence and there is no guarantee that would stay the case if you update ANGLE.