Summary: | 32-bit failures for spec.arb_compute_shader.execution.atomic-counter | ||
---|---|---|---|
Product: | Mesa | Reporter: | Mark Janes <mark.a.janes> |
Component: | Drivers/DRI/i965 | Assignee: | Jordan Justen <jljusten> |
Status: | RESOLVED DUPLICATE | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | currojerez |
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Mark Janes
2016-05-31 21:39:36 UTC
tests/spec/arb_compute_shader/execution/atomic-counter.shader_test uses atomic_uint, which should be a 32-bit value on 64-bit processes as well. The test has a uint atomic counter that starts at 0, and gets decremented 512 times. Does this test have a similar failure? tests/spec/arb_shader_atomic_counters/execution/atomic-counter.shader_test https://www.opengl.org/registry/specs/ARB/shader_atomic_counters.txt says "Increments and decrements at the limit of the range will wrap to [0, 2^32-1]", so I think the test is valid. The shader_runner code looks valid for treating the buffer as a uint32_t pointer. I don't see any failures from that shader test. Sorry. I guess that was a test that I made when adding shader_runner atomic counter support, but I didn't send it to piglit. I added it in my freedesktop.org piglit repo atomic-fs 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.