Make RID_Owner<Texture> threadsafe in TextureStorage for GLES3

[0x0ACB]

This seems to fix #88195. In the Vulkan driver the RID_Owner<Texture> is already thread safe and indeed, textures might be created from threads. Also the RID_Owner<CanvasTexture> for gles3 is thread safe as well. I think this was just forgotten to add for the Texture one in a refactor.

[RandomShaper]

I'm not sure you can create textures from threads in the OpenGL ES backend. Also, there's some ongoing work (#77004) that may need to be aware of this change to potentially revert it if it turns out in the end to be possible to funnel all the renderer calls via a unique thread in the case of GL.

[0x0ACB]

It is (currently) possible to create textures from threads, atleast that is what I found while debugging my issue. Or atleast you can create the RID from a thread.

[RandomShaper]

Oh, right. Allocating a RID would need sync indeed.

PS: I'm wondering if RID_Owner could be enhanced with a locking pattern that makes that more optimal, given most of the time it will be read-written from the renderer thread. I'll add this to my TODO list.

[AThousandShips]

Like:

• Make RID_Owner lock-free for fetching. #86333

Perhaps?

[RandomShaper]

I think this makes sense, but I don't have time to repro and debug, and I'm not very familiar with the GL implementation. I'm approving, but TIWAGOS.

[RandomShaper]

Like:

• Make RID_Owner lock-free for fetching. #86333

Perhaps?

Not quite... The requirements here would be: 1) any thread can allocate uninitialized RIDs, 2) only the "owner" thread can do everything else. So, both usages involve writing, but with different constraints.

[akien-mga]

Thanks!

[akien-mga]

Cherry-picked for 4.2.2.