On Wed, Mar 25, 2015 at 4:44 PM, Tom Stellard <t...@stellard.net> wrote: > On Wed, Mar 25, 2015 at 04:35:03PM -0400, Ilia Mirkin wrote: >> On Wed, Mar 25, 2015 at 4:27 PM, Dave Airlie <airl...@gmail.com> wrote: >> > On 26 March 2015 at 06:07, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> >> So.... what do you do when someone goes to shadertoy.com which on >> >> average uses 1000 temps? >> > >> > Fall over in a heap, like every other driver on shadertoy, >> >> nouveau (nv50/nvc0) tends to do pretty well. There's one particular >> shader that ends up being shifted over for reasons unknown, but no >> compilation failures. i965 tends to do OK too, although I've seen >> weird rendering artifacts, although those could well be due to the >> shaders relying on unspecified behaviour. >> >> > >> > This would be raelly bad for r600g in its present state, since it >> > doesn't go TGSI->SB yet, and thus has a TEMP limit that this would >> > only make worse. >> >> D'oh, right, r600 relies on there being no more than 124 or 128 >> registers. Forgot about that. >> >> > >> > so Nak from me. >> > >> > Dave. >> >> So I suppose you want to fix the copy_propagation issue? :) >> > > Can you add a flag for drivers to disable it?
Well, the present reality is that the pass is broken. I was hoping that simply disabling it would be an acceptable fix for the issue, but it sounds like there are still a few use-cases that want it around. I think that reducing the amount of different TGSI output that st/mesa can produce would be best, so I'd rather explore other options before making it an optional pass. Even if I make it optional for nouveau, it'll still break code when feeding to r600/etc... -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
