Bug 94037 - [Gallium] glGetQueryObject with GL_ANY_SAMPLES_PASSED returns the same as with GL_SAMPLES_PASSED
Summary: [Gallium] glGetQueryObject with GL_ANY_SAMPLES_PASSED returns the same as wit...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-07 22:33 UTC by peter.fiss
Modified: 2016-02-08 10:45 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
Source code of the test program. Needs SDL2 to build. It shows a red background if the describes bug exists. (41.05 KB, text/plain)
2016-02-07 22:33 UTC, peter.fiss 		Details
View All

Description peter.fiss 2016-02-07 22:33:18 UTC 
Created attachment 121579 [details]
Source code of the test program. Needs SDL2 to build. It shows a red background if the describes bug exists.

The OpenGL-Wiki says, the function should return "GL_FALSE if none of the scoped drawing commands generate samples that pass the depth test; otherwise, the value is GL_TRUE". Source: https://www.opengl.org/wiki/Query_Object

When calling glGetQueryObjecti64v on r600 or nouveau (probably on any gallium driver) however, it returns the number of samples which passed the depth test. This would be correct behaviour if the argument was GL_SAMPLES_PASSED instead of GL_ANY_SAMPLES_PASSED.

I have attached the source code of a simple example program. It worked correctly on the following platforms:
- Arch Linux with Intel Ivy Bridge graphics (Mesa 11.1.1-1)
- Windows 7 with the same Intel graphics
- Windows 7 with Nvidia GeForce GT 640M
- Windows 7 with ATI Radeon HD 5670

It showed incorrect behaviour on these systems:
- Arch Linux with Nouveau and GeForce GT 640M (Mesa 11.1.1-1)
- Manjaro with r600 and Radeon HD 5670 (Mesa 11.1.1-1)

Note that the bugtracker does not allow me to specify 11.1 as mesa version.
Comment 1 Ilia Mirkin 2016-02-07 22:46:53 UTC 
This should have been (semi-accidentally) fixed in commit 

https://cgit.freedesktop.org/mesa/mesa/commit/?id=386a9ec77b7113c1e0c29c30b981a50175ac16e8

which refactored a lot of that code, and will be fixed even harder once my recent series cleaning this up lands:

https://patchwork.freedesktop.org/series/3163/

note that the issue only applied to the 64-bit getters. Both of the 32-bit getters did force the value to be true/false.

Long story short, try mesa-git, the problem should go away.
Comment 2 peter.fiss 2016-02-07 23:27:36 UTC 
Thanks for the quick answer. I'm going to try mesa-git on my Manjaro machine, but it looks like it will take a while until llvm-svn and mesa-git are compiled and installed.
Comment 3 Ilia Mirkin 2016-02-07 23:35:37 UTC 
(In reply to peter.fiss from comment #2)
> Thanks for the quick answer. I'm going to try mesa-git on my Manjaro
> machine, but it looks like it will take a while until llvm-svn and mesa-git
> are compiled and installed.

You should be fine with your system llvm (or no llvm at all, unless you're using radeonsi or are testing llvmpipe).
Comment 4 peter.fiss 2016-02-08 09:53:47 UTC 
I needed to install llvm-svn, because it was a dependency of mesa-git from the Arch User Repository. As a non-mesa-dev this seemed to be the easiest way for me to get mesa-git to work.

Anyway, I can confirm that the bug is fixed in mesa-git. Thanks for your help and for the excellent response time!

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.