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.
pgppwKfdOuPed.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
