Jordan Justen <jljus...@gmail.com> writes: > On Wed, Jan 9, 2013 at 11:11 AM, Eric Anholt <e...@anholt.net> wrote: >> Jordan Justen <jordan.l.jus...@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.
pgpfElKZEAWyr.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
