Am 09.08.2014 17:25, schrieb Ilia Mirkin: > On Sat, Aug 9, 2014 at 11:12 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 09.08.2014 16:33, schrieb Ilia Mirkin: >>> On Sat, Aug 9, 2014 at 10:14 AM, Roland Scheidegger <srol...@vmware.com> >>> wrote: >>>> On closer look, it looks to me like it wouldn't be all that difficult to >>>> make proper sampler array dcls (as you apparently get them quite easily >>> >>> If you can briefly outline how you think that should be done, I'd be >>> happy to try to do it. Right now the samplers are declared in >>> st_translate_program, which only has the program->samplers_used >>> bitfield (where program is glsl_to_tgsi_visitor). >>> >>> One quick thing that occurs to me is to keep track of samplers in a >>> map of index -> array size (0 if it's not accessed indirectly or not >>> an array), and then using the map to create the declarations. Does >>> that seem reasonable? >>> >> Well I didn't think about it that much but nothing is stopping you from >> putting whatever you need into the glsl_to_tgsi_visitor to keep that >> array information instead of just filling out samplers_used. >> >>> Either way, this seems like a nice-to-have rather than required, so >>> I'm going to push this patch even if the other one isn't ready. >> Agreed. The address thingy is also something which should go away as >> discussed but really separate issue too. >> btw you get the actual sampler type from the constant in the sampler reg >> right? So if you have >> 4: TEX TEMP[1], TEMP[1], SAMP[ADDR[2].x+1], 2D >> that +1 in there says the 2nd declared sampler determines what kind of >> sampler this is (2d, 3d, shadow...). > > From what I can tell, samplers (in TGSI) have no attached semantics... Yeah you're right. All comes from textures (though it is sort of the same).
> they're just an index into an array that you're promised was set up > correctly beforehand. For emitting the instructions, we look at the 2D > from the tex instruction. > > BTW, I have a follow-up patch that I'll send shortly which generates > > FRAG > PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1 > DCL IN[0], GENERIC[0], PERSPECTIVE > DCL OUT[0], COLOR > DCL SAMP[0] > DCL SAMP[1..3] > DCL CONST[4] > DCL TEMP[0..1], LOCAL > DCL ADDR[0..2] > IMM[0] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} > 0: MOV TEMP[0].xy, IN[0].xyyy > 1: TEX TEMP[0], TEMP[0], SAMP[0], 2D > 2: MOV TEMP[1].xy, IN[0].xyyy > 3: UARL ADDR[2].x, CONST[4].xxxx > 4: TEX TEMP[1], TEMP[1], SAMP[ADDR[2].x+1], 2D > 5: MAD TEMP[0], TEMP[0], IMM[0].xxxx, TEMP[1] > 6: MOV OUT[0], TEMP[0] > 7: END > > Is that what you had in mind? > That looks good to me. Would something like SAMP[ADDR[2].x+2] be illegal with the above sampler declaration? Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev