On Thu, Jun 23, 2011 at 10:38 AM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 23.06.2011 16:09, schrieb Jerome Glisse: >> On Wed, Jun 22, 2011 at 10:49 PM, Alex Deucher <alexdeuc...@gmail.com> wrote: >>> On Wed, Jun 22, 2011 at 10:12 PM, Roland Scheidegger <srol...@vmware.com> >>> wrote: >>>> Am 21.06.2011 20:59, schrieb Sven Arvidsson: >>>>> This change broke a whole lot of stuff on r600g, for example Unigine >>>>> Heaven: >>>>> >>>>> shader uses too many varying components (36 > 32) >>>> >>>> It looks like the r600g driver claims to only support 10 varyings, which >>>> the state tracker reduces to 8 (as it subtracts the supposedly included >>>> color varyings). >>>> At first sight I can't quite see why it's limited to 10, all r600 chips >>>> should be able to handle 32 (dx10 requirement) but of course the driver >>>> might not (mesa itself is limited to 16 it seems). If it worked just >>>> fine before that suggests it indeed works just fine with more... >>>> Someone more familiar with the driver should be able to tell if it's >>>> safe to increase the limit to 32 (the state tracker will cap it to 16). >>> >>> The hardware definitely supports 32. I'm not sure why it's currently >>> set to 10; I don't see any limitations in the code off hand. >>> >>> Alex >> >> IIRC it's just cut & paste from r300g it can be safely bump > > Ok Marek bumped it to 34. That seems to be lying too I don't think it > could handle 32 generic inputs and 2 colors. But there's no way to > really express that right now. > > Roland >
Also iirc r6xx/r7xx needs special code for handling varying over 16, can't remember if we had proper code for that. Cheers, Jerome _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
