[Mesa-dev] [Bug 90081] [llvmpipe] piglit ext_transform_feedback-immediate-reuse-uniform-buffer regression

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90081

--- Comment #1 from Roland Scheidegger <sroland at vmware.com> ---
Ah yes I actually knew about that but didn't consider it all that important.
The reason is that the code was already buggy and this change just exposed the
bug.

In short here's what happens:
- the transform feedback buffer is only 4 bytes, which is later bound as
constant buffer
- constant buffers are expected to be in multiples of 16 bytes (as the contents
are vec4 elements), thus the size is considered to be zero by (llvm) draw (and
would be the same for llvmpipe fragment shaders as well).

Before this change, this worked because we do not verify that an access to a
buffer constant is within range of the buffer, IFF the access is done via an
immediate (so, indirect access would always have returned zero even with the
old code). This is in fact not very safe (I've got some quickly hacked up
piglit test which tries to cause a crash but didn't manage really more than
valgrind warnings). This did not change (though I think it probably will in the
future), however for simplified shader code we now bind (1-element sized) fake
buffers explicitly if the buffer size is zero (this was actually trivial to
crash before just don't bind a constant buffer then any attempt at constant
buffer lookup would have produced a nice clean null pointer dereference).

I don't have time to fix these issues though for now. Well the one not
verifying accesses outside of range ought to be easy but doesn't help this
case, but the bug causing one I'm actually not quite sure HOW it should be
fixed. Since it is not really ok to bind 4-byte sized buffers as a constant
buffer which thus could be considered a state tracker bug but I'm not sure if
it actually could do much about it. Of course could be easily hacked up in draw
so the test passes again (could only use fake buffer if size is 0 before the
divide by 16 for instance) but it wouldn't really serve much purpose, I'd
rather have it fail so the issue doesn't get lost completely.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150418/2d205602/attachment.html>