[Openal-devel] Faster buffer model, and more random stuff

[Sherief N. Farouk]

I'm not too sure how I feel about that. I like being able to reuse buffers by 
specifying a new size/format without having to destroy/recreate it. Some 
audio sources can also work with variable length input streams (eg. capture, 
or a real-time network audio stream), and forcing a specific buffer size 
would cause problems. And when dealing with end-of-stream where you might not 
even have enough to fill a buffer...

True, however...

Letting the implementation dictate its own internal storage format is 
something that really helps with where CPU usage is concerned. GL these days 
is being targetted for pretty strong/dedicated hardware, so "minor" 
inefficiencies may not be as big of a deal. But since audio doesn't tend to 
have dedicated hardware (and indeed people like to argue it doesn't need it, 
even though I don't agree), being able to keep the actual internal sample 
format away from the app would help mixer efficiency, which is a good thing. 
It's hard enough to do what it already does efficiently, and forcing more 
stringent storage specifications won't help.

>>: I believe there's something you're missing here. I'm totally against forcing the implementation to use the internal format. My argument is:
With the MapBuffer methodology, all implementations can expose the optimal path. Software implementations that use the same format as the buffer can directly map to it, no extra allocation. HW implementations that directly support the format can map to where it wants the data for transfer to HW, no extra allocation. Implementations that don't directly support the format will map to a temporary buffer, which the user writes directly into, and then the implementation is the one responsible for managing it, so it can convert it in a low-priority thread in the background if it's not immediately needed. No extra copy here as we lost the concept of user giving ptr to user allocated data that he needn't maintain after the call, the main concept that forces either an immediate conversion at the call location (MURDER on one of the platforms we work on) or making an internal copy of the data.

> >>: I'd go for the standard buffer, instead of introducing a new type.
> >>: Unified buffers are cleaner IMO, and that can be managed via "usage
> >>: flags" for buffers, like READ, WRITE, READ_WRITE.

We can do both. The FBO extension added the render buffer at the same time as 
allowing texture targets. I suppose the reason being that a render buffer 
could be set up in a more efficient manner (since the actual storage is 
hidden), whereas a texture could require some extra processor time to make 
sure it's written correctly with zero-copying to be used as a texture. Render 
buffers and double/tripled as depth/stencil storage.

>>: No, renderbuffer was made mainly for "I won't need to bind that for reading" kind of data, as not all hardware put depth/stencil buffers in texture-fetchable memory.

> OK, this one was a slideshow rip-out, so terminology wasn't explained.
> Varying buffers have nothing to do with GL's use of the term. Varying
> buffers are persistent: Whatever you write to them will still be there the
> next time the shader executes. Varying buffers are a per-source attribute.

Ah, I see. Yeah, that could be useful for some stuff (eg. being able to do 
reverb entirely in shaders).

>>: Yes, the whole EAX set should be doable in shaders. If you're interested in writing a reverb shader, let me know and I can let you play on the highly unstable experimental compiler (and I *MEAN* both highly and unstable. We're talking nitroglycerine here).

> > 1) Source shader gets access to the given source's and its
> > listener/context attributes. The shader would be responsible for
> > translating and rotating the source position, setting the gain (as
> > determined by distance, cones, etc), and the pitch (as determined by
> > velocities). It could also write out pairs of attributes that the
> > listener shader would get interpolated (varyings). Multi-channel buffers
> > would only be affected by the pitch and gain.
>
> Why treat multi channel differently? Whatever the user wants to apply to
> the data, he can do it.

Because spatialization doesn't really make sense for multi-channel buffers. A 
single-channel/mono buffer would be "generated" from a single point in space. 
But how would the different channels of a multi-channel buffer map to a 3d 
world through a single source? How would the channels react as the source is 
moved around?

This would probably better serve through a multibuffer (multitexture-like) 
extension. The problem here would be being able to not only sample from a 
buffer that can have an indeterminate number of channels (currently up to 8) 
with I'd assume 4-float components, but to also write them out without 
worrying about/knowing the number of output channels.

>>: A shader can sample from more than one buffer. One of the neat things about that is sometimes multiple emitters can be bundled into one source (an NPC and his weapon can sometimes be treated as one-source and blended in-shader. You usually don't need that level of accuracy in a game).

- Sherief