This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How efficient is fragment discarding for large amounts of triangle overlap?

I have a question regarding the efficiency of discarding fragments for scenes that are excellently sorted, but have many overlapping triangles.

If you have a large number of large triangles (eg. 1000) that are perfectly front-to-back sorted but overlap (or occlude) one another, roughly how much hardware performance penalty will this incur? I understand that the sorting will result in zero overdraw and thus fewer fragment's being processed by the fragment shader, but in this case will Mali be able to discard fragments that are not seen at a very low performance cost?

If there is a significant performance cost, what is a rule-of-thumb maximum amount of triangle overlap before performance starts to degrade?

Sean

Parents
  • Hi Sean,

    Rendering front-to-back rendering is generally really efficient - although I doubt we could hide the cost of loading 999 occluded triangles - that's quite a lot of bandwidth in terms of triangle loading, just to work out that the triangle isn't visible. How much we can actually hide depends on the shader complexity of the visible front layer - if that only takes a single cycle in throughput terms then you will be able to hide a lot less overdraw load overhead than a  situation with the front-facing triangle which takes a thousand cycles a pixel.

    Most 3D content is pretty good at implementing culling in the application, so for well written applications the overdraw rates for opaque geometry is generally between 20% and 100% of the visible fragments, which we can generally happily hide with no penalty, but making that as low as possible via application-side techniques is always better.

    Pete

Reply
  • Hi Sean,

    Rendering front-to-back rendering is generally really efficient - although I doubt we could hide the cost of loading 999 occluded triangles - that's quite a lot of bandwidth in terms of triangle loading, just to work out that the triangle isn't visible. How much we can actually hide depends on the shader complexity of the visible front layer - if that only takes a single cycle in throughput terms then you will be able to hide a lot less overdraw load overhead than a  situation with the front-facing triangle which takes a thousand cycles a pixel.

    Most 3D content is pretty good at implementing culling in the application, so for well written applications the overdraw rates for opaque geometry is generally between 20% and 100% of the visible fragments, which we can generally happily hide with no penalty, but making that as low as possible via application-side techniques is always better.

    Pete

Children