[Mesa-dev] [PATCH] nv50: report only 16 texure_samplers

[Marek Olšák]

On Sat, Oct 12, 2013 at 6:52 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 12.10.2013 17:19, schrieb Christoph Bumiller:
>> On 12.10.2013 02:47, Emil Velikov wrote:
>>> On 12/10/13 01:25, Roland Scheidegger wrote:
>>>> Am 12.10.2013 02:02, schrieb Brian Paul:
>>>>> On 10/11/2013 10:44 AM, Emil Velikov wrote:
>>>>>> Current mesa code(cso and drivers) expect and use only up-to 16
>>>>>> texture samplers.
>>>>>>
>>>>>> Verbatum copy from the nvc0 driver.
>>>>>>
>>>>>> Cc "9.1" <mesa-stable at lists.freedesktop.org>
>>>>>> Cc "9.2" <mesa-stable at lists.freedesktop.org>
>>>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70212
>>>>>> Reported-by: Aaron Watry <awatry at gmail.com>
>>>>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>>>>> ---
>>>>>>   src/gallium/drivers/nouveau/nv50/nv50_screen.c | 4 ++++
>>>>>>   1 file changed, 4 insertions(+)
>>>>>>
>>>>>> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
>>>>>> b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
>>>>>> index f454ec7..3f81cc4 100644
>>>>>> --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
>>>>>> +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
>>>>>> @@ -249,7 +249,11 @@ nv50_screen_get_shader_param(struct pipe_screen
>>>>>> *pscreen, unsigned shader,
>>>>>>      case PIPE_SHADER_CAP_INTEGERS:
>>>>>>         return 1;
>>>>>>      case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
>>>>>> +      return 16; /* would be 32 in linked (OpenGL-style) mode */
>>>>>> +      /*
>>>>>> +   case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLER_VIEWS:
>>>>>>         return 32;
>>>>>> +      */
>>>>>>      default:
>>>>>>         NOUVEAU_ERR("unknown PIPE_SHADER_CAP %d\n", param);
>>>>>>         return 0;
>>>>>>
>>>>> Since PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLER_VIEWS doesn't really exist,
>>>>> I'd rather see it removed entirely.
>>>> Actually it doesn't seem to exist at all?
>>>>
>>> Indeed and afaics it never did :)
>>>
>>> As the commit says it's a verbatim copy of nvc0, which also started with
>>> 32 TEXTURE_SAMPLERS.
>>>
>>>>> If you wanted to future-proof the code you could do
>>>>>    return MIN2(32, PIPE_MAX_SAMPLERS);
>>>>>
>>>>> in case we bump PIPE_MAX_SAMPLERS to 32 one of these days.
>>>>>
>>>>>
>>>>> In any case, Reviewed-by: Brian Paul <brianp at vmware.com>
>>>>>
>>>>
>>>> Well I think there is quite some hw out there which can only do 16
>>>> samplers but more sampler views as this is what d3d10/11 wants (16
>>>> samplers max per stage, but 128 sampler views). So making it queryable
>>>> may have some benefits, but OpenGL can't really make any use of it in
>>>> any case.
>>>>
>>> I'm not entirely sure what is the case in here, as I'm a bit short of
>>> knowledge about the hardware, especially with the lack of documentation.
>>
>> That comment's there as a reminder that gallium should have that cap.
>>
>> On nv50 have 2 big tables in VRAM, of texture view (or "sampler view" in
>> gallium, "shader resource view" in d3d) descriptors (TIC) and sampler
>> descriptors (TSC).
>> These are mapped to texture and sampler "units" via a binding table
>> (that happens as a result of calling glBindTexture).
>> In the shader you have to select the units, you have 4 bits for the
>> sampler and 5 bits for the texture unit index.
> Hmm if you have only 5 bits for the texture unit index how do you access
> 128 different sampler views as required by d3d10?
>
>
>>
>> You can set the hardware to linked mode (LINKED_TSC) so that sampler
>> unit index automatically corresponds to the texture view unit index.
>> Now you can't select them independently but you access 32 bindings of
>> them tied together (which is how OpenGL works).
>> But gallium requires them to be selectable independently we can't use that.
>>
>> With Kepler they removed the binding table and you can select the
>> descriptors directly via a 32-bit register so you can access (1 << 20)
>> texture views and (1 << 12) samplers, there's no problem there.
> For bindless textures I assume (a neat extension).

I think it's for Compute, so that you can have an unlimited number
resources. On Southern Islands, resources and samplers are truly
unlimited. The descriptors must first be loaded to shader TEMPs, only
then the fetch and store instructions can use them. The flexibility is
obvious there.

Marek