[Mesa-dev] Status of GL_ARB_separate_shader_objects? I would like to help.

[Ian Romanick]

On 03/23/2013 02:05 PM, gregory hainaut wrote:
> On Fri, 22 Mar 2013 15:44:07 -0700
> Matt Turner <mattst88 at gmail.com> wrote:
>
>> On Fri, Mar 22, 2013 at 1:00 PM, gregory hainaut
>> <gregory.hainaut at gmail.com> wrote:
>>> * GenProgramPipelines doesn't create object!
>>> ... Spec extract:
>>> These names are marked as used, for the purposes of GenBuffers only,
>>>    but they acquire buffer state only when they are first bound with
>>>    BindBuffer (see below), just as if they were unused.
>>> ...
>>>
>>> Basically any command (like BindBuffer) that access the pipeline
>>> will create the pipeline. It seems like vertex array object. From an
>>> implemention point of view it seems much easier to create the object
>>> during GenProgramPipelines call. However I don't know if
>>> IsProgramPipeline must return FALSE if the object was never really
>>> created (bind) like VAO.
>>
>> This is a weird part of the spec. After glGen* (but before glBind*)
>> the associated glIs* function usually returns false. It's something
>> that no one but conformance tests seem to care about. See commit
>> fd93d55141f11069fb76a9b377ad1af88d0ecdd3 (in Mesa) for how to fix this
>> kind of thing.
>>
>> I said "usually" above because there is some inconsistency. The
>> ARB_sampler_objects spec says that the act of calling glIsSampler()
>> actually creates the object.
>>
>> It looks like for ARB_separate_shader_objects that glGen* followed by
>> glIs* should return false (like VAOs).
>
> Ok. Thanks for the example. I updated my code and create a  piglit
> test. By the way, fglrx doesn't follow this behavior, dunno for nvidia.
>
>
> On the mix UseProgram/BindProgramPipeline subjet.
> I try to search the spec for additional info and found this example:
> ##############
> Issue 4:
>          When a non-zero program is passed to UseProgram, any subsequent
>          uniform updates will affect that program, ignoring the active
> program in any bound pipeline object.  For example:
>
>            glUseProgram(0);
>            glBindProgramPipeline(1);
>            glActiveProgram(1, 2);
>            glUniform1f(0, 3.0);          // affects program 2
>            glUseProgram(3);
>            glUniform1f(0, 3.0);          // affects program 3
>            glUseProgram(0);
>            glUniform1f(0, 3.0);          // affects program 2
> ###############
>
> So after glUseProgram(0), the state of the pipeline is restored (or they
> forgot to update this part of the spec when they clarify the priority
> rule), at least the ActiveProgram. Anyway, I write an extensive piglit
> test and check the behavior on fglrx. Here the outcome, glUseProgram(0)
> destroy current program state, the pipeline need to be rebound
> again for any shader based rendering. However ActiveProgram is restored
> as the previous example! Any opinion is welcome, run the test on
> nvidia? Mimic AMD behavior?

There are a few places in GL that behave this way.  There are two 
separate pieces of state that may be used.  In this case, either the 
UseProgram state or the BindProgramPipeline state.  If UseProgram sets a 
non-zero program, that state is used.  Otherwise the BindProgramPipeline 
state is used.  In Mesa we generally handle this by having both sets of 
state tracked in the context and a third _State field that's the one 
actually in use.

Right now in the context we have

    struct gl_shader_state Shader; /**< GLSL shader object state */

I think we'd expand this to

    struct gl_shader_state Shader; /**< GLSL shader object state */
    struct gl_shader_state SSOShader;
    struct gl_shader_state *_Shader; /**< Points to ::Shader or 
::SSOShader */

Or similar.

In this case, I think AMD's behavior is incorrect.

> Cheers
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev