<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 26, 2018 at 6:27 AM, Nicolai Hähnle <span dir="ltr"><<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.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="HOEnZb"><div class="h5">On 25.04.2018 23:29, Roland Scheidegger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 25.04.2018 um 23:16 schrieb Marek Olšák:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
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>
<br></div></div>
It really doesn't make much sense, but unfortunately the ChromeOS gralloc is just completely braindead. It basically assumes that tilings don't exist. You have to give it a stride when a texture is allocated, and that is the stride that has to be there whenever the texture is mapped for a transfer.<br></blockquote><div>So we give it the right stride at allocation: aligned to 64 or 256.<br><br></div><div>Marek<br></div></div></div></div>