I just noticed new extensions in the registry:
WGL_3DL_stereo_control
GL_EXT_stencil_clear_tag
GL_EXT_texture_sRGB
GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample
GL_MESAX_texture_stack
Nice to see GL_EXT_framebuffer_multisample…
I wonder how long until “GL_EXT_framebuffer_blit”, GL_EXT_framebuffer_multisample and “GL_EXT_packed_depth_stencil” appear in ATI’s drivers and what hardware it will be supported on…
Seems a GL_EXT_timer_query has also appeared from somewhere in my 6600 drivers too, but no mention of it in the registry…anyone have an idea what this is to do with?
GL_EXT_timer_query lets you use the query mechanism to perform timing on the GPU. By tracing into the Nvidia driver, I discovered that the enum 0x88BF is now a valid value for the target parameter of glBeginQuery, glEndQuery, and glGetQueryiv. I found a name for this value in the Mesa headers:
#define GL_TIME_ELAPSED_EXT 0x88BF
Bracketing a series of OpenGL commands with glBeginQuery and glEndQuery for the GL_TIME_ELAPSED_EXT target begins and ends a timing interval. Then, you call glGetQueryiv to retreive the elapsed time later. I don’t know what units of time are returned, but I’m guessing it’s microseconds.
Any word on the relation between the multisample-framebuffers, and the multisample-hint? Is it safe to assume that it’s the same as regular multisampled framebuffers?
I think there is a typo in the Errors section of FBO multisample:
If the value of SAMPLE_BUFFERS for either the draw or read
framebuffer is greater than zero, then the error INVALID_OPERATION
is generated if BlitFramebufferEXT is called and the values of
SAMPLES for the draw and read framebuffers do not match.
This should be:
If the value of SAMPLE_BUFFERS for both the draw and read
framebuffer is greater than zero, then the error INVALID_OPERATION
is generated if BlitFramebufferEXT is called and the values of
SAMPLES for the draw and read framebuffers do not match.
Also:
The error OUT_OF_MEMORY is generated when
RenderbufferStorageMultisampleEXT cannot storage of the specified
size.
should be
The error OUT_OF_MEMORY is generated when
RenderbufferStorageMultisampleEXT cannot allocate storage of the specified
size.
It could also use a run through a spell checker (eg “resovle” )
I also find it strange that ReadPixels is not going to be supported on multisample FBO’s. (even tho it is on standard multisample framebuffers)
Originally posted by sqrt[-1]:
[b]I think there is a typo in the Errors section of FBO multisample:
If the value of SAMPLE_BUFFERS for either the draw or read
framebuffer is greater than zero, then the error INVALID_OPERATION
is generated if BlitFramebufferEXT is called and the values of
SAMPLES for the draw and read framebuffers do not match.
This should be:
If the value of SAMPLE_BUFFERS for both the draw and read
framebuffer is greater than zero, then the error INVALID_OPERATION
is generated if BlitFramebufferEXT is called and the values of
SAMPLES for the draw and read framebuffers do not match.
[/b]
I don’t see why it is wrong. Semantically it is actually the same thing. It would imply that you can’t blit a multisampled framebuffer onto non-multisampled.
Or am I missing something?
It is obviously wrong (and it is not the same thing!), as if it was correct there would be no way to actually use the result of rendering to a multisample FBO. (Can’t copy to a texture or the screen)
This is the actual text from the spec:
Append to 4.3.3 (Reading Pixels)
Append to the section describing BlitFramebuffer that was added by
EXT_framebuffer_blit.
"If SAMPLE_BUFFERS for the read framebuffer is greater than zero and
SAMPLE_BUFFERS for the draw framebuffer is zero, the samples
corresponding to each pixel location in the source are converted to
a single sample before being written to the destination.
If SAMPLE_BUFFERS for the read framebuffer is zero and
SAMPLE_BUFFERS for the draw framebuffer is greater than zero, the
value of the source sample is replicated in each of the destination
samples.
If SAMPLE_BUFFERS for both the read and draw framebuffers are
greater than zero, and the value of SAMPLES for the read framebuffer
matches the value of SAMPLES for the draw framebuffer, the samples
are copied without modification from the read framebuffer to the
draw framebuffer. Otherwise, no copy is performed and an
INVALID_OPERATION error is generated.sqrt is correct about both typos.
ReadPixels is not supported from a multisampled FBO because this would require an implicit downsample from the multisample format to single sample. One of the design considerations was to never require the implementation to alloc a scratch buffer nor to perform an implicit downsample. This was viewed as an improvement to the original multisample specification, which was written years ago for a different class of hardware and is problematic to support today.
If you wish to perform a ReadPixels from a multisampled FBO, simply blit to a non-multisample buffer and read from that instead.
Originally posted by gold:
If you wish to perform a ReadPixels from a multisampled FBO, simply blit to a non-multisample buffer and read from that instead.
Ok sure, if it is difficult to implement, I can live with it. (Just requires a bit of a hassle to create a buffer that I will blow away after one operation)
Perhaps this should be added to the “Errors” section of the spec as I initially did not notice it.
I wonder why this “driver might have to alloc some memory to perform the operation” is an issue at all. Isn´t memory allocation and management a driver´s daily work?
Ok, aside from ReadPixels - why are CopyTexImage and CopyTexSubImage not allowed either?
CopyTexImage is expected to alloc some space anyway (and this is working for a decade now…), while CopyTexSubImage wouldn´t have to allocate memory at all.
Now its time for the vendors to implement. For ATI it took over 6 months for FBO, and EXT_packed_depth_stencil is still not on the horizon. I wonder, how long it will take this time 
Originally posted by skynet:
Now its time for the vendors to implement. For ATI it took over 6 months for FBO, and EXT_packed_depth_stencil is still not on the horizon. I wonder, how long it will take this time
Yes, this is somewhat… intresting.
tbh, I wish that the IHVs talked to the developers a bit more, gave us some idea as to how long we will have to wait for stuff to appear.
Specs are all well and good, but without implimentation they arent worth the bandwidth it takes to read them…
I wonder why this “driver might have to alloc some memory to perform the operation” is an issue at all. Isn´t memory allocation and management a driver´s daily work?
When drivers allocate memory under normal circumstances, it is memory that is specifically bound to some user-defined object. Either that, or it is a buffer to be used for storing vertex data or something fairly permanant. In both cases, allocated memory is permanant (until the user deletes the object), not temporary.
Doing copy operations that alloocate and then later deallocate memory can cause all kinds of problems.
Ok, aside from ReadPixels - why are CopyTexImage and CopyTexSubImage not allowed either?
CopyTexImage is expected to alloc some space anyway (and this is working for a decade now…), while CopyTexSubImage wouldn´t have to allocate memory at all.
CopyTexSubImage would need to allocate temporary space. Texture memory is not necessarily framebuffer memory. Texture memory tends to be swizzled, while framebuffer memory tends to be linear. As such, the hardware may not be able to do the multisampling reduction when copying to texture memory.
very good work! i wait it for some time. anybody have test it in nvidia card?
Originally posted by skynet:
I wonder why this “driver might have to alloc some memory to perform the operation” is an issue at all. Isn´t memory allocation and management a driver´s daily work?
With classic multisample there is a natural place to resolve the multisample buffer - to the corresponding single sample buffer. With FBOs there is no single sample buffer associated with a multisample buffer so there is no obvious target for the resolve. The problem with allocating a scratch buffer is, there is no way for the implementation to know whether this will be done just once (and therefore throw away the buffer) or many times (keep it around so you don’t thrash on vidmem alloc/free). Further, as I stated above, hardware does not behave as the legacy multisample language suggests, and the implicit resolve can occur more frequently than necessary, depending on application behavior. Therefore moving control of the resolve to the user seemed like the best solution to both of these issues. There are additional benefits, the realization of which are left as an exercise for the user.
Ok, aside from ReadPixels - why are CopyTexImage and CopyTexSubImage not allowed either?
Same reason - there is no obvious destination for the resolve.