On Tue, Nov 22, 2011 at 6:04 PM, Jose Fonseca <jfons...@vmware.com> wrote: > ----- 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/*?
I don't think so. From the looks of it, drivers don't even get to see any shader the linker rejects. I guess it would be cleaner to have boolean flags SkipVaryingLimitChecking and SkipUniformLimitChecking in gl_constants and changing the linker to read those flags. Does that sound like a good idea? > >> 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. Sorry, I didn't mean to offend anybody. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
