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

[Chris Robinson]

On Monday 25 February 2008 12:17:11 am Sherief N. Farouk wrote:
> >>: I believe there's something you're missing here. I'm totally against
> >>: forcing the implementation to use the internal format. My argument is:
>
> With the MapBuffer methodology, all implementations can expose the optimal
> path. Software implementations that use the same format as the buffer can
> directly map to it, no extra allocation. HW implementations that directly
> support the format can map to where it wants the data for transfer to HW,
> no extra allocation. Implementations that don't directly support the format
> will map to a temporary buffer, which the user writes directly into, and
> then the implementation is the one responsible for managing it, so it can
> convert it in a low-priority thread in the background if it's not
> immediately needed.

But the latter may or may not cause transparent memory allocation when mapped, 
something you'd want to avoid as it's yet another possible run-time point of 
failure in low-memory situations. GFX cards already hold client-side copies 
of some on-card data in case a clobber event happens, but for implementations 
where data can't be dirtied, there's no need for this. With a mappable buffer 
object you know that you're getting its memory segment, whether its stored in 
system RAM or the card's RAM.

I just don't think making alMapBuffer potentially create a temporary buffer, 
maybe, depending on the phase of the moon, is something an app would like. It 
either always should, or it should never, IMO. Uncertainty isn't a very good 
thing.

What could work I suppose is making a "mappable" buffer attribute. Off by 
default, but turning it on would work only if the format's being stored in 
a "compatible" format that was hinted by the app. But I still don't quite 
like it because it's completely at the whim of the implementation design, as 
opposed to implementation capability.

What you're asking for with this sounds more like a client memory storage 
extension. Something that the majority of GL implementations don't implement 
(only Apple, and maybe MESA).

> >>: No, renderbuffer was made mainly for "I won't need to bind that for
> >>: reading" kind of data, as not all hardware put depth/stencil buffers in
> >>: texture-fetchable memory.

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.

> >>: If you're
> >>: interested in writing a reverb shader, let me know and I can let you
> >>: play on the highly unstable experimental compiler (and I *MEAN* both
> >>: highly and unstable. We're talking nitroglycerine here).

Maybe.. are there specs for your shaders (inputs, outputs, how to use, etc)?

> >>: A shader can sample from more than one buffer. One of the neat things
> >>: about that is sometimes multiple emitters can be bundled into one
> >>: source (an NPC and his weapon can sometimes be treated as one-source
> >>: and blended in-shader. You usually don't need that level of accuracy in
> >>: a game).

Yeah, this could be handled by something like multi-buffers. Dirty psuedo-code 
example:

// Bind the buffer to the source, and set the blending mode to add (simple
// mixing) with buffer 0
alSourcei(source, AL_BUFFER1, gun_shot);
alSource2i(source, AL_BUFFER1, AL_BLEND_MODE, AL_ADD);
// Set the buffer to disable when reaching the end, and enable it
// (automatically start playing on the next mixing update)
alSourcei(source, AL_BUFFER1, AL_AUTO_DISABLE);
alSourcei(source, AL_BUFFER1, AL_ENABLE);

Each buffer would have its own play position. In a shader, you could sample 
from each buffer individually and do whatever blending you want, with the 
blend_mode only used as part of the fixed-function pipeline.