On 09/21/2011 02:20 PM, Eric Anholt wrote:
> On Wed, 21 Sep 2011 11:22:25 -0700, Kenneth Graunke <kenn...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
