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.
Processing time at vertex shader
Author
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.
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.
Author
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?
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.
Author
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
