CC'ing Topi.

Topi, this sounds an awful lot like bugs you've fixed lately.  Thoughts?

Right, upstream has a fix for this, test passes. If I revert:

commit ca84e190a446bbc29c3ef2864ba4ea5c7358a89a
Author: Topi Pohjolainen <topi.pohjolainen@intel.com>
Date:   Tue Nov 15 22:27:12 2016 +0200

    i965/miptree: Don't shrink textures when augmenting for more levels
    
    This was detected when examining CCS_E failures with piglit test:
    "fbo-generatemipmap-formats". Test creates a 2D texture with
    dimensions 293x277. It manually loops over all levels and calls
    glTexImage2D(). Level one triggers creation of full miptree:
    intel_alloc_texture_image_buffer() realizes that there is only one
    level in the miptree and calls intel_miptree_create_for_teximage()
    to re-allocate the miptree with all 9 levels. However, the end result
    is a miptree with level zero dimensions of 292x276.


I get: FAIL should draw with [255, 0, 0, 255]

(In reply to Topi Pohjolainen from comment #2)
> Right, upstream has a fix for this, test passes. If I revert:
> 
> commit ca84e190a446bbc29c3ef2864ba4ea5c7358a89a
> Author: Topi Pohjolainen <topi.pohjolainen@intel.com>
> Date:   Tue Nov 15 22:27:12 2016 +0200
> 
>     i965/miptree: Don't shrink textures when augmenting for more levels
>     
>     This was detected when examining CCS_E failures with piglit test:
>     "fbo-generatemipmap-formats". Test creates a 2D texture with
>     dimensions 293x277. It manually loops over all levels and calls
>     glTexImage2D(). Level one triggers creation of full miptree:
>     intel_alloc_texture_image_buffer() realizes that there is only one
>     level in the miptree and calls intel_miptree_create_for_teximage()
>     to re-allocate the miptree with all 9 levels. However, the end result
>     is a miptree with level zero dimensions of 292x276.
> 
> 
> I get: FAIL should draw with [255, 0, 0, 255]

The test still fails both on Iris Pro 6200 (Broadwell GT3e) and HD Graphics 530 (Skylake GT2) on ToT Mesa with the above patch. Could you help to verify it again?

This does fail for me, still.

Disabling the meta pbo TexSubImage path fixes the test.  Topi was replacing that anyway...I think he's just about done.

Oh, really odd. I just re-tried as well. And I still get the same results on my SKL. Current upstream passes but if I revert that one patch I get the failure I described.

I got worried I tested earlier with my tex upload rework branch. But no, just tried with current mesa master.

Any update here guys? Thanks.

Is there anything new here to try? Can this bug be closed Qiankun?

Tried with latest Mesa (fc9b119) and Chromium, the case still fails.

Maybe a 3rd engineer could try this and see what results?

Topi-Any thoughts on who else might be able to try to reproduce this failure?

I checked again with latest upstream and newer laptop of mine. I'm also able to reproduce using current upstream.

However, I also have native i965 path (based on blorp) for tex uploads. This doesn't suffer from the buggy meta path and passes the test. This is not upstreamed yet but can be found in:

git://people.freedesktop.org/~tpohjola/mesa:blorp_tex_upload

Topi-Is this still blocked by the flushing work?

Also now blocked by the "flushing" work Jason took over...

Since the flushing work seems to be upstreamed is there anything else blocking progress on this bug?

Is this still an open bug?

This should be. Even though flushing shortcomings have been addressed we still haven't switched over to blorp.

Should be fixed by

commit dffda6cbbbc1a8c2f7125db1b9cf15fbcdc8eb11
Author: Jason Ekstrand <jason.ekstrand@intel.com>
Date:   Tue Jun 6 09:58:07 2017 -0700

    i965: Use blorp instead of meta for PBO texture uploads
    
    Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

or some patch in that series at least.

I just verified the issue has been fixed with latest code (79d403417c). Thanks!