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
