[Mesa-dev] [PATCH 20/23] i965 teximage: allocate texture image buffer for fallback path

[Jordan Justen]

On Mon, Jan 7, 2013 at 1:25 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 01/04/2013 06:41 PM, Jordan Justen wrote:
>>
>> Signed-off-by: Jordan Justen <jordan.l.justen at intel.com>
>> ---
>>   src/mesa/drivers/dri/intel/intel_tex_image.c |    1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
>> b/src/mesa/drivers/dri/intel/intel_tex_image.c
>> index 9676623..c6bb0f2 100644
>> --- a/src/mesa/drivers/dri/intel/intel_tex_image.c
>> +++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
>> @@ -239,6 +239,7 @@ intelTexImage(struct gl_context * ctx,
>>          __FUNCTION__, texImage->Width, texImage->Height, texImage->Depth,
>>          pixels);
>>
>> +   ctx->Driver.AllocTextureImageBuffer(ctx, texImage);
>>      if (format != GL_NONE && type != GL_NONE) {
>>         _mesa_store_teximage(ctx, dims, texImage,
>>                              format, type, pixels, unpack);
>>
>
> I'm confused about this patch and the previous patch.  Can you provide some
> addition background about these changes?

In GLES3-GTF, a copyteximage scenario was hit that try_pbo_upload
couldn't handle. It would assert, so I added a change like Ken's
66ea6e8.

66ea6e8 causes try_pbo_upload to fail, rather than assert in this
case. Now this code path (tweaked in 19/20) was hit, and the call to
_mesa_store_teximage would die. (patch 19)

I then found that since neither intel_texsubimage_tiled_memcpy or
try_pbo_upload were calling AllocTextureImageBuffer, I needed patch
20.

-Jordan