<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Implement SSBOs in GLSL front-end and i965" href="https://bugs.freedesktop.org/show_bug.cgi?id=89597#c19">Comment # 19</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Implement SSBOs in GLSL front-end and i965" href="https://bugs.freedesktop.org/show_bug.cgi?id=89597">bug 89597</a> from <a class="email" href="mailto:krh@bitplanet.net" title="Kristian Høgsberg <krh@bitplanet.net>"> Kristian Høgsberg</a> <pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=89597#c18">comment #18</a>) > Jason, I think I got it working for SIMD8 but I have a question regarding > SIMD16: > > > (In reply to Jason Ekstrand from <a href="show_bug.cgi?id=89597#c16">comment #16</a>) > > > 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</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>