Where else would the flush go? I'll look into fixing it differently
but if the flush is anywhere in the makecurrent path, the same issue
will happen. Again, none of the classic dri drivers do it.

Stéphane


2012/1/11 Jose Fonseca <jfons...@vmware.com>:
> Stephane,
>
> Although flushing the front buffer may be unnecessary, flushing itself is 
> not, as glXMakeCurrent mandates that the current must be flushed:
>
>   "Pending commands to the previous context, if any, are flushed before it is 
> released."
>
> So this flush call can only be removed, if a flush is done elsewhere in DRI 
> shared code, otherwise rendering queued in that context may not happen.
>
> Jose
>
> ----- Original Message -----
>> In the following scenario:
>> - CreateContext C1
>> - MakeCurrent C1
>> - DestroyContext C1 (does not actually destroy the first context,
>> postponed
>>   until the next MakeCurrent)
>> - CreateContext C2
>> - MakeCurrent C2
>>
>> MakeCurrent will call flush on a context which might not even have
>> had a front
>> buffer, leading to crashes. Since none of the dri drivers use the
>> flush in
>> their unbind_context implementation either, we remove this useless
>> flush front
>> call.
>>
>> This fixes GPU crashes with Chrome and gallium drivers.
>> ---
>>  .../state_trackers/dri/common/dri_context.c        |    1 -
>>  1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/dri/common/dri_context.c
>> b/src/gallium/state_trackers/dri/common/dri_context.c
>> index b47d8d9..226c630 100644
>> --- a/src/gallium/state_trackers/dri/common/dri_context.c
>> +++ b/src/gallium/state_trackers/dri/common/dri_context.c
>> @@ -188,7 +188,6 @@ dri_unbind_context(__DRIcontext * cPriv)
>>
>>     if (--ctx->bind_count == 0) {
>>        if (ctx->st == ctx->stapi->get_current(ctx->stapi)) {
>> -         ctx->st->flush(ctx->st, ST_FLUSH_FRONT, NULL);
>>           stapi->make_current(stapi, NULL, NULL, NULL);
>>        }
>>     }
>> --
>> 1.7.5.3.367.ga9930
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to