Fullscreen quad invoking fragment shader twice along triangle seam?

[ReaperSMS]

How exactly are you writing to the other image? If it's not through the blend unit, it might be incrementing whenever the fragment program is run, not whenever it actually produced a pixel. If so, that would explain the doubling up, as on most chips fragment programs get run in 2x2 blocks -- thus running the fragment program twice on every pixel along the diagonal.

The clipping shouldn't be generating new triangles as long as your fullscreen tri stays within a reasonable range. IIRC, for +/- 1 NDC space, the vertices you need are (-1, -1) (3, -1) (-1, 3). http://www.gamedev.net/topic/568915-...reen-triangle/ has a bit more detail on it.

[Alfonse Reinheart]

when I try to render a fullscreen quad, the seam between the two triangles appears to have some overlap, which causes the fragment shader to be run twice on those pixels. This is a major problem, because it means that I can not assume the shader will be run once for each pixel, and I can't assume that only one shader instance will be accessing a pixel's data structures at a time.

That should not be possible. All writes from any fragment shaders that execute outside of a triangle's boundaries should be discarded. What is the fragment shader you use to detect this?

[mbentrup]

That should not be possible. All writes from any fragment shaders that execute outside of a triangle's boundaries should be discarded. What is the fragment shader you use to detect this?

If MSAA is enabled, you would get two fragments with each having one half of the samples masked. You could enable per-sample shading plus atomic counters to see if MSAA is active.

[Alfonse Reinheart]

Yes, but that's both normal and to be expected.

[AlexN]

Is the overlapping region a single pixel wide, or is it sometimes a couple pixels wide and blocky? If a single pixel, that sounds like a precision issue. If more than one pixel and blocky, it's likely that you're seeing an artifact from the GPU invoking your fragment shader in 2x2 (or larger) groups of pixels for efficiency. Normally this is not visible because the extra fragments are discarded, but if you make accesses to main memory then there can be side effects.

Either way, the easiest solution may be to change how you render your full screen quad. Try using a single triangle that is larger than your viewport and fully contains it. This is typically more efficient anyway as it avoids the wasted fragments along the seam between two triangles due to the pixel grouping mentioned above.

Edit: I take back the bit about accessing main memory from a helper fragment having side effects. Looks like that is not supposed to happen, though there could be a bug you a hitting if so. From http://www.opengl.org/registry/specs...load_store.txt

(22) If implementations run fragment shaders for fragments that aren't covered by the primitive or fail early depth tests (e.g., "helper pixels"), how does that interact with stores and atomics? RESOLVED: Stores will have no effect. Atomics will also not update memory. The values returned by atomics are undefined.

[Dan Bartlett]

Does having them wound the same direction have any effect?

eg. Instead of:
{0, 1, 2, 1, 2, 3}
using
{0, 1, 2, 1, 3, 2}.

AFAICT if either way is used only one polygon should produce a fragment along the common edge, so you'll probably need to wait for a driver fix. Triangles wound the same direction may be a more tested path though.

[mhagain]

Have you tried this with drawing your fullscreen quad as a single triangle strip using glDrawArrays?

[Alfonse Reinheart]

Either way, the easiest solution may be to change how you render your full screen quad. Try using a single triangle that is larger than your viewport and fully contains it. This is typically more efficient anyway as it avoids the wasted fragments along the seam between two triangles due to the pixel grouping mentioned above.

Have you tried this with drawing your fullscreen quad as a single triangle strip using glDrawArrays?

This was suggested in the second post of the thread, and he tried it in the third.

[mhagain]

This was suggested in the second post of the thread, and he tried it in the third.

Sigh.

Triangle strip, not triangle.

As well as potentially providing a solution, a strip (not a single triangle) can provide useful diagnostic info for the OP too, such as confirmation of the MSAA theory mentioned above.

All of this is coming from the perspective of trying to help the OP rather than score points off other posters.

[Alfonse Reinheart]

I missed a word; sorry about that.

Though I don't see how it matters if it's a strip or two triangles. I seriously doubt the rasterizer would treat it any differently. It's not like it even sees anything but individual triangles. Multisampling would work the same way as well, regardless of whether it's a strip or individual triangles.

Indeed, I would be very concerned about the validity of the rendering pipeline if turning it into a strip had any effect at all.