I have a few questions about GPU Perfstudio.
1) Why I cannot know values of compute-shader-realated counters when I use OpenGL instead of DirectX? I do not know why the current GPU Perfstudio version only supports CS counters with DirectX.
2) What does TexUnitBusy exactly mean? According to the GPU Perf API document, TexUnitBusy means a percentage of GPUTime the texture unit is active, and TexUnitBusy is measured with all extra fetches and any cache or memory effects taken into account. I understand that the texture unit (maybe the L2 texture cache?) deals with all memory requests including fetches of textures, vertices, frame buffers, etc. In fact, even though textures were not used in a scene, the TexUnitBusy value was higher than zero (maybe) due to vertex fetches. Do I understand correctly?
Additionally, what does (VS/DS/GS/PS)TexBusy mean? I found that the sum of (VS/DS/GS/PS)TexBusy was less than the value of TexUnitBusy, and the ratio of (VS/DS/GS/PS)TexBusy to (VS/DS/GS/PS)ALUBusy was similar when screen resolutions (and TexMissRate) were changed. It means that (VS/DS/GS/PS)TexBusy may be affected by not total texture mapping costs including memory accesses but only texture instruction processing. Do I understand correctly? If so, can I interpret that TexUnitBusy is related to both texture processing of each shader and memory accesses? If a texture cache hit rate is 100%, will the value of TexUnitBusy be equal to the sum of (VS/DS/GS/PS)TexBusy? Otherwise, will TexUnitBusy be zero due to no off-chip memory accesses in this case?
To sum up, I am curious the relationship between TexUnitBusy and (VS/DS/GS./PS)TexBusy. Currently, I understand as follows:
* TexUnitBusy = GPU time for texture mapping/filtering and all off-chip memory accesses. The total percentage of (VS/DS/GS/PS)Texbusy should be included in the percentage of TexUnitBusy.
* (VS/DS/GS/PS)TexBusy = GPU time for texture instruction processing in each shader. Memory fetch costs are not included.
Is it correct?
3) When can I download the updated version with the fix of the incorrect average calculation bug in the frame profiler which I asked one month ago?