Can't read pixels from multisampled FBO.

Hi All. I am really confused on how to multisample textures in FBOs .I found some info on Multisampling in "OpenGL super bible" and in the examples from www.g-truc.ne . And I can't get a unified picture of how to do it right .What I want to do is to create an FBO , render my object with texture applied to it to the FBO's color attachment .After that I am reading the color attachment into pixels which I render to image file.
Now I found several options but none works for me . For example I see that it is possible to attach to FBO multisampled render buffers and multisampled tex images. I tried both.Reading from any of those pixels gets me an image with black screen.So anyone can answer me to the following questions? I do it with OpenGL 4.0 btw.
The texture for object material has to be defined as GL_TEXTURE_2D_MULTISAMPLE always?

FBO -what is the better way to compose it for depth and color attachments - using render buffers or textures?

If you have a multisample buffer (either renderbuffer or texture) as color attachment, glReadPixels or other pixel transfer operations won't work.
You first have to perform sample resolve by blitting the content of your multisample framebuffer to a non-multisample framebuffer (glBlitFramebuffer), then read from that non-multisample framebuffer.

Thank you, yes I googled more and found that I need to blit to a regular buffer.Now i would like to ask more questions regarding MSAA :
What is preferable to use a target in the FBO renbder buffers or textures? I mean in terms of reading speed.
Can the input texture (one that comes from the image file of material) be also multisampled as the target textures or it is always shoulod be GL_TEXTURE2D ?

And another question:
Can the multi-sampled buffer and the one that used for resolving be in a single FBO ?

...more questions regarding MSAA :
What is preferable to use a target in the FBO renbder buffers or textures?

Theoretically, use renderbuffers unless you need to feed the results back into a subsequent pass (via shader samplers) and in that case use textures.

In practice, I've not heard of anyone seeing any performance difference out of these, so in the case you don't need to feed the results back into a shader, it's your call.

Can the input texture (one that comes from the image file of material) be also multisampled as the target textures or it is always shoulod be GL_TEXTURE2D ?

That's an interesting question. Whether you'd really want to is determined by if there's utility in doing so.

In the shader the only things you can do with a multisample texture (AFAIK) is query its resolution and fetch individual texture samples. So I guess if you were going to implement your own filtering and/or wrapping behavior, there might conceivably be some utility. Though it would be worth considering whether there might be an advantage to using a 2D texture (possibly larger res) to get the GPU texture sampler interpolation support. Note that multisample textures can't have MIPmaps so if you wanted to do some fast large-extent filtering on those that's something you'd have to work around.

As far as logistically reading and writing multisample textures, they're not really meant for this so saving/loading them isn't as easy as with single-sample textures (e.g. gllTexImage2DMultisample() doesn't take a data pointer). You'd have to do some shader passes with texelFetch() to extract all the samples and you can query the sample locations via some other APIs IIRC, and to load you'd probably need render passes while varying the sample write mask.

So to answer your question, yes. But saving/loading it would be some work, and what you could do with it once you had it is pretty limited.

Can the multi-sampled buffer and the one that used for resolving be in a single FBO ?

No (AFAIK). See the attached man pages. But basically, Blit requires the framebuffers to be framebuffer complete. And they (it) can't be framebuffer complete if it has attachments with different numbers of samples.