[Mesa-dev] [PATCH 3/3] radeonsi: fix the max vertex shader input limit

Vadim Girlin vadimgirlin at gmail.com
Thu May 2 09:23:14 PDT 2013


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 <vadimgirlin at 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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev



More information about the mesa-dev mailing list