[Mesa-dev] [PATCH 19/23] i965 teximage: don't call _mesa_store_teximage if format/type==GL_NONE

Eric Anholt eric at anholt.net
Thu Jan 10 09:08:34 PST 2013


Jordan Justen <jljusten at gmail.com> writes:

> On Wed, Jan 9, 2013 at 11:11 AM, Eric Anholt <eric at anholt.net> wrote:
>> Jordan Justen <jordan.l.justen at intel.com> writes:
>>
>>> Mesa core's copyteximage calls the driver with format/type==GL_NONE
>>> to "Allocate texture memory". In this case, we shouldn't call
>>> _mesa_store_teximage.
>>
>> I'm not sure if GL_NONE/GL_NONE really makes sense to test for here.  I
>> bet the actual problem is that the app's pixel unpack state (like having
>> a PBO bound, and thus pixels == NULL still meaning to upload data) is
>> leaking into this path through the use of &ctx->Unpack instead of
>> ctx->DefaultPacking.
>
> There is an assert during the _mesa_store_teximage, because at some
> point someone tries to get the bytes/pixel of GL_NONE/GL_NONE.
> (Indeed, a few levels under a call to _mesa_validate_pbo_teximage).
>
> I'm not sure I understand your alternative approach to fix this.

Either use Driver.AllocateTexImageBuffer instead of Driver->TexImage()
(since we never want to upload anything), or use ctx->DefaultPacking in
the Driver->TexImage() call instead of the user-specified ctx->Unpack,
since it's a user PBO being bound in ctx->Unpack that's causing
_mesa_store_teximage() to actually try to store something.  I think
AllocateTexImageBuffer() is the right way to go.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130110/58e0a39d/attachment.pgp>


More information about the mesa-dev mailing list