[Mesa-dev] [PATCH] nv50: report only 16 texure_samplers
e0425955 at student.tuwien.ac.at
Sat Oct 12 17:19:05 CEST 2013
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
>>>> 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;
>>>> + */
>>>> 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
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.
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.
> 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 :)
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev