On 05/02/2013 07:55 PM, Marek Olšák wrote:
AFAIK, there are 16 fetch shader resources. These are the resource
slots for r600:

Ah, you are right (though it's higher on EG as Alex wrote). Anyway, I'm not against your patch, I just wanted to understand where this limit comes from. I think this cap itself is a bit misleading, because its description in the docs is about input registers, not about resources/buffers, and shader inputs do not necessarily come from separate resources.

Vadim


[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

Reply via email to