[Mesa-dev] [PATCH 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT
From: Marek Olšák --- src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_get.c| 3 +++ src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/vc5/vc5_screen.c | 1 + src/gallium/drivers/virgl/virgl_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + 18 files changed, 22 insertions(+) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 3837360fb40..7cc6d378306 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -413,20 +413,23 @@ The integer capabilities: supported priority levels. A driver that does not support prioritized contexts can return 0. * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling semaphores using fence_server_signal(). * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that must be set when binding that buffer as constant buffer 0. If the buffer doesn't have those bits set, pipe_context::set_constant_buffer(.., 0, ..) is ignored by the driver, and the driver can throw assertion failures. * ``PIPE_CAP_PACKED_UNIFORMS``: True if the driver supports packed uniforms as opposed to padding to vec4s. +* ``PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT``: The minimum supported alignment of + the user_stride parameter of transfer_map. If 0, the user-specified stride + is unsupported and the user_stride parameter is ignored. .. _pipe_capf: PIPE_CAPF_* The floating-point capabilities are: * ``PIPE_CAPF_MAX_LINE_WIDTH``: The maximum width of a regular line. diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c b/src/gallium/drivers/etnaviv/etnaviv_screen.c index b0f8b4bebe3..915e7d7da7d 100644 --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c @@ -267,20 +267,21 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_MEMOBJ: case PIPE_CAP_LOAD_CONSTBUF: case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS: case PIPE_CAP_TILE_RASTER_ORDER: case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES: case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET: case PIPE_CAP_CONTEXT_PRIORITY_MASK: case PIPE_CAP_FENCE_SIGNAL: case PIPE_CAP_CONSTBUF0_FLAGS: case PIPE_CAP_PACKED_UNIFORMS: + case PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT: return 0; /* Stream output. */ case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS: case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME: case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS: case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS: return 0; /* Geometry shader output, unsupported. */ diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index f338d756dfe..dd052a22f25 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -333,20 +333,21 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_NIR_SAMPLERS_AS_DEREF: case PIPE_CAP_QUERY_SO_OVERFLOW: case PIPE_CAP_MEMOBJ: case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS: case PIPE_CAP_TILE_RASTER_ORDER: case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES: case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET: case PIPE_CAP_FENCE_SIGNAL: case PIPE_CAP_CONSTBUF0_FLAGS: case PIPE_CAP_PACKED_UNIFORMS: + case PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT: return 0; case PIPE_CAP_CONTEXT_PRIORITY_MASK: return screen->priority_mask; case PIPE_CAP_DRAW_INDIRECT: if (is_a4xx(screen) || is_a5xx(screen)) return 1; return 0; diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 59d2ec66284..6ec0d026bed 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -320,20 +320,21 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_MEMOBJ: case PIPE_CAP_LOAD_CONSTBUF: case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS: case PIPE_CAP_TILE_RASTER_ORDER: case P
Re: [Mesa-dev] [PATCH 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT
Am 25.04.2018 um 23:16 schrieb Marek Olšák: > From: Marek Olšák > > --- > src/gallium/docs/source/screen.rst | 3 +++ > src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + > src/gallium/drivers/freedreno/freedreno_screen.c | 1 + > src/gallium/drivers/i915/i915_screen.c | 1 + > src/gallium/drivers/llvmpipe/lp_screen.c | 1 + > src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + > src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + > src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + > src/gallium/drivers/r300/r300_screen.c | 1 + > src/gallium/drivers/r600/r600_pipe.c | 1 + > src/gallium/drivers/radeonsi/si_get.c| 3 +++ > src/gallium/drivers/softpipe/sp_screen.c | 1 + > src/gallium/drivers/svga/svga_screen.c | 1 + > src/gallium/drivers/swr/swr_screen.cpp | 1 + > src/gallium/drivers/vc4/vc4_screen.c | 1 + > src/gallium/drivers/vc5/vc5_screen.c | 1 + > src/gallium/drivers/virgl/virgl_screen.c | 1 + > src/gallium/include/pipe/p_defines.h | 1 + > 18 files changed, 22 insertions(+) > > diff --git a/src/gallium/docs/source/screen.rst > b/src/gallium/docs/source/screen.rst > index 3837360fb40..7cc6d378306 100644 > --- a/src/gallium/docs/source/screen.rst > +++ b/src/gallium/docs/source/screen.rst > @@ -413,20 +413,23 @@ The integer capabilities: >supported priority levels. A driver that does not support prioritized >contexts can return 0. > * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling semaphores >using fence_server_signal(). > * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that must be >set when binding that buffer as constant buffer 0. If the buffer doesn't > have >those bits set, pipe_context::set_constant_buffer(.., 0, ..) is ignored >by the driver, and the driver can throw assertion failures. > * ``PIPE_CAP_PACKED_UNIFORMS``: True if the driver supports packed uniforms >as opposed to padding to vec4s. > +* ``PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT``: The minimum supported > alignment of > + the user_stride parameter of transfer_map. If 0, the user-specified stride > + is unsupported and the user_stride parameter is ignored. Does this really make a whole lot of sense? What if the minimum stride natively supported isn't always the same? What happens if the stride requested is larger than what the hw usually would do, does that need to be honored as well - it certainly looks like the cap query here wouldn't answer that? Roland > > > .. _pipe_capf: > > PIPE_CAPF_* > > > The floating-point capabilities are: > > * ``PIPE_CAPF_MAX_LINE_WIDTH``: The maximum width of a regular line. > diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c > b/src/gallium/drivers/etnaviv/etnaviv_screen.c > index b0f8b4bebe3..915e7d7da7d 100644 > --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c > +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c > @@ -267,20 +267,21 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum > pipe_cap param) > case PIPE_CAP_MEMOBJ: > case PIPE_CAP_LOAD_CONSTBUF: > case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS: > case PIPE_CAP_TILE_RASTER_ORDER: > case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES: > case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET: > case PIPE_CAP_CONTEXT_PRIORITY_MASK: > case PIPE_CAP_FENCE_SIGNAL: > case PIPE_CAP_CONSTBUF0_FLAGS: > case PIPE_CAP_PACKED_UNIFORMS: > + case PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT: >return 0; > > /* Stream output. */ > case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS: > case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME: > case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS: > case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS: >return 0; > > /* Geometry shader output, unsupported. */ > diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c > b/src/gallium/drivers/freedreno/freedreno_screen.c > index f338d756dfe..dd052a22f25 100644 > --- a/src/gallium/drivers/freedreno/freedreno_screen.c > +++ b/src/gallium/drivers/freedreno/freedreno_screen.c > @@ -333,20 +333,21 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum > pipe_cap param) > case PIPE_CAP_NIR_SAMPLERS_AS_DEREF: > case PIPE_CAP_QUERY_SO_OVERFLOW: > case PIPE_CAP_MEMOBJ: > case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS: > case PIPE_CAP_TILE_RASTER_ORDER: > case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES: > case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET: > case PIPE_CAP_FENCE_SIGNAL: > case PIPE_CAP_CONSTBUF0_FLAGS: > case PIPE_CAP_PACKED_UNIFORMS: > + case PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT: > return 0; > > case PIPE_CAP_CONTEXT_PRIORITY_MASK: > return screen->priority_mask; > > case PIPE_CAP_DRAW_INDIRECT: > if (is_a4xx(screen)
Re: [Mesa-dev] [PATCH 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT
On Wed, Apr 25, 2018 at 5:29 PM, Roland Scheidegger wrote: > Am 25.04.2018 um 23:16 schrieb Marek Olšák: > > From: Marek Olšák > > > > --- > > src/gallium/docs/source/screen.rst | 3 +++ > > src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + > > src/gallium/drivers/freedreno/freedreno_screen.c | 1 + > > src/gallium/drivers/i915/i915_screen.c | 1 + > > src/gallium/drivers/llvmpipe/lp_screen.c | 1 + > > src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + > > src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + > > src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + > > src/gallium/drivers/r300/r300_screen.c | 1 + > > src/gallium/drivers/r600/r600_pipe.c | 1 + > > src/gallium/drivers/radeonsi/si_get.c| 3 +++ > > src/gallium/drivers/softpipe/sp_screen.c | 1 + > > src/gallium/drivers/svga/svga_screen.c | 1 + > > src/gallium/drivers/swr/swr_screen.cpp | 1 + > > src/gallium/drivers/vc4/vc4_screen.c | 1 + > > src/gallium/drivers/vc5/vc5_screen.c | 1 + > > src/gallium/drivers/virgl/virgl_screen.c | 1 + > > src/gallium/include/pipe/p_defines.h | 1 + > > 18 files changed, 22 insertions(+) > > > > diff --git a/src/gallium/docs/source/screen.rst > b/src/gallium/docs/source/screen.rst > > index 3837360fb40..7cc6d378306 100644 > > --- a/src/gallium/docs/source/screen.rst > > +++ b/src/gallium/docs/source/screen.rst > > @@ -413,20 +413,23 @@ The integer capabilities: > >supported priority levels. A driver that does not support prioritized > >contexts can return 0. > > * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling > semaphores > >using fence_server_signal(). > > * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that > must be > >set when binding that buffer as constant buffer 0. If the buffer > doesn't have > >those bits set, pipe_context::set_constant_buffer(.., 0, ..) is > ignored > >by the driver, and the driver can throw assertion failures. > > * ``PIPE_CAP_PACKED_UNIFORMS``: True if the driver supports packed > uniforms > >as opposed to padding to vec4s. > > +* ``PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT``: The minimum supported > alignment of > > + the user_stride parameter of transfer_map. If 0, the user-specified > stride > > + is unsupported and the user_stride parameter is ignored. > Does this really make a whole lot of sense? What if the minimum stride > natively supported isn't always the same? What happens if the stride > requested is larger than what the hw usually would do, does that need to > be honored as well - it certainly looks like the cap query here wouldn't > answer that? > Correct. The CAP query is only used by the test. I don't think gralloc cares what you (or anyone) support. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT
On 25.04.2018 23:29, Roland Scheidegger wrote: Am 25.04.2018 um 23:16 schrieb Marek Olšák: From: Marek Olšák --- src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_get.c| 3 +++ src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/vc5/vc5_screen.c | 1 + src/gallium/drivers/virgl/virgl_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + 18 files changed, 22 insertions(+) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 3837360fb40..7cc6d378306 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -413,20 +413,23 @@ The integer capabilities: supported priority levels. A driver that does not support prioritized contexts can return 0. * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling semaphores using fence_server_signal(). * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that must be set when binding that buffer as constant buffer 0. If the buffer doesn't have those bits set, pipe_context::set_constant_buffer(.., 0, ..) is ignored by the driver, and the driver can throw assertion failures. * ``PIPE_CAP_PACKED_UNIFORMS``: True if the driver supports packed uniforms as opposed to padding to vec4s. +* ``PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT``: The minimum supported alignment of + the user_stride parameter of transfer_map. If 0, the user-specified stride + is unsupported and the user_stride parameter is ignored. Does this really make a whole lot of sense? What if the minimum stride natively supported isn't always the same? What happens if the stride requested is larger than what the hw usually would do, does that need to be honored as well - it certainly looks like the cap query here wouldn't answer that? 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. Cheers, Nicolai Roland .. _pipe_capf: PIPE_CAPF_* The floating-point capabilities are: * ``PIPE_CAPF_MAX_LINE_WIDTH``: The maximum width of a regular line. diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c b/src/gallium/drivers/etnaviv/etnaviv_screen.c index b0f8b4bebe3..915e7d7da7d 100644 --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c @@ -267,20 +267,21 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_MEMOBJ: case PIPE_CAP_LOAD_CONSTBUF: case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS: case PIPE_CAP_TILE_RASTER_ORDER: case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES: case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET: case PIPE_CAP_CONTEXT_PRIORITY_MASK: case PIPE_CAP_FENCE_SIGNAL: case PIPE_CAP_CONSTBUF0_FLAGS: case PIPE_CAP_PACKED_UNIFORMS: + case PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT: return 0; /* Stream output. */ case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS: case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME: case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS: case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS: return 0; /* Geometry shader output, unsupported. */ diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index f338d756dfe..dd052a22f25 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -333,20 +333,21 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_NIR_SAMPLERS_AS_DEREF: case PIPE_CAP_QUERY_SO_OVERFLOW: case PIPE_CAP_MEMOBJ: case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS: case PIPE_CAP_TILE_RASTER_ORDER: case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES: case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET: case PIPE_CAP_FENCE_SIGNAL: case PIPE_CAP_CONSTBUF0_FLAGS: case PIPE_CAP_PACK
Re: [Mesa-dev] [PATCH 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT
On Thu, Apr 26, 2018 at 6:27 AM, Nicolai Hähnle wrote: > On 25.04.2018 23:29, Roland Scheidegger wrote: > >> Am 25.04.2018 um 23:16 schrieb Marek Olšák: >> >>> From: Marek Olšák >>> >>> --- >>> src/gallium/docs/source/screen.rst | 3 +++ >>> src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + >>> src/gallium/drivers/freedreno/freedreno_screen.c | 1 + >>> src/gallium/drivers/i915/i915_screen.c | 1 + >>> src/gallium/drivers/llvmpipe/lp_screen.c | 1 + >>> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + >>> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >>> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >>> src/gallium/drivers/r300/r300_screen.c | 1 + >>> src/gallium/drivers/r600/r600_pipe.c | 1 + >>> src/gallium/drivers/radeonsi/si_get.c| 3 +++ >>> src/gallium/drivers/softpipe/sp_screen.c | 1 + >>> src/gallium/drivers/svga/svga_screen.c | 1 + >>> src/gallium/drivers/swr/swr_screen.cpp | 1 + >>> src/gallium/drivers/vc4/vc4_screen.c | 1 + >>> src/gallium/drivers/vc5/vc5_screen.c | 1 + >>> src/gallium/drivers/virgl/virgl_screen.c | 1 + >>> src/gallium/include/pipe/p_defines.h | 1 + >>> 18 files changed, 22 insertions(+) >>> >>> diff --git a/src/gallium/docs/source/screen.rst >>> b/src/gallium/docs/source/screen.rst >>> index 3837360fb40..7cc6d378306 100644 >>> --- a/src/gallium/docs/source/screen.rst >>> +++ b/src/gallium/docs/source/screen.rst >>> @@ -413,20 +413,23 @@ The integer capabilities: >>> supported priority levels. A driver that does not support >>> prioritized >>> contexts can return 0. >>> * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling >>> semaphores >>> using fence_server_signal(). >>> * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that >>> must be >>> set when binding that buffer as constant buffer 0. If the buffer >>> doesn't have >>> those bits set, pipe_context::set_constant_buffer(.., 0, ..) is >>> ignored >>> by the driver, and the driver can throw assertion failures. >>> * ``PIPE_CAP_PACKED_UNIFORMS``: True if the driver supports packed >>> uniforms >>> as opposed to padding to vec4s. >>> +* ``PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT``: The minimum supported >>> alignment of >>> + the user_stride parameter of transfer_map. If 0, the user-specified >>> stride >>> + is unsupported and the user_stride parameter is ignored. >>> >> Does this really make a whole lot of sense? What if the minimum stride >> natively supported isn't always the same? What happens if the stride >> requested is larger than what the hw usually would do, does that need to >> be honored as well - it certainly looks like the cap query here wouldn't >> answer that? >> > > 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. > So we give it the right stride at allocation: aligned to 64 or 256. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
