On 04/06/15 20:36, Rob Clark wrote:
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. ;-)
So does my counter-point: if it's OK to add readily available upstream
information to TGSI for downstream convenience, it should also be OK to
add readily available upstream information to NIR for downstream
convenience.
In short, why not add this info to NIR's declarations?
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.
Not really, as the sort bugs I'm worried is driver's TGSI translation,
not TGSI internal inconsistency. In particular, drivers like llvmpipe,
that need support both cases, having bugs due to that.
It's also bad for new drivers developers -- it's not clear if/which
parts of TGSI to support.
Take also drivers that want to spew D3D10 shaders / GLSL on the other
side -- they too could benefit of having this info in the shader decls.
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..
If you don't want to add SVIEW decls fine. Let's add the type to the TEX
declaration then. It's a least a steap in that direction.
But I'm afraid can't really endorse having two places in TGSI for this..
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
