Forum Discussion

🚨 This forum is archived and read-only. To submit a forum post, please visit our new Developer Forum. 🚨
Anonymous's avatar
Anonymous
9 years ago

Transfer of data to texture degradates Rift FPS - any solution ?

We need to transfer to a texture in Unity a lot of data (4k 60 fps video playback). We had created a super fast video plugin oursef, so Unity itself play at 150 and more FPS ... The scene without the texture image updated run on Rift at 90 FPS without problems. If we start the video data transfer to the texture, Rift FPS fall on 65-70 FPS and frames are dropping. In this situation CPU load is O.K., GPU load is OK. - this is not the bottleneck. We had even tested pure video data transfer from a buffer (so no video decompression - almost 0% CPU load) - we gat 65-70 FPS again. We transfer about 2.5 GB/s data through the PCI-E buss, but PCI-E 3.0 16x limit should be 16 GB/s. It sound like the Rift drivers blocks the PC-E transfer in some way ... It does not give sense - the drivers should not use PCI-E because they already have all data in GPU. Does anybody have some idea what to test, how to make diagnostic e.t.c. ?

2 Replies

Replies have been turned off for this discussion
  • vrdaveb's avatar
    vrdaveb
    Oculus Staff
    That should be avoidable. How are you populating the texture? Is data being transferred to system memory or are there fences or other stalls between your decoder and Unity? One way is to render directly to the resource you get from RenderTexture.GetNativeTexturePtr(). Another option is to write a native plugin and use LibOVR directly, where you can render to a world-locked overlay. That will pass your video data straight to our compositor to be displayed on top of the Unity scene.
  • Anonymous's avatar
    Anonymous
    We already use the RenderTexture.GetNativeTexturePtr() method ... We need to render to the texture because the video is mapped on a Unity object, so we can not probably use the second method you mention (If I catch the idea) . I will ask may colleague to describe the issue more precisely ...