| Summary: | piglit ext_transform_feedback-change-size offset-grow regression | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Vinson Lee <vlee> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | zackr |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Unfortunately, this is not a regression. We were over overflowing without the patch, now we're simply correctly computing the overflow.
Mesa's transformfeedback.c:compute_transform_feedback_buffer_sizes
incorrectly computes size for gallium's so targets: in particular it does:
GLsizeiptr available_space
= buffer_size <= offset ? 0 : buffer_size - offset;
computed_size = available_space;
and returns that as the size of the buffer. Then when setting gallium stream output targets it sets the computed_size as the new buffer size and
then it also sets the same offset it used when computing the computed_size. So essentially for gallium:
buffer_size = buffer_size - offset
offset = offset
which means that gallium's stream output target's buffer size is always 'offset' less than it should be. I'm not going to have time to fix this right now..
Actually I was wrong, gallium lies about the naming of the buffer_size variable, it's actually available_space. Patch sent for a review. mesa: f3bbf65929e395360e5565d08d015977dd5b79fa (master) piglit ext_transform_feedback-change-size offset-grow now passes with latest master. |
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.
mesa: 573d8813fdbb116f4500d2044c56d80aab73ab7f (master) $ ./bin/ext_transform_feedback-change-size offset-grow -auto PRIMITIVES_WRITTEN: expected=2, actual=1 data[0]: expected=-1.000000, actual=-1.000000 data[1]: expected=-1.000000, actual=-1.000000 data[2]: expected=-1.000000, actual=-1.000000 data[3]: expected=101.000000, actual=101.000000 data[4]: expected=102.000000, actual=102.000000 data[5]: expected=103.000000, actual=103.000000 data[6]: expected=104.000000, actual=-1.000000 data[7]: expected=105.000000, actual=-1.000000 data[8]: expected=106.000000, actual=-1.000000 data[9]: expected=-1.000000, actual=-1.000000 PIGLIT: {'result': 'fail' } 53d36d5fb09cda39c8d3646cbccbd343b34bfb54 is the first bad commit commit 53d36d5fb09cda39c8d3646cbccbd343b34bfb54 Author: Zack Rusin <zackr@vmware.com> Date: Tue Apr 23 18:56:47 2013 -0400 draw/so: Fix overflow calculations We weren't taking the buffer offset, destination offset or the stride into consideration so we were frequently writing into an overflown buffer. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: José Fonseca <jfonseca@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> :040000 040000 72bbc0b1c2b6295a3ef7cc74bfac173d542ac4e0 7393f146148f10efa422cbb76658f2b6b6df65d9 M src bisect run success