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

Marek Olšák maraeo at gmail.com
Thu May 2 10:37:01 PDT 2013


There is a single limit in OpenGL - GL_MAX_VERTEX_ATTRIBS, and there
is one-to-one mapping between vertex array bindings and vertex shader
inputs. Anyway, the core Mesa limit is 16 at the moment and I don't
plan to change it (the vbo module has to analyze all available vertex
attribs no matter how many of them are actually used).

If we had 2 separate caps for the vertex buffer and vertex element
limit, we would have to set the minimum of the two for OpenGL.

Marek

On Thu, May 2, 2013 at 6:23 PM, Vadim Girlin <vadimgirlin at gmail.com> wrote:
> 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