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

[Chris Robinson]

On Monday 25 February 2008 10:37:15 am Sherief N. Farouk wrote:
> >>>: Not really. GL separates format from internal format sometimes. My
> >>>: idea isn't to allow direct access to the buffer memory, my idea is to
> >>>: have an interface that allows the implementation to perform smart
> >>>: optimizations. Simply put, give me one situation where alBufferData is
> >>>: faster than or uses less memory than the proposed alMapBuffer.

I can't. But alBufferData is inherently safer, I think. Take the following 
scenario:

alSourceUnqueueBuffers(source, 1, &bid);
ALvoid *buf = alMapBuffer(bid);
if(!buf)
{
    // The !buf may be triggered at any time because this specific
    // implementation had to create a temp memory space for the map, and we
    // ran out (as opposed to just failing to create a dma map for hardware)
    break;
}
write_to(buf);
alUnmapBuffer(buf);
alSourceQueueBuffers(source, 1, &bid);

As opposed to a reusable one-time allocation the app controls:

ALvoid *buf = malloc(buffer_len);
...
// Unlikely to fail in low memory situations since no new allocations are
// needed
alSourceUnqueueBuffers(source, 1, &buf);
write_to(buf);
alBufferData(..., buf);
alSourceQueueBuffers(source, 1, &buf);


The former method also loses out on being able to cleanly stuff the AL buffer 
back into the queue, which can cause issues when an app relies on the buffers 
returned by Unqueue. You also need to consider cases where this stuff is 
handled by a kernel module (eg. a sound card driver), where it may have a 
comparitively limited address space mapped to the process (and are shared by 
DMA maps, video drivers, etc), and such allocations can take up precious 
space.


> I see. But my point still stands, that we can create render buffers along
> with "mixer buffer objects" as an alternative to using AL buffers as a
> target.
>
> >>>: I fail to see why there should be a distinction. Why can't it simply
> >>>: be one of the proposed buffer usage flags?

The format the mixer writes to may not be compatible with its buffer storage 
format (eg. interlaced vs deinterlaced). In that case, a render buffer could 
be used like a mappable buffer object, and call alBufferData with that using 
a special format identifier to avoid card->cpu->card transfers.

> >>>: If you look at the XAL designs, two of them have blending units, one
> >>>: with variable multiplier and one with functionality resembling AL_ADD.
> >>>: Blending was dropped in favor of the more flexible blend0in-shader
> >>>: model. The pipeline we went with is #3.

I don't see why it's not possible to have both. There'd be a queryable number 
of buffer units per source that the fixed-function pipeline can blend, and 
the blending is subsumed when a listener shader is active (which can sample 
from all buffers on a source and do the blending itself).