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