On 08/23/2016 07:09 AM, Marek Olšák wrote: > On Mon, Aug 22, 2016 at 6:34 PM, Brian Paul <bri...@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.ol...@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.
Agreed, I was just about to suggest querying from winsys/drm by query_memory_info as it has everything. Cheers, Edward. > > Marek > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
