I’ve been trying to tune up my bad game performance, so I tried out PStats.
It works really great, but I have a question about it.
I saw that nearly 100% of my time goes into the Draw, and about 90% of the Draw is spent on something called “Copy texture”.
What exactly is “Copy texture”, what does it do, and are there perhaps any suggestions on limiting its draw time (about 50 ms, which is quite much compared to my total rendering time).
Secondly, my water buffer is consuming a lot. Any ideas on bringing that down?
It could be a good idea to have a reference of all pstats things somewhere.
That’s short for “copy from the framebuffer into a texture.” It’s used when you create an offscreen buffer, and the offscreen buffer creation code can’t create a real offscreen buffer, so it creates a ParasiteBuffer instead.
However, these timing figures can be very misleading. When Panda3D issues an OpenGL command like glDrawElements or the like, OpenGL puts the command in a queue and then returns immediately. OpenGL doesn’t even start processing the command until significantly later. This makes it very hard to measure how much time the command took.
Worse yet, let’s say you keep on issuing OpenGL commands. Eventually, OpenGL’s queue of commands will fill up, and OpenGL will have to pause. So what will happen is you’ll issue a command, and it will appear to take a very long time, even though it was a trivial command. That’s because OpenGL wasn’t even executing the command - it was busy finishing up previously-issued commands.
Then, there are certain commands like glCopyTexSubImage2D which, depending on how well the driver is implemented, may force OpenGL to actually drain the whole queue. In that case, the glCopyTexSubImage2D may appear to take absolutely forever. I suspect that may be what’s happening here.
So, I think the reality is that your scene rendering is taking a long time, but it could be for any of the usual reasons that scene rendering takes a long time – ie, too many pixels, too many shader instructions, too many batches, you name it. We should check pixels and batches first, because one of these is usually the problem, and because both are easy to check. For pixels, just resize the window real small and see if that makes a huge difference. For batches, just get a geom count for the whole scene - if it exceeds about 300, you have a potential problem.
Thanks for your quick response, and the detailed explanation.
The geom count was around 150 and the vertex count was around 2.6k, so those can’t be the problem. But indeed, resizing the window to something small almost entirely removes the “Copy texture” part.
What could be causing that / how can I solve that? Is it related to some pixel shader I have somewhere or so? Is there a way to narrow it down more closely? Or does my graphics card just suck? (GF5200FX)
Also, dr_0 of a window/buffer, is that the actual thing that renders the whole bunch? Those take also quite some time (the buffers even more than the window!)
Certainly. My terrain texturing system, soft shadows system, and reflections have all kind of large shaders.
Thanks. I’ll go buy a different one one of these days with 5 fps it is kind of hard to play it.
So, I guess that’s also the reason of my water buffer that’s even slower than my normal camera renderer? My water pixel shader is also not so very small.
for terrain you might want to look into my terrain blender which uses no shaders but it might hit you on depth complexity and z sorting issues because i layer transparent surfaces with holes.
Another good terrain solution to look into is spring TA. Ill come up with a sample which uses spring like solution which basically takes a large map breaks it into tiles then figures out which tiles are duplicated.
treeform, my terrain shader is nothing compared to my water shader or soft shadow shaders. I can pass as many textures to my pixel shader as I want, so I’m good . I already have enough offscreen buffers.
with 5 fps it is kind of hard to play it.