[Mesa-dev] [PATCH] st/mesa: set Const.MaxTextureMbytes

[Marek Olšák]

On Mon, Aug 22, 2016 at 6:34 PM, Brian Paul <brianp at vmware.com> wrote:
> On 08/22/2016 10:26 AM, Brian Paul wrote:
>>
>> On 08/22/2016 08:06 AM, Marek Olšák wrote:
>>>
>>> From: Marek Olšák <marek.olsak at amd.com>
>>>
>>> ---
>>>   src/mesa/state_tracker/st_extensions.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/src/mesa/state_tracker/st_extensions.c
>>> b/src/mesa/state_tracker/st_extensions.c
>>> index 1f53bdf..ebf1f04 100644
>>> --- a/src/mesa/state_tracker/st_extensions.c
>>> +++ b/src/mesa/state_tracker/st_extensions.c
>>> @@ -458,20 +458,22 @@ void st_init_limits(struct pipe_screen *screen,
>>>       * PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS has the same
>>>       * number of layers as we need, although we technically
>>>       * could have more the generality is not really useful
>>>       * in practicality.
>>>       */
>>>      c->MaxFramebufferLayers =
>>>         screen->get_param(screen, PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS);
>>>
>>>      c->MaxWindowRectangles =
>>>         screen->get_param(screen, PIPE_CAP_MAX_WINDOW_RECTANGLES);
>>> +
>>> +   c->MaxTextureMbytes = screen->get_param(screen,
>>> PIPE_CAP_VIDEO_MEMORY);
>>>   }
>>>
>>>
>>>   /**
>>>    * Given a member \c x of struct gl_extensions, return offset of
>>>    * \c x in bytes.
>>>    */
>>>   #define o(x) offsetof(struct gl_extensions, x)
>>>
>>>
>>>
>>
>> I'll have to update the VMware driver.  We currently return 1 for
>> PIPE_CAP_VIDEO_MEMORY.
>>
>> freedreno returns 10 (MB).  virgl returns 0.  Some drivers like
>> llvmpipe/softpipe return 0 if there's an error.
>>
>> Maybe we could do something like
>>
>> c->MaxTextureMbytes = MAX2(128, screen->get_param(screen,
>> PIPE_CAP_VIDEO_MEMORY));
>>
>> Just to be sure we don't get a crazy small value.
>
>
> BTW, a few drivers (such as softpipe/llvmpipe/svga implement
> pipe_screen::can_create_resource() so MaxTextureMbytes shouldn't matter for
> proxy texture testing.
>
> I'm going to post a patch for our driver which returns more reasonable
> values, just to be safe.

Well, I'll drop the patch. PIPE_CAP_VIDEO_MEMORY returns the VRAM
size, but GPUs and APUs can also use RAM. We should set whichever is
greater.

Also, PIPE_CAP_VIDEO_MEMORY should probably be removed, because
pipe_screen::query_memory_info guarded by PIPE_CAP_QUERY_MEMORY_INFO
is much better and contains everything.

Marek