Processing time at vertex shader

The vertex shader is a program. The time it needs depends entirely on that program, so it is not possible to give a general answer. There is also the complication that the time that the main application spends waiting on the vertex shader may not be the same time as the vertex shader needs, as some operations are ongoing in parallel. Not only that, but the vertex shader itself can execute in parallel, doing more than one vertex at a time. This depends on the hardware.

Another complication is that a "real" application usually have many vertex shaders, used for different things. And maybe they are using deferred shading, in which case you call two different vertex shaders after each other (where the second time is quick).

You mention geometry shading, are you sure you are going to use that?

There are ways to actually measure the time that the GPU needs, and that is by using queries.

Please say what you need the information for, and maybe there may be ways to help you optimize.

Thank for your response, Larspensjo, here is my case:

Giving a vertex shader program, assuming that I have 1000 vertices now I want to know how long does it take the vertex shader to process 1000 vertices. Is there any way to put the timer in the middle to measure the processing time?

Thanks,
-D

In my case, at first I just take the vertex shader into account, I mentioned geometry shader just because it is part of rendering pipeline. There is nothing to do with it at the moment. I know there are ways to measure the processing time of GPU, or in other words, of the entire rendering pipeline. Now I just want to measure the processing time consumed by part of it.

For a short summary on how to measure performance, see Measuring graphics performance.

If you want to measure only the vertex shader, there is a trick to disable the fragment shader: Calling glCullFace(GL_FRONT_AND_BACK) will cull all facets (but not primitives like points and lines). This would of course be something you only do for testing.

Thanks. I will check it out

You will never be able to track that. But also, there is no vertex shader anymore:
Read stream processor.
http://www.alteredgamer.com/pc-gaming-tech/984-painting-the-scene-graphics-cards-explained/

Well, that is slightly misleading; there are still vertex shaders, there just hasn't been any dedicated hardware for it for some time now.

If you really want to get performance data then you'll need to break out specific tools to do timing be it NV, AMD or Intel's graphics debugging/analysis programs or any extensions which let you do profiling of the pipeline.

Simply turning on culling and trying to time that way is going to give you some results I just... wouldn't trust them too much personally...

Thank you guys. My current approach is to disable rasterzation stage (glEnable(GL_RASTERIZER_DISCARD_NV)) by using transform feedback mode. But I think inaccuracy occurs as the time it takes to copy data to transform feedback buffer is significant.

-D

I'm still looking for more accurate ways anw.

Why do you want to measure this "average time in the vertex shader", and what are you going to use that information for?

It may turn out that you can get a value, which may not be relevant as a decision support.

The general recommendation is to push as much computation as possible from the fragment shader to the vertex shader. One way of doing that, if you have many lights, is to use a deferred shader. That way, light computation is only limited to pixels that are actually going to be shown.

At the moment, I just want to investigate GPU in terms of processing time. The outcome could be a comparison of avg. processing time among shaders including vertex shader, fragment shader.

there are still vertex shaders, there just hasn't been any dedicated hardware for it for some time now.[/quote]
Well do any of the tools track each processors state, can you query back the percentage of time each or all processors were doing vertex or pixel shader operations? And still knowing those numbers will not tell you anything about how efficient your shaders are or anything relevant. Because they switch all the time you cant be vertex or pixel bound. The GPU will try to even those out.

Yes, the tools and librarys to track his information do indeed break down by shader type and give you information about the time spent processing those shader types.

Some counters from AMD's GPUPerf lib;

Timing : ShaderBusy, ShaderBusyCS, ShaderBusyDS, ShaderBusyGS, ShaderBusyHS, ShaderBusyPS, ShaderBusyVS
Vertex Shader; VSALUBusy, VSALUEfficiency

(They have many more, covering all shader types, memory information and more. NV and Intel will cover the same.).

And of course you can still be vertex or pixel bound - if most of your shader time in a frame is being spent on vertex shader operations then you are vertex bound. Same thing if you replace 'vertex' with 'pixel', 'geometry', 'hull', 'domain' or 'compute'.

Just because there are no longer dedicated "pipes" doesn't mean you can't be bound by a perticular shader type; being 'bound' by something just means it is taking the most amount of time and optimsing other parts of the process aren't going to make a difference.

Just because the GPU can balance resources as it needs to doesn't magically mean that all shaders will execute in the same amount of time, it just means the GPU can stay as busy as possible while it has work to do.

Hi Phantom,

If I understand you correctly, suppose the time it takes to render 1 frame is 0.5 ms it means that the execution time at vertex shader and pixel shader are also 0.5 ms, right? is it something called unified shader model?

Hi Phantom,

If I understand you correctly, suppose the time it takes to render 1 frame is 0.5 ms it means that the execution time at vertex shader and pixel shader are also 0.5 ms, right? is it something called unified shader model?

It is not possible to give a general answer to that. In a "real application", you generally have several shader programs. Each of them have at least a vertex shader and a fragment shader. And all of these vertex shaders and fragment shaders can maybe be running in parallel, or they may not. It depends on the hardware, on your state changes, on what the CPU is busy with, and other things.

I think the concept of Unified Shader Model is about the hardware design. That is, the shader "execution unit" is not specialized for vertex shading and fragment shading, which allows for more flexible usage. I suppose it can mean that an application that is using much resources from fragment shading can have automatic reallocation to improve processing speed.

I think the concept of Unified Shader Model is about the hardware design. That is, the shader "execution unit" is not specialized for vertex shading and fragment shading, which allows for more flexible usage.
[/quote]

Agree