[Mesa-dev] [PATCH 6/7] intel: Drop gratuitous flush in PBO blit upload.

[Kenneth Graunke]

On 09/21/2011 02:20 PM, Eric Anholt wrote:
> On Wed, 21 Sep 2011 11:22:25 -0700, Kenneth Graunke <kenneth at whitecape.org> wrote:
>> On 09/21/2011 10:15 AM, Eric Anholt wrote:
>>> Since the blit gets sequenced after other batchbuffer rendering like
>>> normal, there's no need to push things out early.
>>> ---
>>>  src/mesa/drivers/dri/intel/intel_tex_image.c |    3 ---
>>>  1 files changed, 0 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c b/src/mesa/drivers/dri/intel/intel_tex_image.c
>>> index 9ae0aee..ac3489b 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_tex_image.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
>>> @@ -196,9 +196,6 @@ try_pbo_upload(struct intel_context *intel,
>>>  
>>>     dst_stride = intelImage->mt->region->pitch;
>>>  
>>> -   if (drm_intel_bo_references(intel->batch.bo, dst_buffer))
>>> -      intel_flush(&intel->ctx);
>>> -
>>>     {
>>>        GLuint offset;
>>>        drm_intel_bo *src_buffer =
>>
>> I'm a bit uncertain about this patch.  Is it possible to:
>> 1. Render some stuff
>> 2. TexImage to upload a PBO
>> 3. Do more rendering, reading or writing the PBO
>>
>> ...all within the same batchbuffer?
>>
>> The point of these flushes is to make sure the blit happens before any
>> further uses of the buffer.  If the current render batch can read from
>> the PBO, it'll get garbage; any writes it does would be clobbered by the
>> blit.
>>
>> It's not obvious to me why this is unnecessary.
> 
> If "further uses" is GPU rendering, that ends up serialized after the
> blit, just like the blit after other GPU rendering.  If it's CPU
> rendering, everything that uses the CPU to map checks if the BO is
> referenced by the batch and flushes, and then the CPU mapping blocks.

Ah, right...it's not mapped.  Mapping it would cause a flush.

That makes sense, thanks.  I'm fine with this now.