[Mesa-dev] [PATCH 12/12] mesa/sso: Implement ValidateProgramPipeline

Ian Romanick idr at freedesktop.org
Fri Mar 14 17:29:05 PDT 2014


On 03/13/2014 10:52 AM, Eric Anholt wrote:
> Ian Romanick <idr at freedesktop.org> writes:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/05/2014 01:00 PM, Eric Anholt wrote:
>>> Ian Romanick <idr at freedesktop.org> writes:
>>>
>>>> From: Gregory Hainaut <gregory.hainaut at gmail.com>
>>>>
>>>> Implementation note: I don't use context for ralloc (don't know
>>>> how).
>>>>
>>>> The check on PROGRAM_SEPARABLE flags is also done when the
>>>> pipeline isn't bound.  It doesn't make any sense in a DSA style
>>>> API.
>>>>
>>>> Maybe we could replace _mesa_validate_program by 
>>>> _mesa_validate_program_pipeline.  For example we could recreate a
>>>> dummy pipeline object.  However the new function checks also the 
>>>> TEXTURE_IMAGE_UNIT number not sure of the impact.
>>>>
>>>> V2: Fix memory leak with ralloc_strdup Formatting improvement
>>>>
>>>> V3 (idr): * Actually fix the leak of the InfoLog. :) * Directly
>>>> generate logs in to gl_pipeline_object::InfoLog via 
>>>> ralloc_asprintf isntead of using a temporary buffer. * Split out
>>>> from previous uber patch. * Change spec references to include
>>>> section numbers, etc. * Fix a bug in checking that a different
>>>> program isn't active in a stage between two stages that have the
>>>> same program.  Specifically,
>>>>
>>>> if (pipe->CurrentVertexProgram->Name ==
>>>> pipe->CurrentGeometryProgram->Name && 
>>>> pipe->CurrentGeometryProgram->Name !=
>>>> pipe->CurrentVertexProgram->Name)
>>>>
>>>> should have been
>>>>
>>>> if (pipe->CurrentVertexProgram->Name ==
>>>> pipe->CurrentFragmentProgram->Name && 
>>>> pipe->CurrentGeometryProgram->Name !=
>>>> pipe->CurrentVertexProgram->Name)
>>>>
>>>> v4 (idr): Rework to use CurrentProgram array in loops.
>>>>
>>>> Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
>>>
>>>> diff --git a/src/mesa/main/pipelineobj.c
>>>> b/src/mesa/main/pipelineobj.c index 3db97c0..d371e88 100644 ---
>>>> a/src/mesa/main/pipelineobj.c +++ b/src/mesa/main/pipelineobj.c
>>>
>>>> +   /* Section 2.11.11 (Shader Execution), subheading
>>>> "Validation," of the +    * OpenGL 4.1 spec says: +    * +    *
>>>> "[INVALID_OPERATION] is generated by any command that transfers +
>>>> *     vertices to the GL if: +    * +    *         ... +    * +
>>>> *         - Any two active samplers in the current program object
>>>> are of +    *           different types, but refer to the same
>>>> texture image unit. +    * +    *         - The number of active
>>>> samplers in the program exceeds the +    *           maximum
>>>> number of texture image units allowed." +    */ +   if
>>>> (!_mesa_sampler_uniforms_pipeline_are_valid(pipe)) +      goto
>>>> err; + +   pipe->Validated = GL_TRUE; +   return GL_TRUE;
>>>
>>> What ensures that the sampler validate will be redone when sampler 
>>> uniforms change?
>>
>> _mesa_valid_to_render calls _mesa_validate_program_pipeline.  If the
>> application calls glValidateProgramPipeline (getting an error),
>> changes the uniform, then calls glDrawArrays, the program will get
>> revalidated.
> 
> I was thinking of the transition from a working pipeline with
> non-overlapping samplers to overlapping samplers of different types.

Ah... you were wise to be suspicious of that.  It turns out, we already
have a problem in that case with non-separable programs.  There appear
to be some additional problems in the separable case.  I sent a couple
piglit tests out that reproduce these issues.

I think I'd like to

1. Fix the new problems in _mesa_ValidateProgramPipeline.
2. Push _mesa_ValidateProgramPipeline.
3. Fix the pre-existing problems.

Sound like a good plan?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140314/b11d22cb/attachment.pgp>


More information about the mesa-dev mailing list