Am 22.02.2014 04:04, schrieb Emil Velikov:
> Both drivers report 0xffffffff as vendor/device id, and the maximum
> amount of system memory as video memory. We might want to reconsider
> the latter.
>
> Cc: Brian Paul <bri...@vmware.com>
> Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com>
> ---
> src/gallium/drivers/llvmpipe/lp_screen.c | 25 +++++++++++++++++++++++++
> src/gallium/drivers/softpipe/sp_screen.c | 25 +++++++++++++++++++++++++
> 2 files changed, 50 insertions(+)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
> b/src/gallium/drivers/llvmpipe/lp_screen.c
> index 604f853..c28f9a7 100644
> --- a/src/gallium/drivers/llvmpipe/lp_screen.c
> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
> @@ -245,6 +245,31 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
> return 11;
> case PIPE_CAP_MAX_GL_ES2_VERSION:
> return 20;
> +
> + case PIPE_CAP_VENDOR_ID:
> + return 0xFFFFFFFF;
> + case PIPE_CAP_DEVICE_ID:
> + return 0xFFFFFFFF;
> + case PIPE_CAP_ACCELERATED:
> + return 0;
> + case PIPE_CAP_VIDEO_MEMORY: {
> + /* XXX: Do we want to return the full amount fo system memory ? */
fo->of
> + const long system_memory_pages = sysconf(_SC_PHYS_PAGES);
> + const long system_page_size = sysconf(_SC_PAGE_SIZE);
> +
> + if (system_memory_pages <= 0 || system_page_size <= 0)
> + return 0;
> +
> + const uint64_t system_memory_bytes = (uint64_t) system_memory_pages
> + * (uint64_t) system_page_size;
> +
> + const unsigned system_memory_megabytes =
> + (unsigned) (system_memory_bytes / (1024 * 1024));
> +
> + return system_memory_megabytes;
> + }
> + case PIPE_CAP_UMA:
> + return 0;
> }
> /* should only get here on unhandled cases */
> debug_printf("Unexpected PIPE_CAP %d query\n", param);
> diff --git a/src/gallium/drivers/softpipe/sp_screen.c
> b/src/gallium/drivers/softpipe/sp_screen.c
> index 3a6d31a..bf91274 100644
> --- a/src/gallium/drivers/softpipe/sp_screen.c
> +++ b/src/gallium/drivers/softpipe/sp_screen.c
> @@ -195,6 +195,31 @@ softpipe_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
> return 11;
> case PIPE_CAP_MAX_GL_ES2_VERSION:
> return 20;
> +
> + case PIPE_CAP_VENDOR_ID:
> + return 0xFFFFFFFF;
> + case PIPE_CAP_DEVICE_ID:
> + return 0xFFFFFFFF;
> + case PIPE_CAP_ACCELERATED:
> + return 0;
> + case PIPE_CAP_VIDEO_MEMORY: {
> + /* XXX: Do we want to return the full amount fo system memory ? */
fo->of
Good question if this should be restricted, though I guess returning
everything isn't too bad. Generally, these drivers still restrict max
texture size etc. but since it should be possible to use all memory it's
probably ok.
> + const long system_memory_pages = sysconf(_SC_PHYS_PAGES);
> + const long system_page_size = sysconf(_SC_PAGE_SIZE);
> +
> + if (system_memory_pages <= 0 || system_page_size <= 0)
> + return 0;
> +
> + const uint64_t system_memory_bytes = (uint64_t) system_memory_pages
> + * (uint64_t) system_page_size;
> +
> + const unsigned system_memory_megabytes =
> + (unsigned) (system_memory_bytes / (1024 * 1024));
> +
> + return system_memory_megabytes;
> + }
> + case PIPE_CAP_UMA:
> + return 0;
> }
> /* should only get here on unhandled cases */
> debug_printf("Unexpected PIPE_CAP %d query\n", param);
>
I'm not sure I really agree on PIPE_CAP_UMA being 0 for these software
drivers. Though indeed the glx_mesa_query_renderer spec says that. I
think it is a lot more relevant that all the uploaded texture data etc.
lives in the same system memory rather than where display memory is (and
that would depend on winsys anyway, you could have a non-display
software winsys which still uses system memory). From the PIPE_CAP
description this is also very non-obvious.
Roland
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
