hw accumulation buffer?

Any infos about consumer-level hardware that (will) support accumulation buffer in HW? :wink:

just to know… it’s gl1.1 btw! ;))

The Radeon 9700/9500 support HW accumulation buffers.

-Evan

finaly, there is someone out there, who is accelerating OpenGL 1.1 functions instead creating new extensions with the same functionality !!!

but i still, don’t get the point, why accumulation buffers are not supported on “low-end” HW like a GF2,GF3,GF4 or Radeon(lower than 9700) ?
all functionality of accumulation buffers can be “simulated” with a bunch of ARB_ EXT_ NV_ and wgl extensions… but why can’t it be implemented with the standard accumulation-buffer method ?
why do i have to use wglPBuffers instead ?

as far as i know, it could be implemented even on a TNT or a RAGE, so what’s the point, why it’s not implemented ?

and while i’m camplaining: why can’t there be a support for AUX buffers ?

does anyone have answers for me ? (i really would like to know that…nearly as much as i would like to use the accum.buffer )

Accum buffers really can’t be accelerated properly on older HW. They require rasterizing into a signed buffer and additional precision which older cards don’t have. The accum buffer effects you could do required domain knowledge of what you were implementing to accomplish it on older HW.

Oh, and the 9700 driver does support AUX buffers for some pixel formats. I have only been using them with pbuffers, so I don’t know off the top of my head if you can get one with a window.

-Evan

Originally posted by ehart:
Oh, and the 9700 driver does support AUX buffers for some pixel formats. I have only been using them with pbuffers, so I don’t know off the top of my head if you can get one with a window.

Why only some ? Is there something special about AUX buffers or is it just with the current drivers, that only some formats work ? I’ve used AUX buffers with floating point pbuffers, so those definitely work.

[This message has been edited by PH (edited 02-13-2003).]

Well, I said some because AUX buffers are part of the pixel format, just like the presence of a back buffer. In other words, you can get a pixel format with or without an AUX buffer.

-Evan

Originally posted by AdrianD:
all functionality of accumulation buffers can be “simulated” with a bunch of ARB_ EXT_ NV_ and wgl extensions…

still curious, could you list thoses extensions u’re talking about? :wink:

as we’re talking about mpass rendering, don’t u think that it is also possible to use blending funcs + mpass successively into the color buffer to achieve some of the basics of accum.buffer? (mul factor and additive) that are needed for both fsaa and dof with the jittering stuff? :slight_smile:

I may be wrong, but I think most cards (modern at least) SUPPORT accum. buffers, but NOT in HW. Both my GeForce256 & Ti4200 cards support 64-bit accumulation buffers (under both Linux and Windows).

I think the main reason is that accum. buffers are not supported in HW, is that they should have better precision. Look at the pixel format, and you will find that the accum. buffers are usually 64 BPP (16 bits per color component). [glxinfo under Linux ]

I also think that the fact that some pixel formats support accum. buffers and some don’t, is mostly the result of configuration
permutations (so that you can chose a pixel format without accum. buffers if you want to use the memory for something else).

I may be wrong though.

Heya Marcus!

Well, in case accumulation buffer will switch to sw then i (blindly) see 2 alternatives (for simulated dof,fsaa and so on)

emulation of successive GL_ACCUM,factor through : glCopyTexImage2D(…) , BlendOp(GL_ONE,GL_SRC_ALPHA)

or ARB_render_texture + pBuffers , BlendOp(GL_ONE,GL_SRC_ALPHA)

But the last uses WGL_ARB and i don’t know if it is supported on Linux. :-/

Of course, all of this should be quite expensive but far from sw implementations

eh… Marcus, todo for pBuffer support is done? ;-p

[This message has been edited by Ozzy (edited 02-18-2003).]

>>>and you will find that the accum. buffers are usually 64 BPP (16 bits per color component). [glxinfo under Linux ]<<<

Yes, it’s pretty much always been 64bpp, but that’s no longer a big deal, especially since floating point buffers will become common. For fp buffer, you can have 32 bit per component, so that means 128 bpp buffers!
And since fp buffers would consume a lot of mem, they introduced half-floats so that you can go down to 64 bpp (float) buffer.

GL needs abstract buffers, the way GL2 is proposing.

Originally posted by Ozzy:
still curious, could you list thoses extensions u’re talking about?

NV_register_combiners
ARB_fragment_program
EXT_blend_subtract
WGL_pbuffer
WGL_ARB_buffer_region
WGL_ARB_pbuffer
WGL_ARB_render_texture
ARB_texture_env_combine
EXT_texture_env_combine

thanks for the replies guys.

Below some results for those interested :slight_smile:
http://www.orkysquad.org/main.php?id=lir…y&year=2003#562

Some more shots a bit more finalised. :wink:
(but a bit dark i know…)
http://www.orkysquad.org/main.php?id=lir…h&year=2003#562

Btw is hw accumulation buffer supported on FX series?