We are currently extending our simulation and visualization software to support efficient streaming over network and looked into GRID. The main application we consider will be a server running with a Quadro M6000 and streaming a video of the visualization to (mobile) clients.
For this, we are using the GRID SDK 2.3, which appears to be the latest version publicly available, although there ought to be a version 5.0 somewhere …
We have a 64 bit OpenGL 4.5 application and use NvIFR to capture and encode the contents of our main render target, which works quite well, BUT: Only after the render target’s texture type has been switched from GL_TEXTURE_2D to GL_TEXTURE_RECTANGLE. Following NvIFROpenGL.h of the GRID SDK, the call NvIFROGLTransferFramebufferToH264Enc() requires the texture type to be GL_TEXTURE_RECTANGLE. If this is not the case, an OpenGL invalid operation will be thrown due to a texture target mismatch inside this call.
- Why is that?
- Is there any way around it?
I can see that GL_TEXTURE_RECTANGLE provides some backward compatibility, given that GL_TEXTURE_2D does not have to support non-power-of-two dimensions, but in practice, we overcame this limitation about a decade ago. Switching our main render target’s type to GL_TEXTURE_RECTANGLE would require a lot of special handling in shaders for sampling due to the unnormalized texture coordinates and we would need to maintain different filtering shaders etc. for sampler2D and samplerRect. Is it really so crucial that only the quite obsolete rectangle textures are supported, but the common 2d textures are not?
Right now, we blit the contents of our framebuffer into an additional rectangle texture that we then encode and read back, which costs us 0.25 to 0.5 ms for the additional blit in 720p per frame, which is not dramatic, but still inconvenient. Could the implementation of NvIFROGLTransferFramebufferToH264Enc() be extended to also work with GL_TEXTURE_2D textures?