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

[Sherief N. Farouk]

First of all I'd like to say sorry for jumping into a middle of a
discussion that quite simply, I don't understand thoroughly. I hope I
don't sound too confused :)

>From what I can see, the changes that Sherief Farouk is proposing are
motivated by a desire to optimise the memory interaction of a program
and openal. Correct me if I'm wrong but these points seem to be the
goal:

a) Provide more information on buffer creation so an implementation can
optimise creation ready for filling the buffer.
b) Allow a method of using a buffer's memory directly from the program
without storing temporarily in the program (e.g. when reading from a
file)
c) Prevent unnecessary deallocs and reallocs occuring in the openal
implementation.

My comments:

First comment I want to make is that I feel that the openal API (not the
implementation or extensions available) should always accommodate to the
lowest common denominator in programmer. If it can be possible to start
a sound playing in a few lines without having programmed in sound before
or understanding details of formats, then the API should provide this.
After all, it was the simplicity of openal that got me into it in the
first place.

>>: And I agree. We're not making D3D5 here ;). The number of lines should
be almost the same. The difference is where the parameters are provided:
size and format are given to create buffer, rather than buffer data.

And I do mean a few lines of openAL, not Alut - while I love to use
toolkits like alut and glut for small specifc tasks, using Alut
completely and never touching a line of openal code seems
counterintuitive to me. Advanced buffering techniques, etc... might be
best implemented and made available via extensions and perhaps hints
given to the objects, although I'm not sure if this would be too
unwieldy.

>>: True.

Onto the rest:

a) Having to provide a stack of information (say 10 arguments) in an
object creation is not something I have liked in other APIs. Providing
two options - the current buffer creation function with state based
changes (which may be implemented as merely holding a booking for a
future 'proper' creation) as well as a 'the-works' buffer creation
function might be a solution.

>>: The number of parameters is the same - the difference is in where you
provide them: to create buffer or to buffer data.

b) I don't see, with the conversion between formats and the possibility
of not knowing an internal format, how this can be done. I think I don't
understand the term 'convert-on-read'. If the mapping is not a direct
mapping then how can it be saving memory? Won't two copies of the data
still need to be stored?

>>: With BufferData, two copies ALWAYS have to be made (Or a stall). With
MapBuffer, if the copy is unnecessary it won't be made, and if it causes a
stall it can be processed asynchronously with one less copy.

c) As far as I can imagine, it would be a very unlikely situation for a
buffer to be continually changing size and needing a realloc. Shouldn't
the implementation assume that the buffer size will not likely change,
and so only dealloc or realloc when given larger data than it can hold?

>>: See, there's this problem when you Ass-u-me ;). But seriously, that's
one of the things I'm trying to change with the new buffer model. Immutable
buffers allow for A LOT of transparent optimizations.

The last thing I want to ask is for what purpose has openal been
designed... do the openal implementations work well on resource-limited
devices? As I thought that 99% of openal use was on resource-rich modern
computers, I don't feel that the essential parts of the API should be
made more complicated.

>>: In game development, we can't afford to waste a cycle, and especially
memory space and allocations. Some target platforms have no branch
prediction, in order execution and less than 256 MB of memory for the whole
game! See my point?

This was meant to be a quick comment... looks like I got carried away.
Sorry if I've said anything stupid - it's only through ignorance!

>>: Eh, you don't even need to apologize. Not that anything was stupid, mind
you.

- Sherief