retrieve multisample texture content in buffer object?

[shadocko]

Hello,

Is there a direct way of copying the contents of a multisample texture or renderbuffer to a buffer object?
I mean every sample, because glReadPixels would average the samples at each texel/fragment and glGetTexImage is forbidden with ARB_texture_multisample (out of laziness?).
Right now it seems I'm stuck with fetching individual samples through an additional pass using a shader with texelFetch so any alternate solution would be welcome...

[aqnuep]

There is no other way that I'm aware of to do that.

What's the problem with running an additional pass that does per-sample fetching? The driver would probably have to do the same thing anyway if it would be supported.

[shadocko]

Well, depending on the memory layout of the multisample buffer, it could have been just a memory copy in the driver instead of width*height*numsamples calls to texelFetch...
Also that means I'll have more code to write...

I thought it would be something enough people would like to have to justify an API, the slow path of which would be the equivalent of the texelFetch solution.
I guess that's just the general spirit in which the API has evolved lately (the "Hey, let's deprecate that! The latest mainstream video card should not (but do) accelerate it. We should make it harder on software developers and easier on IHVs" spirit).

[kyle_]

I thought it would be something enough people would like to have to justify an API, the slow path of which would be the equivalent of the texelFetch solution.

texelFetch is the fast path. Samplers are built specifically to have fast accesses to texture. memcpy on actual texture memory probably wont be very usefull (consider things like tiling and samples layout).

Also note that much of 'width*height*numsamples calls to texelFetch' are done at the same time, while driver reading texture memory is sequential.

[shadocko]

Also note that much of 'width*height*numsamples calls to texelFetch' are done at the same time, while driver reading texture memory is sequential.

I was not referring to an actual CPU-side memcpy but to a memory copy on the GPU, which could be parallel as well and certainly make better use of texture caches than a shader making random texelFetches.

With the shader approach (which BTW I ended up implementing), one also has to feed the fragment coordinates and sample indices to the shader (remember I want to output to a buffer object, not another renderbuffer, so no rasterization and no interpolated varyings), either by storing them in a big VBO or generating them through tesselation.
All in all it's a lot of code to write and certainly is not as optimal as what a specially-purposed API would allow.

What bothers me the most is that such an API DID exist. If a layout had been chosen for allowing glGetTexImage to work with multisample textures, things would be nicer. It wouldn't have to be the actual layout of the texture in memory (it's already not the case with plain old textures), just a standard way to serialize multisampled data (let's say, samples of the same fragment in contiguous memory).