Jump to content
  • Advertisement
Sign in to follow this  
sienaiwun

OpenGL OpenGl Es analysis

This topic is 731 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement

To stress the vertex shader, I'd render a high polygon mesh (if you can't get access to one, then make something in code by subdividing a tetrahedron or icosahedron to make a sphere perhaps). Then render it multiple times, but use the scissor rectangle so that you only rasterize a tiny amount of the screen.

 

With your fragment shader test, can I just check that each of your screen quads has transparency? If not, then mobile hardware often has hidden-surface-removal which will invalidate your test as only the top quad will actually be rendered.

 

I have no idea how you would measure the cost of rasterization as a distinct measure from fragment shader, or even if trying to do so makes any sense.

Share this post


Link to post
Share on other sites

Thanks @Columbo for your reply.

 

With my fragment shader test, I do it with depth write off and depth test off. I think it is similar way to get a massive amout of overdraw like transparent rendering.

 

With your vertex shader way, can I do it by projecting the vertexes to a given fixed tiny point so that they are not rasterized?

 

I also need to measure the cost of varying parameters between VShader and FShader and whether the bandwidth is the bottleneck as well. Is there some idea? 

Share this post


Link to post
Share on other sites

Turning depth write/tests off is not enough on tiled based hardware typical to mobile devices. I believe both PowerVR and Mali chips (qualcomm too probably) do analysis in hidden surface removal hardware which will eliminate the hidden layers even if there's no depth buffer at all.

 

I would imagine that projecting vertices to a tiny point would work.

 

Measuing cost of varyings will be hard. Apart from anything else, you're limited to 8 on some devices so it's difficult to really stress it in isolation. 

Share this post


Link to post
Share on other sites

For any decent analysis, you would need access to the hardware counters for each device. Rendering quad, null VS/FS just gives a high level view of whats going on, so if thats the end goal, then no need got go any further. Even then those test are highly subjective since even there are other variables in play that may skew your result on one architecture vs the next.

Share this post


Link to post
Share on other sites

For isolating vertex shader performance I would suggest:

  • You need a large data set, in a vertex buffer in GPU memory, which can be submitted in a single draw call.
  • Use points rather than triangles to simplify (and therefore minimize the overhead of) primitive assembly, clipping, culling, etc.
  • Transform each point to outside of the view frustum so that it's discarded by the pipeline as soon as possible after the vertex shader, and no subsequent shader stages run.

That will give you a reasonably accurate number, but I'd suggest that the number you get is actually useless.  It has no bearing whatsoever on the kind of performance you'll get in a real-world program, and the mention of pipeline stages you optimize or skip above should hint why: because a real-world program won't be optimizing or skipping these stages, and will therefore have extra load on both the CPU and GPU that your test doesn't measure.

Share this post


Link to post
Share on other sites

Thanks @Columbo for your reply.

I do my Fshader test with alpha blending on, although it may involve unnecessary blending operation after Fshader.

Share this post


Link to post
Share on other sites

Thanks @cgrant and @mhagain for your kindly reply.

I knew it might make little sense to measure a shader in this naive way and it was difficult to isolate different stages. But since the actual temporal performances are closely guarded secrets of the chip vendors, that is the only way I can come up with. I took up this idea from ''In-Depth Performance Analyses of DirectX 9 Shading Hardware." from ShaderX3.

I knew this kind of measurement is old-fashioned, but is there some better ideas to give a coarse value to the artists that how fine is the geometry and how fine is the geometry and how much is the max chararacters a mobile device can support? There are several 3-rd party measurement tools like  GPU ShaderAnalyze from AMD or ShaderPerf2 from NV. But they are not friendly to mobile Gpus.

Edited by sienaiwun

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!