|Summary:||arb_query_buffer_object expects type conversion on GPU reads|
|Product:||Mesa||Reporter:||Chris Wilson <chris>|
|Component:||Drivers/DRI/i965||Assignee:||Ian Romanick <idr>|
|Status:||RESOLVED MOVED||QA Contact:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|i915 platform:||i915 features:|
|Attachments:||arb_query_buffer_object: have_cpu_result is only accurate for 64bit reads|
Description Chris Wilson 2016-10-07 07:39:23 UTC
when reading a 64bit value through glGetQueryObjectiv() or glGetQueryObjectuiv() the result is truncated. This means that we can not use the result as an accurate value unless the full glGetQueryObjectui64v() is used - i.e. have_cpu_result should only be true when using GL_UNSIGNED_INT64_ARB datatypes.
Comment 1 Chris Wilson 2016-10-07 07:41:35 UTC
Created attachment 127084 [details] [review] arb_query_buffer_object: have_cpu_result is only accurate for 64bit reads
Comment 2 Nicolai Hähnle 2016-10-07 07:52:37 UTC
I disagree. OpenGL 4.5 (Compatibility Profile), page 48 (5th paragraph after the listing of GetQuery[Buffer]Object*) says: "If pname is QUERY_RESULT, then the query object’s result value is returned as a single integer. If the value is so large in magnitude that it cannot be represented with the requested type, then ***the nearest value*** representable using the requested type is returned." Furthermore, whether the value is saturated or truncated doesn't even matter for this particular part of the test. The real point is that GetQueryObject and GetQueryBufferObject must return the same result, because there is no part in the spec that allows for such a different: the query object result value is described in the spec as a piece of state, and those functions just return that piece of state.
Comment 3 Chris Wilson 2016-10-07 07:58:48 UTC
(In reply to Nicolai Hähnle from comment #2) > I disagree. OpenGL 4.5 (Compatibility Profile), page 48 (5th paragraph after > the listing of GetQuery[Buffer]Object*) says: > > "If pname is QUERY_RESULT, then the query object’s result value is returned > as a single integer. If the value is so large in magnitude that it cannot be > represented with the requested type, then ***the nearest value*** > representable using the requested type is returned." Which is what mesa does. > Furthermore, whether the value is saturated or truncated doesn't even matter > for this particular part of the test. The result from the CPU read is then used for an exact comparison with the full result read via the GPU. It matters.
Comment 4 Nicolai Hähnle 2016-10-07 08:12:57 UTC
The CPU and GPU reads should always be using the same type for the read. If they don't, then that's the bug.
Comment 5 Chris Wilson 2016-10-07 08:23:12 UTC
Ah, the GPU read does have the type information as well. Thanks.
Comment 6 GitLab Migration User 2019-09-25 18:58:27 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1543.