----- Original Message ----- > On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca <jfons...@vmware.com> > wrote: > > Marek, > > > > I think we should take one of two approaches here: > > - aim for a short-term workaround, without gallium interface > > changes: > > - e.g., provide to GLSL compiler infinite/huge limits, while > > advertising to the app the pipe driver ones > > - or detect the wine process and advertise bigger limits in the > > r300 driver > > - aim for accurately describing the pipe driver compiling abilities > > - e.g., allow the state tracker to create shaders that exceed > > abilities, and force a trial generation and compilation of the > > TGSI shaders when the GLSL shader is first linked > > > > But the hard limit caps interface change you propose below doesn't > > quite align to neither approach: it is an interface change which > > doesn't truly help describing the pipe driver compiler abilities > > any better (the actual maximum constants/inputs depends on the > > shader and is not a global constant), so it merely provides a > > short term relief. > > I would gladly commit this patch: > [...]
Isn't there anything equally easy that can be done without touching src/glsl/*? > Now seriously. I do really care about users. And I'd like to release > a > product which works best for them. I understand. And I agree that on this particular case this is an intolerable regression for the users concerned. However, I don't think that Ian doesn't care about users, but rather that not following the spec is more harmful to the users on the long term. And, given he's one of the main GLSL author/maintainer that carries weight on my book, as far as that sub-component is concerned. Anyway, I don't see any need for us to clash against each others: all Mesa developers have and will always have different goals, schedules, and external pressures; but it should be possible to share the same code between all drivers without having to share the same policy. GLSL is a sub-component among others. Surely it must be possible to accommodate both a strict enforcement of max uniforms on Intel drivers, and a more lenient enforcement on another drivers. So instead of trying to decide who's right, let's just focus our energy into finding that flexible solution. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
