Nope

On Tue, Jan 9, 2018 at 9:22 AM, Alex Smith <[email protected]>
wrote:

> Thanks Jason. I take it you didn't find any other state that needed
> resetting then?
>
> Alex
>
> On 9 January 2018 at 16:49, Jason Ekstrand <[email protected]> wrote:
>
>> From: Alex Smith <[email protected]>
>>
>> After executing a secondary command buffer, we need to update certain
>> state on the primary command buffer to reflect changes by the secondary.
>> Otherwise subsequent commands may not have the correct state set.
>>
>> This fixes various issues (rendering errors, GPU hangs) seen after
>> executing secondary command buffers in some cases.
>>
>> v2 (Jason Ekstrand):
>>  - Reset to invalid values instead of pulling from the secondary
>>  - Change the comment to be more descriptive
>>
>> Signed-off-by: Alex Smith <[email protected]>
>> Reviewed-by: Jason Ekstrand <[email protected]>
>> Cc: [email protected]
>> ---
>>  src/intel/vulkan/genX_cmd_buffer.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
>> b/src/intel/vulkan/genX_cmd_buffer.c
>> index b7253d5..4b73ac8 100644
>> --- a/src/intel/vulkan/genX_cmd_buffer.c
>> +++ b/src/intel/vulkan/genX_cmd_buffer.c
>> @@ -1078,6 +1078,15 @@ genX(CmdExecuteCommands)(
>>        anv_cmd_buffer_add_secondary(primary, secondary);
>>     }
>>
>> +   /* The secondary may have selected a different pipeline (3D or
>> compute) and
>> +    * may have changed the current L3$ configuration.  Reset our tracking
>> +    * variables to invalid values to ensure that we re-emit these in the
>> case
>> +    * where we do any draws or compute dispatches from the primary after
>> the
>> +    * secondary has returned.
>> +    */
>> +   primary->state.current_pipeline = UINT32_MAX;
>> +   primary->state.current_l3_config = NULL;
>> +
>>     /* Each of the secondary command buffers will use its own state base
>>      * address.  We need to re-emit state base address for the primary
>> after
>>      * all of the secondaries are done.
>> --
>> 2.5.0.400.gff86faf
>>
>>
>
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to