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

[Chris Robinson]

On Tuesday 26 February 2008 08:44:21 am Sherief N. Farouk wrote:
> >>: Let's forget about PBOs. Let's think of the mapping proposal as if
> >>: glMapBuffer never existed. Let's make a mapping function that's easiest
> >>: to use while allowing most implementation side optimizations. That's
> >>: why I propose convert on read/write, to isolate the user from the
> >>: implementation internal format if different, and to directly map into
> >>: format sink if same. Smarter things can be done when you're
> >>: multithreaded.

But the problem is, regardless of GL/PBOs/what-have-you, if you're asking to 
get a buffer's memory, you should get the buffer's memory as-is. It shouldn't 
be 'give me the buffer's memory, but convert the data inline to/from 
something I want'. Otherwise the optimization where you can map data and be 
sure there's no hidden, potentially complex conversions or copies going on, 
is lost. Nor would it be good, IMO, to have mapping symantics different from 
one type of object, eg. a buffer, to another type, eg. a sample object.

When you're coding to an API, as opposed to a specific implementation, you 
have to code to the worst-case possibility of a function call. And if people 
have to assume buffer mapping would incur potentially costly temporary 
allocations and conversions, it's not too useful. But if people code assuming 
the best case (buffer mapping is comparitively quick and efficient), then 
their code will perform poorly on some implementations.

This is why sample objects and literal mappings would be more useful. You can 
get direct DMA access to an on-card memory buffer (or a RAM buffer for 
software mixers), then have that used as the source/target for buffering 
operations. At the worst case, it wouldn't be any more inefficient than it is 
now, but at the best case, you just got the buffer load and conversion for 
free.