[Mesa-dev] [PATCH] i965: Don't create a temp PBO when uploading data from glTexImage*

[Neil Roberts]

> On Fri, Jun 12, 2015 at 7:34 AM, Neil Roberts <neil at linux.intel.com> wrote:
>> The code was buggy anyway because it was checking whether the buffer
>> was busy before calling Driver->AllocTextureImageBuffer. That function
>> actually always frees the buffer and recreates a new one so it was
>> checking whether the previous buffer was busy and this is irrelevant.

Jason Ekstrand <jason at jlekstrand.net> writes:

> I'm not sure this is correct.  You can still do partial updates with
> TexImage if you are updating a single miplevel or cube face.

Ah yes, you're right. I didn't look into the code far enough. When it
calls Driver->AllocTextureImageBuffer it will likely get the same
miptree back because there is a pointer to it from the texture object.

However, it still seems like creating a PBO would be counter-productive
most of the time because you are most probably going to replace all of
the mipmaps if you replace one of them. Maybe a good thing to do would
be to check whether intel_texobj->mt is busy in
intel_alloc_texture_image_buffer and then let it allocate a new mt in
that case. That way in the likely case that the rest of the images are
updated too then it would use a new buffer and avoid blocking without
introducing an extra copy. If it turns out that the application really
is just updating one image then it will be copied in anyway when the
texture is finalized which achieves more or less the same thing as using
a PBO.

>> In practice I think this wouldn't matter too much because the upper
>> layers of Mesa always call Driver->FreeTextureImageBuffer before
>> calling Driver->TexImage anyway so there would never be a buffer that
>> could be busy.

I think this point still holds and means it's effectively impossible to
hit the create_pbo=true case.

Regards,
- Neil