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

Roland Scheidegger sroland at vmware.com
Sat Oct 12 18:52:51 CEST 2013


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).

Roland


> 
>> FWIW I've intentionally added/copied the SAMPLER_VIEWS, as I feel it's
>> beneficial in the long term. That is after going through the build
>> system(s), my plan is to jump into the nv50 driver + vdpau st and some
>> of the missing extensions and other things along the way :)
>>
>> Cheers
>> Emil
>>
>>> Roland
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>> _______________________________________________
>> 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