> On Fri, Jun 12, 2015 at 7:34 AM, Neil Roberts <n...@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 <ja...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
