<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 25, 2018 at 5:29 PM, Roland Scheidegger <span dir="ltr"><<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_7060788964232317551HOEnZb"><div class="m_7060788964232317551h5">Am 25.04.2018 um 23:16 schrieb Marek Olšák:<br>
> From: Marek Olšák <<a href="mailto:marek.olsak@amd.com" target="_blank">marek.olsak@amd.com</a>><br>
> <br>
> ---<br>
> src/gallium/docs/source/screen<wbr>.rst | 3 +++<br>
> src/gallium/drivers/etnaviv/et<wbr>naviv_screen.c | 1 +<br>
> src/gallium/drivers/freedreno/<wbr>freedreno_screen.c | 1 +<br>
> src/gallium/drivers/i915/i915_<wbr>screen.c | 1 +<br>
> src/gallium/drivers/llvmpipe/l<wbr>p_screen.c | 1 +<br>
> src/gallium/drivers/nouveau/nv<wbr>30/nv30_screen.c | 1 +<br>
> src/gallium/drivers/nouveau/nv<wbr>50/nv50_screen.c | 1 +<br>
> src/gallium/drivers/nouveau/nv<wbr>c0/nvc0_screen.c | 1 +<br>
> src/gallium/drivers/r300/r300_<wbr>screen.c | 1 +<br>
> src/gallium/drivers/r600/r600_<wbr>pipe.c | 1 +<br>
> src/gallium/drivers/radeonsi/s<wbr>i_get.c | 3 +++<br>
> src/gallium/drivers/softpipe/s<wbr>p_screen.c | 1 +<br>
> src/gallium/drivers/svga/svga_<wbr>screen.c | 1 +<br>
> src/gallium/drivers/swr/swr_sc<wbr>reen.cpp | 1 +<br>
> src/gallium/drivers/vc4/vc4_sc<wbr>reen.c | 1 +<br>
> src/gallium/drivers/vc5/vc5_sc<wbr>reen.c | 1 +<br>
> src/gallium/drivers/virgl/virg<wbr>l_screen.c | 1 +<br>
> src/gallium/include/pipe/p_def<wbr>ines.h | 1 +<br>
> 18 files changed, 22 insertions(+)<br>
> <br>
> diff --git a/src/gallium/docs/source/scre<wbr>en.rst b/src/gallium/docs/source/scre<wbr>en.rst<br>
> index 3837360fb40..7cc6d378306 100644<br>
> --- a/src/gallium/docs/source/scre<wbr>en.rst<br>
> +++ b/src/gallium/docs/source/scre<wbr>en.rst<br>
> @@ -413,20 +413,23 @@ The integer capabilities:<br>
> supported priority levels. A driver that does not support prioritized<br>
> contexts can return 0.<br>
> * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling semaphores<br>
> using fence_server_signal().<br>
> * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that must be<br>
> set when binding that buffer as constant buffer 0. If the buffer doesn't have<br>
> those bits set, pipe_context::set_constant_buf<wbr>fer(.., 0, ..) is ignored<br>
> by the driver, and the driver can throw assertion failures.<br>
> * ``PIPE_CAP_PACKED_UNIFORMS``: True if the driver supports packed uniforms<br>
> as opposed to padding to vec4s.<br>
> +* ``PIPE_CAP_TRANSFER_USER_STRID<wbr>E_ALIGNMENT``: The minimum supported alignment of<br>
> + the user_stride parameter of transfer_map. If 0, the user-specified stride<br>
> + is unsupported and the user_stride parameter is ignored.<br>
</div></div>Does this really make a whole lot of sense? What if the minimum stride<br>
natively supported isn't always the same? What happens if the stride<br>
requested is larger than what the hw usually would do, does that need to<br>
be honored as well - it certainly looks like the cap query here wouldn't<br>
answer that?<br></blockquote><div><br></div><div>Correct. The CAP query is only used by the test. I don't think gralloc cares what you (or anyone) support.<br><br></div><div>Marek<br></div></div><br></div></div>