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

[Chris Robinson]

On Wednesday 27 February 2008 04:15:01 am Sherief N. Farouk wrote:
> Newer version discussing recent changes updated at
> http://www.mganin.com/oal/oal.html

First, I'd like to say I don't fully appreciate the tone you portrayed my 
concerns as. But as for responses..

> 1) Hey, that's not how mapping behaves in OpenGL
> I don't need to strictly follow OpenGL, I'm proposing a function independent
> from OpenGL. The concept of audio buffer is local to OpenAL

It is, however, comparable to the concept of a texture. And if you want to 
propose new functionaly, that's fine, great. I may not agree with its 
usefulness, but I'm hardly the final go-to guy for these things (just some 
shmuck working on his own implementation). But you do have to be careful 
about the terms used for functionality so that it's unambiguous for 
programmers, and in that sense, I don't believe calling it buffer mapping is 
ideal as it clashes with the concept OpenGL has already brought forth and 
that OpenAL may want to provide later on.

In actuality, after giving it some more thought, this behavior sounds more 
like DirectX's texture/sound locking mechanisms. I don't mean that as a bad 
comparison by any stretch, just an observation.

> 2) But.. but.. It can't be! MapBuffer has to return a pointer to the actual
> buffer, in its implementation dependant internal format!
> No. That's pointless, useless, and breaks the cross platform benefits of
> OpenAL

I completely agree, and never once said we should expose the implementation 
dependant internal format to the app.

> 6) alBufferData and alBufferDataStatic are all we need, with some app-side
> smartness 
> Most apps aren't that smart, most apps won't bother to be that smart, and
> most apps can't be as smart as the implementation without being tied to a
> specific implementation.

If an app isn't smart enough to use alBufferData/alBufferDataStatic correctly, 
why would they use, eg. alLockBuffer, correctly?

> 7) Fast schmfast, we don't need unspecified behavior! Will it allocate or
> not, etc.
> Hey, on the user end of things, all you care for is the OBSERVED behavior.
> If you're sticking to "GL doesn't do that", get an instrumented driver for a
> recent nvidia GPU and fire up GLExpert, see how VBOs are given pointers by
> glMapBuffer. It's non-deterministic about which memory region you get your
> pointer in.

Of course, because when you put data into GL buffer objects, you tell it 
more-or-less whether it's static or dynamic or what-have-you. And further, 
when you map it, you have to say whether you're going to read to it, write to 
it, or both. GL takes these only as hints and is allowed to put the buffer 
wherever it deems most appropriate for the actual usage (RAM, AGP, on-board, 
etc), and it may change its mind over where to put it. Also given the whole 
local storage thing, if it has a copy in RAM it may decide to give you a 
pointer to there instead of mapping the on-card memory, and do the copy 
itself later on.

However, giving one of a couple pre-existing memory regions as-is is quite 
different from potentially temporarily allocating and doing beind-the-back 
conversions on the buffer object data.


And BTW, you asked for an example where alBufferData would be better off than 
this buffer locking method. Here's one:

ALchar buffer[4096];
fill_data(buffer);
...
ALvoid *buf = alLockBuffer(bid, ...);
memcpy(buf, buffer, ...);
alUnlockBuffer(bid);

There's quite a few cases where you may already have the buffer data and just 
need to get it to the card (such as where the actual sound system is 
seperated from data loading; eg. due to having a wrapper over various output 
backends and not being able to get "direct" buffer access). If locking a 
buffer may give temporary memory space due to the pre-converted data being 
too large for the post-converted's memory space, that means you may have 2 or 
3 seperate copies. As opposed to:

ALchar buffer[4096];
fill_data(buffer);
...
alBufferData(bid, ..., buffer);

which will only have 2. Further, alBufferDataStatic can cut that down to 1, 
but with the aforementioned caveats.