[Bug 89597] Implement SSBOs in GLSL front-end and i965

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jun 10 05:07:49 PDT 2015


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

--- Comment #61 from Francisco Jerez <currojerez at riseup.net> ---
(In reply to Samuel Iglesias from comment #60)
> Francisco, I have a question for you related to untyped write messages
> source code:
> 
> Today, I have been rebasing our SSBO patch series to master, finding that FS
> builder was already pushed upstream and a lot of code was migrated to use
> it. I found a crash that is related to one of the patches we picked from you
> some time ago that emits untyped write messages. This is the problem:
> 
> When processing nir_intrinsic_store_ssbo in brw_fs_nir.cpp, there is a call
> to
> surface_access::emit_untyped_write() which ends up internally calling to
> emit_header().
>     
> The function emit_header() (in
> src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp)
> copies the sample mask to the header register:
>     
>        exec_all(ubld.MOV(component(dst, 7), sample_mask));
>     
> This MOV fails the following assert in function emit(instruction *inst) at
> src/mesa/drivers/dri/i965/brw_fs_builder.h:
>     
>     assert(inst->exec_size == dispatch_width() || force_writemask_all);
>    
> According to GDB, those variables have the following values:
>     
>     * inst->exec_size = 1
>     * dispatch_width() = 8
>     * force_writemask_all = 0
>     
> Removing this assert makes the code to work properly but I wonder if we need
> to update our code in some way or if you have already a fix for this.
> 
> If you want to test it, I have published a branch which includes the assert
> deletion in the last commit:
> 
> $ git clone -b wip/siglesias/ARB_shader_storage_buffer_object-v2.3
> https://github.com/Igalia/mesa.git
> 
> You can run the following piglit test to reproduce the crash, if you revert
> last commit:
> 
> $ bin/arb_shader_storage_buffer_object-layout-std140-write-shader -fbo -auto

Ah, yeah, that's because the way channel enable masking is handled has changed
since I sent you that branch.  Instead of the exec_all() function there's now
an exec_all() method in the builder you need to call to get the same effect. 
I've rebased your branch on top of the latest builder changes (including some
changes in the VEC4 builder which is not upstream yet), see the for-samuel
branch of my mesa tree:

git://people.freedesktop.org/~currojerez/mesa

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150610/1bcd27ff/attachment.html>


More information about the intel-3d-bugs mailing list