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

[Sherief N. Farouk]

> The "vagueness" of a just-created buffer is similar to the vagueness of a 
> just-created texture in GL. It creates the object, but doesn't allocate any 
> storage for it, which is what alBufferData is for.

And GL people realized this is A Bad Idea, and they moved away from it for GL 3.0.
In GL 3.0, a texture has its dimensions and type specified on creation and are immutable attributes.

> 3) BufferData Should be thrown out and left to die. It has one fatal flaw
> that's annoying on low-memory systems: If I'm decoding from a compressed
> file, 2 copies of the uncompressed data have to exist in memory at some
> point, specially at the call to BufferData, since the caller isn't required
> to maiuntain the pointed to data any longer. My proposition is using the
> buffer mapping analogy from OpenGL (and the enhancments in 3.0). A MapBuffer
> call returns a pointer to a memory location with enough storage for the
> buffer size specified to CreateBuffer.

This won't do much for memory requirements, unfortunately. The storage format 
of an OpenAL buffer is completely implementation dependant, so a mapped 
buffer would have to be a seperate memory segment you write to, which would 
then have to be fed/converted to the buffer when unmapped. You'd still have 
two buffers, just that they'd be handled by the implementation instead of one 
in the implementation and one by the user. This is basically what GL does 
with pixel buffer objects and textures/framebuffers.

>>: It is, but that's not "would have to be" situation. It's the most flexible IMO:
If the formats are the same, a pointer to the internal buffer will be given. If not, the implementation gets To hand the application the pointer, which it could have allocated from a commonly used pool or even in DMA region if HW supports it. In short, the implementation knows better is a safe assumption to make. And if some HW pops up with native VORBIS support, say, the interface still supports maximum performance on that.

> That said, I'd kinda like a mappable buffer object that could potentially do 
> asyncronous server-side copies for alBufferData, and/or that can hold source 
> attributes, or something. Also something like alBufferSubData would be nice.

alBufferSubData can be completely removed if you use GL3-style invalidation (where you unvalidate the range you wrote to only).


> That's not even getting into how hardware may be representing it. In GL, you 
> can't get directly to texture data for the same reason. You'd map a pixel 
> buffer object, read/write it, and call glTexImage*D to transfer/convert from 
> the pixel buffer to the texture, server-side.

Again, GL people are steering away from that in GL3.0.

Usage flags should be used to allow for read, write, or both.

> There's actually already an extension like this: XRAM. It lets you specify a 
> buffer's storage type as accessible (dynamic), static, or automatic 
> (autoselect). Though it does this with two new functions instead of a simpler 
> buffer attribute. It also allows querying how much memory the card has and is 
> available.

> Taking a queue from GL, we could have a way to select an AL buffer (as 
> returned by alGenBuffers), or a new render buffer type object, as a mixer 
> target through a "mixer buffer object". For the most part, it shouldn't be 
> Difficult to mirror the FBO functions, however given OpenAL's async rendering 
> nature, actually utilizing them on the API level efficiently would be a task.

>>: 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.

> Hmm, well, based on xal_pipeline_1.png, my thinking would be that the 3D 
> positioning would be part of the source shader. It would be automatic with 
> fixed-function, but a shader would need to manually set local position, 
> pitch, etc, given the listener and source attributes. I'm also not sure how 
> varyings (if going by the GL term) would apply to the listener shader, as it 
> would be analogous to a fragment shader. Though a source shader would still 
> need to have a way to set variables for a listener shader. So something like:

        Source and Listener
             Attribs
                |
                V
             Source(1)
             Shader---+
                |     | Varyings
                V     |
    Source->Listener<-+
    Buffer   Shader(2)
                |
                V
              Mixed
              Buffer

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.

> 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.

> 2) The listener shader gets the current sampler position, gain, and can sample 
> from the source's buffer. It would be expected to sample from the buffer, 
> apply the gain, and write out a sample that is spatialized and mixed. 
> Multi-channel buffers would bypass the listener shader completely.
Again, why exceptions for multichannel here? One of the channels could actually be sort of a lookup-table (think vertex attributes in GL), and not actual audio data per se.

- Sherief