Bug 93110 - [NVE4] textureSize() and textureQueryLevels() uses a texture bound during the previous draw call
Summary: [NVE4] textureSize() and textureQueryLevels() uses a texture bound during the...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: 11.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-26 00:38 UTC by Józef Kucia
Modified: 2015-11-27 22:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
A small program to demonstrate the issue (10.70 KB, text/plain)
2015-11-26 00:38 UTC, Józef Kucia 		Details
View All

Description Józef Kucia 2015-11-26 00:38:15 UTC 
Created attachment 120124 [details]
A small program to demonstrate the issue

It seems that a texture bound in the previous draw call is used by textureSize() and textureQueryLevels() (instead of the currently bound texture).

The attached program demonstrated the bug. When the program is built with -DBROKEN, it incorrectly prints "width: 2.000000 height 2.000000 miplevels 2.000000" while the current texture is 512x256 with 4 miplevels.

OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVE4
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.0.5
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1) (prog-if 00 [VGA controller])
Comment 1 Józef Kucia 2015-11-26 08:09:21 UTC 
It works correctly in 11.2.0-devel (git-63b49e1). I guess it was fixed meanwhile.
Comment 2 Ilia Mirkin 2015-11-27 22:03:20 UTC 
I did a reverse-bisect, and found this is what fixed it:

commit 5877a594d54fdd2b3aa329f4d35b3491a7ee8a33
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Thu Sep 10 23:58:17 2015 -0400

    nvc0/ir: start offset at texBindBase for txq, like regular texturing
    
    Curiously this has no actual effect. I think it's because the first 8
    textures are bound in multiple slots for some reason. However seems
    prudent to use these the same way as regular texturing, esp in the case
    where there are more than 8 textures bound.
    
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

I really couldn't find an effect that it practically had at the time. I could spend time thinking about what the difference is, but... I'm insufficiently interested. I'll ask for a cherry-pick to the 11.0 branch.

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.