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. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
