I’m using a framebuffer object without attachments because I render to an image unit with the Image Load Store operations instead. Ideally, I want to access the hit/miss count of the sub-pixel samples from within the fragment shader. Is this possible?
The documentation makes it seem like the only way to leverage multisampling is to generate a multisample texture and to downsample this texture afterwards e.g. using framebuffer blitting, yet it’s possible to set GL_FRAMEBUFFER_DEFAULT_SAMPLES with glFramebufferParameteri. However, I’m not sure how to use this.
[QUOTE=jasonellis;1262251]I’m using a framebuffer object without attachments because I render to an image unit with the Image Load Store operations instead. Ideally, I want to access the hit/miss count of the sub-pixel samples from within the fragment shader. Is this possible?
The documentation makes it seem like the only way to leverage multisampling is to generate a multisample texture and to downsample this texture afterwards e.g. using framebuffer blitting, yet it’s possible to set GL_FRAMEBUFFER_DEFAULT_SAMPLES with glFramebufferParameteri. However, I’m not sure how to use this.[/QUOTE]
What do you mean by hit/miss?
If you’re looking for the total number of times “any” subsample a render target (if you had one) would be written to or blended to by rasterizing one or more primitive to it, look into occlusion query or atomic counters.
Or do you mean the number of times a specific subsample in a render target (if you had one) would have been written to (or blended to) by rasterizing one or more primitives to it? You could add a color or stencil attachment, and add one to it each time it is written. But that would defeat the premise of your question. You could use a bazillion atomics in some image buffer, but that seems like it would be a lot less efficient than just letting the pipeline update a render target.
Or since you don’t have any depth/stencil/etc. buffers to cause fragments to fail, you could just analytically pixel/sample coverage from the input data.
I’m going to ask differently: The specs for ARB_framebuffer_no_attachments say “When a framebuffer has no attachments, it is considered to have sample buffers if and only if the value of FRAMEBUFFER_DEFAULT_SAMPLES is non-zero.”. What does it exactly mean to have sample buffer without attachments? Say I have set the sample number to 8, then it will generate 8 samples per pixel, each of which will invoke the fragment shader with coordinates of each subsample?
That’s a really good question. I hadn’t read that spec before. After skimming it, it sounds like it “conceptually” has sample buffers but physically does not (that’s a guess, but fits with the intent and the language about how you specify the number of samples in the absense of attachments).
… each of which will invoke the fragment shader with coordinates of each subsample?
Now I wouldn’t think that part is necessarily true. I’d think that you need to enable SSAA rasterization (ala ARB_sample_shading) as well to get that behavior. Otherwise with merely GL_MULTISAMPLE enabled, you should get the default MSAA rasterization behavior (one frag shader execution per pixel).
> Otherwise with merely GL_MULTISAMPLE enabled, you should get the default MSAA rasterization behavior (one frag shader execution per pixel).
I thought the default MSAA rasterization behavior is that the fragment shader is executed n times per fragment with a sample count of n. How would one do the anti-aliasing otherwise?
MSAA = One shading sample per pixel; multiple geometry samples per pixel.
SSAA = Multiple shading and geometry samples per pixel.
So MSAA will supersample your geometry edges, but it will not supersample your shading (i.e. fragment shader operations). This gives you smooth geometry edges without the cost of SSAA.
Anti-aliasing within the interior of a primitive is handled by texture filtering.
MSAA is for anti-aliasing the edges; either the actual geometric edges or where parts primitive are clipped away by depth or stencil tests. The effect is to generate “shaped fragments”, which have a single colour but which don’t necessarily cover the entire pixel.
You could use a bazillion atomics in some image buffer, but that seems like it would be a lot less efficient than just letting the pipeline update a render target.