AFAIK, there are 16 fetch shader resources. These are the resource slots for r600:
[offset .. +count] PS: 0 .. +160 VS: 160 .. +160 FS: 320 .. +16 GS: 336 .. +160 Marek On Thu, May 2, 2013 at 5:04 PM, Vadim Girlin <vadimgir...@gmail.com> wrote: > On 05/02/2013 11:06 AM, Michel Dänzer wrote: >> >> On Don, 2013-05-02 at 05:45 +0200, Marek Olšák wrote: >>> >>> --- >>> src/gallium/drivers/radeonsi/radeonsi_pipe.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c >>> b/src/gallium/drivers/radeonsi/radeonsi_pipe.c >>> index c923c67..3b9be54 100644 >>> --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c >>> +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c >>> @@ -481,7 +481,7 @@ static int r600_get_shader_param(struct pipe_screen* >>> pscreen, unsigned shader, e >>> case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH: >>> return 32; >>> case PIPE_SHADER_CAP_MAX_INPUTS: >>> - return 32; >>> + return shader == PIPE_SHADER_VERTEX ? 16 : 32; >> >> >> For r600g, I assume the limit of 16 is due to the number of hardware >> registers available for vertex shader inputs, > > > AFAIK there is no such limit on r600 hw as well. IIRC there are at least 32 > registers for semantic fetch mapping, but I think we aren't limited even by > this because we can use non-semantic fetches (and currently we don't use > semantic fetches at all). Am I missing something? > > Vadim > > >> but as of SI the state is >> no longer stored in registers but in resource descriptors in a BO. In >> theory, I think we could even support many more inputs than 32, but >> let's just leave it at that for now. >> > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
