[Mesa-dev] [PATCH 14/20] radeonsi: reserve a parameter slot for FMASK resources in shaders

[Marek Olšák]

Interleaving might not be a good idea, but they could be in the same
array, like this:

0..15: textures
16..31: FMASK textures

I'll test LLVM master, but we should probably bump the LLVM version
requirement in configure.ac to prevent users from using LLVM 3.3.

Marek

On Thu, Aug 8, 2013 at 10:37 AM, Christian König
<deathsimple at vodafone.de> wrote:
> Am 08.08.2013 10:30, schrieb Michel Dänzer:
>
>> On Don, 2013-08-08 at 02:20 +0200, Marek Olšák wrote:
>>>
>>> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
>>> b/src/gallium/drivers/radeonsi/si_state_draw.c
>>> index 746ace6..4208fa7 100644
>>> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
>>> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
>>> @@ -241,6 +241,7 @@ static void si_pipe_shader_ps(struct pipe_context
>>> *ctx, struct si_pipe_shader *s
>>>                 /* Last 2 reserved SGPRs are used for VCC */
>>>                 num_sgprs = num_user_sgprs + 2;
>>>         }
>>> +       num_sgprs += 1; /* XXX this fixes VM faults */
>>>         assert(num_sgprs <= 104);
>>
>> You can't just increment num_sgprs unconditionally here, or the
>> assertion will spuriously fail again when num_sgprs was 104 to begin
>> with.
>>
>> More fundamentally, I'd really like us to understand why / under what
>> circumstances the value needs to be incremented at all. You mentioned on
>> IRC that you were using an LLVM 3.3 tree, is this change still necessary
>> with LLVM master / trunk? If yes, it would be good to look into at least
>> some example shaders where the change is really necessary, to try and
>> understand the circumstances.
>
>
> Additional to that I'm not sure if we should add another sgpr pointer to the
> shader, the docs speak of quite a performance penalty for each. Since they
> are (optional) attributes to the textures anyway they could probably be
> interleaved with the texture resources.
>
> Christian.