I just realized that the state tracker will degrade this to 16 attribs anyway (looks like mesa can only handle 16 generic attribs). So, I suppose it's pretty much untested and not all that helpful...
Roland Am 01.01.2018 um 03:11 schrieb srol...@vmware.com: > From: Roland Scheidegger <srol...@vmware.com> > > Evergreen clearly has 32 slots, so it should just work (and the affected array > is already sized with PIPE_MAX_ATTRIB). > Note: As dx10.1 chips, r600/r700 should support this too, but seemingly > there's > only 16 resource slots for fetch shaders (fs). However, a quick looks seems to > suggest the fs slots are actually shared with vs and not separate (as the > fetch > shader uses a offset of 160 on these chips), therefore (we're not even close > to using all vs slots) just using different offsets might work, but I cannot > verify this. > > No piglit change. > --- > src/gallium/drivers/r600/r600_pipe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/r600/r600_pipe.c > b/src/gallium/drivers/r600/r600_pipe.c > index 2583c719a3..c294973e8b 100644 > --- a/src/gallium/drivers/r600/r600_pipe.c > +++ b/src/gallium/drivers/r600/r600_pipe.c > @@ -559,7 +559,7 @@ static int r600_get_shader_param(struct pipe_screen* > pscreen, > case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH: > return 32; > case PIPE_SHADER_CAP_MAX_INPUTS: > - return shader == PIPE_SHADER_VERTEX ? 16 : 32; > + return shader == PIPE_SHADER_VERTEX ? (rscreen->b.family >= > CHIP_CEDAR ? 32 : 16) : 32; > case PIPE_SHADER_CAP_MAX_OUTPUTS: > return shader == PIPE_SHADER_FRAGMENT ? 8 : 32; > case PIPE_SHADER_CAP_MAX_TEMPS: > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
