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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #20 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Kristian Høgsberg from comment #19)
> (In reply to Iago Toral from comment #18)
> > Jason, I think I got it working for SIMD8 but I have a question regarding
> > SIMD16:
> > 
> > > (In reply to Jason Ekstrand from comment #16)
> > > > I think you are misunderstanding how these SIMD8/16 write messages work. 
> > > > I'll assume 8 in the following discussion but it all applies to 16.
> > > > 
> > > > As the shader executes, it is executes 8 pixels at a time.  Each
> > > > sub-register represents the same symbolic value in GLSL but for a different
> > > > pixel.  Suppose I have an SSBO declared as follows:
> > > > 
> > > > buffer Block {
> > > >     vec4 s[128];
> > > > };
> > > > 
> > > > And suppose I execute the line of code "s[i].xzw = foo;" where foo is some
> > > > vec3.  When the SIMD8 shader reaches this line, it stores 12 values in the
> > > > SSBO; 3 per pixel.  If the client doesn't want the values to stomp on each
> > > > other, it is up to the client to ensure that i is different for each pixel.
> > > > 
> > > > How does this work with the scattered read/write messages?  They are
> > > > designed for exactly a case like this.  When you get to this statement, you
> > > > will have one register that holds the value of i and three more for foo. 
> > > > Each of these registers has 8 sub-registers one for each SIMD channel (or
> > > > pixel).
> > 
> > In SIMD16 the instructions operate on 16 elements, but I understand that
> > registers still have 8 sub-registers, so this instruction:
> > 
> > mov(16)   g116<1>F     1.0F                { align1 1H };
> > 
> > is writing 1.0 in all sub-registers of g116 (8 elements) and all
> > sub-registers of g117 (8 elements). Is this correct? If I am correct, then I
> > would expect this assembly code for a SIMD16 scattered write to work:
> > 
> > mov(8)    g113<1>UD    g0<8,8,1>UD         { align1 WE_all 1Q compacted };
> > mov(1)    g113.2<1>UD  0x00000000UD        { align1 WE_all compacted };
> > mov(16)   g114<1>UD    g13<8,8,1>UD        { align1 1H compacted };
> > mov(16)   g116<1>F     1.0F                { align1 1H };
> > send(16)  g0<1>F       g113<8,8,1>F
> >         data ( DC DWORD scatterd write, 1, 3) mlen 5 rlen 0 { align1 1H };
> > 
> > The first mov(16) would write the offset payload to M1,M2 (g114,g115) and
> > the second mov(16) would write the data payload to M3,M4 (g116,g117).
> > However, I see that this does not produce correct writes into the buffer, I
> > see writes to the correct offsets but with wrong data, so I guess I am
> > understanding something wrong again?.
> > 
> > For the record, this same code works fine if I make the second mov(16) write
> > to g115 (like I do in SIMD8, where we want offsets in M1 and data in M2),
> > but as far as my understanding goes, this should actually be incorrect for
> > SIMD16.
> > 
> > > > All you should have to do is build 3 messages each one of which is
> > > > i + some math for the address part and a component of foo for the payload
> > > > part.  Each scattered write writes 8 values but they are the different
> > > > values from the different SIMD channels, not from different components of
> > > > foo.  The first one will write all 8 of the s[i].x, the next one s[i].y, etc.
> 
> Are you setting the block size in the message descriptor?
> 
> Bits 9:8 should be
> 
>   10: 8 DWords
>   11: 16 DWords

Yes, I think this is most likely the problem. We actually have a nice #define
for this.  You can see it in use in my wip/fs-indirects-v0.5 branch in this
commit:

http://cgit.freedesktop.org/~jekstrand/mesa/commit/?h=wip/fs-indirects-v0.5&id=df4293526f873102b45dd89dc20b084bc8662181

In fact, feel free to just cherry-pick that if you think it's what you want. 
It also handles setting the right opcode for the different gens.

-- 
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/20150417/876df3db/attachment.html>