Bug 98923 - Texture size changes after updating texture with TexSubImage3D from pixel buffer
Summary: Texture size changes after updating texture with TexSubImage3D from pixel buffer
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-01 08:50 UTC by Qiankun Miao
Modified: 2017-10-13 08:26 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Qiankun Miao 2016-12-01 08:50:57 UTC
TexSubImage3D is buggy when updating texture data from pixel buffer on Linux + Mesa + Skylake. Size of the texture changes after updating data with TexSubImage3D from pixel buffer.
Steps to reproduce:
1. download chrome from https://www.google.com/chrome/browser/desktop/ or use latest chrome in your linux distribution
2. un chrome --enable-unsafe-es3-apis --ignore-gpu-blacklist 
3. open url: https://www.khronos.org/registry/webgl/sdk/tests/conformance2/textures/misc/tex-subimage3d-pixel-buffer-bug.html?webglVersion=2
4. All tests should pass.
5. You will see failure in the page.

This happens on Linux with Mesa 11.0 and 13.0, not on other GPU vendor or Windows and Mac.

Also see chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=666384
Comment 1 Kenneth Graunke 2016-12-01 18:07:24 UTC
CC'ing Topi.

Topi, this sounds an awful lot like bugs you've fixed lately.  Thoughts?
Comment 2 Topi Pohjolainen 2016-12-01 22:39:29 UTC
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]
Comment 3 Qiankun Miao 2016-12-05 01:59:11 UTC
(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?
Comment 4 Kenneth Graunke 2016-12-05 06:14:27 UTC
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.
Comment 5 Topi Pohjolainen 2016-12-05 07:38:12 UTC
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.
Comment 6 Annie 2017-01-23 23:47:39 UTC
Any update here guys? Thanks.
Comment 7 Annie 2017-02-13 06:06:05 UTC
Is there anything new here to try? Can this bug be closed Qiankun?
Comment 8 Yang Gu 2017-02-15 12:02:08 UTC
Tried with latest Mesa (fc9b119) and Chromium, the case still fails.
Comment 9 Annie 2017-03-09 01:41:58 UTC
Maybe a 3rd engineer could try this and see what results?
Comment 10 Annie 2017-03-24 19:21:50 UTC
Topi-Any thoughts on who else might be able to try to reproduce this failure?
Comment 11 Topi Pohjolainen 2017-04-13 07:26:16 UTC
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
Comment 12 Annie 2017-04-28 01:15:43 UTC
Topi-Is this still blocked by the flushing work?
Comment 13 Annie 2017-06-12 19:22:06 UTC
Also now blocked by the "flushing" work Jason took over...
Comment 14 Annie 2017-07-13 18:16:24 UTC
Since the flushing work seems to be upstreamed is there anything else blocking progress on this bug?
Comment 15 Annie 2017-08-24 22:19:01 UTC
Is this still an open bug?
Comment 16 Topi Pohjolainen 2017-08-25 06:40:59 UTC
This should be. Even though flushing shortcomings have been addressed we still haven't switched over to blorp.
Comment 17 Kenneth Graunke 2017-10-13 06:35:05 UTC
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.
Comment 18 Yang Gu 2017-10-13 08:26:42 UTC
I just verified the issue has been fixed with latest code (79d403417c). Thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.