Texturing breaks when using OpenVR

[mkovaxx]

Submitting frames to the OpenVR compositor invalidates a glium::Texture2d (or its contents).

The glium::Texture2d mentioned above is used to render a textured quad in the main window.
Two other textures are used for submitting frames to OpenVR.
Each frame is submitted by passing the output of GlObject::get_id called on a glium::Texture2d.
Nothing is rendered to any of the textures.

Setup:

• Rust toolchain version: 1.46.0
• openvr version: 0.6.0
• glium version: 0.27.0
• OpenGL vendor: NVIDIA Corporation
• OpenGL renderer: GeForce GTX 1070 Ti/PCIe/SSE2
• OpenGL version: 3.1.0 NVIDIA 432.00
• OS: Windows 10
• Headset: Oculus Rift

The same issue is reproduced on an Alienware laptop with a 1060.
Also tried with an Oculus Quest (via Oculus Link), same result.

Here's code that demonstrates the problem:
https://github.com/mkovacs/openvr-texture-problem

Also note that I've posted the same issue on the rust-openvr repo almost a year ago:
rust-openvr/rust-openvr#43

[mkovaxx]

Found this post on Reddit where another person describes the same issue:
https://www.reddit.com/r/rust/comments/biuzaw/bizarre_issue_with_glium/
CC @NickDriscoll

[mkovaxx]

The hypothesis put forward by a commenter on the Reddit thread above seems to be correct.
Glium doesn't seem to handle well that an external process modifies the GL context state.

I collected info about two frames via RenderDoc.
Looking at the info about the fragment shader stage reveals the issue.

Frame 0, taken before submitting anything to OpenVR:

Frame 1, taken after submitting stuff to OpenVR:

There's simply no texture bound to the checker_texture uniform in the shader.
That's likely because the OpenVR compositor unbinds it, which is a change that Glium doesn't expect to happen.

[mkovaxx]

This seems to be related to #1696, i.e. could be fixed by the ability to tell Glium that the cached GL state is no longer valid.

[mkovaxx]

I think a solution to #1505 would also resolve this issue.