Re: [AD] shader deferred sets

[Peter Wang <novalazy@xxxxxxxxxx>]

On Sat, 02 Mar 2013 00:10:14 -0500, SiegeLord <slabode@xxxxxxxxxx> wrote:
> On 03/01/2013 05:51 PM, Peter Wang wrote:
> > So, in all, would al_set_shader_* implicitly changing the current
> > program object cause trouble for anyone?
> 
> I'm not clear on what the motivation to remove this feature is. On the 
> face of it (and just looking at the API) is seems convenient and 
> intuitive to be able to set uniforms without affecting the value of the 
> current shader.

Sure.  I don't know if everyone should pay for it.

> 
> If the concern is the memory allocation then there can be a trivial (and 
> ultimately necessary) optimization to bypass the deferred sets when the 
> relevant shader is in use. It is necessary because currently deferred 
> sets do not function when the shader is in use (in the sense that they 
> don't apply until you call al_use_shader again). The solution is to not 
> defer the sets when the shader is in use, which coincidentally takes 
> care the memory allocation issue.

Removing is easier :)

If you set the same variable repeatedly (deferred) it will allocate more
memory.  A silly thing to do, but still.

> 
> If we want to remove this feature, then I would alter the API to remove 
> any sort of intuition that you can modify the shader uniforms without 
> using the shader. I'd introduce a global value of the current shader (we 
> already have it for HLSL and OpenGL will also need one to fix the issues 
> current API/functionality).

Yes, for al_use_shader(NULL) for example.

> Then the al_set_shader_* API will lose it's 
> shader parameter, and al_use_shader (as it exists today) will be gone. 
> I.e. you'd use the shaders like this:
> 
> al_use_shader(shader_A);
> al_set_shader_int("my_uniform", 5);
> al_use_shader(shader_B);
> al_set_shader_int("my_uniform", 5);
> 
> This way the global state changes are explicit and it's absolutely clear 
> that you cannot change uniforms without first changing the current 
> shader.

Seems alright to me.

Independent of the above API design, where would you put the current
shader in the global state?  I'm thinking the target bitmap state would
be interesting.  When you target another bitmap it would implicitly use
whatever shader you installed the last time the bitmap was targeted.
The shader and target bitmap have to be compatible, so you can't use a
shader when targeting a memory bitmap.  No special exception required.

Peter