[Bug 105351] [Gen6+] piglit's arb_shader_image_load_store-host-mem-barrier fails with a glGetTexSubImage fallback path

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Francisco Jerez <currojerez at riseup.net> ---
(In reply to Andriy Khulap from comment #4)
> Actually intel_get_tex_sub_image() is called 3 times: 2 times during test
> initialization (source datas are float 0 1 0 1 and all floats 66) and once
> when checking the results (source data is half red - half green).
> Destination addresses for these 3 calls all different.
> 
Yeah, but the textures downloaded by those are temporaries which aren't
accessed by image load/store either.

> Modifying test to do Write-Read-Write (instead of Write-Write) solving the
> issue.
> Write-Write-Write still fails.
> 
> P.S. these results are for "fallback" path with intel_gettexsubimage_blorp
> returning false.

>From playing around with the test a bit I believe the corruption is caused by
glBufferSubData() unexpectedly taking the unsynchronized path when
intel_gettexsubimage_blorp() hasn't been used earlier -- Other than that the
glGetTexSubImage path taken doesn't seem to have any influence on the result. 
The reason why glBufferSubData() is taking the unsynchronized path as a side
effect even though the BO is busy is because image surface setup isn't using
the intel_bufferobj_buffer() wrapper to get the BO pointer, which updates
intel_buffer_object::gpu_active_start/end used by glBufferSubData() to decide
whether to take the unsynchronized path.  The attached patch should address
that (along with a few more issues I found while looking into this).

-- 
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: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20180317/19be156b/attachment.html>