Horde3D

Hello.

We have strange upload times of dynamic textures (videos) using h3dmap/unmapstream functionality on Nvidia cards. No matter the size of the uploaded texture (from 400*400 up to 1920*1080), it takes about 12-17 ms to upload. Tested on 3 machines with Nvidia cards: Core 2 Quad 2.66, GeForce 250, XP sp3; Xeon Quad, GeForce 275, XP sp3; Notebook Core 2 Duo 2.53, GeForce 240, Win 7. Used different versions of drivers, from rather old to latest.

Our architecture is the following:
In main horde loop:


Time is checked before h3dmapResStream and after unmapResStream, as well as in the check procedure. The most interesting part is that most of the time the difference between the time after texture uploading and the time of check for uploading of the next video frame is about 1-7 ms. That means that horde somehow manages to render the whole frame in about 3-4ms (h3dRender, Finalize, DumpMessages, swap buffers in glfw and go on to the next loop).

Any ideas how to fix the uploading times? Our scene is not very complex, and we use 8x MSAA (forward lighting) and v-sync. This gives us steady 60fps when not playing videos.
On old P4 3Ghz, ATI x1950 Pro, XP sp3 uploading times are 3-5ms.

Well, for such long times actually I would suspect either some performance problems because the driver has to regenerate mipmaps, or due to color format conversion. The latter is no problem with h3d as all textures everywhere are bgra8 though, aren't they? And no idea why it works on the amd gpu.

3-4 ms for rendering are not that uncommon given you have quite fast graphics cards (that would be 200/300 fps if it wasn't for the texture uploading) at least on smaller scenes.

When dynamic texture is created for the first time, it is set to NoTexMipmaps, and yes, it is in bgra8 format.

But the rendering should be limited to 60fps because of the vsync, so rendering time should take around 16-17 ms. Without vsync scene renders up to 88fps with 8xMSAA (about 11.3 ms for one frame).

I could imagine that the CPU is stalling and waiting for the GPU to finish, before uploading the texture data. It is not possible to modify texture data if it is still in use (referenced in the GPU command buffer) because else the previous frame or draw calls would already use the modified texture data and look "wrong". Sometimes the driver works around this by creating a temporary texture but this is not guaranteed.

You could try to create a second dynamic texture and swap usage between the two. PBOs could help but can still have the stall problems. It might also help to call glTexImage2D with NULL data inside Horde's updateTextureData function but this is just speculation (very driver dependent but for VBOs glBufferData with NULL data is often used to give a hint to the driver that the data is not needed any more).

Sorry for the stupid question, but if I, for example, try to use PBO for updating video textures, would it be possible to implement PBOs without modifying Horde or writing an extension (so, make all of the texture update in the app)? If so, how to get an opengl texture, that is used in horde, in order to update it via PBO?

I tried to implement texture swapping, but for some reason textures are not displayed. Maybe because I make h3dmap/unmap in a separate thread? Texture swapping is made in the main thread.

Edit 2:
I moved map/unmap to main thread, and everything works, but then texture swapping is useless, because upload times are the same. If I use map/unmap in the different thread, then I don't see video, but it is decoded normally, sound goes, and fps is around 58 on 1920*1080 video.
Maybe there is a better way to implement it?

As texture upload is very fundamental functionality, PBOs would have to be implemented directly in the core. One option is to create a PBO for each texture resource that has H3DResFlags::TexDynamic set. A more advanced solution would be to create a shared pool of PBOs but that is more complicated, especially if it should work for the general case (with an arbitrary number of resources etc.).

One thing you could try to find out if stalling is the problem is uploading the texture but not using it for rendering.

I made that uploaded textures are not rendered (new material is not applied to the object), but uploading times are the same, so the problem is really with uploading. Unfortunately, texture swapping in a separate thread doesn't work (video doesn't show) and if I implement it in the main thread, than everything is like it is without texture swap.

What is very interesting, is that if I use a debug version of horde, than my scene renders in about 19 fps, but uploading times are about 5 ms...