----- Original Message ----- > On Tue, Jul 03, 2012 at 12:39:47PM -0700, Jose Fonseca wrote: > > Note that all registers are stored as floats (for convenience, and > > because LLVM has no unions), so integers are bitcasted into floats > > while storing/loading. And I'm not sure if your patch would break > > that. > > I did test the patch with a llvmpipe in a glsl 120/no native integer > setup. draw_instanced worked. I didn't try a full piglit though. > > > > I still think that having draw/gallivm guessing whether native > > integer support is intended or not is bad. Either: > > 1) TGSI is extended (e.g., more type annotations) so that > > native-integer support can inferred from it > > 2) draw/gallivm need to now if the driver has native-integer or not > > > > I'm inclined towards 1), as TGSI should be self-documented. That > > is, > > it should not be necessary to know if the driver has or not native > > integer support to know whether system values should be assumed to > > be integers or floats... > > It could be argued that dtype being TGSI_TYPE_FLOAT is the > documentation on what is expected. But I'm quickly reaching the > point > where I don't really care, just tell me what you want. As long as > textureFetch stays the only issue between llvmpipe and 1.30 I'm ok.
hmm.. I don't think you and I are on the same wave length here. I don't want to tell you what to do, as I haven't figured that out myself either. What I'd want is for you to help me understand the issue better, because I got the feeling that something is broken in the gallium/draw interfaces in regard to this, but I don't have the time to investigate this in detail, and make my own mind. If you would describe the problem in detail (e.g, paste snippets of the TGSI and respective IR), I'd appreciate it. If you can't be bothered, no biggie. As long as your patch fixes something and does not break anything, I'm happy to commit it as is. Just confirm that there are no piglit regressions in other tests that exercise integer opcodes. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
