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

[Sherief N. Farouk]

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).

>>>: 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.

> >>: 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.

>>>: I fail to see why there should be a distinction. Why can't it simply be one of the proposed buffer usage flags?

> >>: 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)?

>>>: Give me some time and I'll work on that.

> >>: 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.

>>>: 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.

- Sherief