On Thu, Jun 4, 2015 at 3:22 PM, Rob Clark <robdcl...@gmail.com> wrote: > On Thu, Jun 4, 2015 at 3:11 PM, Jose Fonseca <jfons...@vmware.com> wrote: >> On 04/06/15 19:50, Rob Clark wrote: >>> >>> On Thu, Jun 4, 2015 at 2:14 PM, Jose Fonseca <jfons...@vmware.com> wrote: >>>> >>>> I think we had a discussion about this on mesa3d-dev a while ago. I >>>> don't >>>> recall the conclusions but I wish I did. >>>> >>>> We have tgsi_return_type. Why isn't this enough? Or better, why isn't >>>> being used for this? >>> >>> >>> mostly arbitrary reasons.. the unorm/snorm values don't really make >>> sense here, so it didn't quite seem to fit (plus would have needed >>> another bit, although I guess that isn't really an issue) >>> >>> Or if the question was, why not include the type information in the >>> decl rather than the instr? Well.. that at least is more awkward for >>> the implementation, since the information is part of the instruction >>> for both GLSL IR and NIR (and at the end of the day, that is also >>> where I need the info in my compiler) >> >> >> IIUC, GLSL also has this information readily available in the sampler >> declaration: >> >> uniform sampler2D ftex; >> uniform isampler2D itex; >> uniform usampler2D utex; >> >> So isn't this a double standard? After all, if the argument here is >> >> "GLSL IR / NIR has this info readily available, so let's pass it to the >> TGSI", >> >> then the same rationale should apply to >> >> "GLSL has this info readily available on the sampler declaration, so lets' >> pass it to GLSL IR/NIR 's declarations." >> > > ok, possibly GLSL IR has this info also in the decl.. tbh I'm not a > GLSL IR expert. I just figured out my way around since I know where I > want the info in NIR, and then looked at where it came from in > glsl_to_nir. > > But at any rate, NIR only has it on the tex instruction. So my point > about having it in the decl making it more akward for tgsi-to-nir and > my compiler still stands. ;-) > >> >> I want to avoid having two places for this info in TGSI: in decl and in >> instruction, as that's a recipe for bugs and complexity. _Specially_ when >> the decl is imposed for D3D10 support, while the inst is mere a matter of >> internal Mesa convention... >> > > having the information duplicated (or at least in the instruction) is > more convenient for the consumer of tgsi. If you are worried about > bugs/inconsistencies then something similar to nir_validate_shader() > for tgsi would have seemed like a better direction. > > BR, > -R > >> >> In short, I'm fine in in principle with piping this info through, but lets >> come up a decent generalization. In particular, lets try get this in the >> decls so it's consistent.
oh, hmm, the sampler-view thing looks like a rather longer path to get what I need.. since it isn't even used currently.. BR, -R >> >> >> Jose >> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
