Uploading texture in a loop and driver getting stuck

[hateom]

Hi guys,

I am testing one approach on various machines and on some of them it is causing weird behaviour - the app is getting stuck, the image blinks and sometimes hangs the GPU.

It’s a very simple app that consists of 2 threads. Each with a separate OpenGL context (shared).
In the main thread I simply render one textured quad on screen.
In the 2nd thread I upload textures in a loop (it’s actually a pool of N textures that I update in a ring buffer fashion).
Simply:

while(...) {
   glTexSubImage2D(...);
}

What I am trying to test is the CPU-GPU memory throughput and see if this kind of way of streaming images to the GPU makes sense.
On some machines this works well. But why this might be an issue on some other GPUs?
Looks like something is overflowing or a GPU queue is getting full and can’t process the upload requests. But shouldn’t glTexSubimage2D block until the texture is ready on the GPU?

Thanks,
Tom

[Dark_Photon]

@hateom

I am testing one approach on various machines and on some of them it is causing weird behaviour - the app is getting stuck, the image blinks and sometimes hangs the GPU.

…2 threads. Each with a separate OpenGL context (shared).
In the main thread I simply render…
In the 2nd thread I upload textures…

Which GPU and driver version are you seeing the app stuck / GPU hangs problem on?

Do you have a GL debug message callback plugged in? The driver may be trying to tell you what’s wrong:

• OpenGL Error # Catching errors (the easy way)

Are you honoring this?:

@OpenGL 4.6 Spec

Rule 3 Changes to the contents of shared objects are not automatically propagated
between contexts. If the contents of a shared object T are changed in a
context other than the current context, and T is already directly or indirectly attached
to the current context, any operations on the current context involving T via
those attachments are not guaranteed to use its new contents.

Rule 4 If the contents of an object T are changed in a context other than the current
context, T must be attached or re-attached to at least one binding point in the
current context, or at least one attachment point of a currently bound container
object C, in order to guarantee that the new contents of T are visible in the current
context. …

---

shouldn’t glTexSubimage2D block until the texture is ready on the GPU?

No.

[hateom]

@Dark_Photon

Which GPU and driver version are you seeing the app stuck / GPU hangs problem on?

Actually the the worst behaviour I have seen was on M1 Mac, but it’s not that important, because I will have a Metal port, so I guess it’s just a problem with the OpenGL emulator on M1.
But I had also some problems on some portable AMD GPU in a small form factor NUC PC - I will check the exact model and driver version.

@Dark_Photon

Do you have a GL debug message callback plugged in? The driver may be trying to tell you what’s wrong:

…

Don’t use the latest OpenGL version but I will try to see if it helps.

@Dark_Photon

Are you honoring this?:

…

The thing is that I don’t even use the textures uploaded in the other thread. I just upload them and nothing more. The textured quad in the main thread is using a single texture created in the same thread.