Re: [Mesa-dev] [PATCH] st: Don't try to finalize the texture in st_render_texture().
Brian Paul writes: > On 03/27/2018 10:14 PM, Eric Anholt wrote: >> We can't necessarily finalize the texture at this point if we're rendering >> to a texture image whose format is different from the baselevel's format. > > This is just a test suite scenario, right? It's not the sort of thing a > real app would do, I hope. Yeah, it seems pretty crazy to me. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st: Don't try to finalize the texture in st_render_texture().
We can't necessarily finalize the texture at this point if we're rendering
to a texture image whose format is different from the baselevel's format.
This was introduced as a fix for fbo-incomplete-texture-03 in
de414f491526610bb260c73805c81ba413388e20, but the later fix for vmware on
that testcase in 95d5c48f68b598cfa6db25f44aac52b3e11403cc made it
unnecessary.
Fixes assertion failures in util_resource_copy_region() in
KHR-GLES3.copy_tex_image_conversions.forbidden.* when trying to finalize
an R8 texture image to the RG8 texture object's pt.
---
src/mesa/state_tracker/st_cb_fbo.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 02ae8e1380e3..f859133e399e 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -509,14 +509,10 @@ st_render_texture(struct gl_context *ctx,
struct gl_renderbuffer_attachment *att)
{
struct st_context *st = st_context(ctx);
- struct pipe_context *pipe = st->pipe;
struct gl_renderbuffer *rb = att->Renderbuffer;
struct st_renderbuffer *strb = st_renderbuffer(rb);
struct pipe_resource *pt;
- if (!st_finalize_texture(ctx, pipe, att->Texture, att->CubeMapFace))
- return;
-
pt = get_teximage_resource(att->Texture,
att->CubeMapFace,
att->TextureLevel);
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] gallium/u_vbuf: Protect against overflow with large instance divisors.
GTF-GLES3.gtf.GL3Tests.instanced_arrays.instanced_arrays_divisor uses -1
as a divisor, so we would overflow to count=0 and upload no data,
triggering the assert below. We want to upload 1 element in this case,
fixing the test on VC5.
v2: Use some more obvious logic, and explain why we don't use the normal
round_up().
---
src/gallium/auxiliary/util/u_vbuf.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
b/src/gallium/auxiliary/util/u_vbuf.c
index 95d7990c6ca4..8a680d60a687 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -936,7 +936,16 @@ u_vbuf_upload_buffers(struct u_vbuf *mgr,
size = mgr->ve->src_format_size[i];
} else if (instance_div) {
/* Per-instance attrib. */
- unsigned count = (num_instances + instance_div - 1) / instance_div;
+
+ /* Figure out how many instances we'll render given instance_div. We
+ * can't use the typical div_round_up() pattern because the CTS uses
+ * instance_div = ~0 for a test, which overflows div_round_up()'s
+ * addition.
+ */
+ unsigned count = num_instances / instance_div;
+ if (count * instance_div != num_instances)
+count++;
+
first += vb->stride * start_instance;
size = vb->stride * (count - 1) + mgr->ve->src_format_size[i];
} else {
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st: Allow accelerated CopyTexImage from RGBA to RGB.
There's nothing to worry about here -- the A channel just gets dropped by
the blit. This avoids a segfault in the fallback path when copying from a
RGBA16_SINT renderbuffer to a RGB16_SINT destination represented by an
RGBA16_SINT texture (the fallback path tries to get/fetch to float
buffers, but the float pack/unpack functions are NULL for SINT/UINT).
Fixes KHR-GLES3.packed_pixels.pbo_rectangle.rgba16i on VC5.
v2: Extract the logic to a helper function and explain what's going on
better.
---
src/mesa/state_tracker/st_cb_texture.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 6345ead6396b..5a23c7e8b6cd 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -2281,6 +2281,31 @@ fallback_copy_texsubimage(struct gl_context *ctx,
pipe->transfer_unmap(pipe, src_trans);
}
+static bool
+st_can_copyteximage_using_blit(struct gl_texture_image *texImage,
+ struct gl_renderbuffer *rb)
+{
+ GLenum tex_baseformat = _mesa_get_format_base_format(texImage->TexFormat);
+
+ /* We don't blit to a teximage where the GL base format doesn't match the
+* texture's chosen format, except in the case of a GL_RGB texture
+* represented with GL_RGBA (where the alpha channel is just being
+* dropped).
+*/
+ if (texImage->_BaseFormat != tex_baseformat &&
+ ((texImage->_BaseFormat != GL_RGB || tex_baseformat != GL_RGBA))) {
+ return false;
+ }
+
+ /* We can't blit from a RB where the GL base format doesn't match the RB's
+* chosen format (for example, GL RGB or ALPHA with rb->Format of an RGBA
+* type, because the other channels will be undefined).
+*/
+ if (rb->_BaseFormat != _mesa_get_format_base_format(rb->Format))
+ return false;
+
+ return true;
+}
/**
* Do a CopyTex[Sub]Image1/2/3D() using a hardware (blit) path if possible.
@@ -2324,12 +2349,7 @@ st_CopyTexSubImage(struct gl_context *ctx, GLuint dims,
goto fallback;
}
- /* The base internal format must match the mesa format, so make sure
-* e.g. an RGB internal format is really allocated as RGB and not as RGBA.
-*/
- if (texImage->_BaseFormat !=
- _mesa_get_format_base_format(texImage->TexFormat) ||
- rb->_BaseFormat != _mesa_get_format_base_format(rb->Format)) {
+ if (!st_can_copyteximage_using_blit(texImage, rb)) {
goto fallback;
}
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] st/mesa: s/unsigned/enum pipe_shader_type/
Brian Paul writes: > --- > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 6 -- > src/mesa/state_tracker/st_glsl_to_tgsi.h | 2 +- > 2 files changed, 5 insertions(+), 3 deletions(-) This series is: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 7/7] broadcom/vc4: add path to nir_builder.h
"Juan A. Suarez Romero" writes: > As the other VC4 files do. Otherwise, it won't find nir_builder.h > > v2: add path in source code rather changing autotools (Emil) > > Reviewed-by: Emil Velikov Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] tgsi: convert opcode macros to enums
Brian Paul writes: > Enums are nicer in gdb. This series is: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st: Allow accelerated CopyTexImage from RGBA to RGB.
There's nothing to worry about here -- the A channel just gets dropped by
the blit. This avoids a segfault in the fallback path when copying from a
RGBA16_SINT renderbuffer to a RGB16_SINT destination represented by an
RGBA16_SINT texture (the fallback path tries to get/fetch to float
buffers, but the float pack/unpack functions are NULL for SINT/UINT).
Fixes KHR-GLES3.packed_pixels.pbo_rectangle.rgba16i on VC5.
---
src/mesa/state_tracker/st_cb_texture.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 6345ead6396b..469a82a75390 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -2327,8 +2327,10 @@ st_CopyTexSubImage(struct gl_context *ctx, GLuint dims,
/* The base internal format must match the mesa format, so make sure
* e.g. an RGB internal format is really allocated as RGB and not as RGBA.
*/
- if (texImage->_BaseFormat !=
- _mesa_get_format_base_format(texImage->TexFormat) ||
+ if ((texImage->_BaseFormat !=
+_mesa_get_format_base_format(texImage->TexFormat) &&
+(texImage->_BaseFormat != GL_RGB ||
+ _mesa_get_format_base_format(texImage->TexFormat) != GL_RGBA)) ||
rb->_BaseFormat != _mesa_get_format_base_format(rb->Format)) {
goto fallback;
}
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/u_vbuf: Protect against overflow with large instance divisors.
GTF-GLES3.gtf.GL3Tests.instanced_arrays.instanced_arrays_divisor uses -1
as a divisor, so we would overflow to count=0 and upload no data,
triggering the assert below. We want to upload 1 element in this case,
fixing the test on VC5.
---
src/gallium/auxiliary/util/u_vbuf.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
b/src/gallium/auxiliary/util/u_vbuf.c
index 95d7990c6ca4..9073f3feed98 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -936,7 +936,12 @@ u_vbuf_upload_buffers(struct u_vbuf *mgr,
size = mgr->ve->src_format_size[i];
} else if (instance_div) {
/* Per-instance attrib. */
- unsigned count = (num_instances + instance_div - 1) / instance_div;
+ unsigned count = (num_instances + instance_div - 1);
+
+ if (count < num_instances)
+count = 0x;
+ count /= instance_div;
+
first += vb->stride * start_instance;
size = vb->stride * (count - 1) + mgr->ve->src_format_size[i];
} else {
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] nir: Initial implementation of a nir_instr_worklist
Thomas Helland writes:
> Make a simple worklist by basically just wrapping u_vector.
> This is intended used in nir_opt_dce to reduce the number of calls
> to ralloc, as we are currenlty spamming ralloc quite bad. It should
> also give better cache locality and much lower memory usage.
> ---
> src/compiler/nir/nir_worklist.h | 69
> +
> 1 file changed, 69 insertions(+)
>
> diff --git a/src/compiler/nir/nir_worklist.h b/src/compiler/nir/nir_worklist.h
> index 39521a386c..5071c7aec1 100644
> --- a/src/compiler/nir/nir_worklist.h
> +++ b/src/compiler/nir/nir_worklist.h
> @@ -30,6 +30,8 @@
> #define _NIR_WORKLIST_
>
> #include "nir.h"
> +#include "util/set.h"
> +#include "util/u_vector.h"
>
> #ifdef __cplusplus
> extern "C" {
> @@ -83,6 +85,73 @@ nir_block *nir_block_worklist_peek_tail(const
> nir_block_worklist *w);
>
> nir_block *nir_block_worklist_pop_tail(nir_block_worklist *w);
>
> +
> +
> +
Drop two of these extra newlines?
Also, the "typedef struct nir_instr_worklist_node
nir_instr_worklist_node;" in the second patch should probably be in this
one.
> +/*
> + * This worklist implementation, in contrast to the block worklist, does not
> + * have unique entries, meaning a nir_instr can be inserted more than once
> + * into the worklist. It uses u_vector to keep the overhead and memory
> + * footprint at a minimum.
> + *
Trailing whitespace here.
Other than that, this looks great. I particularly like that you've
explained the choice of the implementation details in the comments here.
With these little nits fixed, both patches are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/blorp: Fix compiler warning about num_layers.
The compiler doesn't notice that the condition for num_layers to be
undefined already defined it above (as our assert checked in a debug
build).
v2: Move the pair of assignments to one outside of the block.
Cc: Jason Ekstrand
Cc: Lionel Landwerlin
---
src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 72c5d194efec..72578b6ea5cc 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1426,8 +1426,8 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
} else {
level = irb->mt_level;
start_layer = irb->mt_layer;
- num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
}
+ num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
stencil_mask = ctx->Stencil.WriteMask[0] & 0xff;
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] intel/blorp: Fix compiler warning about num_layers.
Lionel Landwerlin writes:
> On 13/03/18 17:38, Eric Anholt wrote:
>> The compiler doesn't notice that the condition for num_layers to be
>> undefined already defined it above (as our assert checked in a debug
>> build).
>>
>> Cc: Jason Ekstrand
>> ---
>> src/mesa/drivers/dri/i965/brw_blorp.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
>> b/src/mesa/drivers/dri/i965/brw_blorp.c
>> index 1d586e5ef38d..2b8d913fa282 100644
>> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
>> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
>> @@ -1408,6 +1408,7 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
>>assert(level == irb->mt_level);
>>assert(start_layer == irb->mt_layer);
>>assert(num_layers == fb->MaxNumLayers ? irb->layer_count : 1);
>> + num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
>> } else {
>>level = irb->mt_level;
>>start_layer = irb->mt_layer;
>
> I guess if we're going to assign it in both block, better put it
> before/after the 2 blocks.
>
> What's your compiler? :)
Just gcc 7.3
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements
Kenneth Graunke writes: > [ Unknown signature status ] > On Friday, March 9, 2018 12:12:28 PM PDT Mark Janes wrote: > [snip] >> I've been doing this for Intel. Developers are on the hook to fix their >> bugs, but you can't make them do it. They have many pressures on them, >> and a maintainer can't make the call as to whether a rendering bug is >> more important than day-1 vulkan conformance, for example. >> >> We could heighten the transparency of what is blocking the build by >> publicizing the authors of bisected blocking bugs to Phoronix, which >> might get things moving. > > I hope you're being sarcastic here, or else I'm misunderstanding your > proposal. Public shaming of developers who create bugs has absolutely > no place in the Mesa community, IMHO. It would foster the kind of toxic > community that none of us want to be a part of. Agreed! signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965: Silence compiler warning about promoted_constants.
We only have a cfg != NULL if we went through one of the paths that set
it, but my compiler doesn't figure that out.
Cc: Jason Ekstrand
Fixes: 6411defdcd6f ("intel/cs: Re-run final NIR optimizations for each SIMD
size")
---
src/intel/compiler/brw_fs.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 422eedcf0af1..8529fda6f091 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -7220,7 +7220,7 @@ brw_compile_cs(const struct brw_compiler *compiler, void
*log_data,
fs_visitor *v8 = NULL, *v16 = NULL, *v32 = NULL;
cfg_t *cfg = NULL;
const char *fail_msg = NULL;
- unsigned promoted_constants;
+ unsigned promoted_constants = 0;
/* Now the main event: Visit the shader IR and generate our CS IR for it.
*/
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] anv: Silence warning about heap_size.
We only get VK_SUCCESS if it was initialized, but apparently my compiler doesn't track that far. Cc: Jason Ekstrand --- src/intel/vulkan/anv_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c index d8c4e9863164..030862a6753c 100644 --- a/src/intel/vulkan/anv_device.c +++ b/src/intel/vulkan/anv_device.c @@ -110,7 +110,7 @@ anv_physical_device_init_heaps(struct anv_physical_device *device, int fd) device->supports_48bit_addresses = (device->info.gen >= 8) && anv_gem_supports_48b_addresses(fd); - uint64_t heap_size; + uint64_t heap_size = 0; VkResult result = anv_compute_heap_size(fd, &heap_size); if (result != VK_SUCCESS) return result; -- 2.16.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] anv: Silence compiler warnings about uninitialized bind_offset.
This is a legitimate warning: if anv's blorp_alloc_binding_table() throws
an error from anv_cmd_buffer_alloc_blorp_binding_table(), we silently
continue to use this undefined value. The rest of this code doesn't seem
very allocation-error-proof, though, either.
Cc: Jason Ekstrand
---
src/intel/blorp/blorp_genX_exec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/blorp/blorp_genX_exec.h
b/src/intel/blorp/blorp_genX_exec.h
index 1348659233c4..5b59af491ee8 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -1388,7 +1388,7 @@ blorp_emit_surface_states(struct blorp_batch *batch,
const struct blorp_params *params)
{
const struct isl_device *isl_dev = batch->blorp->isl_dev;
- uint32_t bind_offset, surface_offsets[2];
+ uint32_t bind_offset = 0, surface_offsets[2];
void *surface_maps[2];
MAYBE_UNUSED bool has_indirect_clear_color = false;
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] intel/blorp: Fix compiler warning about num_layers.
The compiler doesn't notice that the condition for num_layers to be
undefined already defined it above (as our assert checked in a debug
build).
Cc: Jason Ekstrand
---
src/mesa/drivers/dri/i965/brw_blorp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 1d586e5ef38d..2b8d913fa282 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1408,6 +1408,7 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
assert(level == irb->mt_level);
assert(start_layer == irb->mt_layer);
assert(num_layers == fb->MaxNumLayers ? irb->layer_count : 1);
+ num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
} else {
level = irb->mt_level;
start_layer = irb->mt_layer;
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: Use hash table cloning in copy propagation
Thomas Helland writes:
> Walking the whole hash table, inserting entries by hashing them first
> is just a really bad idea. We can simply memcpy the whole thing.
> ---
> src/compiler/glsl/opt_copy_propagation.cpp | 13 --
> .../glsl/opt_copy_propagation_elements.cpp | 29
> --
> 2 files changed, 15 insertions(+), 27 deletions(-)
>
> diff --git a/src/compiler/glsl/opt_copy_propagation.cpp
> b/src/compiler/glsl/opt_copy_propagation.cpp
> index e904e6ede4..96667779da 100644
> --- a/src/compiler/glsl/opt_copy_propagation.cpp
> +++ b/src/compiler/glsl/opt_copy_propagation.cpp
> @@ -220,10 +220,7 @@ ir_copy_propagation_visitor::handle_if_block(exec_list
> *instructions)
> this->killed_all = false;
>
> /* Populate the initial acp with a copy of the original */
> - struct hash_entry *entry;
> - hash_table_foreach(orig_acp, entry) {
> - _mesa_hash_table_insert(acp, entry->key, entry->data);
> - }
> + acp = _mesa_hash_table_clone(orig_acp, NULL);
Remove creation of acp above
>
> visit_list_elements(this, instructions);
>
> @@ -271,10 +268,10 @@ ir_copy_propagation_visitor::handle_loop(ir_loop *ir,
> bool keep_acp)
> this->killed_all = false;
>
> if (keep_acp) {
> - struct hash_entry *entry;
> - hash_table_foreach(orig_acp, entry) {
> - _mesa_hash_table_insert(acp, entry->key, entry->data);
> - }
> + acp = _mesa_hash_table_clone(orig_acp, NULL);
> + } else {
> + acp = _mesa_hash_table_create(NULL, _mesa_hash_pointer,
> + _mesa_key_pointer_equal);
> }
Again, remove the old creation of the acp.
Other than that, these are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH RESEND] spirv: Silence compiler warning about undefined srcs[0]
v2: Use assume() at the srcs[] definition instead.
Cc: Jason Ekstrand
Cc: Ian Romanick
Cc: Eric Engestrom
---
src/compiler/spirv/spirv_to_nir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
index 6a358c597316..3de45c47371e 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -2925,6 +2925,7 @@ vtn_handle_composite(struct vtn_builder *b, SpvOp opcode,
case SpvOpCompositeConstruct: {
unsigned elems = count - 3;
+ assume(elems >= 1);
if (glsl_type_is_vector_or_scalar(type)) {
nir_ssa_def *srcs[4];
for (unsigned i = 0; i < elems; i++)
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] meson: Use system_has_kms_drm in default driver selection
Greg V writes: > --- I've pushed this patch with Dylan's and my review on it. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/56] anv/entrypoints: Generalize the string map a bit
Jason Ekstrand writes: > On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker wrote: > >> Quoting Jason Ekstrand (2018-03-07 20:22:51) >> > Yes, that is what happened. That said, wrote that patch in September and >> > you've had about 6 months to look at it. The only particularly active >> Mesa >> > contributor who hasn't had access is Ilia. >> >> No, just no. Having a patch in a branch does not count, especially not in a >> closed branch. I have plenty of patches that have sat in branches for >> months, >> years even. You're saying it's okay for me to send them to the list and >> push >> them a couple hours later because I wrote them a long time ago? > > > No, that's not what I'm saying. However, I think there's a difference > between a private branch that you've had sitting around for a while and a > mostly public branch that you've been pestering your coworkers to review > for the past 6 months and gotten zero takers. Every single patch I sent > had been reviewed and many of them by multiple people. > > This is something that we as a community (and team) need to sort out. With > both hardware enabling and new extension work, we are working with > embargoes. Sometimes large pieces of work go into enabling said hardware > and features. This series was fairly small at 56 patches; If you look at > all of Vulkan 1.1, it's probably more like 500. If we wait until it's > public to get code review, you may be looking at weeks or months before you > can land it. > > This problem is only getting worse now that the mesa project is getting > caught up on features. It used to be that we could do basically everything > publicly because we were several whole GL versions behind and basically > zero feature work was embargoed. The only people working with an embargo > were people doing hardware enabling and they were sending the patches out > months before the hardware was available to anyone so waiting a week or two > doesn't matter. Now, basically everything we do that isn't refactoring or > optimization work has to happen behind closed doors. It's unfortunate, but > it's also reality. > > How do we deal with that as an open-source community? That's a good > question and one which I'm happy to discuss. I'm not sure what the right > balance is here but the "it doesn't exist until it's public" model just > isn't fair to the people who are in the unfortunate circumstance of working > under an embargo. > > On Thu, Mar 8, 2018 at 10:37 AM, Michel Dänzer wrote: > >> On 2018-03-08 06:10 PM, Dylan Baker wrote: >> > >> > When I was given commit access I was told that I should wait 24 hours >> > after sending patches unless they were trivial or fixed something >> > critical, ie, without them you can't compile or nothing works. >> >> FWIW, I think that's a good rule, and I follow it. >> >> If one doesn't wait for at least 24 hours, e.g. somebody living in a >> different timezone may not get a chance to send feedback before the >> patch is applied. So it's kind of implying one isn't interested in >> feedback from such people. >> > > I agree. 24 hours means one turn of the globe and pushing much faster than > that does sort-of imply that you don't care about that feedback. In this > case, the only thing that's implied is that I don't care too much about > feedback from the 5% of the mesa community who doesn't have a Khronos > account. Maybe that makes me a jerk, but I didn't think it did. > > >> > I know we've always given a lot of flexibility to vendor specific code >> > (i965 or nouveau), but you hope everyone can understand my frustration >> > with a 56 patch series that I sent review for 8 hours after it was >> > posted to the list and I got told "Oh, I merged that hours ago, >> > patches welcome." >> >> I can. I guess Jason got a bit carried away by the Vulkan 1.1 excitement. >> > > Perhaps. :-) I do think that being there day-1 is important. If nothing > else, it shows the rest of the graphics community (who already fears the > concept of open-source) that working in the open isn't going to cramp their > style. If we can deliver full-featured and fully conformant Vulkan 1.1 > drivers on day 1, then they can to. I think that's an important message > for the open-source community to send. I completely agree here. We have git. We can change code after it lands. The value we as a project get from having day 1 support is huge, and the value of getting our python style polished before any patches land is... well, it doesn't even compare. Also, I feel that if the Vulkan driver implementors are happy with this Vulkan driver support code, then that trumps style requests from others. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] meson: make GLX_USE_TLS optional
Greg V writes:
> FreeBSD builds Mesa with --disable-glx-tls in autotools because:
> https://github.com/dumbbell/test-tls-initial-exec
>
> Add the equivalent option to Meson.
> ---
> meson.build | 5 -
> meson_options.txt | 6 ++
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index e71f4ddd73..1c4293d464 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -329,7 +329,10 @@ if with_egl and not (with_platform_drm or
> with_platform_surfaceless)
>endif
> endif
>
> -pre_args += '-DGLX_USE_TLS'
> +if get_option('glx-tls')
> + pre_args += '-DGLX_USE_TLS'
> +endif
Instead of introducing an option, could we just test
host_machine.system() for freebsd here, so that nobody on any OS can
choose the wrong value?
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] meson: Allow building dri based EGL without GLX
Dylan Baker writes: > It should be possible to build EGL without GLX, but the meson build > currently doesn't allow that because it too tightly couples glx and dri. > This patch eases dri and glx apart, so that EGL without GLX can be > built. These are: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallium: Add a util_blitter path for using a custom VS and FS.
Like the r600 paths to use other custom states, we pass in a couple of
parameters to customize the innards of the blitter. It's up to the caller
to wrap other state necessary for its shaders (for example, constant
buffers for the uniforms the shader uses).
---
src/gallium/auxiliary/util/u_blitter.c | 64 ++
src/gallium/auxiliary/util/u_blitter.h | 5 +++
2 files changed, 69 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 98c3ac5df3af..4748627fc523 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -129,6 +129,8 @@ struct blitter_context_priv
unsigned dst_width;
unsigned dst_height;
+ void *custom_vs;
+
bool has_geometry_shader;
bool has_tessellation;
bool has_layered;
@@ -2564,3 +2566,65 @@ void util_blitter_custom_color(struct blitter_context
*blitter,
util_blitter_restore_render_cond(blitter);
util_blitter_unset_running_flag(blitter);
}
+
+static void *get_custom_vs(struct blitter_context *blitter)
+{
+ struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
+
+ return ctx->custom_vs;
+}
+
+/**
+ * Performs a custom blit to the destination surface, using the VS and FS
+ * provided.
+ *
+ * Used by vc4 for the 8-bit linear-to-tiled blit.
+ */
+void util_blitter_custom_shader(struct blitter_context *blitter,
+struct pipe_surface *dstsurf,
+void *custom_vs, void *custom_fs)
+{
+ struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
+ struct pipe_context *pipe = ctx->base.pipe;
+ struct pipe_framebuffer_state fb_state;
+
+ ctx->custom_vs = custom_vs;
+
+ assert(dstsurf->texture);
+ if (!dstsurf->texture)
+ return;
+
+ /* check the saved state */
+ util_blitter_set_running_flag(blitter);
+ blitter_check_saved_vertex_states(ctx);
+ blitter_check_saved_fragment_states(ctx);
+ blitter_check_saved_fb_state(ctx);
+ blitter_disable_render_cond(ctx);
+
+ /* bind states */
+ pipe->bind_blend_state(pipe, ctx->blend[PIPE_MASK_RGBA][0]);
+ pipe->bind_depth_stencil_alpha_state(pipe, ctx->dsa_keep_depth_stencil);
+ pipe->bind_fs_state(pipe, custom_fs);
+ pipe->set_sample_mask(pipe, (1ull << MAX2(1, dstsurf->texture->nr_samples))
- 1);
+
+ /* set a framebuffer state */
+ fb_state.width = dstsurf->width;
+ fb_state.height = dstsurf->height;
+ fb_state.nr_cbufs = 1;
+ fb_state.cbufs[0] = dstsurf;
+ fb_state.zsbuf = 0;
+ pipe->set_framebuffer_state(pipe, &fb_state);
+ pipe->set_sample_mask(pipe, ~0);
+
+ blitter_set_common_draw_rect_state(ctx, false);
+ blitter_set_dst_dimensions(ctx, dstsurf->width, dstsurf->height);
+ blitter->draw_rectangle(blitter, ctx->velem_state, get_custom_vs,
+ 0, 0, dstsurf->width, dstsurf->height,
+ 0, 1, UTIL_BLITTER_ATTRIB_NONE, NULL);
+
+ util_blitter_restore_vertex_states(blitter);
+ util_blitter_restore_fragment_states(blitter);
+ util_blitter_restore_fb_state(blitter);
+ util_blitter_restore_render_cond(blitter);
+ util_blitter_unset_running_flag(blitter);
+}
diff --git a/src/gallium/auxiliary/util/u_blitter.h
b/src/gallium/auxiliary/util/u_blitter.h
index dba773906aef..9e945983baac 100644
--- a/src/gallium/auxiliary/util/u_blitter.h
+++ b/src/gallium/auxiliary/util/u_blitter.h
@@ -384,6 +384,11 @@ void util_blitter_custom_resolve_color(struct
blitter_context *blitter,
void *custom_blend,
enum pipe_format format);
+/* Used by vc4 for 8/16-bit linear-to-tiled blits */
+void util_blitter_custom_shader(struct blitter_context *blitter,
+struct pipe_surface *dstsurf,
+void *custom_vs, void *custom_fs);
+
/* The functions below should be used to save currently bound constant state
* objects inside a driver. The objects are automatically restored at the end
* of the util_blitter_{clear, copy_region, fill_region} functions and then
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] broadcom/vc4: Add an accelerated path to turn raster R8/RG88 into tiled.
Drawing a 1080p YV12 video stream generated by MMAL goes from 10.5 FPS to
36.
---
src/gallium/drivers/vc4/vc4_blit.c| 200 ++
src/gallium/drivers/vc4/vc4_context.c | 7 ++
src/gallium/drivers/vc4/vc4_context.h | 4 +
3 files changed, 211 insertions(+)
diff --git a/src/gallium/drivers/vc4/vc4_blit.c
b/src/gallium/drivers/vc4/vc4_blit.c
index f23f74c8f169..7543e9d4aa08 100644
--- a/src/gallium/drivers/vc4/vc4_blit.c
+++ b/src/gallium/drivers/vc4/vc4_blit.c
@@ -24,6 +24,7 @@
#include "util/u_format.h"
#include "util/u_surface.h"
#include "util/u_blitter.h"
+#include "nir_builder.h"
#include "vc4_context.h"
static struct pipe_surface *
@@ -183,9 +184,139 @@ vc4_blitter_save(struct vc4_context *vc4)
vc4->fragtex.num_textures, vc4->fragtex.textures);
}
+static void *vc4_get_yuv_vs(struct pipe_context *pctx)
+{
+ struct vc4_context *vc4 = vc4_context(pctx);
+ struct pipe_screen *pscreen = pctx->screen;
+
+ if (vc4->yuv_linear_blit_vs)
+ return vc4->yuv_linear_blit_vs;
+
+ const struct nir_shader_compiler_options *options =
+ pscreen->get_compiler_options(pscreen,
+ PIPE_SHADER_IR_NIR,
+ PIPE_SHADER_VERTEX);
+
+ nir_builder b;
+ nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_VERTEX, options);
+ b.shader->info.name = ralloc_strdup(b.shader, "linear_blit_vs");
+
+ const struct glsl_type *vec4 = glsl_vec4_type();
+ nir_variable *pos_in = nir_variable_create(b.shader, nir_var_shader_in,
+ vec4, "pos");
+
+ nir_variable *pos_out = nir_variable_create(b.shader, nir_var_shader_out,
+ vec4, "gl_Position");
+ pos_out->data.location = VARYING_SLOT_POS;
+
+ nir_store_var(&b, pos_out, nir_load_var(&b, pos_in), 0xf);
+
+ struct pipe_shader_state shader_tmpl = {
+ .type = PIPE_SHADER_IR_NIR,
+ .ir.nir = b.shader,
+ };
+
+ vc4->yuv_linear_blit_vs = pctx->create_vs_state(pctx, &shader_tmpl);
+
+ return vc4->yuv_linear_blit_vs;
+}
+
+static void *vc4_get_yuv_fs(struct pipe_context *pctx, int cpp)
+{
+ struct vc4_context *vc4 = vc4_context(pctx);
+ struct pipe_screen *pscreen = pctx->screen;
+ struct pipe_shader_state **cached_shader;
+ const char *name;
+
+ if (cpp == 1) {
+ cached_shader = &vc4->yuv_linear_blit_fs_8bit;
+ name = "linear_blit_8bit_fs";
+ } else {
+ cached_shader = &vc4->yuv_linear_blit_fs_16bit;
+ name = "linear_blit_16bit_fs";
+ }
+
+ if (*cached_shader)
+ return *cached_shader;
+
+ const struct nir_shader_compiler_options *options =
+ pscreen->get_compiler_options(pscreen,
+ PIPE_SHADER_IR_NIR,
+ PIPE_SHADER_FRAGMENT);
+
+ nir_builder b;
+ nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT, options);
+ b.shader->info.name = ralloc_strdup(b.shader, name);
+
+ const struct glsl_type *vec4 = glsl_vec4_type();
+ const struct glsl_type *glsl_int = glsl_int_type();
+
+ nir_variable *color_out = nir_variable_create(b.shader, nir_var_shader_out,
+ vec4, "f_color");
+ color_out->data.location = FRAG_RESULT_COLOR;
+
+ nir_variable *pos_in = nir_variable_create(b.shader, nir_var_shader_in,
+ vec4, "pos");
+ pos_in->data.location = VARYING_SLOT_POS;
+ nir_ssa_def *pos = nir_load_var(&b, pos_in);
+
+ nir_ssa_def *one = nir_imm_int(&b, 1);
+ nir_ssa_def *two = nir_imm_int(&b, 2);
+
+ nir_ssa_def *x = nir_f2i32(&b, nir_channel(&b, pos, 0));
+ nir_ssa_def *y = nir_f2i32(&b, nir_channel(&b, pos, 1));
+
+ nir_variable *stride_in = nir_variable_create(b.shader, nir_var_uniform,
+ glsl_int, "stride");
+ nir_ssa_def *stride = nir_load_var(&b, stride_in);
+
+ nir_ssa_def *x_offset;
+ nir_ssa_def *y_offset;
+ if (cpp == 1) {
+ nir_ssa_def *intra_utile_x_offset =
+ nir_ishl(&b, nir_iand(&b, x, one), two);
+ nir_ssa_def *inter_utile_x_offset =
+ nir_ishl(&b, nir_iand(&b, x, nir_imm_int(&b, ~3)), one);
+
+ x_offset = nir_iadd(&b,
+ intra_utile_x_offset,
+ inter_utile_x_offset);
+ y_offset = nir_imul(&b,
+ nir_iadd(&b,
+nir_ishl(&b, y, one),
+nir_ushr(&b, nir_iand(&b, x, two),
one)),
+ stride);
+ } else {
+ x_offset = nir_ishl(&b, x, two);
+ y_offset = nir_imul(&b, y, stride);
+ }
+
+ nir_intrinsic_instr *load =
+ nir_intrinsic_instr_create(b.shader, nir_intrinsic_load_
Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete
Rob Clark writes: > On Wed, Feb 28, 2018 at 4:09 PM, Eric Anholt wrote: >> Matt Turner writes: >> >>> I find this script *really* annoying. Getting Cc'd on a random sample of >>> a series is doing it wrong. Cc lists of 14 people is doing it wrong. >>> >>> Let's start the negotiation with "delete this script" and see if anyone >>> can come up with a way of making this not so stupid. >> >> Patch submission done well IMO would be something like github PRs, with >> a bot that auto-tags people based on a MAINTAINERS-style opt-in for >> reviewing certain paths within the tree. >> >> I don't think get_reviewers.pl improves the git-send-email situation >> compared to maintainers needing to manage email filters. It's not >> consistent, so you need to indoctrinate new submitters (more barriers to >> entry!) and maintainers need to maintain their mail filters anyway. > > Hmm, you have mail filters that parse paths in git patches? No, I actually skim all the patches. But it's what you'd have to do if you want to actually see all patches to your area and not actually skim all the patches yourself, since get_reviewer.pl isn't (and won't ever be) used universally. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/13] nir: add load_param
Rob Clark writes:
> From: Karol Herbst
>
> OpenCL kernels have parameters (see pipe_grid_info::input), and so we
> need a way to access them.
>
> Signed-off-by: Rob Clark
>
> ---
> src/compiler/nir/nir_intrinsics.h | 2 ++
> src/compiler/nir/nir_lower_io.c | 13 ++---
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/nir/nir_intrinsics.h
> b/src/compiler/nir/nir_intrinsics.h
> index ede29277876..0915c5e809f 100644
> --- a/src/compiler/nir/nir_intrinsics.h
> +++ b/src/compiler/nir/nir_intrinsics.h
> @@ -435,6 +435,8 @@ LOAD(ubo, 2, 0, xx, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE |
> NIR_INTRINSIC_CAN_REOR
> LOAD(input, 1, 2, BASE, COMPONENT, xx, NIR_INTRINSIC_CAN_ELIMINATE |
> NIR_INTRINSIC_CAN_REORDER)
> /* src[] = { vertex, offset }. const_index[] = { base, component } */
> LOAD(per_vertex_input, 2, 2, BASE, COMPONENT, xx,
> NIR_INTRINSIC_CAN_ELIMINATE | NIR_INTRINSIC_CAN_REORDER)
> +/* src[] = { }. const_index[] = { base } */
> +LOAD(param, 0, 1, BASE, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE |
> NIR_INTRINSIC_CAN_REORDER)
I know this is a new request compared to the existing pattern, but could
you put a comment describing what load_param does in the code as well as
the commit message? Especially what the meaning of the base is. We've
been bad at this in NIR, and it makes learning how to write a new NIR
backend more challenging than it should be.
Also, what makes these params different from UBOs or default uniforms?
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete
Matt Turner writes: > I find this script *really* annoying. Getting Cc'd on a random sample of > a series is doing it wrong. Cc lists of 14 people is doing it wrong. > > Let's start the negotiation with "delete this script" and see if anyone > can come up with a way of making this not so stupid. Patch submission done well IMO would be something like github PRs, with a bot that auto-tags people based on a MAINTAINERS-style opt-in for reviewing certain paths within the tree. I don't think get_reviewers.pl improves the git-send-email situation compared to maintainers needing to manage email filters. It's not consistent, so you need to indoctrinate new submitters (more barriers to entry!) and maintainers need to maintain their mail filters anyway. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ttn: remove {varying_slot, frag_result}_to_tgsi_semantic helpers
Emil Velikov writes: > From: Emil Velikov > > The respective drivers have been updated and the helpers are no longer > needed. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gbm: Fix the alpha masks in the GBM format table.
Once GBM started looking at the values of the alpha masks, ARGB/ABGR
wouldn't match any more because we had both A and R in the low bits.
Fixes: 2ed344645d65 ("gbm/dri: Add RGBA masks to GBM format table")
---
src/gbm/backends/dri/gbm_dri.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 0d088bd62b62..f987c04c1b7d 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -562,7 +562,7 @@ static const struct gbm_dri_visual gbm_dri_visuals_table[]
= {
},
{
GBM_FORMAT_ARGB, __DRI_IMAGE_FORMAT_ARGB,
- { 0x00ff, 0xff00, 0x00ff, 0x00ff },
+ { 0x00ff, 0xff00, 0x00ff, 0xff00 },
},
{
GBM_FORMAT_XBGR, __DRI_IMAGE_FORMAT_XBGR,
@@ -570,7 +570,7 @@ static const struct gbm_dri_visual gbm_dri_visuals_table[]
= {
},
{
GBM_FORMAT_ABGR, __DRI_IMAGE_FORMAT_ABGR,
- { 0x00ff, 0xff00, 0x00ff, 0x00ff },
+ { 0x00ff, 0xff00, 0x00ff, 0xff00 },
},
{
GBM_FORMAT_XRGB2101010, __DRI_IMAGE_FORMAT_XRGB2101010,
--
2.16.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
Kristian Høgsberg writes: > On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher wrote: > >> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace > wrote: >> > On Thu 21 Dec 2017, Daniel Vetter wrote: >> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen < > hoegsb...@google.com> wrote: >> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico < > mvicom...@nvidia.com> wrote: >> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg < > hoegsb...@gmail.com> wrote: >> > I'd like to see concrete examples of actual display controllers >> > supporting more format layouts than what can be specified with a 64 >> > bit modifier. >> >> The main problem is our tiling and other metadata parameters can't >> generally fit in a modifier, so we find passing a blob of metadata a >> more suitable mechanism. >> >>> >> >>> I understand that you may have n knobs with a total of more than a > total of >> >>> 56 bits that configure your tiling/swizzling for color buffers. What > I don't >> >>> buy is that you need all those combinations when passing buffers > around >> >>> between codecs, cameras and display controllers. Even if you're > sharing >> >>> between the same 3D drivers in different processes, I expect just > locking >> >>> down, say, 64 different combinations (you can add more over time) and >> >>> assigning each a modifier would be sufficient. I doubt you'd extract >> >>> meaningful performance gains from going all the way to a blob. >> > >> > I agree with Kristian above. In my opinion, choosing to encode in >> > modifiers a precise description of every possible tiling/compression >> > layout is not technically incorrect, but I believe it misses the point. >> > The intention behind modifiers is not to exhaustively describe all >> > possibilites. >> > >> > I summarized this opinion in VK_EXT_image_drm_format_modifier, >> > where I wrote an "introdution to modifiers" section. Here's an excerpt: >> > >> > One goal of modifiers in the Linux ecosystem is to enumerate for > each >> > vendor a reasonably sized set of tiling formats that are > appropriate for >> > images shared across processes, APIs, and/or devices, where each >> > participating component may possibly be from different vendors. >> > A non-goal is to enumerate all tiling formats supported by all > vendors. >> > Some tiling formats used internally by vendors are inappropriate for >> > sharing; no modifiers should be assigned to such tiling formats. > >> Where it gets tricky is how to select that subset? Our tiling mode >> are defined more by the asic specific constraints than the tiling mode >> itself. At a high level we have basically 3 tiling modes (out of 16 >> possible) that would be the minimum we'd want to expose for gfx6-8. >> gfx9 uses a completely new scheme. >> 1. Linear (per asic stride requirements, not usable by many hw blocks) >> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick) >> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible), >> tile split (7 possible), sample split (4 possible), num banks (4 >> possible), bank width (4 possible), bank height (4 possible), macro >> tile aspect (4 possible) all of which are asic config specific) > >> I guess we could do something like: >> AMD_GFX6_LINEAR_ALIGNED_64B >> AMD_GFX6_LINEAR_ALIGNED_256B >> AMD_GFX6_LINEAR_ALIGNED_512B >> AMD_GFX6_1D_THIN_DISPLAY >> AMD_GFX6_1D_THIN_DEPTH >> AMD_GFX6_1D_THIN_ROTATED >> AMD_GFX6_1D_THIN_THIN >> AMD_GFX6_1D_THIN_THICK > > AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > > AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 >> etc. > >> We only probably need 40 bits to encode all of the tiling parameters >> so we could do family, plus
[Mesa-dev] [PATCH 09/17 v2] spirv: Silence compiler warning about undefined srcs[0]
v2: Use assume() at the srcs[] definition instead.
Cc: Jason Ekstrand
Cc: Ian Romanick
Cc: Eric Engestrom
---
src/compiler/spirv/spirv_to_nir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
index c6df764682ec..e22fe25a2e82 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -2922,6 +2922,7 @@ vtn_handle_composite(struct vtn_builder *b, SpvOp opcode,
case SpvOpCompositeConstruct: {
unsigned elems = count - 3;
+ assume(elems >= 1);
if (glsl_type_is_vector_or_scalar(type)) {
nir_ssa_def *srcs[4];
for (unsigned i = 0; i < elems; i++)
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/17] loader: Fix compiler warnings about truncating the PCI ID path.
Ian Romanick writes:
> On 02/10/2018 08:33 AM, Eric Anholt wrote:
>> My build was producing:
>>
>> ../src/loader/loader.c:121:67: warning: ‘%1u’ directive output may be
>> truncated writing between 1 and 3 bytes into a region of size 2
>> [-Wformat-truncation=]
>>
>> and we can avoid this careful calculation by just using asprintf (as we do
>> elsewhere in the file).
>>
>> Cc: Eric Engestrom
>> ---
>> src/loader/loader.c | 15 +++
>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/loader/loader.c b/src/loader/loader.c
>> index 913b3dcac032..92b4c5204b19 100644
>> --- a/src/loader/loader.c
>> +++ b/src/loader/loader.c
>> @@ -110,17 +110,16 @@ static char *loader_get_dri_config_device_id(void)
>>
>> static char *drm_construct_id_path_tag(drmDevicePtr device)
>> {
>> -#define PCI_ID_PATH_TAG_LENGTH sizeof("pci-_xx_xx_x")
>> char *tag = NULL;
>>
>> if (device->bustype == DRM_BUS_PCI) {
>> -tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
>> -if (tag == NULL)
>> -return NULL;
>> -
>> -snprintf(tag, PCI_ID_PATH_TAG_LENGTH, "pci-%04x_%02x_%02x_%1u",
>> - device->businfo.pci->domain, device->businfo.pci->bus,
>> - device->businfo.pci->dev, device->businfo.pci->func);
>> + if (asprintf(&tag, "pci-%04x_%02x_%02x_%1u",
>> + device->businfo.pci->domain,
>> + device->businfo.pci->bus,
>> + device->businfo.pci->dev,
>> + device->businfo.pci->func) < 0) {
>> + return NULL;
>
> Won't tag be NULL on failure? Then you could just
>
> asprintf(&tag, "pci-%04x_%02x_%02x_%1u",
>device->businfo.pci->domain,
>device->businfo.pci->bus,
>device->businfo.pci->dev,
>device->businfo.pci->func);
> return tag;
"If memory allocation wasn't possible, or some other error occurs, these
functions will return -1, and the contents of strp are undefined."
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] meson: build gallium unit tests
Dylan Baker writes:
> Signed-off-by: Dylan Baker
> ---
> src/gallium/tests/meson.build | 1 +-
> src/gallium/tests/unit/meson.build | 31 +++-
> 2 files changed, 32 insertions(+)
> create mode 100644 src/gallium/tests/unit/meson.build
>
> diff --git a/src/gallium/tests/meson.build b/src/gallium/tests/meson.build
> index 1779874..7e45d13 100644
> --- a/src/gallium/tests/meson.build
> +++ b/src/gallium/tests/meson.build
> @@ -19,3 +19,4 @@
> # SOFTWARE.
>
> subdir('trivial')
> +subdir('unit')
> diff --git a/src/gallium/tests/unit/meson.build
> b/src/gallium/tests/unit/meson.build
> new file mode 100644
> index 000..f320c56
> --- /dev/null
> +++ b/src/gallium/tests/unit/meson.build
> @@ -0,0 +1,31 @@
> +# Copyright © 2018 Intel Corporation
> +
> +# Permission is hereby granted, free of charge, to any person obtaining a
> copy
> +# of this software and associated documentation files (the "Software"), to
> deal
> +# in the Software without restriction, including without limitation the
> rights
> +# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> +# copies of the Software, and to permit persons to whom the Software is
> +# furnished to do so, subject to the following conditions:
> +
> +# The above copyright notice and this permission notice shall be included in
> +# all copies or substantial portions of the Software.
> +
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE
> +# SOFTWARE.
> +
> +foreach t : ['pipe_barrier_test', 'u_cache_test', 'u_half_test',
> + 'u_format_test', 'u_format_compatible_test', 'translate_test']
> + executable(
> +t,
> +'@0@.c'.format(t),
> +include_directories : [inc_common, inc_gallium_drivers,
> inc_gallium_winsys],
> +link_with : [libgallium, libmesa_util, libtrace, libws_null],
> +dependencies : [driver_swrast, dep_thread],
> +install : false,
> + )
> +endforeach
This should probably be gated on with_gallium_softpipe (so driver_swrast
is present). Other than that, patch 9-10 are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 17/17] glsl: Suppress sign-compare warning generated by flex 2.6.1.
I got the following warning:
src/compiler/glsl/glsl_lexer.cpp:1521:18: warning: comparison between signed
and unsigned integer expressions [-Wsign-compare]
for ( n = 0; n < max_size && \
src/compiler/glsl/glsl_lexer.cpp:3448:3: note: in expansion of macro ‘YY_INPUT’
YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
^~~~
and it doesn't look like something from our code. Just silence it.
---
src/compiler/glsl/meson.build | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/compiler/glsl/meson.build b/src/compiler/glsl/meson.build
index 26ab4f1c8d3a..12bf545132fd 100644
--- a/src/compiler/glsl/meson.build
+++ b/src/compiler/glsl/meson.build
@@ -199,13 +199,20 @@ files_libglsl_standalone = files(
'standalone.h',
)
+# flex 2.6.1 generates code with sign-compare warnings
+glsl_lexer_warnings_suppressed = static_library('glsl-lexer',
+ glsl_lexer_cpp,
+ cpp_args : [cpp_vis_args, cpp_msvc_compat_args, '-Wno-sign-compare'],
+ include_directories : [inc_common, inc_compiler, inc_nir],
+)
+
libglsl = static_library(
'glsl',
- [files_libglsl, glsl_parser, glsl_lexer_cpp, ir_expression_operation_h,
+ [files_libglsl, glsl_parser, ir_expression_operation_h,
ir_expression_operation_strings_h, ir_expression_operation_constant_h],
c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
- link_with : libglcpp,
+ link_with : [libglcpp, glsl_lexer_warnings_suppressed],
include_directories : [inc_common, inc_compiler, inc_nir],
dependencies : idep_nir,
build_by_default : false,
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/17] i965: Silence compiler warning about promoted_constants.
We only have a cfg != NULL if we went through one of the paths that set
it, but my compiler doesn't figure that out.
Cc: Jason Ekstrand
Fixes: 6411defdcd6f ("intel/cs: Re-run final NIR optimizations for each SIMD
size")
---
src/intel/compiler/brw_fs.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index bed632d21b91..8a81257b6522 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -7005,7 +7005,7 @@ brw_compile_cs(const struct brw_compiler *compiler, void
*log_data,
fs_visitor *v8 = NULL, *v16 = NULL, *v32 = NULL;
cfg_t *cfg = NULL;
const char *fail_msg = NULL;
- unsigned promoted_constants;
+ unsigned promoted_constants = 0;
/* Now the main event: Visit the shader IR and generate our CS IR for it.
*/
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/17] anv: Silence warning about heap_size.
We only get VK_SUCCESS if it was initialized, but apparently my compiler doesn't track that far. Cc: Jason Ekstrand --- src/intel/vulkan/anv_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c index 86c1bdc1d51d..ae3a29779c94 100644 --- a/src/intel/vulkan/anv_device.c +++ b/src/intel/vulkan/anv_device.c @@ -109,7 +109,7 @@ anv_physical_device_init_heaps(struct anv_physical_device *device, int fd) device->supports_48bit_addresses = (device->info.gen >= 8) && anv_gem_supports_48b_addresses(fd); - uint64_t heap_size; + uint64_t heap_size = 0; VkResult result = anv_compute_heap_size(fd, &heap_size); if (result != VK_SUCCESS) return result; -- 2.15.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/17] spirv: Silence compiler warning about undefined srcs[0]
It doesn't know that elems >= 1.
Cc: Jason Ekstrand
---
src/compiler/spirv/spirv_to_nir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
index c6df764682ec..f86d45511df8 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -2923,7 +2923,7 @@ vtn_handle_composite(struct vtn_builder *b, SpvOp opcode,
case SpvOpCompositeConstruct: {
unsigned elems = count - 3;
if (glsl_type_is_vector_or_scalar(type)) {
- nir_ssa_def *srcs[4];
+ nir_ssa_def *srcs[4] = { NULL };
for (unsigned i = 0; i < elems; i++)
srcs[i] = vtn_ssa_value(b, w[3 + i])->def;
val->ssa->def =
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/17] glsl: Silence warnings in the uniform initializer test about 16-bit types
They should probably get unit tests implemented, but this cleans up a
bunch of warnings in my build for now.
Fixes: 59f458cd8703 ("glsl: Add 16-bit types")
Cc: Eduardo Lima Mitev
---
src/compiler/glsl/tests/uniform_initializer_utils.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/compiler/glsl/tests/uniform_initializer_utils.cpp
b/src/compiler/glsl/tests/uniform_initializer_utils.cpp
index c5502b632697..701c8ef4d091 100644
--- a/src/compiler/glsl/tests/uniform_initializer_utils.cpp
+++ b/src/compiler/glsl/tests/uniform_initializer_utils.cpp
@@ -110,6 +110,9 @@ generate_data_element(void *mem_ctx, const glsl_type *type,
case GLSL_TYPE_INTERFACE:
case GLSL_TYPE_SUBROUTINE:
case GLSL_TYPE_FUNCTION:
+ case GLSL_TYPE_FLOAT16:
+ case GLSL_TYPE_UINT16:
+ case GLSL_TYPE_INT16:
ASSERT_TRUE(false);
break;
}
@@ -150,6 +153,9 @@ generate_data_element(void *mem_ctx, const glsl_type *type,
case GLSL_TYPE_INTERFACE:
case GLSL_TYPE_SUBROUTINE:
case GLSL_TYPE_FUNCTION:
+ case GLSL_TYPE_FLOAT16:
+ case GLSL_TYPE_UINT16:
+ case GLSL_TYPE_INT16:
ASSERT_TRUE(false);
break;
}
@@ -262,6 +268,9 @@ verify_data(gl_constant_value *storage, unsigned
storage_array_size,
case GLSL_TYPE_INTERFACE:
case GLSL_TYPE_SUBROUTINE:
case GLSL_TYPE_FUNCTION:
+ case GLSL_TYPE_FLOAT16:
+ case GLSL_TYPE_UINT16:
+ case GLSL_TYPE_INT16:
ASSERT_TRUE(false);
break;
}
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/17] loader: Fix compiler warnings about truncating the PCI ID path.
My build was producing:
../src/loader/loader.c:121:67: warning: ‘%1u’ directive output may be truncated
writing between 1 and 3 bytes into a region of size 2 [-Wformat-truncation=]
and we can avoid this careful calculation by just using asprintf (as we do
elsewhere in the file).
Cc: Eric Engestrom
---
src/loader/loader.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 913b3dcac032..92b4c5204b19 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -110,17 +110,16 @@ static char *loader_get_dri_config_device_id(void)
static char *drm_construct_id_path_tag(drmDevicePtr device)
{
-#define PCI_ID_PATH_TAG_LENGTH sizeof("pci-_xx_xx_x")
char *tag = NULL;
if (device->bustype == DRM_BUS_PCI) {
-tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
-if (tag == NULL)
-return NULL;
-
-snprintf(tag, PCI_ID_PATH_TAG_LENGTH, "pci-%04x_%02x_%02x_%1u",
- device->businfo.pci->domain, device->businfo.pci->bus,
- device->businfo.pci->dev, device->businfo.pci->func);
+ if (asprintf(&tag, "pci-%04x_%02x_%02x_%1u",
+ device->businfo.pci->domain,
+ device->businfo.pci->bus,
+ device->businfo.pci->dev,
+ device->businfo.pci->func) < 0) {
+ return NULL;
+ }
}
return tag;
}
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/17] anv: Silence compiler warnings about uninitialized bind_offset.
This is a legitimate warning: if anv's blorp_alloc_binding_table() throws
an error from anv_cmd_buffer_alloc_blorp_binding_table(), we silently
continue to use this undefined value. The rest of this code doesn't seem
very allocation-error-proof, though, either.
Cc: Jason Ekstrand
---
src/intel/blorp/blorp_genX_exec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/blorp/blorp_genX_exec.h
b/src/intel/blorp/blorp_genX_exec.h
index 5e1312aa305c..72554e25e1cf 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -1354,7 +1354,7 @@ blorp_emit_surface_states(struct blorp_batch *batch,
const struct blorp_params *params)
{
const struct isl_device *isl_dev = batch->blorp->isl_dev;
- uint32_t bind_offset, surface_offsets[2];
+ uint32_t bind_offset = 0, surface_offsets[2];
void *surface_maps[2];
MAYBE_UNUSED bool has_indirect_clear_color = false;
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/17] radv: Fix compiler warning about uninitialized 'set'
The compiler doesn't figure out that we only get result == VK_SUCCESS if
set got initialized.
Cc: Dave Airlie
---
src/amd/vulkan/radv_descriptor_set.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_descriptor_set.c
b/src/amd/vulkan/radv_descriptor_set.c
index bbabfa9b2755..056a5644dfa0 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -518,7 +518,7 @@ VkResult radv_AllocateDescriptorSets(
VkResult result = VK_SUCCESS;
uint32_t i;
- struct radv_descriptor_set *set;
+ struct radv_descriptor_set *set = NULL;
/* allocate a set of buffers for each shader to contain descriptors */
for (i = 0; i < pAllocateInfo->descriptorSetCount; i++) {
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/17] glsl/tests: Fix a compiler warning about signed/unsigned loop comparison.
Cc: Ian Romanick
Fixes: d32956935edf ("glsl: Walk a list of ir_dereference_array to mark array
elements as accessed")
---
src/compiler/glsl/tests/array_refcount_test.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/glsl/tests/array_refcount_test.cpp
b/src/compiler/glsl/tests/array_refcount_test.cpp
index ecd7f46900b8..0d8f4521caed 100644
--- a/src/compiler/glsl/tests/array_refcount_test.cpp
+++ b/src/compiler/glsl/tests/array_refcount_test.cpp
@@ -628,7 +628,7 @@ TEST_F(array_refcount_test, visit_array_indexing_an_array)
ir_array_refcount_entry *const entry_c = v.get_variable_entry(var_c);
- for (unsigned i = 0; i < var_c->type->array_size(); i++) {
+ for (int i = 0; i < var_c->type->array_size(); i++) {
EXPECT_EQ(true, entry_c->is_linearized_index_referenced(i)) <<
"array c, i = " << i;
}
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/17] glsl/tests: Fix strict aliasing warning about int64/double.
Cc: Rhys Kidd
Fixes: 4bf986274728 ("glsl/tests: Add UINT64 and INT64 types")
---
.../glsl/tests/uniform_initializer_utils.cpp | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/compiler/glsl/tests/uniform_initializer_utils.cpp
b/src/compiler/glsl/tests/uniform_initializer_utils.cpp
index 701c8ef4d091..0d7fa26752fd 100644
--- a/src/compiler/glsl/tests/uniform_initializer_utils.cpp
+++ b/src/compiler/glsl/tests/uniform_initializer_utils.cpp
@@ -204,6 +204,22 @@ generate_array_data(void *mem_ctx, enum glsl_base_type
base_type,
val = new(mem_ctx) ir_constant(array_type, &values_for_array);
}
+static uint64_t
+uint64_storage(union gl_constant_value *storage)
+{
+ uint64_t val;
+ memcpy(&val, &storage->i, sizeof(uint64_t));
+ return val;
+}
+
+static uint64_t
+double_storage(union gl_constant_value *storage)
+{
+ double val;
+ memcpy(&val, &storage->i, sizeof(double));
+ return val;
+}
+
/**
* Verify that the data stored for the uniform matches the initializer
*
@@ -252,13 +268,13 @@ verify_data(gl_constant_value *storage, unsigned
storage_array_size,
EXPECT_EQ(val->value.b[i] ? boolean_true : 0, storage[i].i);
break;
case GLSL_TYPE_DOUBLE:
- EXPECT_EQ(val->value.d[i], *(double *)&storage[i*2].i);
+ EXPECT_EQ(val->value.d[i], double_storage(&storage[i*2]));
break;
case GLSL_TYPE_UINT64:
- EXPECT_EQ(val->value.u64[i], *(uint64_t *)&storage[i*2].i);
+EXPECT_EQ(val->value.u64[i], uint64_storage(&storage[i*2]));
break;
case GLSL_TYPE_INT64:
- EXPECT_EQ(val->value.i64[i], *(int64_t *)&storage[i*2].i);
+ EXPECT_EQ(val->value.i64[i], uint64_storage(&storage[i*2]));
break;
case GLSL_TYPE_ATOMIC_UINT:
case GLSL_TYPE_STRUCT:
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/17] i965: Fix compiler warning about write being undefined.
This looks like it should be protected by the assume() about
nr_color_regions, but my compiler warns anyway.
Cc: Matt Turner
---
src/intel/compiler/brw_fs.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 6fb46e7374c0..bed632d21b91 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -3070,7 +3070,7 @@ fs_visitor::emit_repclear_shader()
.MOV(vec4(brw_message_reg(color_mrf)), fs_reg(reg));
}
- fs_inst *write;
+ fs_inst *write = NULL;
if (key->nr_color_regions == 1) {
write = bld.emit(FS_OPCODE_REP_FB_WRITE);
write->saturate = key->clamp_fragment_color;
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/17] ac/nir: Fix compiler warning about uninitialized dw_addr.
Even switching the def's condition to be the same chip revision check as
the use, the compiler doesn't figure it out. Just NULL-init it.
Fixes: ec53e527421d ("ac/nir: Add ES output to LDS for GFX9.")
Cc: Bas Nieuwenhuizen
---
src/amd/common/ac_nir_to_llvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cd128054962d..5485062a5bd6 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -6099,7 +6099,7 @@ handle_es_outputs_post(struct nir_to_llvm_context *ctx,
}
for (unsigned i = 0; i < RADEON_LLVM_MAX_OUTPUTS; ++i) {
- LLVMValueRef dw_addr;
+ LLVMValueRef dw_addr = NULL;
LLVMValueRef *out_ptr = &ctx->nir->outputs[i * 4];
int param_index;
int length = 4;
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/17] egl/gbm: Fix compiler warning about visual matching.
The compiler doesn't know that num_visuals > 0.
Fixes: 37a8d907cc16 ("egl/gbm: Ensure EGLConfigs match GBM surface format")
Cc: Daniel Stone
---
src/egl/drivers/dri2/platform_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index 3eabd678e92e..01fa1f11b953 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -95,7 +95,7 @@ dri2_drm_config_is_compatible(struct dri2_egl_display
*dri2_dpy,
const __DRIconfig *config,
struct gbm_surface *surface)
{
- const struct gbm_dri_visual *visual;
+ const struct gbm_dri_visual *visual = NULL;
unsigned int red, green, blue, alpha;
int i;
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/17] gallium/llvmpipe: Fix compiler warnings about ddx/ddy/ddmax.
My gcc doesn't figure out that dims >= 1 (seems reasonable), and doesn't
notice that ddmax is used from the same no_rho_opt as its initialization.
Cc: Roland Scheidegger
---
src/gallium/auxiliary/gallivm/lp_bld_sample.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample.c
index db3d9d65c9ca..ab9d051c9115 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample.c
@@ -275,7 +275,7 @@ lp_build_rho(struct lp_build_sample_context *bld,
rho = lp_build_mul(rho_bld, cubesize, rho);
}
else if (derivs) {
- LLVMValueRef ddmax[3], ddx[3], ddy[3];
+ LLVMValueRef ddmax[3] = { NULL }, ddx[3] = { NULL }, ddy[3] = { NULL };
for (i = 0; i < dims; i++) {
LLVMValueRef floatdim;
LLVMValueRef indexi = lp_build_const_int32(gallivm, i);
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/17] r200: Remove dead rop table
Fixes: 0aaa27f29187 ("mesa: Pass the translated color logic op
dd_function_table::LogicOpcode")
Cc: Ian Romanick
---
src/mesa/drivers/dri/r200/r200_state.c | 20
1 file changed, 20 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_state.c
b/src/mesa/drivers/dri/r200/r200_state.c
index 33b696347a3d..d53225d63abe 100644
--- a/src/mesa/drivers/dri/r200/r200_state.c
+++ b/src/mesa/drivers/dri/r200/r200_state.c
@@ -1626,26 +1626,6 @@ static void r200RenderMode( struct gl_context *ctx,
GLenum mode )
FALLBACK( rmesa, R200_FALLBACK_RENDER_MODE, (mode != GL_RENDER) );
}
-
-static GLuint r200_rop_tab[] = {
- R200_ROP_CLEAR,
- R200_ROP_AND,
- R200_ROP_AND_REVERSE,
- R200_ROP_COPY,
- R200_ROP_AND_INVERTED,
- R200_ROP_NOOP,
- R200_ROP_XOR,
- R200_ROP_OR,
- R200_ROP_NOR,
- R200_ROP_EQUIV,
- R200_ROP_INVERT,
- R200_ROP_OR_REVERSE,
- R200_ROP_COPY_INVERTED,
- R200_ROP_OR_INVERTED,
- R200_ROP_NAND,
- R200_ROP_SET,
-};
-
static void r200LogicOpCode(struct gl_context *ctx, enum gl_logicop_mode
opcode)
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/17] intel/blorp: Fix compiler warning about num_layers.
The compiler doesn't notice that the condition for num_layers to be
undefined already defined it above (as our assert checked in a debug
build).
Cc: Jason Ekstrand
---
src/mesa/drivers/dri/i965/brw_blorp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index aa62abde9c41..f483a78b82bf 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1404,6 +1404,7 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
assert(level == irb->mt_level);
assert(start_layer == irb->mt_layer);
assert(num_layers == fb->MaxNumLayers ? irb->layer_count : 1);
+ num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
} else {
level = irb->mt_level;
start_layer = irb->mt_layer;
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/17] gallium/util: Fix compiler warning about unknown pipe_filter_state.
Fixes: 6321b1bd4005 ("gallium/util: replace uint with tgsi enum types").
Cc: Brian Paul
---
src/gallium/auxiliary/util/u_blit.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.h
b/src/gallium/auxiliary/util/u_blit.h
index 085ea6357007..8fd24e5595c2 100644
--- a/src/gallium/auxiliary/util/u_blit.h
+++ b/src/gallium/auxiliary/util/u_blit.h
@@ -31,18 +31,14 @@
#include "pipe/p_compiler.h"
+#include "pipe/p_state.h"
#ifdef __cplusplus
extern "C" {
#endif
-
struct cso_context;
-struct pipe_context;
-struct pipe_resource;
-struct pipe_sampler_view;
-struct pipe_surface;
extern struct blit_state *
util_create_blit(struct pipe_context *pipe, struct cso_context *cso);
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] st/mesa: generate blend state according to the number of enabled color buffers
Marek Olšák writes: > From: Marek Olšák > > Non-MRT cases always translate blend state for 1 color buffer only. > MRT cases only check and translate blend state for enabled color buffers. > > This also avoids an assertion failure in translate_blend for: > > dEQP-GLES31.functional.draw_buffers_indexed.overwrite_common.common_advanced_blend_eq_buffer_blend_eq Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] st/mesa: don't translate blend state when color writes are disabled
Marek Olšák writes: > From: Marek Olšák Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] st/mesa: don't translate blend state when it's disabled for a colorbuffer
Marek Olšák writes:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_atom_blend.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_blend.c
> b/src/mesa/state_tracker/st_atom_blend.c
> index f7327d6..a5f7edb 100644
> --- a/src/mesa/state_tracker/st_atom_blend.c
> +++ b/src/mesa/state_tracker/st_atom_blend.c
> @@ -154,26 +154,27 @@ st_update_blend( struct st_context *st )
>blend->independent_blend_enable = 1;
> }
> if (ctx->Color.ColorLogicOpEnabled) {
>/* logicop enabled */
>blend->logicop_enable = 1;
>blend->logicop_func = ctx->Color._LogicOp;
> }
> else if (ctx->Color.BlendEnabled && !ctx->Color._AdvancedBlendMode) {
>/* blending enabled */
>for (i = 0, j = 0; i < num_state; i++) {
> + if (!(ctx->Color.BlendEnabled & (1 << i)))
> +continue;
>
> - blend->rt[i].blend_enable = (ctx->Color.BlendEnabled >> i) & 0x1;
> -
> - if (ctx->Extensions.ARB_draw_buffers_blend)
> + if (ctx->Extensions.ARB_draw_buffers_blend)
> j = i;
>
> + blend->rt[i].blend_enable = 1;
maybe 'true' instead of '1'?
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10.5/24] st/mesa: don't set sampler states for TBOs
Marek Olšák writes: > On Wed, Feb 7, 2018 at 1:33 AM, Ilia Mirkin wrote: >> This breaks nouveau (at least on nv50). Same deal as in commit >> 2b938a390c15a06be8cf706083890c822979508f which fixed a similar issue >> where this assumption that buffer doesn't need sampler was also >> temporarily introduced. >> >> Do I need to go change a ton of stuff in nouveau, or can we stick with >> the original rule where there's a always a sampler associated with a >> view? > > Updating sampler states here would add overhead to all drivers, so > let's consider it an nvidia hardware issue needing a workaround in > nouveau. VC5 also uses the sampler along with the view for all its sampler uniforms, so I guess I'll need to flag non-sampler-using sampler uniform references. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meson: Add build option for tools
Scott D Phillips writes: > Add a build option to control building some of the misc tools we > have. Also set the executables to install, presumably you want > that if you're asking for the build. I took a look, since I've got some WIP vc5 tools that really should live in Mesa instead of an external tree. I like it. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: change ctx->Color.ColorMask into a 32-bit bitmask
Marek Olšák writes:
> From: Marek Olšák
>
> 4 bits per draw buffer, 8 draw buffers in total --> 32 bits.
>
> This is easier to work with.
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_driver.c
> b/src/mesa/drivers/dri/nouveau/nouveau_driver.c
> index 998e751..018f65a 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_driver.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_driver.c
> @@ -125,21 +125,27 @@ nouveau_clear(struct gl_context *ctx, GLbitfield
> buffers)
> if (buf & BUFFER_BITS_COLOR) {
> const float *color = ctx->Color.ClearColor.f;
>
> if (fb->Attachment[i].Renderbuffer->_BaseFormat ==
> GL_LUMINANCE_ALPHA)
> value = pack_la_clamp_f(
> s->format, color[0], color[3]);
> else
> value = pack_rgba_clamp_f(s->format, color);
>
> - mask = pack_rgba_i(s->format, ctx->Color.ColorMask[0]);
> + const uint8_t colormask[4] = {
> + GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 0) ?
> 0xf : 0,
> + GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 1) ?
> 0xf : 0,
> + GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 2) ?
> 0xf : 0,
> + GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 3) ?
> 0xf : 0,
> + };
I think you meant 0xff instead of 0xf.
With this and Roland's other suggestion, the patch is:
Reviewed-by: Eric Anholt
(and now my plane is boarding)
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: enable ASTC format for CompressedTexSubImage3D
"Juan A. Suarez Romero" writes: > If extensions GL_KHR_texture_compression_astc_hdr or > GL_KHR_texture_compression_astc_sliced_3d are implemented then ASTC > format are supported in CompressedTex*Îmage3D. > > Fixes KHR-GLES2.texture_3d.* with this format. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] gallium: Add a new A4B4G4R4 pipe format for Broadcom.
The VC5 HW puts A in the low bits and R in the high bits. We can't just
swizzle in the shaders because the blending HW can't pick what channel A
is in, so make a new format to match it.
---
src/gallium/auxiliary/util/u_format.csv | 1 +
src/gallium/drivers/svga/svga_format.c | 1 +
src/gallium/include/pipe/p_format.h | 1 +
src/mesa/state_tracker/st_format.c | 8 +++-
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index 689895f400c9..f9e4925f27cc 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -78,6 +78,7 @@ PIPE_FORMAT_X1B5G5R5_UNORM, plain, 1, 1, x1 , un5 ,
un5 , un5 , wzy1, r
PIPE_FORMAT_A1B5G5R5_UNORM, plain, 1, 1, un1 , un5 , un5 , un5 , wzyx,
rgb, un5 , un5 , un5 , un1 , xyzw
PIPE_FORMAT_B4G4R4A4_UNORM, plain, 1, 1, un4 , un4 , un4 , un4 , zyxw,
rgb, un4 , un4 , un4 , un4 , yzwx
PIPE_FORMAT_B4G4R4X4_UNORM, plain, 1, 1, un4 , un4 , un4 , x4 , zyx1,
rgb, x4 , un4 , un4 , un4 , yzw1
+PIPE_FORMAT_A4B4G4R4_UNORM, plain, 1, 1, un4 , un4 , un4 , un4 , wzyx,
rgb, un4 , un4 , un4 , un4 , xyzw
PIPE_FORMAT_B5G6R5_UNORM , plain, 1, 1, un5 , un6 , un5 , , zyx1,
rgb, un5 , un6 , un5 , , xyz1
PIPE_FORMAT_R10G10B10A2_UNORM , plain, 1, 1, un10, un10, un10, un2 , xyzw,
rgb, un2 , un10, un10, un10, wzyx
PIPE_FORMAT_R10G10B10X2_UNORM , plain, 1, 1, un10, un10, un10, x2, xyz1,
rgb, x2 , un10, un10, un10, wzy1
diff --git a/src/gallium/drivers/svga/svga_format.c
b/src/gallium/drivers/svga/svga_format.c
index 964923f084ea..20a6e6b159f3 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -368,6 +368,7 @@ static const struct vgpu10_format_entry
format_conversion_table[] =
{ PIPE_FORMAT_R10G10B10X2_UNORM, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, 0 },
{ PIPE_FORMAT_A1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, 0 },
{ PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_A4B4G4R4_UNORM,SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, 0 },
};
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index fedac8a06d7e..57399800fa47 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -394,6 +394,7 @@ enum pipe_format {
PIPE_FORMAT_R10G10B10X2_UNORM = 308,
PIPE_FORMAT_A1B5G5R5_UNORM = 309,
PIPE_FORMAT_X1B5G5R5_UNORM = 310,
+ PIPE_FORMAT_A4B4G4R4_UNORM = 311,
PIPE_FORMAT_COUNT
};
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index cc72ba406e6e..c50ce1e14bb1 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -84,6 +84,8 @@ st_mesa_format_to_pipe_format(const struct st_context *st,
return PIPE_FORMAT_A1B5G5R5_UNORM;
case MESA_FORMAT_B4G4R4A4_UNORM:
return PIPE_FORMAT_B4G4R4A4_UNORM;
+ case MESA_FORMAT_A4B4G4R4_UNORM:
+ return PIPE_FORMAT_A4B4G4R4_UNORM;
case MESA_FORMAT_B5G6R5_UNORM:
return PIPE_FORMAT_B5G6R5_UNORM;
case MESA_FORMAT_B2G3R3_UNORM:
@@ -567,6 +569,8 @@ st_pipe_format_to_mesa_format(enum pipe_format format)
return MESA_FORMAT_A1B5G5R5_UNORM;
case PIPE_FORMAT_B4G4R4A4_UNORM:
return MESA_FORMAT_B4G4R4A4_UNORM;
+ case PIPE_FORMAT_A4B4G4R4_UNORM:
+ return MESA_FORMAT_A4B4G4R4_UNORM;
case PIPE_FORMAT_B5G6R5_UNORM:
return MESA_FORMAT_B5G6R5_UNORM;
case PIPE_FORMAT_B2G3R3_UNORM:
@@ -1155,7 +1159,8 @@ static const struct format_mapping format_map[] = {
},
{
{ GL_RGBA4, GL_RGBA2, 0 },
- { PIPE_FORMAT_B4G4R4A4_UNORM, DEFAULT_RGBA_FORMATS }
+ { PIPE_FORMAT_B4G4R4A4_UNORM, PIPE_FORMAT_A4B4G4R4_UNORM,
+DEFAULT_RGBA_FORMATS }
},
{
{ GL_RGB5_A1, 0 },
@@ -1170,6 +1175,7 @@ static const struct format_mapping format_map[] = {
{
{ GL_RGB4 },
{ PIPE_FORMAT_B4G4R4X4_UNORM, PIPE_FORMAT_B4G4R4A4_UNORM,
+PIPE_FORMAT_A4B4G4R4_UNORM,
DEFAULT_RGB_FORMATS }
},
{
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa: Drop incorrect A4B4G4R4 _mesa_format_matches_format_and_type() cases.
swapBytes operates on bytes, not 4-bit channels, so you can't just take
non-swapBytes cases and flip the REV flag.
Avoids piglit texture-packed-formats regressions when enabling the
ABGR format.
Fixes: c5a5c9a7db89 ("mesa/formats: add new mesa formats and their pack/unpack
functions.")
---
src/mesa/main/formats.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index c1d8641116ec..8d32757a8795 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -1568,15 +1568,9 @@ _mesa_format_matches_format_and_type(mesa_format
mesa_format,
if (format == GL_RGBA && type == GL_UNSIGNED_SHORT_4_4_4_4 && !swapBytes)
return GL_TRUE;
- if (format == GL_RGBA && type == GL_UNSIGNED_SHORT_4_4_4_4_REV &&
swapBytes)
- return GL_TRUE;
-
if (format == GL_ABGR_EXT && type == GL_UNSIGNED_SHORT_4_4_4_4_REV &&
!swapBytes)
return GL_TRUE;
- if (format == GL_ABGR_EXT && type == GL_UNSIGNED_SHORT_4_4_4_4 &&
swapBytes)
- return GL_TRUE;
-
return GL_FALSE;
case MESA_FORMAT_R4G4B4A4_UNORM:
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] broadcom/vc5: Switch our RGBA4 support to the new gallium format.
Fixes fbo-generatemipmap-formats, fbo-alphatest-formats, etc. tests for
GL_RGBA4, GL_RGB4, GL_RGBA2, etc.
---
src/gallium/drivers/vc5/v3dx_format_table.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/vc5/v3dx_format_table.c
b/src/gallium/drivers/vc5/v3dx_format_table.c
index 6d198a225f07..884f7373a173 100644
--- a/src/gallium/drivers/vc5/v3dx_format_table.c
+++ b/src/gallium/drivers/vc5/v3dx_format_table.c
@@ -70,8 +70,7 @@ static const struct vc5_format format_table[] = {
FORMAT(R10G10B10A2_UNORM, RGB10_A2, RGB10_A2,SWIZ_XYZW, 16, 0),
FORMAT(B10G10R10A2_UINT, RGB10_A2UI, RGB10_A2UI, SWIZ_ZYXW, 16, 0),
-FORMAT(B4G4R4A4_UNORM,ABGR, RGBA4, SWIZ_YZWX, 16, 0),
-FORMAT(B4G4R4X4_UNORM,ABGR, RGBA4, SWIZ_YZW1, 16, 0),
+FORMAT(A4B4G4R4_UNORM,ABGR, RGBA4, SWIZ_XYZW, 16, 0),
FORMAT(A1B5G5R5_UNORM,ABGR1555, RGB5_A1, SWIZ_XYZW, 16, 0),
FORMAT(X1B5G5R5_UNORM,ABGR1555, RGB5_A1, SWIZ_XYZ1, 16, 0),
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: remove pipe_blend_state::dither
Marek Olšák writes: > From: Marek Olšák > > very few drivers actually implement it. I disagree. If the hardware supports it and the API supports it, then we should support it, too. I've got a branch around somewhere for vc4 dithering. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/glsl_to_nir: add more nir opts to st_nir_opts()
Timothy Arceri writes: > All of the current gallium nir driver use these optimisations but > they do so in their backends. Having these called in the backend > only can cause a number of problems: > > - Shader compile times are greater because the opts need to do > significant passes over all shader variants. > - The shader cache is partially defeated due to the significant > optimisation passes over variants. > - We might miss out on nir linking optimisation opportunities. > > Adding these passes to st_nir_opts() alleviates these problems. Maybe some driver gaining NIR input would want vector math instead of scalar, but if all of our drivers agree at the moment, then let's put it here. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix glGet MAX_VERTEX_ATTRIB queries
Marek Olšák writes: > From: Marek Olšák > > Broken by f96a69f916aed40519e755d0460a83940a587 Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] mesa: enable ASTC/ETC1 compressed 3D textures
"Juan A. Suarez Romero" writes:
> Enable these kind of 3D texture when proper extensions are available.
>
> Fixes KHR-GLES2.texture_3d.* with these textures.
>
> v2: add better clarification (Eric)
> ---
> src/mesa/main/teximage.c | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index e5f8bb0718f..56235898c66 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1487,6 +1487,9 @@ _mesa_target_can_be_compressed(const struct gl_context
> *ctx, GLenum target,
>break;
> case GL_TEXTURE_3D:
>switch (layout) {
> + case MESA_FORMAT_LAYOUT_ETC1:
> + target_can_be_compresed =
> ctx->Extensions.OES_compressed_ETC1_RGB8_texture;
> + break;
>case MESA_FORMAT_LAYOUT_ETC2:
> /* See ETC2/EAC comment in case GL_TEXTURE_CUBE_MAP_ARRAY. */
OK, I took a look at the ETC2/EAC comment above, this time, and it looks
like 3D textures are supposed to be not supported with ETC2 or ASTC
according to table 8.17 in GLES 3.2.
This is looking more like a testcase bug to me.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] nir: Use a freelist in nir_opt_dce to avoid spamming ralloc
Thomas Helland writes: > Also, allocate worklist_elem in groups of 20, to reduce the burden of > allocation. Do not use rzalloc, as there is no need. This lets us drop > the number of calls to ralloc from aproximately 10% of all calls to > ralloc(130 000 calls), down to a mere 2000 calls to ralloc_array_size. > This cuts the runtime of shader-db by 1%, while at the same time > reducing the number of stalled cycles, executed cycles, and executed > instructions by about 1 % as reported by perf. I did a five-run > benchmark pre and post and got a statistical variance less than 0.1% pre > and post. This was with i965's ir validation polluting the benchmark, so > the numbers are even better in release builds. > > Performance change as found with perf-diff: > 4.74% -0.23% libc-2.26.so[.] _int_malloc > 1.88% -0.21% libc-2.26.so[.] malloc > 2.27% +0.16% libmesa_dri_drivers.so [.] match_value.part.7 > 2.95% -0.12% libc-2.26.so[.] _int_free > +0.11% libmesa_dri_drivers.so [.] worklist_push > 1.22% -0.08% libc-2.26.so[.] malloc_consolidate > 0.16% -0.06% libmesa_dri_drivers.so [.] mark_live_cb > 1.21% +0.06% libmesa_dri_drivers.so [.] match_expression.part.6 > 0.75% -0.05% libc-2.26.so[.] cfree@GLIBC_2.2.5 > 0.50% -0.05% libmesa_dri_drivers.so [.] ralloc_size > 0.57% +0.04% libmesa_dri_drivers.so [.] nir_replace_instr > 1.29% -0.04% libmesa_dri_drivers.so [.] unsafe_free I'm curious, since a NIR instruction worklist seems like a generally useful thing to have: Could nir_worklist.c keep the implementation of this? Also, I wonder if it wouldn't be even better to have a u_dynarray of instructions in the worklist, with push/pop on the end of the array, and a struct set tracking the instructions in the array to avoid double-adding. I actually don't know if that would be better or not, so I'd be happy with the worklist management just moved to nir_worklist.c. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: enable ASTC/ETC1 compressed textures
"Juan A. Suarez Romero" writes:
> Enable these kind of texture when proper extensions are available.
In the subject, s/textures/3D textures/ since it's surprising to hear
that they're not supported yet :)
> Fixes KHR-GLES2.texture_3d.* with these textures.
> ---
> src/mesa/main/teximage.c | 26 +++---
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index e5f8bb0718f..a9940de88b1 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1487,6 +1487,9 @@ _mesa_target_can_be_compressed(const struct gl_context
> *ctx, GLenum target,
>break;
> case GL_TEXTURE_3D:
>switch (layout) {
> + case MESA_FORMAT_LAYOUT_ETC1:
> + target_can_be_compresed =
> ctx->Extensions.OES_compressed_ETC1_RGB8_texture;
> + break;
>case MESA_FORMAT_LAYOUT_ETC2:
> /* See ETC2/EAC comment in case GL_TEXTURE_CUBE_MAP_ARRAY. */
> if (_mesa_is_gles3(ctx))
> @@ -4648,10 +4651,12 @@ out:
> */
> static GLboolean
> compressed_subtexture_target_check(struct gl_context *ctx, GLenum target,
> - GLint dims, GLenum format, bool dsa,
> + GLint dims, GLenum intFormat, bool dsa,
> const char *caller)
> {
> GLboolean targetOK;
> + mesa_format format;
> + enum mesa_format_layout layout;
>
> if (dsa && target == GL_TEXTURE_RECTANGLE) {
>_mesa_error(ctx, GL_INVALID_OPERATION, "%s(invalid target %s)", caller,
> @@ -4712,21 +4717,28 @@ compressed_subtexture_target_check(struct gl_context
> *ctx, GLenum target,
>* which is (at this time) only bptc. Otherwise we'd say s3tc (and
>* more) are valid here, which they are not, but of course not
>* mentioned by core spec.
> + *
> + * We add also other formats supported due extensions.
I think the explanation could use some expansion, like:
"The OES_texture_3D spec doesn't specify any list of supported formats
for CompressedTex*Image3D, and OES_texture_compressed_ETC1_RGB8_texture
mentions only 2D for a function supporting it. However, given a KHR
conformance test expects that the two work together in the obvious way,
follow the tests not the specs."
>*/
> - switch (format) {
> + format = _mesa_glenum_to_compressed_format(intFormat);
> + layout = _mesa_get_format_layout(format);
> + switch (layout) {
> /* These are the only 3D compression formats supported at this time
> */
> - case GL_COMPRESSED_RGBA_BPTC_UNORM:
> - case GL_COMPRESSED_SRGB_ALPHA_BPTC_UNORM:
> - case GL_COMPRESSED_RGB_BPTC_SIGNED_FLOAT:
> - case GL_COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT:
> + case MESA_FORMAT_LAYOUT_BPTC:
> /* valid format */
> break;
> + case MESA_FORMAT_LAYOUT_ASTC:
> +targetOK = ctx->Extensions.KHR_texture_compression_astc_ldr;
> +break;
> + case MESA_FORMAT_LAYOUT_ETC1:
> +targetOK = ctx->Extensions.OES_compressed_ETC1_RGB8_texture;
> +break;
> default:
> /* invalid format */
> _mesa_error(ctx, GL_INVALID_OPERATION,
> "%s(invalid target %s for format %s)", caller,
> _mesa_enum_to_string(target),
> -_mesa_enum_to_string(format));
> +_mesa_enum_to_string(intFormat));
> return GL_TRUE;
> }
> break;
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] broadcom/vc5: Fix source file name.
Vinson Lee writes:
> Fixes: c9b2cb78972d ("vc5: add missing files to the tarball")
> Signed-off-by: Vinson Lee
Reviewed and pushed these two. Thanks!
(Also, we need to get automake's distcheck into Travis. I would have
caught this before pushing, if so).
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Only require independent blending for GLES 3.2.
We've been requiring this since GLES 3.0 was introduced, but the GLES 3.2 spec is the one that has "Supporting blending on a per-draw-buffer basis" in the new features. V3D 3.3 would require lowering blending to shader code to implement independent blending. --- src/mesa/main/version.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c index 68079f4ebbba..1fce8fe7ca9c 100644 --- a/src/mesa/main/version.c +++ b/src/mesa/main/version.c @@ -516,7 +516,6 @@ compute_version_es2(const struct gl_extensions *extensions, extensions->ARB_texture_float && extensions->ARB_texture_rg && extensions->ARB_depth_buffer_float && - extensions->EXT_draw_buffers2 && /* extensions->ARB_framebuffer_object && */ extensions->EXT_framebuffer_sRGB && extensions->EXT_packed_float && @@ -546,6 +545,7 @@ compute_version_es2(const struct gl_extensions *extensions, extensions->ARB_gpu_shader5 && extensions->EXT_shader_integer_mix); const bool ver_3_2 = (ver_3_1 && + extensions->EXT_draw_buffers2 && extensions->KHR_blend_equation_advanced && extensions->KHR_robustness && extensions->KHR_texture_compression_astc_ldr && -- 2.15.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meson: ensure that xmlpool_options.h is generated for targets that need it
Dylan Baker writes: > Currently a couple of gallium targets race with xmlpool_options.h being > generated, don't do that. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] meson: Don't confuse the install and search paths for dri drivers
Dylan Baker writes: > Currently there is not a separate option for setting the search path of > DRI drivers in meson, like there is in scons and autotools. This is an > oversight and needs to be fixed. This adds an extra option > `dri-search-path`, which will default to the value of > `dri-drivers-path`, like autotools does. > > v2: - Split input list before joining. > > Reported-by: Ilia Mirkin > Signed-off-by: Dylan Baker Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/14] vc4, vc5: add ETIME fallback define
Dylan Baker writes:
> [ Unknown signature status ]
> I'm not sure how Emil feels about this (and the related patches) but I think
> it
> might be better to handle this at the build system level, for meson it would
> look something like (in the top level meson.build):
>
> if cc.get_define('ETIME') == ''
> pre_args += '-DETIME=ETIMEDOUT'
> endif
>
> Which should be a permanent fix. Emil can probably provide an autotools
> equivalent.
>
> Quoting Greg V (2017-12-31 08:55:16)
>> FreeBSD only has ETIMEDOUT, not ETIME
Agreed, that if FreeBSD can't sort out the portability issue on their
end (which they really should), it should at least be a global
workaround in Mesa and not per-file.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] compiling OpenCL C to NIR
Tomeu Vizoso writes: > Hi, > > I'm still trying to estimate the work required to support OpenCL on > Freedreno, and as part of that I have given a try to put Khronos' > LLVM-SPIRV into a shape that Mesa can depend on: > > https://gitlab.collabora.com/tomeu/llvm-spirv > > I basically took Khronos' master branch, rewrote history to remove > anything not SPIRV-specific, and applied on top Nic's changes to match > LLVM 6.0. Also borrowed some build system changes from clspv. > > Hopefully at some point this will become something that can be merged > into LLVM (probably as a target), but that doesn't seem to be close > enough and right now it's blocking other work. > > Once/if I start working on this in earnest, my first steps will be > making it a proper FOSS project to which people can contribute, and then > have Clover use it to pass SPIR-V to spirv-to-nir and from there to > Gallium drivers that are able to consume NIR. > > Have checked with a few simple CL C kernels that spirv-to-nir is able to > consume the SPIRV that llvm-spirv produces, so I think this approach > will allows us to progressively advance on spec coverage by working > mostly on spirv2nir, Clover and the Gallium drivers. > > Thanks to everybody who has given feedback so far! This sounds really nice! I'd love to take a look at this once I get the GLES3.1 compute stuff on VC5 working. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meson: Don't confuse the install and search paths for dri drivers
Dylan Baker writes:
> Currently there is not a separate option for setting the search path of
> DRI drivers in meson, like there is in scons and autotools. This is an
> oversight and needs to be fixed. This adds an extra option
> `dri-search-path`, which will default to the value of
> `dri-drivers-path`, like autotools does.
>
> Reported-by: Ilia Mirkin
> Signed-off-by: Dylan Baker
> ---
> meson.build | 6 ++
> meson_options.txt | 8 +++-
> src/egl/meson.build | 2 +-
> src/gbm/meson.build | 2 +-
> src/glx/meson.build | 3 ++-
> 5 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index ae31cdd6571..8002668666b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -57,6 +57,12 @@ dri_drivers_path = get_option('dri-drivers-path')
> if dri_drivers_path == ''
>dri_drivers_path = join_paths(get_option('libdir'), 'dri')
> endif
> +_search = get_option('dri-search-path')
> +if _search != ''
> + dri_search_path = ';'.join(_search)
If the user is passing a comma-separated string, don't you need to split
on the commas before joining?
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meson: generate translations for driconf
Dylan Baker writes: > Currently meson implements the same logic as SCons for translations, > namely it doesn't do them. This patch changes meson to use logic more > like autotools, and generate translations. To do this we have to go > behind meson's back a bit, and wrap the whole thing up in a single > python script. > > Meson has a module for gettext translations, but it assumes that one > will have a pot file, and then .mo translations will be generated and > checked into the source repo (or generated by hand using custom ninja > targets before building), mesa assumes that the targets will be > regenerated on each invocation of make or ninja. I think this can be > fixed upstream, but in the mean time this adds support for using > translations. Is there a reason you have a new python script, instead of having each msgfmt invcation generating a mo file in its own custom target, and then the custom target for the gen_xmlpool.py call depending on that? signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] broadcom/vc4: Add support for HW perfmon
Boris Brezillon writes: > The V3D engine provides several perf counters. > Implement ->get_driver_query_[group_]info() so that these counters are > exposed through the GL_AMD_performance_monitor extension. This all looks good to me! I'm looking forward to the piglit tests, but this patch is: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] nir: Add a lowering pass for gl_FragColor to glFragData[] writes.
Kenneth Graunke writes:
> [ Unknown signature status ]
> On Thursday, December 28, 2017 5:56:18 PM PST Eric Anholt wrote:
>> For VC5, the shader needs to have the appropriate base type for the
>> variable in the render target write, and gallium's
>> FS_COLOR0_WRITES_ALL_CBUFS (used for glClearBufferiv) doesn't give you
>> that information. This pass lets the backend decide what types to explode
>> the gl_FragColor write out to.
>>
>> This would also be a prerequisite of moving some of VC5's render target
>> format packing into NIR as well.
>
> This type confusion seems a bit unfortunate. Both gl_FragColor and
> gl_FragData[i] are always float vec4s. But, we've used (abused?) it in
> the past for integer clear/blit paths, since it's the only way to splat
> out to all render targets.
>
> I suppose this must be an internally generated shader? Or, do you also
> need this for people writing to gl_FragColor but binding integer render
> targets? (If so, what about people declaring 'out vec4 foo' but binding
> an integer render target?)
Yeah, it's gallium's internal glClearBufferiv() shader, translated using
TGSI-to-NIR. I had initially written this pass without the types
argument, but found that adding it got me a whole bunch more tests
working. I suppose we could move this into TTN and delay TTN until draw
time, to make sure that we always maintain proper types in the NIR, but
this was pretty easy. How about adding this to the top comment:
* The pass's types argument lets the caller choose between vec4, uvec4, and
* ivec4 per render target. This is necessary for TGSI-to-NIR output, which
* emits vec4 gl_FragColor writes even for integer render targets (because
* TGSI doesn't know the types).
If you use "out vec4 foo" but bind integer, you get "If the values
written by the fragment shader do not match the format(s) of the
corresponding color buffer(s), the result is undefined." (GL 4.3 spec)
>> +/**
>> + * Lowers gl_FragColor to a per-render-target store.
>> + *
>> + * GLSL's gl_FragColor writes implicitly broadcast their store to every
>> active
>> + * render target. This can be used by driver backends to implement
>> + * gl_FragColor in the same way as other multiple-render-target shaders, and
>> + * is particularly useful if the driver needs to do other per-render-target
>> + * lowering in NIR.
>> + *
>> + * Run before nir_lower_io.
>> + */
>> +
>> +typedef struct {
>
> Let's avoid typedefs here - this is just a struct containing the state
> of the pass. We do use typedefs in NIR, but mostly for core concepts.
> This isn't anything that special or fundamental (and most passes just
> use a plain struct).
Agreed. I think I was just following core NIR.
>> + nir_shader *shader;
>> + nir_builder b;
>> +
>> + nir_variable *var; /* gl_FragColor */
>> +
>> + int num_rt_vars;
>> + nir_variable *rt_var[32]; /* gl_FragDataN */
>> +} lower_gl_fragcolor_state;
>> +
>> +static void
>> +lower_gl_fragcolor(lower_gl_fragcolor_state *state, nir_intrinsic_instr
>> *intr)
>> +{
>> + nir_builder *b = &state->b;
>> +
>> + assert(intr->dest.is_ssa);
>> +
>> + b->cursor = nir_before_instr(&intr->instr);
>> +
>> + /* Generate a gl_FragDataN write per render target. */
>> + nir_ssa_def *color = nir_ssa_for_src(b, intr->src[0], 4);
>> + for (int i = 0; i < state->num_rt_vars; i++) {
>> + nir_store_var(b, state->rt_var[i], color, 0xf);
>> + }
>> +
>> + /* Remove the gl_FragColor write. */
>> + nir_instr_remove(&intr->instr);
>> +}
>> +
>> +static bool
>> +lower_gl_fragcolor_block(lower_gl_fragcolor_state *state, nir_block *block)
>> +{
>> + nir_foreach_instr_safe(instr, block) {
>> + if (instr->type == nir_instr_type_intrinsic) {
>> + nir_intrinsic_instr *intr = nir_instr_as_intrinsic(instr);
>> + if (intr->intrinsic == nir_intrinsic_store_var) {
>> +nir_deref_var *dvar = intr->variables[0];
>> +nir_variable *var = dvar->var;
>> +
>> +if (var == state->var) {
>> + /* gl_FragColor should not have array/struct derefs: */
>> + assert(dvar->deref.child == NULL);
>> + lower_gl_fragcolor(state, intr);
>> +}
>> + }
>> + }
>> + }
>> +
>> + return true;
>> +}
>> +
>> +bool
>> +nir_lower_gl_fragcolor(nir_shader *shader,
[Mesa-dev] [PATCH 2/3] nir: Add a helper to get the uvec4 type.
I needed this in the vc5 compiler.
---
src/compiler/nir_types.cpp | 6 ++
src/compiler/nir_types.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index 377de0c9c7bd..cbdd452dc813 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -297,6 +297,12 @@ glsl_vec4_type(void)
return glsl_type::vec4_type;
}
+const glsl_type *
+glsl_uvec4_type(void)
+{
+ return glsl_type::uvec4_type;
+}
+
const glsl_type *
glsl_int_type(void)
{
diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
index daff97325093..4397c2406f9a 100644
--- a/src/compiler/nir_types.h
+++ b/src/compiler/nir_types.h
@@ -136,6 +136,7 @@ const struct glsl_type *glsl_double_type(void);
const struct glsl_type *glsl_vec_type(unsigned n);
const struct glsl_type *glsl_dvec_type(unsigned n);
const struct glsl_type *glsl_vec4_type(void);
+const struct glsl_type *glsl_uvec4_type(void);
const struct glsl_type *glsl_int_type(void);
const struct glsl_type *glsl_uint_type(void);
const struct glsl_type *glsl_int64_t_type(void);
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] nir: Add a lowering pass for gl_FragColor to glFragData[] writes.
For VC5, the shader needs to have the appropriate base type for the
variable in the render target write, and gallium's
FS_COLOR0_WRITES_ALL_CBUFS (used for glClearBufferiv) doesn't give you
that information. This pass lets the backend decide what types to explode
the gl_FragColor write out to.
This would also be a prerequisite of moving some of VC5's render target
format packing into NIR as well.
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/meson.build | 1 +
src/compiler/nir/nir.h| 3 +
src/compiler/nir/nir_lower_gl_fragcolor.c | 143 ++
4 files changed, 148 insertions(+)
create mode 100644 src/compiler/nir/nir_lower_gl_fragcolor.c
diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index d3f746f5f948..4afaa1a2146a 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -220,6 +220,7 @@ NIR_FILES = \
nir/nir_lower_constant_initializers.c \
nir/nir_lower_double_ops.c \
nir/nir_lower_drawpixels.c \
+ nir/nir_lower_gl_fragcolor.c \
nir/nir_lower_global_vars_to_local.c \
nir/nir_lower_gs_intrinsics.c \
nir/nir_lower_load_const_to_scalar.c \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index 5dd21e6652f0..9e11279118f6 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -114,6 +114,7 @@ files_libnir = files(
'nir_lower_constant_initializers.c',
'nir_lower_double_ops.c',
'nir_lower_drawpixels.c',
+ 'nir_lower_gl_fragcolor.c',
'nir_lower_global_vars_to_local.c',
'nir_lower_gs_intrinsics.c',
'nir_lower_load_const_to_scalar.c',
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 440c3fe9974c..17bb8fc8de4c 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2680,6 +2680,9 @@ bool nir_lower_atomics(nir_shader *shader,
bool nir_lower_atomics_to_ssbo(nir_shader *shader, unsigned ssbo_offset);
bool nir_lower_uniforms_to_ubo(nir_shader *shader);
bool nir_lower_to_source_mods(nir_shader *shader);
+bool nir_lower_gl_fragcolor(nir_shader *shader,
+uint32_t rt_mask,
+const struct glsl_type **types);
bool nir_lower_gs_intrinsics(nir_shader *shader);
diff --git a/src/compiler/nir/nir_lower_gl_fragcolor.c
b/src/compiler/nir/nir_lower_gl_fragcolor.c
new file mode 100644
index ..d4b39f00c233
--- /dev/null
+++ b/src/compiler/nir/nir_lower_gl_fragcolor.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright © 2017 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ */
+
+#include "nir.h"
+#include "nir_builder.h"
+
+/**
+ * Lowers gl_FragColor to a per-render-target store.
+ *
+ * GLSL's gl_FragColor writes implicitly broadcast their store to every active
+ * render target. This can be used by driver backends to implement
+ * gl_FragColor in the same way as other multiple-render-target shaders, and
+ * is particularly useful if the driver needs to do other per-render-target
+ * lowering in NIR.
+ *
+ * Run before nir_lower_io.
+ */
+
+typedef struct {
+ nir_shader *shader;
+ nir_builder b;
+
+ nir_variable *var; /* gl_FragColor */
+
+ int num_rt_vars;
+ nir_variable *rt_var[32]; /* gl_FragDataN */
+} lower_gl_fragcolor_state;
+
+static void
+lower_gl_fragcolor(lower_gl_fragcolor_state *state, nir_intrinsic_instr *intr)
+{
+ nir_builder *b = &state->b;
+
+ assert(intr->dest.is_ssa);
+
+ b->cursor = nir_before_instr(&intr->instr);
+
+ /* Generate a gl_FragDataN write per render target. */
+ nir_ssa_def *color = nir_ssa_for_src(b, intr->src[0], 4);
+ for (int i = 0; i < state->num_rt_vars; i++) {
+ nir_store_var(b, state->rt_var[i], color, 0xf);
+ }
+
+ /* Remove the gl_FragColor write. */
+ nir_instr_remove(&intr->instr);
+}
+
+static bool
+lower_gl_fragcolor_block(lower_g
[Mesa-dev] [PATCH 3/3] broadcom/vc5: Use the new glFragColor lowering pass.
This fixes dEQP-GLES3.functional.fbo.color.clear.r16i and friends, by
making sure we do an integer TLB store instead of float.
---
src/broadcom/compiler/nir_to_vir.c| 5 +
src/broadcom/compiler/v3d_compiler.h | 6 ++
src/broadcom/compiler/vir.c | 13 +
src/gallium/drivers/vc5/vc5_program.c | 5 +
4 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/src/broadcom/compiler/nir_to_vir.c
b/src/broadcom/compiler/nir_to_vir.c
index 1cf8865bf0e1..4bd9ae2e9a74 100644
--- a/src/broadcom/compiler/nir_to_vir.c
+++ b/src/broadcom/compiler/nir_to_vir.c
@@ -1493,10 +1493,7 @@ ntq_setup_outputs(struct v3d_compile *c)
if (c->s->info.stage == MESA_SHADER_FRAGMENT) {
switch (var->data.location) {
case FRAG_RESULT_COLOR:
-c->output_color_var[0] = var;
-c->output_color_var[1] = var;
-c->output_color_var[2] = var;
-c->output_color_var[3] = var;
+unreachable("Should have been lowered");
break;
case FRAG_RESULT_DATA0:
case FRAG_RESULT_DATA1:
diff --git a/src/broadcom/compiler/v3d_compiler.h
b/src/broadcom/compiler/v3d_compiler.h
index bbe7a57fa10e..d060af3c4169 100644
--- a/src/broadcom/compiler/v3d_compiler.h
+++ b/src/broadcom/compiler/v3d_compiler.h
@@ -322,6 +322,12 @@ struct v3d_fs_key {
uint8_t swap_color_rb;
/* Mask of which render targets need to be written as 32-bit floats */
uint8_t f32_color_rb;
+
+/* Mask of which render targets need gl_FragColor output as a vec4. */
+uint8_t gl_fragcolor_lower_vec4;
+/* Mask of which render targets need gl_FragColor output as a uvec4. */
+uint8_t gl_fragcolor_lower_uvec4;
+
uint8_t alpha_test_func;
uint8_t logicop_func;
uint32_t point_sprite_mask;
diff --git a/src/broadcom/compiler/vir.c b/src/broadcom/compiler/vir.c
index 4e78a477bd7d..abcb430c6e3b 100644
--- a/src/broadcom/compiler/vir.c
+++ b/src/broadcom/compiler/vir.c
@@ -750,6 +750,19 @@ uint64_t *v3d_compile_fs(const struct v3d_compiler
*compiler,
if (key->base.ucp_enables)
NIR_PASS_V(c->s, nir_lower_clip_fs, key->base.ucp_enables);
+const struct glsl_type *gl_fragcolor_types[4] = {NULL, NULL, NULL,
NULL};
+for (int i = 0; i < ARRAY_SIZE(gl_fragcolor_types); i++) {
+if (key->gl_fragcolor_lower_vec4 & (1 << i))
+gl_fragcolor_types[i] = glsl_vec4_type();
+else if (key->gl_fragcolor_lower_uvec4 & (1 << i))
+gl_fragcolor_types[i] = glsl_uvec4_type();
+}
+
+NIR_PASS_V(c->s, nir_lower_gl_fragcolor,
+ key->gl_fragcolor_lower_vec4 |
+ key->gl_fragcolor_lower_uvec4,
+ gl_fragcolor_types);
+
/* Note: FS input scalarizing must happen after
* nir_lower_two_sided_color, which only handles a vec4 at a time.
*/
diff --git a/src/gallium/drivers/vc5/vc5_program.c
b/src/gallium/drivers/vc5/vc5_program.c
index 4f902fd4c65d..2fb50897730d 100644
--- a/src/gallium/drivers/vc5/vc5_program.c
+++ b/src/gallium/drivers/vc5/vc5_program.c
@@ -378,6 +378,11 @@ vc5_update_compiled_fs(struct vc5_context *vc5, uint8_t
prim_mode)
desc->channel[0].size == 32) {
key->f32_color_rb |= 1 << i;
}
+
+if (desc->channel[0].pure_integer)
+key->gl_fragcolor_lower_uvec4 |= 1 << i;
+else
+key->gl_fragcolor_lower_vec4 |= 1 << i;
}
if (key->is_points) {
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] broadcom/vc4: Add support for HW perfmon
Boris Brezillon writes:
> The V3D engine provides several perf counters.
> Implement ->get_driver_query_[group_]info() so that these counters are
> exposed through the GL_AMD_performance_monitor extension.
Thanks for working on this! I've successfully used it to inform some
work I'm doing on 3DMMES.
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/vc4/vc4_context.h | 13 +++
> src/gallium/drivers/vc4/vc4_job.c | 9 +-
> src/gallium/drivers/vc4/vc4_query.c | 197
> --
> src/gallium/drivers/vc4/vc4_screen.c | 7 ++
> src/gallium/drivers/vc4/vc4_screen.h | 1 +
> 5 files changed, 215 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/vc4/vc4_context.h
> b/src/gallium/drivers/vc4/vc4_context.h
> index 4a1e4093f1a0..b6d9f041efc7 100644
> --- a/src/gallium/drivers/vc4/vc4_context.h
> +++ b/src/gallium/drivers/vc4/vc4_context.h
> @@ -309,6 +309,11 @@ struct vc4_job {
> struct vc4_job_key key;
> };
>
> +struct vc4_hwperfmon {
> +uint32_t id;
> +uint64_t counters[DRM_VC4_MAX_PERF_COUNTERS];
> +};
> +
> struct vc4_context {
> struct pipe_context base;
>
> @@ -387,6 +392,8 @@ struct vc4_context {
> struct pipe_viewport_state viewport;
> struct vc4_constbuf_stateobj constbuf[PIPE_SHADER_TYPES];
> struct vc4_vertexbuf_stateobj vertexbuf;
> +
> +struct vc4_hwperfmon *perfmon;
> /** @} */
> };
>
> @@ -444,6 +451,12 @@ vc4_sampler_state(struct pipe_sampler_state *psampler)
> return (struct vc4_sampler_state *)psampler;
> }
>
> +int vc4_get_driver_query_group_info(struct pipe_screen *pscreen,
> +unsigned index,
> +struct pipe_driver_query_group_info
> *info);
> +int vc4_get_driver_query_info(struct pipe_screen *pscreen, unsigned index,
> + struct pipe_driver_query_info *info);
> +
> struct pipe_context *vc4_context_create(struct pipe_screen *pscreen,
> void *priv, unsigned flags);
> void vc4_draw_init(struct pipe_context *pctx);
> diff --git a/src/gallium/drivers/vc4/vc4_job.c
> b/src/gallium/drivers/vc4/vc4_job.c
> index fb0c5bbc78cf..f75a32565603 100644
> --- a/src/gallium/drivers/vc4/vc4_job.c
> +++ b/src/gallium/drivers/vc4/vc4_job.c
> @@ -362,7 +362,7 @@ vc4_submit_setup_rcl_msaa_surface(struct vc4_job *job,
> rsc->writes++;
> }
>
> -#define MAX_CHUNKS 1
> +#define MAX_CHUNKS 2
>
> /**
> * Submits the job to the kernel and then reinitializes it.
> @@ -467,6 +467,13 @@ vc4_job_submit(struct vc4_context *vc4, struct vc4_job
> *job)
> submit.uniforms = (uintptr_t)job->uniforms.base;
> submit.uniforms_size = cl_offset(&job->uniforms);
>
> +if (vc4->perfmon && screen->has_extended_cl) {
> +chunks[nchunks].perfmon.type = VC4_PERFMON_CHUNK;
> +chunks[nchunks].perfmon.id = vc4->perfmon->id;
> +chunks[nchunks].perfmon.pad = 0;
> +nchunks++;
> +}
> +
> if (nchunks) {
> submit.flags |= VC4_SUBMIT_CL_EXTENDED;
> submit.cl_chunks = (uintptr_t)chunks;
> diff --git a/src/gallium/drivers/vc4/vc4_query.c
> b/src/gallium/drivers/vc4/vc4_query.c
> index ddf8f8fb0c2c..d6b081bb15d7 100644
> --- a/src/gallium/drivers/vc4/vc4_query.c
> +++ b/src/gallium/drivers/vc4/vc4_query.c
> @@ -32,49 +32,224 @@
>
> struct vc4_query
> {
> -uint8_t pad;
> +unsigned num_queries;
> +struct vc4_hwperfmon *hwperfmon;
> };
>
> +static const char *v3d_counter_names[] = {
> +"FEP-valid-primitives-no-rendered-pixels",
> +"FEP-valid-primitives-rendered-pixels",
> +"FEP-clipped-quads",
> +"FEP-valid-quads",
> +"TLB-quads-not-passing-stencil-test",
> +"TLB-quads-not-passing-z-and-stencil-test",
Looks like you missed "TLB-quads-passing-z-and-stencil-test" here.
> +"TLB-quads-with-zero-coverage",
> +"TLB-quads-with-non-zero-coverage",
> +"TLB-quads-written-to-color-buffer",
> +"PTB-primitives-discarded-outside-viewport",
> +"PTB-primitives-need-clipping",
> +"PTB-primitives-discared-reversed",
> +"QPU-total-idle-clk-cycles",
> +"QPU-total-clk-cycles-vertex-coord-shading",
> +"QPU-total-clk-cycles-fragment-shading",
> +"QPU-total-clk-cycles-executing-valid-instr",
> +"QPU-total-clk-cycles-waiting-TMU",
> +"QPU-total-clk-cycles-waiting-scoreboard",
> +"QPU-total-clk-cycles-waiting-varyings",
> +"QPU-total-instr-cache-hit",
> +"QPU-total-instr-cache-miss",
> +"QPU-total-uniform-cache-hit",
> +"QPU-total-uniform-cache-miss",
> +"TMU-total-text-quads-processed",
> +"TMU-total-text-cache-miss",
> +"VPM-total-clk-cycles-VDW-stalled",
>
Re: [Mesa-dev] [PATCH mesa] radeon: remove left over dead code
Eric Engestrom writes: > Fixes: 4e0d99a63588c67a955f "r100: Use shared debug code" > Cc: Pauli Nieminen > Signed-off-by: Eric Engestrom Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] drirc: add option to disable ARB_draw_indirect
Nicolai Hähnle writes: > On 15.12.2017 12:37, Rob Clark wrote: >> On Fri, Dec 15, 2017 at 4:41 AM, Nicolai Hähnle >> wrote: >>> On 15.12.2017 00:56, Rob Clark wrote: On Wed, Dec 6, 2017 at 3:31 PM, Ian Romanick wrote: > > On 12/05/2017 08:25 AM, Ilia Mirkin wrote: >> >> On Tue, Dec 5, 2017 at 8:18 AM, Emil Velikov >> wrote: >>> >>> Hi Rob, >>> >>> On 5 December 2017 at 12:54, Rob Clark wrote: This is a bit sad/annoying. But with current GPU firmware (at least on a5xx) we can support both draw-indirect and base-instance. But we can't support draw-indirect with a non-zero base-instance specified. So add a driconf option to hide the extension from games that are known to use both. Signed-off-by: Rob Clark --- Tbh, I'm also not really sure what to do when/if we got updated firmware which handled draw-indirect with base-instance, since we'd need to make this option conditional on fw version. For STK that probably isn't a big deal since it doesn't use draw-indirect in a particularly useful way (the indirect buffer is generated on CPU). >>> Couldn't freedreno just return 0 for PIPE_CAP_DRAW_INDIRECT (aka >>> disable the extension) as it detects buggy FW? >>> This is what radeons have been doing as they encounter iffy firmware or >>> LLVM. >>> >>> AFAICT freedreno doesn't do GL 4.0 or GLES 3.1 so one should be safe. >> >> >> Rob is this -><- close to ES 3.1, so that's not a great option. > > > And I don't suppose there's a way to get updated firmware? i965 has > similar sorts of cases where higher versions are disabled due to missing > kernel features. > so after r/e the instruction set for the CP microcontrollers and writing a disassembler and assembler[1], and figuring out how the fw handles CP_DRAW_INDIRECT and CP_DRAW_INDX_INDIRECT packets, I've come to the conclusion that the issue isn't actually with draw-indirect vs base-instance (at least not w/ the fw from my pixel2 which md5sum claims is the same as what is in linux-firmware.. it is possible that I was using an earlier version of the fw before when I came to this conclusion). On the plus side, the PFP/ME microcontrollers that parse the cmdstream are pretty neat and I learned some useful stuff along the way. But thinking a bit about how stk is using GL_MAP_PERSISTENT_BIT to map and update the draw-indirect buffers, it seems to me there are plenty of ways this can go wrong w/ tilers (and even more when you throw re-ordering into the mix). Possibly I should disable reordering when the indirect buffer is mapped w/ PERSISTENT bit, although for games like stk this is probably counter-productive vs just hiding the draw-indirect extension.. for games that actually use the GPU to write the draw-indirect buffer it shouldn't be a problem. So I think a driconf patch like this probably still ends up being useful in the end. >>> >>> >>> Can you detail a bit what you think could go wrong? I believe that the >>> intention of the GL spec is that reordering in tilers should be possible at >>> least for buffers that are mapped PERSISTENT but not COHERENT. >>> >>> You may only have to block reordering if the buffer is mapped both >>> PERSISTENT *and* COHERENT -- and even then, reordering is probably possible. >>> >>> Granted, the spec is unclear as usual when it comes to these memory >>> synchronization issues -- the description of the MAP_COHERENT_BIT in section >>> 6.2 does not mention WAR hazards (in particular, Write by client after Read >>> by server) -- but perhaps that can be fixed. >>> >>> To go into a bit more detail, what I suspect you're worried about is >>> applications doing stuff like: >>> >>> 1. Write to indirect buffer (persistently & coherently mapped) >>> 2. Draw*Indirect >>> 3. Write to the same location in the indirect buffer >>> 4. Draw*Indirect >>> >>> ... but this is bound to fail with "normal" GPUs (like ours) as well. >>> Perhaps you have a different scenario in mind? >> >> yeah, this was basically the scenario I had in mind.. although I'm >> perhaps more aggressive in deferring rendering, to the point of >> re-ordering draws if unnecessary fbo switches are made. Normally I >> track which buffers are read and written in a given batch (draw pass) >> in order to preserve correctness (and in some cases shadowing or doing >> a staging transfer to update buffers/textures to avoid splitting a >> batch). Perhaps it is only an issue w/ persistent+coherent, but w/ >> cpu updating buffer without driver knowing when is kind of >> sub-optimal. >> >> I'm thinking I do need to keep track when there are outstanding >> coherent+persistent transfers
Re: [Mesa-dev] [PATCH] meson: fix glx-test race
Dylan Baker writes: > This test should rely on dispatch.h being generated, but it doesn't. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium/util: add u_transfer_helper
Rob Clark writes:
> Add a new helper that drivers can use to emulate various things that
> need special handling in particular in transfer_map:
>
> 1) z32_s8x24.. gl/gallium treats this as a single buffer with depth
> and stencil interleaved but hardware frequently treats this as
> separate z32 and s8 buffers. Special pack/unpack handling is
> needed in transfer_map/unmap to pack/unpack the exposed buffer
>
> 2) fake RGTC.. GPUs designed with GLES in mind, but which can other-
> wise do GL3, if native RGTC is not supported it can be emulated
> by converting to uncompressed internally, but needs pack/unpack
> in transfer_map/unmap
>
> 3) MSAA resolves in the transfer_map() case
>
> v2: add MSAA resolve based on Eric's "gallium: Add helpers for MSAA
> resolves in pipe_transfer_map()/unmap()." patch; avoid wrapping
> pipe_resource, to make it possible for drivers to use both this
> and threaded_context.
Update on changes between versions?
>
> Signed-off-by: Rob Clark
> ---
> src/gallium/auxiliary/Makefile.sources | 2 +
> src/gallium/auxiliary/meson.build | 2 +
> src/gallium/auxiliary/util/u_transfer_helper.c | 499
> +
> src/gallium/auxiliary/util/u_transfer_helper.h | 135 +++
> src/gallium/include/pipe/p_screen.h| 8 +-
> 5 files changed, 645 insertions(+), 1 deletion(-)
> create mode 100644 src/gallium/auxiliary/util/u_transfer_helper.c
> create mode 100644 src/gallium/auxiliary/util/u_transfer_helper.h
>
> diff --git a/src/gallium/auxiliary/Makefile.sources
> b/src/gallium/auxiliary/Makefile.sources
> index f40c4723fae..a2dae04698c 100644
> --- a/src/gallium/auxiliary/Makefile.sources
> +++ b/src/gallium/auxiliary/Makefile.sources
> @@ -304,6 +304,8 @@ C_SOURCES := \
> util/u_tile.h \
> util/u_transfer.c \
> util/u_transfer.h \
> + util/u_transfer_helper.c \
> + util/u_transfer_helper.h \
> util/u_threaded_context.c \
> util/u_threaded_context.h \
> util/u_threaded_context_calls.h \
> diff --git a/src/gallium/auxiliary/meson.build
> b/src/gallium/auxiliary/meson.build
> index 3e623fd099f..8c242ec1a05 100644
> --- a/src/gallium/auxiliary/meson.build
> +++ b/src/gallium/auxiliary/meson.build
> @@ -324,6 +324,8 @@ files_libgallium = files(
>'util/u_tile.h',
>'util/u_transfer.c',
>'util/u_transfer.h',
> + 'util/u_transfer_helper.c',
> + 'util/u_transfer_helper.h',
>'util/u_threaded_context.c',
>'util/u_threaded_context.h',
>'util/u_threaded_context_calls.h',
> diff --git a/src/gallium/auxiliary/util/u_transfer_helper.c
> b/src/gallium/auxiliary/util/u_transfer_helper.c
> new file mode 100644
> index 000..c987a35b36c
> --- /dev/null
> +++ b/src/gallium/auxiliary/util/u_transfer_helper.c
> @@ -0,0 +1,499 @@
> +/*
> + * Copyright © 2017 Red Hat
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE
> + * SOFTWARE.
> + */
> +
> +#include "pipe/p_screen.h"
> +
> +#include "util/u_box.h"
> +#include "util/u_format.h"
> +#include "util/u_format_rgtc.h"
> +#include "util/u_format_zs.h"
> +#include "util/u_inlines.h"
> +#include "util/u_transfer_helper.h"
> +
> +
> +struct u_transfer_helper {
> + const struct u_transfer_vtbl *vtbl;
> + bool separate_z32s8;
> + bool fake_rgtc;
> + bool msaa_map;
> +};
> +
> +static inline bool handle_transfer(struct pipe_resource *prsc)
> +{
> + struct u_transfer_helper *helper = prsc->screen->transfer_helper;
> +
> + if (helper->vtbl->get_internal_format) {
> + enum pipe_format internal_format =
> +helper->vtbl->get_internal_format(prsc);
> + if (internal_format != prsc->format)
> + return true;
> + }
> +
> + if (helper->msaa_map && (prsc->nr_samples > 1))
> + return true;
> +
> + return false;
> +}
> +
> +/* The pipe_transfer ptr could either be the driver
Re: [Mesa-dev] [PATCH 1/3] nir: Fix interaction of GL_CLAMP lowering with texture offsets.
Eric Anholt writes: > We want the clamping of the coordinate to apply after the offset, so we > need to do math to lower the offset out of the instruction. Fixes texwrap > offset cases for GL_CLAMP with GL_NEAREST on vc5. Still looking for a review on this series. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium/util: add u_transfer_helper
Rob Clark writes:
> Add a new helper that drivers can use to emulate various things that
> need special handling in particular in transfer_map:
>
> 1) z32_s8x24.. gl/gallium treats this as a single buffer with depth
> and stencil interleaved but hardware frequently treats this as
> separate z32 and s8 buffers. Special pack/unpack handling is
> needed in transfer_map/unmap to pack/unpack the exposed buffer
>
> 2) fake RGTC.. GPUs designed with GLES in mind, but which can other-
> wise do GL3, if native RGTC is not supported it can be emulated
> by converting to uncompressed internally, but needs pack/unpack
> in transfer_map/unmap
>
> 3) MSAA resolves in the transfer_map() case
>
> v2: add MSAA resolve based on Eric's "gallium: Add helpers for MSAA
> resolves in pipe_transfer_map()/unmap()." patch; avoid wrapping
> pipe_resource, to make it possible for drivers to use both this
> and threaded_context.
The driver side is clean enough with this layer that I'm pretty happy
now. Just one significant review comment, then I think we'll be
ready...
> +static void
> +flush_region(struct pipe_context *pctx, struct pipe_transfer *ptrans,
> + const struct pipe_box *box)
> +{
> + struct u_transfer *trans = u_transfer(ptrans);
> + enum pipe_format format = ptrans->resource->format;
> + unsigned width = ptrans->box.width;
> + unsigned height = ptrans->box.height;
It seems silly to be implementing flush_region and ignoring the box
argument to flush the entire mapped region on every call. We should
either drop this implementation in favor of the no-op and flush at
unmap, or actually use the box in the flushes.
That said, I don't think you can reach flush_region with explicit flush
for non-buffer resources?
> +
> + if (!(ptrans->usage & PIPE_TRANSFER_WRITE))
> + return;
> +
> + if (trans->ss) {
> + struct pipe_blit_info blit;
> + memset(&blit, 0, sizeof(blit));
> +
> + blit.src.resource = trans->ss;
> + blit.src.format = trans->ss->format;
> + blit.src.box.width = ptrans->box.width;
> + blit.src.box.height = ptrans->box.height;
> + blit.src.box.depth = 1;
> +
> + blit.dst.resource = ptrans->resource;
> + blit.dst.format = ptrans->resource->format;
> + blit.dst.level = ptrans->level;
> + blit.dst.box = ptrans->box;
> +
> + blit.mask = util_format_get_mask(ptrans->resource->format);
> + blit.filter = PIPE_TEX_FILTER_NEAREST;
> +
> + pctx->blit(pctx, &blit);
> +
> + return;
> + }
> +
> + switch (format) {
> + case PIPE_FORMAT_Z32_FLOAT_S8X24_UINT:
> + util_format_z32_float_s8x24_uint_unpack_z_float(trans->ptr,
> + trans->trans->stride,
> + trans->staging,
> + ptrans->stride,
> + width, height);
> + /* fallthru */
> + case PIPE_FORMAT_X32_S8X24_UINT:
> + util_format_z32_float_s8x24_uint_unpack_s_8uint(trans->ptr2,
> + trans->trans2->stride,
> + trans->staging,
> + ptrans->stride,
> + width, height);
> + break;
> + case PIPE_FORMAT_RGTC1_UNORM:
> + case PIPE_FORMAT_RGTC1_SNORM:
> + case PIPE_FORMAT_LATC1_UNORM:
> + case PIPE_FORMAT_LATC1_SNORM:
> + util_format_rgtc1_unorm_unpack_rgba_8unorm(trans->ptr,
> + trans->trans->stride,
> + trans->staging,
> + ptrans->stride,
> + width, height);
> + break;
> + case PIPE_FORMAT_RGTC2_UNORM:
> + case PIPE_FORMAT_RGTC2_SNORM:
> + case PIPE_FORMAT_LATC2_UNORM:
> + case PIPE_FORMAT_LATC2_SNORM:
> + util_format_rgtc2_unorm_unpack_rgba_8unorm(trans->ptr,
> + trans->trans->stride,
> + trans->staging,
> + ptrans->stride,
> + width, height);
> + break;
> + default:
> + assert(!"Unexpected staging transfer type");
> + break;
> + }
> +}
> diff --git a/src/gallium/auxiliary/util/u_transfer_helper.h
> b/src/gallium/auxiliary/util/u_transfer_helper.h
> new file mode 100644
> index 000..392b34f0697
> --- /dev/null
> +++ b/src/gallium/auxiliary/util/u_transfer_helper.h
> @@ -0,0 +1,132 @@
> +/*
> + * Copyright © 2017 Red Hat
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "
Re: [Mesa-dev] [PATCH v2] util: hash_table: move NULL assert to string hashing function
Lionel Landwerlin writes: > Hash maps might use pointer keys (which people surely might want to > use to hash values) in which case a 0 value is perfectly acceptable. > It's only if the hash function needs to deference the pointer that we > want to be sure it's not NULL. > > v2: Add assert in _mesa_fnv32_1a_accumulate_block (Ian) No, a key of NULL is not valid. That's the marker of entry_is_free(). signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: glsl_to_tgsi: Dissolve arrays who's elements are only accessed directly
Gert Wollny writes: > Array who's elements are only accessed directly are replaced by the > according number of temporary registers. By doing so the otherwise > reserved register range becomes subject to further optimizations like > copy propagation and register merging. > > Thanks to the resulting reduced register pressure this patch makes > the piglits > > spec/glsl-1.50/execution - > variable-indexing/vs-output-array-vec3-index-wr-before-gs > geometry/max-input-components > > pass on r600 (barts) where they would fail before with a "GPR limit exceeded" > error. > > Signed-off-by: Gert Wollny > --- > No further changes are observed with the piglit shader subset. > > PS: Submitter has no write access to mesa-git This looks like something that should be done with (at most) a small change to opt_array_splitting.cpp, rather than reimplementing it here. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 11/16] broadcom: use NDEBUG to guard asserts
Eric Engestrom writes: > Signed-off-by: Eric Engestrom This and the previous patch are: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 0/7] remove upstreamed specs
Eric Engestrom writes: > On Wednesday, 2017-11-22 12:28:17 -0800, Eric Anholt wrote: >> Jordan Justen writes: >> >> > On 2017-11-22 09:59:34, Eric Engestrom wrote: >> >> A recent thread [1] made me check our local specs to see which ones were >> >> upstream. This series removes the ones that are identical upstream >> >> (modulo "TBD" extension numbers in some cases). >> > >> > While I don't have too strong of an opinion on it, I think we should >> > keep a copy of Mesa specs that are in the upstream registry. >> > >> > I think it makes sense to send a patch to mesa-dev for new Mesa specs >> > or changes to Mesa specs. Having a copy in docs/specs works well for >> > that. >> >> The downside is that that process means that we'll inevitably keep stale >> or divergent copies in Mesa, when the canonical location for GL specs is >> Khronos. We do have a reasonable process for modifying Khronos's specs >> now, which we didn't before. > > Exactly, our local copies are not the authority, Khronos is. > > Changes to specs should be sent to Khronos, on the relevant repo, by > creating a pull request like I've now done for the specs I mentioned > in the cover letter: > https://github.com/KhronosGroup/EGL-Registry/pull/36 > https://github.com/KhronosGroup/OpenGL-Registry/pull/132 > https://github.com/KhronosGroup/OpenGL-Registry/pull/133 > https://github.com/KhronosGroup/OpenGL-Registry/pull/134 > https://github.com/KhronosGroup/OpenGL-Registry/pull/135 > https://github.com/KhronosGroup/OpenGL-Registry/pull/136 > https://github.com/KhronosGroup/OpenGL-Registry/pull/137 > >> >> I think we should get all our specs out and into the Khronos. > > Ack; should I let the specs authors do this themselves, or push them for > them? If you have the time and energy to upstream them, I think that would be quite welcome. I'm sure a lot of these are basically forgotten and people's original motivation for the extensions has faded away. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 06/15] meson: build virgl driver
Dylan Baker writes: > Build tested only. I haven't done a detailed comparison to the autotools build, but this all looks fine. Patches 1-6: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 0/7] remove upstreamed specs
Jordan Justen writes: > On 2017-11-22 09:59:34, Eric Engestrom wrote: >> A recent thread [1] made me check our local specs to see which ones were >> upstream. This series removes the ones that are identical upstream >> (modulo "TBD" extension numbers in some cases). > > While I don't have too strong of an opinion on it, I think we should > keep a copy of Mesa specs that are in the upstream registry. > > I think it makes sense to send a patch to mesa-dev for new Mesa specs > or changes to Mesa specs. Having a copy in docs/specs works well for > that. The downside is that that process means that we'll inevitably keep stale or divergent copies in Mesa, when the canonical location for GL specs is Khronos. We do have a reasonable process for modifying Khronos's specs now, which we didn't before. I think we should get all our specs out and into the Khronos. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] nir: Add a new lowering option to lower all txd to txl.
VC5 requires that all txd are lowered in the shader.
---
src/compiler/nir/nir.h | 6 ++
src/compiler/nir/nir_lower_tex.c | 14 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index f46f6147110a..dd969aeb81bd 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2584,6 +2584,12 @@ typedef struct nir_lower_tex_options {
* with lower_txd_cube_map.
*/
bool lower_txd_shadow;
+
+ /**
+* If true, lower nir_texop_txd on all samplers to a nir_texop_txl.
+* Implies lower_txd_cube_map and lower_txd_shadow.
+*/
+ bool lower_txd;
} nir_lower_tex_options;
bool nir_lower_tex(nir_shader *shader,
diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c
index bd603cc22884..1062afd97f01 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -524,10 +524,9 @@ lower_gradient_cube_map(nir_builder *b, nir_tex_instr *tex)
}
static void
-lower_gradient_shadow(nir_builder *b, nir_tex_instr *tex)
+lower_gradient(nir_builder *b, nir_tex_instr *tex)
{
assert(tex->sampler_dim != GLSL_SAMPLER_DIM_CUBE);
- assert(tex->is_shadow);
assert(tex->op == nir_texop_txd);
assert(tex->dest.is_ssa);
@@ -809,16 +808,19 @@ nir_lower_tex_block(nir_block *block, nir_builder *b,
if (tex->op == nir_texop_txd &&
tex->sampler_dim == GLSL_SAMPLER_DIM_CUBE &&
- (options->lower_txd_cube_map ||
+ (options->lower_txd ||
+ options->lower_txd_cube_map ||
(tex->is_shadow && options->lower_txd_shadow))) {
lower_gradient_cube_map(b, tex);
progress = true;
continue;
}
- if (tex->op == nir_texop_txd && options->lower_txd_shadow &&
- tex->is_shadow && tex->sampler_dim != GLSL_SAMPLER_DIM_CUBE) {
- lower_gradient_shadow(b, tex);
+ if (tex->op == nir_texop_txd &&
+ (options->lower_txd ||
+ (options->lower_txd_shadow &&
+tex->is_shadow && tex->sampler_dim != GLSL_SAMPLER_DIM_CUBE))) {
+ lower_gradient(b, tex);
progress = true;
continue;
}
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] nir: Fix interaction of GL_CLAMP lowering with texture offsets.
We want the clamping of the coordinate to apply after the offset, so we
need to do math to lower the offset out of the instruction. Fixes texwrap
offset cases for GL_CLAMP with GL_NEAREST on vc5.
Note: I moved the get_texture_size() verbatim, so that it was defined
before use.
---
src/compiler/nir/nir_lower_tex.c | 75 ++--
1 file changed, 42 insertions(+), 33 deletions(-)
diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c
index a50cb52d549a..bd603cc22884 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -101,6 +101,36 @@ project_src(nir_builder *b, nir_tex_instr *tex)
nir_tex_instr_remove_src(tex, proj_index);
}
+static nir_ssa_def *
+get_texture_size(nir_builder *b, nir_tex_instr *tex)
+{
+ b->cursor = nir_before_instr(&tex->instr);
+
+ nir_tex_instr *txs;
+
+ txs = nir_tex_instr_create(b->shader, 1);
+ txs->op = nir_texop_txs;
+ txs->sampler_dim = tex->sampler_dim;
+ txs->is_array = tex->is_array;
+ txs->is_shadow = tex->is_shadow;
+ txs->is_new_style_shadow = tex->is_new_style_shadow;
+ txs->texture_index = tex->texture_index;
+ txs->texture = nir_deref_var_clone(tex->texture, txs);
+ txs->sampler_index = tex->sampler_index;
+ txs->sampler = nir_deref_var_clone(tex->sampler, txs);
+ txs->dest_type = nir_type_int;
+
+ /* only single src, the lod: */
+ txs->src[0].src = nir_src_for_ssa(nir_imm_int(b, 0));
+ txs->src[0].src_type = nir_tex_src_lod;
+
+ nir_ssa_dest_init(&txs->instr, &txs->dest,
+ nir_tex_instr_dest_size(txs), 32, NULL);
+ nir_builder_instr_insert(b, &txs->instr);
+
+ return nir_i2f32(b, &txs->dest.ssa);
+}
+
static bool
lower_offset(nir_builder *b, nir_tex_instr *tex)
{
@@ -120,8 +150,17 @@ lower_offset(nir_builder *b, nir_tex_instr *tex)
nir_ssa_def *offset_coord;
if (nir_tex_instr_src_type(tex, coord_index) == nir_type_float) {
- assert(tex->sampler_dim == GLSL_SAMPLER_DIM_RECT);
- offset_coord = nir_fadd(b, coord, nir_i2f32(b, offset));
+ if (tex->sampler_dim == GLSL_SAMPLER_DIM_RECT) {
+ offset_coord = nir_fadd(b, coord, nir_i2f32(b, offset));
+ } else {
+ nir_ssa_def *txs = get_texture_size(b, tex);
+ nir_ssa_def *scale = nir_frcp(b, txs);
+
+ offset_coord = nir_fadd(b, coord,
+ nir_fmul(b,
+ nir_i2f32(b, offset),
+ scale));
+ }
} else {
offset_coord = nir_iadd(b, coord, offset);
}
@@ -148,37 +187,6 @@ lower_offset(nir_builder *b, nir_tex_instr *tex)
return true;
}
-
-static nir_ssa_def *
-get_texture_size(nir_builder *b, nir_tex_instr *tex)
-{
- b->cursor = nir_before_instr(&tex->instr);
-
- nir_tex_instr *txs;
-
- txs = nir_tex_instr_create(b->shader, 1);
- txs->op = nir_texop_txs;
- txs->sampler_dim = tex->sampler_dim;
- txs->is_array = tex->is_array;
- txs->is_shadow = tex->is_shadow;
- txs->is_new_style_shadow = tex->is_new_style_shadow;
- txs->texture_index = tex->texture_index;
- txs->texture = nir_deref_var_clone(tex->texture, txs);
- txs->sampler_index = tex->sampler_index;
- txs->sampler = nir_deref_var_clone(tex->sampler, txs);
- txs->dest_type = nir_type_int;
-
- /* only single src, the lod: */
- txs->src[0].src = nir_src_for_ssa(nir_imm_int(b, 0));
- txs->src[0].src_type = nir_tex_src_lod;
-
- nir_ssa_dest_init(&txs->instr, &txs->dest,
- nir_tex_instr_dest_size(txs), 32, NULL);
- nir_builder_instr_insert(b, &txs->instr);
-
- return nir_i2f32(b, &txs->dest.ssa);
-}
-
static void
lower_rect(nir_builder *b, nir_tex_instr *tex)
{
@@ -749,6 +757,7 @@ nir_lower_tex_block(nir_block *block, nir_builder *b,
}
if ((tex->op == nir_texop_txf && options->lower_txf_offset) ||
+ (sat_mask && nir_tex_instr_src_index(tex, nir_tex_src_coord) >= 0) ||
(tex->sampler_dim == GLSL_SAMPLER_DIM_RECT &&
options->lower_rect_offset)) {
progress = lower_offset(b, tex) || progress;
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] broadcom/vc5: Enable NIR txd lowering on all txd instructions.
Fixes almost all of piglit's arb_shader_texture_lod grad tests, except for
the base -texgrad/texgradcube ones which fail on what appear to be
precision problems.
---
src/broadcom/compiler/vir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/broadcom/compiler/vir.c b/src/broadcom/compiler/vir.c
index e7c050923c7a..d95a150c720a 100644
--- a/src/broadcom/compiler/vir.c
+++ b/src/broadcom/compiler/vir.c
@@ -541,6 +541,7 @@ static void
v3d_lower_nir(struct v3d_compile *c)
{
struct nir_lower_tex_options tex_options = {
+.lower_txd = true,
.lower_rect = false, /* XXX */
.lower_txp = ~0,
/* Apply swizzles to all samplers. */
--
2.15.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/5] gallium: Add helpers for MSAA resolves in pipe_transfer_map()/unmap().
I had replicated this code from vc4 to vc5, but it's something that most
drivers will need to do in a similar way.
---
src/gallium/auxiliary/util/u_transfer.c | 119
src/gallium/auxiliary/util/u_transfer.h | 10 +++
2 files changed, 129 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_transfer.c
b/src/gallium/auxiliary/util/u_transfer.c
index 3089bcb1f340..104d0505aaa8 100644
--- a/src/gallium/auxiliary/util/u_transfer.c
+++ b/src/gallium/auxiliary/util/u_transfer.c
@@ -153,3 +153,122 @@ void u_transfer_unmap_vtbl( struct pipe_context *pipe,
struct u_resource *ur = u_resource(transfer->resource);
ur->vtbl->transfer_unmap(pipe, transfer);
}
+
+struct u_transfer_msaa_helper {
+ struct pipe_transfer base;
+ struct pipe_resource *ss;
+ struct pipe_transfer *wrapped;
+};
+
+/**
+ * Helper to implement the implicit MSAA resolve necessary in the
+ * pipe_transfer API.
+ *
+ * The driver should call this when the resource is multisampled. We create a
+ * temporary single-sampled texture, blit to do the resolve if needed, and
+ * then call back to the driver to map the single-sampled texture.
+ *
+ * Note that the driver's unmap will be called with our ptrans: They need to
+ * detect it and call u_transfer_unmap_msaa_helper() and return immediately.
+ */
+void *
+u_transfer_map_msaa_helper(struct pipe_context *pctx,
+ struct pipe_resource *prsc,
+ unsigned level, unsigned usage,
+ const struct pipe_box *box,
+ struct pipe_transfer **pptrans)
+{
+ struct pipe_screen *pscreen = pctx->screen;
+ assert(prsc->nr_samples > 1);
+
+ struct u_transfer_msaa_helper *trans = calloc(1, sizeof(*trans));
+ if (!trans)
+ return NULL;
+ struct pipe_transfer *ptrans = &trans->base;
+
+ pipe_resource_reference(&ptrans->resource, prsc);
+ ptrans->level = level;
+ ptrans->usage = usage;
+ ptrans->box = *box;
+
+ struct pipe_resource temp_setup = {
+ .target = prsc->target,
+ .format = prsc->format,
+ .width0 = box->width,
+ .height0 = box->height,
+ .depth0 = 1,
+ .array_size = 1,
+ };
+ trans->ss = pscreen->resource_create(pscreen, &temp_setup);
+ if (!trans->ss) {
+ free(trans);
+ return NULL;
+ }
+
+ if (usage & PIPE_TRANSFER_READ) {
+ struct pipe_blit_info blit;
+ memset(&blit, 0, sizeof(blit));
+
+ blit.src.resource = ptrans->resource;
+ blit.src.format = ptrans->resource->format;
+ blit.src.level = ptrans->level;
+ blit.src.box = *box;
+
+ blit.dst.resource = trans->ss;
+ blit.dst.format = trans->ss->format;
+ blit.dst.box.width = box->width;
+ blit.dst.box.height = box->height;
+ blit.dst.box.depth = 1;
+
+ blit.mask = util_format_get_mask(prsc->format);
+ blit.filter = PIPE_TEX_FILTER_NEAREST;
+
+ pctx->blit(pctx, &blit);
+ }
+
+ void *ss_map = pctx->transfer_map(pctx, trans->ss, 0, usage, box,
+ &trans->wrapped);
+ if (!ss_map) {
+ free(trans);
+ return NULL;
+ }
+
+ *pptrans = ptrans;
+ return ss_map;
+}
+
+void u_transfer_unmap_msaa_helper(struct pipe_context *pctx,
+ struct pipe_transfer *ptrans)
+{
+ struct u_transfer_msaa_helper *trans =
+ (struct u_transfer_msaa_helper *)ptrans;
+
+ /* Unmap the single-sample resource, finishing whatever driver side storing
+* is necessary.
+*/
+ pipe_transfer_unmap(pctx, trans->wrapped);
+
+ if (ptrans->usage & PIPE_TRANSFER_WRITE) {
+ struct pipe_blit_info blit;
+ memset(&blit, 0, sizeof(blit));
+
+ blit.src.resource = trans->ss;
+ blit.src.format = trans->ss->format;
+ blit.src.box.width = ptrans->box.width;
+ blit.src.box.height = ptrans->box.height;
+ blit.src.box.depth = 1;
+
+ blit.dst.resource = ptrans->resource;
+ blit.dst.format = ptrans->resource->format;
+ blit.dst.level = ptrans->level;
+ blit.dst.box = ptrans->box;
+
+ blit.mask = util_format_get_mask(ptrans->resource->format);
+ blit.filter = PIPE_TEX_FILTER_NEAREST;
+
+ pctx->blit(pctx, &blit);
+ }
+
+ pipe_resource_reference(&trans->ss, NULL);
+ free(trans);
+}
diff --git a/src/gallium/auxiliary/util/u_transfer.h
b/src/gallium/auxiliary/util/u_transfer.h
index 14084983daf9..237930c06007 100644
--- a/src/gallium/auxiliary/util/u_transfer.h
+++ b/src/gallium/auxiliary/util/u_transfer.h
@@ -14,6 +14,16 @@ struct winsys_handle;
extern "C" {
#endif
+void *
+u_transfer_map_msaa_helper(struct pipe_context *pctx,
+ struct pipe_resource *prsc,
+ unsigned level, unsigned usage,
+ const struct pipe_box *box,
+ struct pipe_transfer **pptrans);
+
+void u_transfer_unmap_msaa_helper(struct pipe_context *pctx,
+
[Mesa-dev] [PATCH v2 4/5] gallium: Make a helper for doing Z32_FLOAT_S8X24_UINT mappings.
v2: Remove the callback, leave avoiding the recursion up to the caller
(probably by rewriting the vtbl either in pctx or u_resource_vtbl)
---
src/gallium/auxiliary/util/u_transfer.c | 114
src/gallium/auxiliary/util/u_transfer.h | 11 +++
2 files changed, 125 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_transfer.c
b/src/gallium/auxiliary/util/u_transfer.c
index 104d0505aaa8..2d219721dcf8 100644
--- a/src/gallium/auxiliary/util/u_transfer.c
+++ b/src/gallium/auxiliary/util/u_transfer.c
@@ -1,4 +1,5 @@
#include "pipe/p_context.h"
+#include "util/u_format_zs.h"
#include "util/u_surface.h"
#include "util/u_inlines.h"
#include "util/u_transfer.h"
@@ -272,3 +273,116 @@ void u_transfer_unmap_msaa_helper(struct pipe_context
*pctx,
pipe_resource_reference(&trans->ss, NULL);
free(trans);
}
+
+struct u_transfer_z32f_s8_helper {
+ struct pipe_transfer base;
+ struct pipe_transfer *z_ptrans;
+ struct pipe_transfer *s_ptrans;
+ void *z, *s;
+ void *merged;
+};
+
+/**
+ * Helper to implement the PIPE_FORMAT_Z32_FLOAT_S8X24_UINT mappings when the
+ * driver stores the Z and S in separate resources.
+ *
+ * We malloc temporary storage, map each resource, and use the CPU to pack the
+ * values into the temporary.
+ *
+ * Note that the driver's unmap will be called with our ptrans: They need to
+ * detect it and call u_transfer_unmap_z32f_s8_helper() and return
+ * immediately.
+ *
+ * In both the map and unmap paths, the driver will need to be careful to
+ * unwrap its transfer_map()/unmap() method that would call us, so that it
+ * doesn't recurse when we call back into it.
+ */
+void *
+u_transfer_map_z32f_s8_helper(struct pipe_context *pctx,
+ struct pipe_resource *z,
+ struct pipe_resource *s,
+ unsigned level, unsigned usage,
+ const struct pipe_box *box,
+ struct pipe_transfer **pptrans)
+{
+ struct u_transfer_z32f_s8_helper *trans = calloc(1, sizeof(*trans));
+ if (!trans)
+ return NULL;
+ struct pipe_transfer *ptrans = &trans->base;
+
+ pipe_resource_reference(&ptrans->resource, z);
+ ptrans->level = level;
+ ptrans->usage = usage;
+ ptrans->box = *box;
+
+ trans->z = pctx->transfer_map(pctx, z, level, usage, box,
+ &trans->z_ptrans);
+ if (!trans->z)
+ goto fail_unref;
+ trans->s = pctx->transfer_map(pctx, s, level, usage, box,
+ &trans->s_ptrans);
+ if (!trans->s)
+ goto fail_unmap_z;
+
+ ptrans->stride = 8 * box->width;
+ trans->merged = malloc(ptrans->stride * box->height);
+ if (!trans->merged)
+ goto fail_unmap_s;
+
+ if (usage & PIPE_TRANSFER_READ) {
+ util_format_z32_float_s8x24_uint_pack_z_float(trans->merged,
+ptrans->stride,
+trans->z,
+trans->z_ptrans->stride,
+box->width,
+box->height);
+ util_format_z32_float_s8x24_uint_pack_s_8uint(trans->merged,
+ptrans->stride,
+trans->s,
+trans->s_ptrans->stride,
+box->width,
+box->height);
+ }
+
+ *pptrans = ptrans;
+ return trans->merged;
+
+ fail_unmap_s:
+ pctx->transfer_unmap(pctx, trans->s_ptrans);
+ fail_unmap_z:
+ pctx->transfer_unmap(pctx, trans->z_ptrans);
+ fail_unref:
+ pipe_resource_reference(&ptrans->resource, NULL);
+ free(trans);
+ return NULL;
+}
+
+void u_transfer_unmap_z32f_s8_helper(struct pipe_context *pctx,
+ struct pipe_transfer *ptrans)
+{
+ struct u_transfer_z32f_s8_helper *trans =
+ (struct u_transfer_z32f_s8_helper *)ptrans;
+
+ if (ptrans->usage & PIPE_TRANSFER_WRITE) {
+ uint32_t width = ptrans->box.width;
+ uint32_t height = ptrans->box.height;
+
+ util_format_z32_float_s8x24_uint_unpack_z_float(trans->z,
+ trans->z_ptrans->stride,
+ trans->merged,
+ ptrans->stride,
+ width, height);
+ util_format_z32_float_s8x24_uint_unpack_s_8uint(trans->s,
+ trans->s_ptrans->stride,
+ trans->merged,
+ ptrans->stride,
+
[Mesa-dev] [PATCH v2 2/5] broadcom/vc4: Switch to using the u_transfer_map_msaa_helper().
---
src/gallium/drivers/vc4/vc4_resource.c | 104 -
src/gallium/drivers/vc4/vc4_resource.h | 3 -
2 files changed, 10 insertions(+), 97 deletions(-)
diff --git a/src/gallium/drivers/vc4/vc4_resource.c
b/src/gallium/drivers/vc4/vc4_resource.c
index cdcbcc917e0d..b97e09414acc 100644
--- a/src/gallium/drivers/vc4/vc4_resource.c
+++ b/src/gallium/drivers/vc4/vc4_resource.c
@@ -75,19 +75,15 @@ static void
vc4_resource_transfer_unmap(struct pipe_context *pctx,
struct pipe_transfer *ptrans)
{
+if (ptrans->resource->nr_samples > 1)
+return u_transfer_unmap_msaa_helper(pctx, ptrans);
+
struct vc4_context *vc4 = vc4_context(pctx);
struct vc4_transfer *trans = vc4_transfer(ptrans);
if (trans->map) {
-struct vc4_resource *rsc;
-struct vc4_resource_slice *slice;
-if (trans->ss_resource) {
-rsc = vc4_resource(trans->ss_resource);
-slice = &rsc->slices[0];
-} else {
-rsc = vc4_resource(ptrans->resource);
-slice = &rsc->slices[ptrans->level];
-}
+struct vc4_resource *rsc = vc4_resource(ptrans->resource);
+struct vc4_resource_slice *slice = &rsc->slices[ptrans->level];
if (ptrans->usage & PIPE_TRANSFER_WRITE) {
vc4_store_tiled_image(rsc->bo->map + slice->offset +
@@ -100,51 +96,10 @@ vc4_resource_transfer_unmap(struct pipe_context *pctx,
free(trans->map);
}
-if (trans->ss_resource && (ptrans->usage & PIPE_TRANSFER_WRITE)) {
-struct pipe_blit_info blit;
-memset(&blit, 0, sizeof(blit));
-
-blit.src.resource = trans->ss_resource;
-blit.src.format = trans->ss_resource->format;
-blit.src.box.width = trans->ss_box.width;
-blit.src.box.height = trans->ss_box.height;
-blit.src.box.depth = 1;
-
-blit.dst.resource = ptrans->resource;
-blit.dst.format = ptrans->resource->format;
-blit.dst.level = ptrans->level;
-blit.dst.box = trans->ss_box;
-
-blit.mask = util_format_get_mask(ptrans->resource->format);
-blit.filter = PIPE_TEX_FILTER_NEAREST;
-
-pctx->blit(pctx, &blit);
-
-pipe_resource_reference(&trans->ss_resource, NULL);
-}
-
pipe_resource_reference(&ptrans->resource, NULL);
slab_free(&vc4->transfer_pool, ptrans);
}
-static struct pipe_resource *
-vc4_get_temp_resource(struct pipe_context *pctx,
- struct pipe_resource *prsc,
- const struct pipe_box *box)
-{
-struct pipe_resource temp_setup;
-
-memset(&temp_setup, 0, sizeof(temp_setup));
-temp_setup.target = prsc->target;
-temp_setup.format = prsc->format;
-temp_setup.width0 = box->width;
-temp_setup.height0 = box->height;
-temp_setup.depth0 = 1;
-temp_setup.array_size = 1;
-
-return pctx->screen->resource_create(pctx->screen, &temp_setup);
-}
-
static void *
vc4_resource_transfer_map(struct pipe_context *pctx,
struct pipe_resource *prsc,
@@ -159,6 +114,11 @@ vc4_resource_transfer_map(struct pipe_context *pctx,
enum pipe_format format = prsc->format;
char *buf;
+if (prsc->nr_samples > 1) {
+return u_transfer_map_msaa_helper(pctx, prsc, level, usage,
+ box, pptrans);
+}
+
/* Upgrade DISCARD_RANGE to WHOLE_RESOURCE if the whole resource is
* being mapped.
*/
@@ -218,50 +178,6 @@ vc4_resource_transfer_map(struct pipe_context *pctx,
ptrans->usage = usage;
ptrans->box = *box;
-/* If the resource is multisampled, we need to resolve to single
- * sample. This seems like it should be handled at a higher layer.
- */
-if (prsc->nr_samples > 1) {
-trans->ss_resource = vc4_get_temp_resource(pctx, prsc, box);
-if (!trans->ss_resource)
-goto fail;
-assert(!trans->ss_resource->nr_samples);
-
-/* The ptrans->box gets modified for tile alignment, so save
- * the original box for unmap time.
- */
-trans->ss_box = *box;
-
-if (usage & PIPE_TRANSFER_READ) {
-struct pipe_blit_info blit;
-memset(&blit, 0, sizeof(blit));
-
-blit.src.resource = ptrans->resource;
-blit.src.format = ptrans->resource->format;
-blit.src.level = ptrans->level;
-
[Mesa-dev] [PATCH v2 5/5] broadcom/vc5: Start adding support for rendering to Z32F_S8X24_UINT.
There may be some more RCL work to be done (I think I need to split my Z/S
stores when doing separate stencil), but this gets piglit's "texwrap
GL_ARB_depth_buffer_float" working.
v2: Unwrap the z32f_wrapper before calling the helper, rather than having
the helper have a callback.
---
src/gallium/drivers/vc5/vc5_rcl.c | 22 +
src/gallium/drivers/vc5/vc5_resource.c | 89 --
src/gallium/drivers/vc5/vc5_resource.h | 6 +++
src/gallium/drivers/vc5/vc5_screen.c | 6 +++
4 files changed, 120 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/vc5/vc5_rcl.c
b/src/gallium/drivers/vc5/vc5_rcl.c
index 1fa00b2e8101..89ae44660f5b 100644
--- a/src/gallium/drivers/vc5/vc5_rcl.c
+++ b/src/gallium/drivers/vc5/vc5_rcl.c
@@ -348,6 +348,28 @@ vc5_emit_rcl(struct vc5_job *job)
if (job->resolve & PIPE_CLEAR_DEPTHSTENCIL)
rsc->writes++;
+
+/* Emit the separate stencil packet if we have a resource for
+ * it. The HW will only load/store this buffer if the
+ * Z/Stencil config doesn't have stencil in its format.
+ */
+if (rsc->separate_stencil) {
+cl_emit(&job->rcl,
+
TILE_RENDERING_MODE_CONFIGURATION_Z_STENCIL_CONFIG,
+zs) {
+zs.address =
+cl_address(rsc->separate_stencil->bo,
+
surf->separate_stencil_offset);
+
+zs.z_stencil_id = 1; /* Separate stencil */
+
+zs.padded_height_of_output_image_in_uif_blocks
=
+
surf->separate_stencil_padded_height_of_output_image_in_uif_blocks;
+
+assert(surf->tiling != VC5_TILING_RASTER);
+zs.memory_format =
surf->separate_stencil_tiling;
+}
+}
}
/* Ends rendering mode config. */
diff --git a/src/gallium/drivers/vc5/vc5_resource.c
b/src/gallium/drivers/vc5/vc5_resource.c
index 0f855c17e21d..f0f7969775fc 100644
--- a/src/gallium/drivers/vc5/vc5_resource.c
+++ b/src/gallium/drivers/vc5/vc5_resource.c
@@ -28,6 +28,7 @@
#include "util/u_inlines.h"
#include "util/u_surface.h"
#include "util/u_upload_mgr.h"
+#include "util/u_format_zs.h"
#include "drm_fourcc.h"
#include "vc5_screen.h"
@@ -280,11 +281,56 @@ fail:
return NULL;
}
+/* Decomposes a PIPE_FORMAT_Z32_FLOAT_S8X24_UINT transfer into mappings of
+ * each resource into a temporary buffer using the gallium helper.
+ *
+ * This has to be a separate function from vc5_resource_transfer_map() to
+ * prevent infinite recusion.
+ */
+static void *
+vc5_resource_transfer_map_z32f_wrapper(struct pipe_context *pctx,
+ struct pipe_resource *prsc,
+ unsigned level, unsigned usage,
+ const struct pipe_box *box,
+ struct pipe_transfer **pptrans)
+{
+if (prsc->format != PIPE_FORMAT_Z32_FLOAT_S8X24_UINT) {
+return vc5_resource_transfer_map(pctx, prsc, level, usage,
+ box, pptrans);
+}
+
+struct vc5_resource *rsc = vc5_resource(prsc);
+pctx->transfer_map = vc5_resource_transfer_map;
+void *map = u_transfer_map_z32f_s8_helper(pctx, prsc,
+ &rsc->separate_stencil->base,
+ level, usage,
+ box, pptrans);
+pctx->transfer_map = vc5_resource_transfer_map_z32f_wrapper;
+return map;
+}
+
+static void
+vc5_resource_transfer_unmap_z32f_wrapper(struct pipe_context *pctx,
+ struct pipe_transfer *ptrans)
+{
+if (ptrans->resource->format == PIPE_FORMAT_Z32_FLOAT_S8X24_UINT) {
+pctx->transfer_unmap = vc5_resource_transfer_unmap;
+u_transfer_unmap_z32f_s8_helper(pctx, ptrans);
+pctx->transfer_unmap =
vc5_resource_transfer_unmap_z32f_wrapper;
+} else {
+vc5_resource_transfer_unmap(pctx, ptrans);
+}
+}
+
static void
vc5_resource_destroy(struct pipe_screen *pscreen,
struct pipe_resource *prsc)
{
struct vc5_resource *rsc = vc5_resource(prsc);
+
+if (rsc->separate_stencil)
+vc5_resource_destroy(pscreen, &rsc->separate_stencil->base);
+
vc5_bo_unreference(&rsc->bo);
free(rsc);
}
@@ -436,7 +482,13 @@ vc5_resource_setup(struct pipe_screen *pscreen,
prsc->screen = pscreen;
if (prsc->nr_samples <= 1) {
-
