[openal] Ideas on an explicit context API

[Chris Robinson]

On 4/22/23 18:22, Chris Robinson wrote:
> ...

As an update to this, I added functions to a preliminary extension for 
this to OpenAL Soft's current Git. I decided to go with the "Direct" 
suffix since it's shorter than "Explicit", but I'm willing to change it 
if people prefer something else.

Implementation wise, I decided to make it a requirement that the context 
be valid. Passing NULL or other pointer values that are not a valid 
context will result in UB. The primary reason for this was to avoid 
costly validation checks for each call, and NULL is simply another value 
for validation. This also avoids the issue of what to do for functions 
that return a value (alGetErrorDirect() in particular) without a valid 
context to get the value from. Consequently, while thread safety exists 
between calls using the same context (as necessary for multi-threaded 
calls using the current context), destroying a context at the same time 
as making a call with it is UB, if you can't guarantee the call is done 
before destroying it.

The extension is currently listed as both ALC_EXTX_direct_context for 
alcIsExtensionPresent, and AL_EXTX_direct_context for 
alIsExtensionPresent (EXTX to signify it's an experimental/in-progress 
EXT extension, and may change in incompatible ways before finalized). 
The functions can be retrieved from either alcGetProcAddress or 
alGetProcAddress. The ALC portion is needed to avoid a catch-22... if 
something uses Direct functions because it can't safely change the 
current context, but needs to set a context to check for the extension 
and get the functions (as per the spec, al[c]GetProcAddress returning a 
non-null pointer doesn't guarantee the returned function is usable if 
the context doesn't support the extension). In theory I suppose 
AL_EXT_thread_local_context can work to do the check on a specific 
thread during initialization, and reset the thread-local context after 
verifying and getting the functions, but that makes it reliant on 
another extension.

And for a final note, this extension cannot work with Creative's router 
DLL, given how the router is currently implemented. Although you can get 
the new Direct functions using al[c]GetProcAddress with a supported 
device/driver, the ALCcontext handle you get from the router's 
alcCreateContext is not the same as the driver's ALCcontext handle, and 
can't be passed to the driver's Direct functions. I'm unfortunately not 
sure how to work around this, given that the router's 
al[c]GetProcAddress will always return its own functions when possible 
and only call the driver to get unknown functions (so you can't get the 
driver's alcOpenDevice or alcCreateContext). Perhaps if there's some way 
to get the HMODULE for some open device's driver, then use Windows' 
GetProcAddress to get the standard ALC/AL functions directly from the 
driver, close the device with the router, then reopen it using the 
driver's functions directly. I could probably add an extension to bypass 
the router's al[c]GetProcAddress override, which would allow getting the 
driver's functions without needing the driver's HMODULE. Then do 
two-step initialization, not too dissimilar to WGL.

The extension will work as-is with OpenAL Soft's router, since it gives 
the same ALCdevice and ALCcontext handle to the app that it got from the 
driver, so the driver's Direct functions will recognize the ALCcontext 
handle the app has.