W3: Possible texture modification while in use

1

Greetings,

a glTexSubImage2D causes the above mentioned warning in a pvrtrace. Is this principally possible if my application only issues gl commands from a single thread?

Regards

2

Hi desperado,

Guessing a bit here, but I believe that what you are seeing is a performance warning, not a correctness one.

I am not sure of the context, but under some circumstances it can be of significant memory cost to be modifying a texture between uses in the same frame.

To understand it better, your could roughly think that if you draw, modify the texture and draw again, then swapbuffers, you might need two copies, and if you do it more, even more. Note that this is usually not affected by the amount that you update in the texture (i.e. just a few pixels may force ghosting). This is irrespective of singlethreading or multithreading.

Note, that this is not a performance killer or anything like that, but PVRTrace helpfully warns you so that you can be aware that changing a texture mid-frame has a non-trivial effect. The recommendation here would be:

  1. Only do it if you need it, obviously. Someone might be tempted to think that instead of using two textures it would be better to use one and modify it, which would not be the case.
  2. Isolate the effect. If you need to be using a dynamically created or updated texture it is fine, but make sure that (for example) it is not part of a large, not-modified texture atlas because you may be forcing a much bigger copy than you need.
  3. You can also experiment with using multiple textures instead of modifying the same, but obviously this would only work if you have a small number of copies, and it would mostly help out for you to understand your memory needs rather than change much.

Regards,
Gerry

3

Hello. Thanks for your answer! So what you are saying is that if I use a texture in a drawcall, then modify it, then draw with the modified texture it will produce this warning? And if it produces the warning, does that mean that the PVR OpenGL implementation will produce a hidden copy of the texture, is that what you are saying? And if yes, will this copy affect cpu side? Will it be done in the drawcall?

4

Yes, if I understand your questions correctly, it looks correct.
i.e. PVRTrace tries to analyse the calls and detect likely ghosting in various cases.
The copy may or may not be important in your case of course, but there will be some use of system resources for the copy (memory/bandwidth/some CPU).
I would not personally describe it as “done in the drawcall”, because PowerVR being a deferred architecture, it processes the frames as a whole in general. It is very difficult to provide you with an exact point in time when this copy will happen.

Regards,
Gerry