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

[Chris Robinson]

On Tuesday 26 February 2008 12:45:27 pm Sherief N. Farouk wrote:
> We've added a simple extension to OpenAL for MacOS X that I think
> might be related to this. Sorry if this is off topic (I haven't read
> through all of the posts), but it seems similar at a cursory glance.
>
> We had requests from developers to provide access to the OAL buffers
> to avoid the copy from the buffer the app is filling which would then
> get copied into the al buffer object.
>
> The extension looks like this:
>
> typedef ALvoid	AL_APIENTRY	(*alBufferDataStaticProcPtr) (const ALint
> bid, ALenum format, ALvoid* data, ALsizei size, ALsizei freq);
>
> So, this works in a similar way to the alBufferData API, except that
> the application owns the memory - it uses the dataPtr the application
> provides directly instead of copying into an internal buffer. The
> application's responsibility is to keep this buffer pointer valid and
> untouched as long as this buffer is in use. So, the contract is
> similar for the applications responsibility with regards to the life
> cycle of an alBuffer (the buffer must not be deleted while it is in
> use by an alSource object)
>
> >>: So developers ARE asking for this :D.

This is pretty much how client storage works (I did mention about how 
GL_APPLE_client_storage works before..). It's only drawback is that you have 
to either code the mixer to use all data formats as-is, or limit what can be 
buffered using it. For hardware GL, you have the benefit of being able to 
convert when sending client->hardware (since you always have a copy on the 
client for when you need to reload it onto the hardware). Audio, especially 
software mixing, doesn't need a client copy like that though since it doesn't 
have to reload data on a whim. So you're left with the drawbacks 
(complicating the mixer or restricting formats), and not the positives 
(user-controlled client copy to reload from).

> Chris, let's consider this: I use the word mapping in my own meaning, that
> I made up. Why? Because your concept of mapping being actual is POINTLESS.
> What the user needs is mapping that BEHAVES, semantically and logically, as
> if it's a pointer into the buffer.

What good is it to behave as if it's a pointer into the buffer, if it's not 
pointing to the buffer or what's actually in the buffer, but instead a 
pointer to some other piece of memory with different data? Outside of the 
case where it can give the buffer pointer (which only a few implementations 
could do in specific circumstances), it's not actually mapping anything, so 
there's no need to call it mapping as it would only confuse things when real 
mapping is made available.

And regardless of AL's connection with GL, there's reasons GL didn't decide to 
allow textures or framebuffers to be "mappable with hidden conversions", and 
instead opted for generic pixel buffer objects that can be mapped as-is by 
applications. In more cases than not, conversions will need to be done on 
texture/framebuffer data, and left out the guess work of "what am I really 
getting and what is it really doing?".


Let me ask you something. If you're on a system that's so memory bound that a 
few app-controlled temporary memory segments are a liability, and someone did 
make an extension that did what you're asking.. would you be able to rely on 
the buffer "mapping" function to never give you a temporary memory segment 
for some of the the buffers anyway, which it may or may not convert as 
needed, for the entire run-time of the program?

Since it's allowed to convert as needed, and possibly allocate temporary space 
for you to write to if there's not enough space to store the pre-converted, 
the extra memory needed by the current buffering scheme may still be needed 
anyway. Only now you don't know if it will or not, so you're left guessing 
and hoping you won't go over your quota.


> The implementation is free to convert it 
> to any internal format for storage as long as changes are reflected when
> needed (and for apps that don't read back buffers, that'll be rare). In
> addition to avoiding the copy, as the extension above proves IS useful, it
> also allows for a bunch of hw/multithreaded optimizations.

Besides which, converting and copying happens in one step. Taking out just the 
copying does buy you much, except a few KB of memory (assuming it can convert 
inline). But given the above, you couldn't be sure you even saved that.

> And rearding low 
> memory platforms: In games, any avoidable waste is unacceptable; and the
> PS3 has < 256MB of available memory for the whole game. 8 MB for the audio
> system is GENEROUS.

Avoidable waste is unacceptable, in CPU time or memory consumption or any 
other resource. You're constantly playing a trade-off game there. This is 
also the reason for things like OpenGL ES, to work with the limitations of 
embedded systems, without encumbering the main API for things it's not likely 
to run into as a serious problem on generalized systems.