<div class="gmail_quote">On Sun, Aug 1, 2010 at 7:27 PM, Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On Sat, 31 Jul 2010 20:32:29 +0200, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote: > Also program_parse.tab.c has been regenerated. > > This fixes the parser error: > > ARB_vp: error: relative address offset too large > > See also: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=28628" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=28628</a> > > 4096 * sizeof(vec4) is the maximum size of the constant buffer on NV50, > so it is a reasonable limit, at least for now. > (should there be any limit at all?) > > Piglit: vp-arl-constant-array-huge-relative-offset </div>The limit comes from: (26) What limits should be imposed on the constants that can be added to or subtracted from the address register for relative addressing? Negative offsets are sometimes useful for shifting down in an array. RESOLVED: -64 to +63 should be sufficient for the time being. Offset sizes are limited to allow offsets to be baked into device-dependent instruction encodings. so wine is really being nonportable here and should handle it itself, but I'm fine with just removing the limits in the core and letting the drivers complain if they can't be supported.</blockquote><div> OK. The thing is proprietary drivers allow much larger offsets than -64/+63. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 4096 doesn't make sense as a limit, as constant buffer size limits should already be expressed through MAX_PROGRAM_PARAMETERS_ARB. </blockquote></div> It is not supposed to be a definite hardware limit, it is just large enough for it not to get in the way. -Marek