Re: [Mesa-dev] [PATCH 06/16] nir: improve convert_yuv_to_rgb when fuse_ffma=true
Den ons 19 dec. 2018 17:44 skrev Jonathan Marek :
> When ffma is available, we can use a different arrangement of constants to
> get a better result. On freedreno/ir3, this reduces the YUV->RGB to 7
> scalar ffma. On freedreno/a2xx, it will allow YUV->RGB to be 3 vec4 ffma.
>
> Signed-off-by: Jonathan Marek
> ---
> src/compiler/nir/nir_lower_tex.c | 62 ++--
> 1 file changed, 43 insertions(+), 19 deletions(-)
>
> diff --git a/src/compiler/nir/nir_lower_tex.c
> b/src/compiler/nir/nir_lower_tex.c
> index 6a6b6c41a7..f7c821bb34 100644
> --- a/src/compiler/nir/nir_lower_tex.c
> +++ b/src/compiler/nir/nir_lower_tex.c
> @@ -342,25 +342,49 @@ convert_yuv_to_rgb(nir_builder *b, nir_tex_instr
> *tex,
> nir_ssa_def *y, nir_ssa_def *u, nir_ssa_def *v,
> nir_ssa_def *a)
> {
> - nir_const_value m[3] = {
> - { .f32 = { 1.0f, 0.0f, 1.59602678f, 0.0f } },
> - { .f32 = { 1.0f, -0.39176229f, -0.81296764f, 0.0f } },
> - { .f32 = { 1.0f, 2.01723214f, 0.0f,0.0f } }
> - };
> -
> - nir_ssa_def *yuv =
> - nir_vec4(b,
> - nir_fmul(b, nir_imm_float(b, 1.16438356f),
> -nir_fadd(b, y, nir_imm_float(b, -16.0f /
> 255.0f))),
> - nir_channel(b, nir_fadd(b, u, nir_imm_float(b, -128.0f /
> 255.0f)), 0),
> - nir_channel(b, nir_fadd(b, v, nir_imm_float(b, -128.0f /
> 255.0f)), 0),
> - nir_imm_float(b, 0.0));
> -
> - nir_ssa_def *red = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[0]));
> - nir_ssa_def *green = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[1]));
> - nir_ssa_def *blue = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[2]));
> -
> - nir_ssa_def *result = nir_vec4(b, red, green, blue, a);
> + nir_ssa_def *result;
> +
> +
> + if (b->shader->options->fuse_ffma) {
> + nir_const_value m[4] = {
>
Drive-by comment, but shouldn't this^ be m[3]?
Regards
Nils
+ { .f32 = { 1.16438356f, 1.16438356f, 1.16438356f, 0.0f } },
> + { .f32 = { 0.0f, -0.39176229f, 2.01723214f, 0.0f } },
> + { .f32 = { 1.59602678f,-0.81296764f, 0.0f,0.0f } },
> + };
> + static const float y_off = -16.0f * 1.16438356f / 255.0f;
> + static const float sc = 128.0f / 255.0f;
> +
> + nir_ssa_def *offset =
> + nir_vec4(b,
> + nir_imm_float(b, y_off - sc * 1.59602678f),
> + nir_imm_float(b, y_off + sc * (0.81296764f +
> 0.39176229f)),
> + nir_imm_float(b, y_off - sc * 2.01723214f),
> + a);
> +
> + result = nir_ffma(b, y, nir_build_imm(b, 4, 32, m[0]),
> + nir_ffma(b, u, nir_build_imm(b, 4, 32, m[1]),
> +nir_ffma(b, v, nir_build_imm(b, 4, 32,
> m[2]), offset)));
> + } else {
> + nir_const_value m[3] = {
> + { .f32 = { 1.0f, 0.0f, 1.59602678f, 0.0f } },
> + { .f32 = { 1.0f, -0.39176229f, -0.81296764f, 0.0f } },
> + { .f32 = { 1.0f, 2.01723214f, 0.0f,0.0f } }
> + };
> +
> + nir_ssa_def *yuv =
> + nir_vec4(b,
> + nir_fmul(b, nir_imm_float(b, 1.16438356f),
> + nir_fadd(b, y, nir_imm_float(b, -16.0f /
> 255.0f))),
> + nir_channel(b, nir_fadd(b, u, nir_imm_float(b, -128.0f
> / 255.0f)), 0),
> + nir_channel(b, nir_fadd(b, v, nir_imm_float(b, -128.0f
> / 255.0f)), 0),
> + nir_imm_float(b, 0.0));
> +
> + nir_ssa_def *red = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[0]));
> + nir_ssa_def *green = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32,
> m[1]));
> + nir_ssa_def *blue = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32,
> m[2]));
> +
> + result = nir_vec4(b, red, green, blue, a);
> + }
>
> nir_ssa_def_rewrite_uses(>dest.ssa, nir_src_for_ssa(result));
> }
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105376] es2gears_wayland reports 120 fps while drawing at 60 fps
https://bugs.freedesktop.org/show_bug.cgi?id=105376 --- Comment #3 from Daniel van Vugt --- Also, on a real 120Hz display, es2gears_wayland reports 240 FPS. Verified in both gnome-shell and weston. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 12:50 PM Jason Ekstrand wrote: > What do you suggest to solve this communication issue? If autotools survives > another release, so be it. However, I want to get us out of the vicious > cycle of long e-mail threads and endless debates and on to a model where > Dylan is working towards something and is able to actually close the gap. > The cynic in me says that if the last week's exchanges teach us anything, > it's that we'll never make the naysayers happy and we're wasting our time > trying. I badly don't want that to be true. However, for my internal cynic > to be proven wrong, we need a more productive model for how we close that gap > and agree that it's "good enough." What do you suggest? Well, there are a few considerations here. First of all, "who should we ask". I'm thinking, whoever's had at least 25 changes this year [not a scientific cut-off, could go higher or lower, but some precedence for that number -- iirc Valve uses that as the cut-off for giving the all-valve-games-package]: git shortlog origin --since 2018-01-01 | grep '^\w' | awk -F"[()]" '$(NF-1) > 25' This works out to 49 people as of a few days ago. I'm thinking these are all people who have built mesa over and over and over again, and know the various pitfalls, as well as are remaining active contributors and thus "part of the community". Ideally these people would also be the ones who know the sorts of issues that end-users run into through doing a bunch of support, but that's harder to screen for. Separately go through each driver and state tracker, and ensure that at least one significant contributor for each one is on that list of people. Glancing over the above list, I believe that's already the case, but a thorough check should be performed. When the current crop of issues is fixed, you should request that each of these people give the current checked-in meson setup a fair shake or forever hold their peace re build systems. You should give about 2 weeks for people to do this -- I know many of the issues I ran into weren't on day 1 but rather on day 10 of using meson. Of these, I assume a bunch won't care and bow out. The remainder should submit a list of asks for a replacement. Hopefully we're all grown-ups and don't ask for the moon -- any outliers can be dealt with separately. I think anything that's materially over and above what autotools does now is just out. However you need to be prepared for feedback that requires changes to meson. Any feedback you [the "meson" group] believe is not worth addressing (or would incur an unduly high amount of effort to resolve) should be separated out [and collated], and we can, as a group decide if it's really worth dealing with or not. Rinse and repeat until the concerns of the group are either addressed or deemed too esoteric. I realize I've taken some shortcuts here ... who determines what's esoteric and what's not, and how does the group come to a consensus on it? I'm hoping we can all be reasonable, and not have to have it come to that. If there's a situation that's not resolvable directly, we'll have to figure it out then. > > what are we supposed to do about the things which aren't actually worse but > are just different? All these things are preferences, of course. Each complaint should be triaged and decided whether it's important to fix or not. On top of preference, practical considerations need to be taken into account -- difficulty, importance, etc. Different isn't necessarily bad, but it's also not necessarily good. I believe it would be a laudable goal to have a way to make this all entirely transparent to the average user [who doesn't care to learn a fancy new system], and in my mind I've sketched out a pretty trivial way to get to it. Perhaps there's a giant gaping hole in my estimate which makes it go from "easy" to "very hard", at which point I'd obviously reconsider the necessity. Lastly, I suspect many of you who are eager to get the shiny new meson build to be the default are considering me to be the bad guy here -- I don't really mind. However realize that there are people out there who *do* mind that sort of thing. Either due to personality, or due to job security (for many of the frequent contributors, mesa is their day job), or due to being on the same team and not wanting real-life weirdness, people won't speak up. I don't think we're at the point where feedback needs to be anonymous or anything, but it's something to be mindful of as we make changes that affect everyone's workflows. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] st/nine: Use helper to release swapchain buffers later
For the series:
Tested-by: Dieter Nützel
(with my 'normal' apps) ;-)
+ LS2015 (D3D9) under Wine Staging Nine 4.0-rc2
nice numbers
Dieter
Am 16.12.2018 22:25, schrieb Axel Davy:
This patch introduces a structure to release the
present_handles only when they are fully released
by the server, thus making
"DestroyD3DWindowBuffer" actually release the buffer
right away when called.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/swapchain9.c | 49
src/gallium/state_trackers/nine/swapchain9.h | 1 +
2 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/nine/swapchain9.c
b/src/gallium/state_trackers/nine/swapchain9.c
index d330c855726..138e8816a05 100644
--- a/src/gallium/state_trackers/nine/swapchain9.c
+++ b/src/gallium/state_trackers/nine/swapchain9.c
@@ -128,6 +128,40 @@ D3DWindowBuffer_create(struct NineSwapChain9
*This,
return ret;
}
+static void
+D3DWindowBuffer_release(struct NineSwapChain9 *This,
+D3DWindowBuffer *present_handle)
+{
+int i;
+/* Add it to the 'pending release' list */
+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (!This->present_handles_pending_release[i]) {
+This->present_handles_pending_release[i] = present_handle;
+break;
+}
+}
+if (i == (D3DPRESENT_BACK_BUFFERS_MAX_EX + 1)) {
+ERR("Server not releasing buffers...\n");
+assert(false);
+}
+
+/* Destroy elements of the list released by the server */
+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (This->present_handles_pending_release[i] &&
+ID3DPresent_IsBufferReleased(This->present,
This->present_handles_pending_release[i])) {
+/* WaitBufferReleased also waits the presentation feedback
+ * (which should arrive at about the same time),
+ * while IsBufferReleased doesn't. DestroyD3DWindowBuffer
unfortunately
+ * checks it to release immediately all data, else the
release
+ * is postponed for This->present release. To avoid leaks
(we may handle
+ * a lot of resize), call WaitBufferReleased. */
+ID3DPresent_WaitBufferReleased(This->present,
This->present_handles_pending_release[i]);
+ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles_pending_release[i]);
+This->present_handles_pending_release[i] = NULL;
+}
+}
+}
+
static int
NineSwapChain9_GetBackBufferCountForParams( struct NineSwapChain9
*This,
D3DPRESENT_PARAMETERS
*pParams );
@@ -291,7 +325,7 @@ NineSwapChain9_Resize( struct NineSwapChain9 *This,
This->enable_threadpool = FALSE;
for (i = 0; i < oldBufferCount; i++) {
-ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles[i]);
+D3DWindowBuffer_release(This, This->present_handles[i]);
This->present_handles[i] = NULL;
if (This->present_buffers[i])
pipe_resource_reference(&(This->present_buffers[i]),
NULL);
@@ -519,6 +553,11 @@ NineSwapChain9_dtor( struct NineSwapChain9 *This )
FREE(This->pending_presentation[i]);
}
+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (This->present_handles_pending_release[i])
+ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles_pending_release[i]);
+}
+
for (i = 0; i < This->num_back_buffers; i++) {
if (This->buffers[i])
NineUnknown_Detach(NineUnknown(This->buffers[i]));
@@ -738,13 +777,7 @@ present( struct NineSwapChain9 *This,
create_present_buffer(This, target_width, target_height,
_resource, _handle);
/* Switch to the new buffer */
if (new_handle) {
-/* WaitBufferReleased also waits the presentation
feedback,
- * while IsBufferReleased doesn't.
DestroyD3DWindowBuffer unfortunately
- * checks it to release immediately all data, else the
release
- * is postponed for This->present release. To avoid
leaks (we may handle
- * a lot of resize), call WaitBufferReleased. */
-ID3DPresent_WaitBufferReleased(This->present,
This->present_handles[0]);
-ID3DPresent_DestroyD3DWindowBuffer(This->present,
This->present_handles[0]);
+D3DWindowBuffer_release(This,
This->present_handles[0]);
This->present_handles[0] = new_handle;
pipe_resource_reference(>present_buffers[0],
new_resource);
pipe_resource_reference(_resource, NULL);
diff --git a/src/gallium/state_trackers/nine/swapchain9.h
b/src/gallium/state_trackers/nine/swapchain9.h
index 0fa0589d3b7..a6146445bdd 100644
--- a/src/gallium/state_trackers/nine/swapchain9.h
+++ b/src/gallium/state_trackers/nine/swapchain9.h
@@
Re: [Mesa-dev] [PATCH v2 1/5] st/glsl_to_nir: call nir_lower_load_const_to_scalar() in the st
For the series:
Tested-by: Dieter Nützel
(with my 'normal' apps) ;-)
Dieter
Am 19.12.2018 11:03, schrieb Timothy Arceri:
This will help the new opt introduced in the following patches
allowing us to remove extra duplicate varyings.
Reviewed-by: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader_nir.c | 2 --
src/mesa/state_tracker/st_glsl_to_nir.cpp| 4 +++-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 0a692277f6..3883337b00 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -823,8 +823,6 @@ si_lower_nir(struct si_shader_selector* sel)
ac_lower_indirect_derefs(sel->nir, sel->screen->info.chip_class);
- NIR_PASS_V(sel->nir, nir_lower_load_const_to_scalar);
-
bool progress;
do {
progress = false;
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index ed9f643e89..5176756433 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -702,8 +702,10 @@ st_link_nir(struct gl_context *ctx,
nir_shader *nir = shader->Program->nir;
- if (is_scalar[i])
+ if (is_scalar[i]) {
NIR_PASS_V(nir, nir_lower_io_to_scalar_early, mask);
+ NIR_PASS_V(nir, nir_lower_load_const_to_scalar);
+ }
st_nir_opts(nir, is_scalar[i]);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] radeonsi: remove unrequired param in si_nir_scan_tess_ctrl()
For the series:
Tested-by: Dieter Nützel
(with my 'normal' apps) ;-)
Dieter
Am 18.12.2018 02:17, schrieb Timothy Arceri:
---
src/gallium/drivers/radeonsi/si_shader.h| 1 -
src/gallium/drivers/radeonsi/si_shader_nir.c| 1 -
src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.h
b/src/gallium/drivers/radeonsi/si_shader.h
index f71e601574..cdb57958dd 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -708,7 +708,6 @@ const char *si_get_shader_name(const struct
si_shader *shader, unsigned processo
void si_nir_scan_shader(const struct nir_shader *nir,
struct tgsi_shader_info *info);
void si_nir_scan_tess_ctrl(const struct nir_shader *nir,
- const struct tgsi_shader_info *info,
struct tgsi_tessctrl_info *out);
void si_lower_nir(struct si_shader_selector *sel);
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 660b5bc356..b81bea00b8 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -278,7 +278,6 @@ static void scan_instruction(struct
tgsi_shader_info *info,
}
void si_nir_scan_tess_ctrl(const struct nir_shader *nir,
- const struct tgsi_shader_info *info,
struct tgsi_tessctrl_info *out)
{
memset(out, 0, sizeof(*out));
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index de00df60ae..2d5d163247 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -2238,7 +2238,7 @@ static void *si_create_shader_selector(struct
pipe_context *ctx,
sel->nir = state->ir.nir;
si_nir_scan_shader(sel->nir, >info);
- si_nir_scan_tess_ctrl(sel->nir, >info, >tcs_info);
+ si_nir_scan_tess_ctrl(sel->nir, >tcs_info);
si_lower_nir(sel);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] radeonsi: don't emit redundant PKT3_NUM_INSTANCES packets
For the series:
Tested-by: Dieter Nützel
(with my 'normal' apps) ;-)
Dieter
Am 14.12.2018 22:23, schrieb Marek Olšák:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pipe.h | 3 +++
src/gallium/drivers/radeonsi/si_state_draw.c | 9 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h
b/src/gallium/drivers/radeonsi/si_pipe.h
index 1d677d29e88..b3522b60752 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -40,20 +40,21 @@
#define ATI_VENDOR_ID 0x1002
#define SI_NOT_QUERY 0x
/* The base vertex and primitive restart can be any number, but we
must pick
* one which will mean "unknown" for the purpose of state tracking and
* the number shouldn't be a commonly-used one. */
#define SI_BASE_VERTEX_UNKNOWN INT_MIN
#define SI_RESTART_INDEX_UNKNOWN INT_MIN
+#define SI_INSTANCE_COUNT_UNKNOWN INT_MIN
#define SI_NUM_SMOOTH_AA_SAMPLES 8
#define SI_MAX_POINT_SIZE 2048
#define SI_GS_PER_ES 128
/* Alignment for optimal CP DMA performance. */
#define SI_CPDMA_ALIGNMENT 32
/* Tunables for compute-based clear_buffer and copy_buffer: */
#define SI_COMPUTE_CLEAR_DW_PER_THREAD 4
#define SI_COMPUTE_COPY_DW_PER_THREAD 4
#define SI_COMPUTE_DST_CACHE_POLICYL2_STREAM
@@ -918,20 +919,21 @@ struct si_context {
booldb_stencil_disable_expclear:1;
boolocclusion_queries_disabled:1;
boolgenerate_mipmap_for_depth:1;
/* Emitted draw state. */
boolgs_tri_strip_adj_fix:1;
boolls_vgpr_fix:1;
int last_index_size;
int last_base_vertex;
int last_start_instance;
+ int last_instance_count;
int last_drawid;
int last_sh_base_reg;
int last_primitive_restart_en;
int last_restart_index;
int last_prim;
int last_multi_vgt_param;
int last_rast_prim;
unsignedlast_sc_line_stipple;
unsignedcurrent_vs_state;
unsignedlast_vs_state;
@@ -1369,20 +1371,21 @@ si_context_add_resource_size(struct si_context
*sctx, struct pipe_resource *r)
/* Add memory usage for need_gfx_cs_space */
sctx->vram += r600_resource(r)->vram_usage;
sctx->gtt += r600_resource(r)->gart_usage;
}
}
static inline void
si_invalidate_draw_sh_constants(struct si_context *sctx)
{
sctx->last_base_vertex = SI_BASE_VERTEX_UNKNOWN;
+ sctx->last_instance_count = SI_INSTANCE_COUNT_UNKNOWN;
}
static inline unsigned
si_get_atom_bit(struct si_context *sctx, struct si_atom *atom)
{
return 1 << (atom - sctx->atoms.array);
}
static inline void
si_set_atom_dirty(struct si_context *sctx, struct si_atom *atom, bool
dirty)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 612ca910cb9..b707a6585c5 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -802,24 +802,29 @@ static void si_emit_draw_packets(struct
si_context *sctx,
radeon_emit(cs, ((sh_base_reg + SI_SGPR_DRAWID * 4 -
SI_SH_REG_OFFSET) >> 2) |
S_2C3_DRAW_INDEX_ENABLE(1) |
S_2C3_COUNT_INDIRECT_ENABLE(!!indirect->indirect_draw_count));
radeon_emit(cs, indirect->draw_count);
radeon_emit(cs, count_va);
radeon_emit(cs, count_va >> 32);
radeon_emit(cs, indirect->stride);
radeon_emit(cs, di_src_sel);
}
} else {
+ unsigned instance_count = info->instance_count;
int base_vertex;
- radeon_emit(cs, PKT3(PKT3_NUM_INSTANCES, 0, 0));
- radeon_emit(cs, info->instance_count);
+ if (sctx->last_instance_count == SI_INSTANCE_COUNT_UNKNOWN ||
+ sctx->last_instance_count != instance_count) {
+ radeon_emit(cs, PKT3(PKT3_NUM_INSTANCES, 0, 0));
+ radeon_emit(cs, instance_count);
+ sctx->last_instance_count = instance_count;
+ }
/* Base vertex and start instance. */
base_vertex = index_size ? info->index_bias : info->start;
if (sctx->num_vs_blit_sgprs) {
/* Re-emit draw constants after we leave u_blitter.
Re: [Mesa-dev] [PATCH 01/38] ac: add various helpers for float16/int16/int8
I personally don't see a point in reimplementing existing LLVM functions.
There is also LLVMConstNull for zeros and LLVMConstAllOnes for integer
ones, though I think those are mainly good for vectors and people are most
used to seeing LLVMConstInt and LLVMConstReal for scalars.
Marek
On Wed, Dec 19, 2018 at 5:03 PM Rhys Perry wrote:
> I would expect these helpers to be much more efficient than the
> functions you suggested. They are also (in my opinion) more readable
> than the suggested functions.
>
> I don't think it matters much though, so I'm fine either way.
>
> On Tue, 18 Dec 2018 at 02:48, Marek Olšák wrote:
> >
> > On Fri, Dec 7, 2018 at 12:22 PM Rhys Perry
> wrote:
> >>
> >> Signed-off-by: Rhys Perry
> >> ---
> >> src/amd/common/ac_llvm_build.c | 123 ++--
> >> src/amd/common/ac_llvm_build.h | 22 +-
> >> src/amd/common/ac_nir_to_llvm.c | 30
> >> 3 files changed, 154 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/src/amd/common/ac_llvm_build.c
> b/src/amd/common/ac_llvm_build.c
> >> index 154cc696a2..cc7c6da5a4 100644
> >> --- a/src/amd/common/ac_llvm_build.c
> >> +++ b/src/amd/common/ac_llvm_build.c
> >> @@ -87,12 +87,16 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
> >> ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
> >> ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
> >>
> >> + ctx->i8_0 = LLVMConstInt(ctx->i8, 0, false);
> >> + ctx->i8_1 = LLVMConstInt(ctx->i8, 1, false);
> >> ctx->i16_0 = LLVMConstInt(ctx->i16, 0, false);
> >> ctx->i16_1 = LLVMConstInt(ctx->i16, 1, false);
> >> ctx->i32_0 = LLVMConstInt(ctx->i32, 0, false);
> >> ctx->i32_1 = LLVMConstInt(ctx->i32, 1, false);
> >> ctx->i64_0 = LLVMConstInt(ctx->i64, 0, false);
> >> ctx->i64_1 = LLVMConstInt(ctx->i64, 1, false);
> >> + ctx->f16_0 = LLVMConstReal(ctx->f16, 0.0);
> >> + ctx->f16_1 = LLVMConstReal(ctx->f16, 1.0);
> >> ctx->f32_0 = LLVMConstReal(ctx->f32, 0.0);
> >> ctx->f32_1 = LLVMConstReal(ctx->f32, 1.0);
> >> ctx->f64_0 = LLVMConstReal(ctx->f64, 0.0);
> >> @@ -201,7 +205,9 @@ ac_get_type_size(LLVMTypeRef type)
> >>
> >> static LLVMTypeRef to_integer_type_scalar(struct ac_llvm_context *ctx,
> LLVMTypeRef t)
> >> {
> >> - if (t == ctx->f16 || t == ctx->i16)
> >> + if (t == ctx->i8)
> >> + return ctx->i8;
> >> + else if (t == ctx->f16 || t == ctx->i16)
> >> return ctx->i16;
> >> else if (t == ctx->f32 || t == ctx->i32)
> >> return ctx->i32;
> >> @@ -268,6 +274,110 @@ ac_to_float(struct ac_llvm_context *ctx,
> LLVMValueRef v)
> >> return LLVMBuildBitCast(ctx->builder, v, ac_to_float_type(ctx,
> type), "");
> >> }
> >>
> >> +LLVMValueRef ac_get_zerof(struct ac_llvm_context *ctx, LLVMTypeRef t)
> >> +{
> >> + if (t == ctx->f16)
> >> + return ctx->f16_0;
> >> + else if (t == ctx->f32)
> >> + return ctx->f32_0;
> >> + else if (t == ctx->f64)
> >> + return ctx->f64_0;
> >> + else
> >> + unreachable("Unhandled float size");
> >> +}
> >> +
> >> +LLVMValueRef ac_get_onef(struct ac_llvm_context *ctx, LLVMTypeRef t)
> >> +{
> >> + if (t == ctx->f16)
> >> + return ctx->f16_1;
> >> + else if (t == ctx->f32)
> >> + return ctx->f32_1;
> >> + else if (t == ctx->f64)
> >> + return ctx->f64_1;
> >> + else
> >> + unreachable("Unhandled float size");
> >> +}
> >> +
> >> +LLVMValueRef ac_get_zero(struct ac_llvm_context *ctx, LLVMTypeRef t)
> >> +{
> >> + if (t == ctx->i8)
> >> + return ctx->i8_0;
> >> + else if (t == ctx->i16)
> >> + return ctx->i16_0;
> >> + else if (t == ctx->i32)
> >> + return ctx->i32_0;
> >> + else if (t == ctx->i64)
> >> + return ctx->i64_0;
> >> + else
> >> + unreachable("Unhandled bit size");
> >> +}
> >> +
> >> +LLVMValueRef ac_get_one(struct ac_llvm_context *ctx, LLVMTypeRef t)
> >> +{
> >> + if (t == ctx->i8)
> >> + return ctx->i8_1;
> >> + else if (t == ctx->i16)
> >> + return ctx->i16_1;
> >> + else if (t == ctx->i32)
> >> + return ctx->i32_1;
> >> + else if (t == ctx->i64)
> >> + return ctx->i64_1;
> >> + else
> >> + unreachable("Unhandled bit size");
> >> +}
> >
> >
> > You don't need these helpers. You can just use LLVMConstInt and
> LLVMConstReal.
> >
> >>
> >> +
> >> +LLVMTypeRef ac_float_of_size(struct ac_llvm_context *ctx, unsigned
> bit_size)
> >> +{
> >> + switch (bit_size) {
> >> + case 16:
> >> + return ctx->f16;
> >> + case 32:
> >> + return ctx->f32;
> >> + case 64:
> >> + return ctx->f64;
> >> + default:
> >> +
Re: [Mesa-dev] nir/algebraic: Generalize an optimization - RADV / DXVK 0.93+0.94 regression with LS2019
Replying myself: FIXED with Ian's nir/algebraic: Don't put quotes around floating point literals commit #96c4b135e34d0804e41bfbc28fc1b5050c49d71e Thanks! Dieter Am 19.12.2018 06:36, schrieb Dieter Nützel: Sorry guys, but my son got a RADV + DXVK 0.93 and 0.94 (D3D11) regression running brand new LS2019 (https://www.farming-simulator.com/?lang=en=us) on our Polaris 20. All heaven textures are gone and some others are wrong. git bisect bad 445867c80d git bisect good e4f9a37ace /opt/mesa> git bisect good 615cc26b97ad520b90a8d3b3f9bdaa49c78dfda5 is the first bad commit commit 615cc26b97ad520b90a8d3b3f9bdaa49c78dfda5 Author: Jason Ekstrand Date: Thu Dec 6 12:56:33 2018 -0600 nir/algebraic: Generalize an optimization This just makes it nicely scale across bit sizes. Reviewed-by: Eric Anholt Reviewed-by: Bas Nieuwenhuizen Tested-by: Bas Nieuwenhuizen :04 04 ced4299ecdd6d76755839c9a0af11417e5f4973a 321e0c0e1c985c49c4e0b37f766c4a68c4ca145f M src But git revert 615cc26b97 alone do NOT help. Have to file a ticket after some sleep...;-) Greetings, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
Gert/Ilia, Could this be reduced this from an error to a warning, with the command-line option suppressing the warning? Perhaps as well as producing the warning, the build could sleep for say 30 seconds after producing the warning message. This would be noticeable if you're building it yourself (which would definitely get the message out there), but wouldn't stop automated build processes (as it's not stopping, just sleeping). At a later date (when meson has more exposure) then perhaps we could move from a warning to an error. Thoughts? On Thu, 20 Dec 2018 at 07:37, Gert Wollny wrote: > Am Mittwoch, den 19.12.2018, 12:19 -0500 schrieb Ilia Mirkin: > > On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny > > wrote: > > > > > > Since Meson will eventually be the only build system deprecate > > > autotools > > > now. It can still be used by invoking configure with the flag > > > --enable-autotools > > > > > > Signed-off-by: Gert Wollny > > > > In case it's not clear from the later discussion: > > > > Strongly NAKed-by: Ilia Mirkin > > This should not be applied to the repository. > > You should probably add this to the patch proposals that want to remove > autotools then. > > I'm certainly not going to push this patch with your NAK, but I'd like > to ask you to reconsider: All this patch does is require to add -- > enable-autotools to the configure call once - a little hickup in the > workflow of those who do not yet use exclusively meson, but it gets the > message out to the others that things are going to change. > > Best, > Gert > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109107] gallium/st/va: change va max_profiles when using Radeon VCN Hardware
https://bugs.freedesktop.org/show_bug.cgi?id=109107 zhoulei changed: What|Removed |Added Version|unspecified |git -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109107] gallium/st/va: change va max_profiles when using Radeon VCN Hardware
https://bugs.freedesktop.org/show_bug.cgi?id=109107 Bug ID: 109107 Summary: gallium/st/va: change va max_profiles when using Radeon VCN Hardware Product: Mesa Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: mfk...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Now va_profiles is assignd to PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH - PIPE_VIDEO_PROFILE_UNKNOWN, but it supports more profiles when using AMD VCN hardware like RAVEN APU. chromium-vaapi's hardware decoder is broken caused by profile number checking. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] radv/query: Use 1-bit booleans in query shaders
Reviewed-by: Bas Nieuwenhuizen
On Wed, Dec 19, 2018 at 11:05 PM Jason Ekstrand wrote:
>
> Fixes: 44227453ec03f "nir: Switch to using 1-bit Booleans for almost..."
> Reviewed-by: Rhys Perry
> ---
> src/amd/vulkan/radv_query.c | 42 ++---
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 6e88de691d6..89e70224630 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -54,7 +54,7 @@ static unsigned get_max_db(struct radv_device *device)
>
> static nir_ssa_def *nir_flag_set(nir_builder *b, nir_ssa_def *flags,
> uint32_t flag)
> {
> - return nir_iand(b, flags, nir_imm_int(b, flag));
> + return nir_i2b(b, nir_iand(b, flags, nir_imm_int(b, flag)));
> }
>
> static void radv_break_on_count(nir_builder *b, nir_variable *var,
> nir_ssa_def *count)
> @@ -138,7 +138,7 @@ build_occlusion_query_shader(struct radv_device *device) {
> nir_variable *outer_counter = nir_local_variable_create(b.impl,
> glsl_int_type(), "outer_counter");
> nir_variable *start = nir_local_variable_create(b.impl,
> glsl_uint64_t_type(), "start");
> nir_variable *end = nir_local_variable_create(b.impl,
> glsl_uint64_t_type(), "end");
> - nir_variable *available = nir_local_variable_create(b.impl,
> glsl_int_type(), "available");
> + nir_variable *available = nir_local_variable_create(b.impl,
> glsl_bool_type(), "available");
> unsigned db_count = get_max_db(device);
>
> nir_ssa_def *flags = radv_load_push_int(, 0, "flags");
> @@ -176,7 +176,7 @@ build_occlusion_query_shader(struct radv_device *device) {
>
> nir_store_var(, result, nir_imm_int64(, 0), 0x1);
> nir_store_var(, outer_counter, nir_imm_int(, 0), 0x1);
> - nir_store_var(, available, nir_imm_int(, 1), 0x1);
> + nir_store_var(, available, nir_imm_true(), 0x1);
>
> nir_loop *outer_loop = nir_loop_create(b.shader);
> nir_builder_cf_insert(, _loop->cf_node);
> @@ -214,14 +214,14 @@ build_occlusion_query_shader(struct radv_device
> *device) {
>
> b.cursor = nir_after_cf_list(_if->else_list);
>
> - nir_store_var(, available, nir_imm_int(, 0), 0x1);
> + nir_store_var(, available, nir_imm_false(), 0x1);
>
> b.cursor = nir_after_cf_node(_loop->cf_node);
>
> /* Store the result if complete or if partial results have been
> requested. */
>
> nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
> VK_QUERY_RESULT_64_BIT);
> - nir_ssa_def *result_size = nir_b32csel(, result_is_64bit,
> nir_imm_int(, 8), nir_imm_int(, 4));
> + nir_ssa_def *result_size = nir_bcsel(, result_is_64bit,
> nir_imm_int(, 8), nir_imm_int(, 4));
>
> nir_if *store_if = nir_if_create(b.shader);
> store_if->condition = nir_src_for_ssa(nir_ior(, nir_flag_set(,
> flags, VK_QUERY_RESULT_PARTIAL_BIT), nir_load_var(, available)));
> @@ -264,7 +264,7 @@ build_occlusion_query_shader(struct radv_device *device) {
> b.cursor = nir_after_cf_list(_if->then_list);
>
> store = nir_intrinsic_instr_create(b.shader,
> nir_intrinsic_store_ssbo);
> - store->src[0] = nir_src_for_ssa(nir_load_var(, available));
> + store->src[0] = nir_src_for_ssa(nir_b2i32(, nir_load_var(,
> available)));
> store->src[1] = nir_src_for_ssa(_buf->dest.ssa);
> store->src[2] = nir_src_for_ssa(nir_iadd(, result_size,
> output_base));
> nir_intrinsic_set_write_mask(store, 0x1);
> @@ -296,11 +296,11 @@ build_pipeline_statistics_query_shader(struct
> radv_device *device) {
> * uint64_t dst_offset = dst_base;
> * uint32_t elem_size = flags & VK_QUERY_RESULT_64_BIT ? 8 : 4;
> * uint32_t elem_count = stats_mask >> 16;
> -* uint32_t available = src_buf[avail_offset + 4 * global_id.x];
> +* uint32_t available32 = src_buf[avail_offset + 4 *
> global_id.x];
> * if (flags & VK_QUERY_RESULT_WITH_AVAILABILITY_BIT) {
> -* dst_buf[dst_offset + elem_count * elem_size] =
> available;
> +* dst_buf[dst_offset + elem_count * elem_size] =
> available32;
> * }
> -* if (available) {
> +* if ((bool)available32) {
> * // repeat 11 times:
> * if (stats_mask & (1 << 0)) {
> * uint64_t start = src_buf[src_offset + 8 *
> indices[0]];
> @@ -372,10 +372,10 @@ build_pipeline_statistics_query_shader(struct
> radv_device *device) {
> nir_ssa_dest_init(>instr, >dest, 1, 32, NULL);
> load->num_components = 1;
> nir_builder_instr_insert(, >instr);
> - nir_ssa_def *available = >dest.ssa;
> + nir_ssa_def *available32 = >dest.ssa;
>
> nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
> VK_QUERY_RESULT_64_BIT);
> -
Re: [Mesa-dev] [PATCH 1/2] radv/query: Add a nir_flag_set helper
On Wed, Dec 19, 2018 at 4:06 PM Bas Nieuwenhuizen
wrote:
> On Wed, Dec 19, 2018 at 8:45 PM Jason Ekstrand
> wrote:
> >
> > This is little more than an iadd_imm right now but it will help in the
> > next commit where we refactor things further.
> > ---
> > src/amd/vulkan/radv_query.c | 31 ---
> > 1 file changed, 16 insertions(+), 15 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> > index 9797d156c88..6e88de691d6 100644
> > --- a/src/amd/vulkan/radv_query.c
> > +++ b/src/amd/vulkan/radv_query.c
> > @@ -51,6 +51,12 @@ static unsigned get_max_db(struct radv_device *device)
> > return num_db;
> > }
> >
> > +
> > +static nir_ssa_def *nir_flag_set(nir_builder *b, nir_ssa_def *flags,
> uint32_t flag)
>
> Can I ask you to rename this to something like nir_test_flag?
> nir_flag_set would first make me think of the verb in imperative,
> which would result in an or instead of an and.
>
Sure. Happy to do so.
> Otherwise
>
> Reviewed-by: Bas Nieuwenhuizen
>
Did you also test it? Because I didn't. :-)
--Jason
> > +{
> > + return nir_iand(b, flags, nir_imm_int(b, flag));
> > +}
> > +
> > static void radv_break_on_count(nir_builder *b, nir_variable *var,
> nir_ssa_def *count)
> > {
> > nir_ssa_def *counter = nir_load_var(b, var);
> > @@ -214,12 +220,11 @@ build_occlusion_query_shader(struct radv_device
> *device) {
> >
> > /* Store the result if complete or if partial results have been
> requested. */
> >
> > - nir_ssa_def *result_is_64bit = nir_iand(, flags,
> > - nir_imm_int(,
> VK_QUERY_RESULT_64_BIT));
> > + nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
> VK_QUERY_RESULT_64_BIT);
> > nir_ssa_def *result_size = nir_b32csel(, result_is_64bit,
> nir_imm_int(, 8), nir_imm_int(, 4));
> >
> > nir_if *store_if = nir_if_create(b.shader);
> > - store_if->condition = nir_src_for_ssa(nir_ior(, nir_iand(,
> flags, nir_imm_int(, VK_QUERY_RESULT_PARTIAL_BIT)), nir_load_var(,
> available)));
> > + store_if->condition = nir_src_for_ssa(nir_ior(,
> nir_flag_set(, flags, VK_QUERY_RESULT_PARTIAL_BIT), nir_load_var(,
> available)));
> > nir_cf_node_insert(b.cursor, _if->cf_node);
> >
> > b.cursor = nir_after_cf_list(_if->then_list);
> > @@ -253,7 +258,7 @@ build_occlusion_query_shader(struct radv_device
> *device) {
> > /* Store the availability bit if requested. */
> >
> > nir_if *availability_if = nir_if_create(b.shader);
> > - availability_if->condition = nir_src_for_ssa(nir_iand(, flags,
> nir_imm_int(, VK_QUERY_RESULT_WITH_AVAILABILITY_BIT)));
> > + availability_if->condition = nir_src_for_ssa(nir_flag_set(,
> flags, VK_QUERY_RESULT_WITH_AVAILABILITY_BIT));
> > nir_cf_node_insert(b.cursor, _if->cf_node);
> >
> > b.cursor = nir_after_cf_list(_if->then_list);
> > @@ -369,15 +374,14 @@ build_pipeline_statistics_query_shader(struct
> radv_device *device) {
> > nir_builder_instr_insert(, >instr);
> > nir_ssa_def *available = >dest.ssa;
> >
> > - nir_ssa_def *result_is_64bit = nir_iand(, flags,
> > - nir_imm_int(,
> VK_QUERY_RESULT_64_BIT));
> > + nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
> VK_QUERY_RESULT_64_BIT);
> > nir_ssa_def *elem_size = nir_b32csel(, result_is_64bit,
> nir_imm_int(, 8), nir_imm_int(, 4));
> > nir_ssa_def *elem_count = nir_ushr(, stats_mask,
> nir_imm_int(, 16));
> >
> > /* Store the availability bit if requested. */
> >
> > nir_if *availability_if = nir_if_create(b.shader);
> > - availability_if->condition = nir_src_for_ssa(nir_iand(, flags,
> nir_imm_int(, VK_QUERY_RESULT_WITH_AVAILABILITY_BIT)));
> > + availability_if->condition = nir_src_for_ssa(nir_flag_set(,
> flags, VK_QUERY_RESULT_WITH_AVAILABILITY_BIT));
> > nir_cf_node_insert(b.cursor, _if->cf_node);
> >
> > b.cursor = nir_after_cf_list(_if->then_list);
> > @@ -401,7 +405,7 @@ build_pipeline_statistics_query_shader(struct
> radv_device *device) {
> > nir_store_var(, output_offset, output_base, 0x1);
> > for (int i = 0; i < 11; ++i) {
> > nir_if *store_if = nir_if_create(b.shader);
> > - store_if->condition = nir_src_for_ssa(nir_iand(,
> stats_mask, nir_imm_int(, 1u << i)));
> > + store_if->condition = nir_src_for_ssa(nir_flag_set(,
> stats_mask, 1u << i));
> > nir_cf_node_insert(b.cursor, _if->cf_node);
> >
> > b.cursor = nir_after_cf_list(_if->then_list);
> > @@ -463,8 +467,7 @@ build_pipeline_statistics_query_shader(struct
> radv_device *device) {
> > b.cursor = nir_after_cf_list(_if->else_list);
> >
> > available_if = nir_if_create(b.shader);
> > - available_if->condition = nir_src_for_ssa(nir_iand(, flags,
> > -
> nir_imm_int(,
Re: [Mesa-dev] [PATCH 1/2] radv/query: Add a nir_flag_set helper
On Wed, Dec 19, 2018 at 8:45 PM Jason Ekstrand wrote:
>
> This is little more than an iadd_imm right now but it will help in the
> next commit where we refactor things further.
> ---
> src/amd/vulkan/radv_query.c | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 9797d156c88..6e88de691d6 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -51,6 +51,12 @@ static unsigned get_max_db(struct radv_device *device)
> return num_db;
> }
>
> +
> +static nir_ssa_def *nir_flag_set(nir_builder *b, nir_ssa_def *flags,
> uint32_t flag)
Can I ask you to rename this to something like nir_test_flag?
nir_flag_set would first make me think of the verb in imperative,
which would result in an or instead of an and.
Otherwise
Reviewed-by: Bas Nieuwenhuizen
> +{
> + return nir_iand(b, flags, nir_imm_int(b, flag));
> +}
> +
> static void radv_break_on_count(nir_builder *b, nir_variable *var,
> nir_ssa_def *count)
> {
> nir_ssa_def *counter = nir_load_var(b, var);
> @@ -214,12 +220,11 @@ build_occlusion_query_shader(struct radv_device
> *device) {
>
> /* Store the result if complete or if partial results have been
> requested. */
>
> - nir_ssa_def *result_is_64bit = nir_iand(, flags,
> - nir_imm_int(,
> VK_QUERY_RESULT_64_BIT));
> + nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
> VK_QUERY_RESULT_64_BIT);
> nir_ssa_def *result_size = nir_b32csel(, result_is_64bit,
> nir_imm_int(, 8), nir_imm_int(, 4));
>
> nir_if *store_if = nir_if_create(b.shader);
> - store_if->condition = nir_src_for_ssa(nir_ior(, nir_iand(, flags,
> nir_imm_int(, VK_QUERY_RESULT_PARTIAL_BIT)), nir_load_var(, available)));
> + store_if->condition = nir_src_for_ssa(nir_ior(, nir_flag_set(,
> flags, VK_QUERY_RESULT_PARTIAL_BIT), nir_load_var(, available)));
> nir_cf_node_insert(b.cursor, _if->cf_node);
>
> b.cursor = nir_after_cf_list(_if->then_list);
> @@ -253,7 +258,7 @@ build_occlusion_query_shader(struct radv_device *device) {
> /* Store the availability bit if requested. */
>
> nir_if *availability_if = nir_if_create(b.shader);
> - availability_if->condition = nir_src_for_ssa(nir_iand(, flags,
> nir_imm_int(, VK_QUERY_RESULT_WITH_AVAILABILITY_BIT)));
> + availability_if->condition = nir_src_for_ssa(nir_flag_set(, flags,
> VK_QUERY_RESULT_WITH_AVAILABILITY_BIT));
> nir_cf_node_insert(b.cursor, _if->cf_node);
>
> b.cursor = nir_after_cf_list(_if->then_list);
> @@ -369,15 +374,14 @@ build_pipeline_statistics_query_shader(struct
> radv_device *device) {
> nir_builder_instr_insert(, >instr);
> nir_ssa_def *available = >dest.ssa;
>
> - nir_ssa_def *result_is_64bit = nir_iand(, flags,
> - nir_imm_int(,
> VK_QUERY_RESULT_64_BIT));
> + nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
> VK_QUERY_RESULT_64_BIT);
> nir_ssa_def *elem_size = nir_b32csel(, result_is_64bit,
> nir_imm_int(, 8), nir_imm_int(, 4));
> nir_ssa_def *elem_count = nir_ushr(, stats_mask, nir_imm_int(,
> 16));
>
> /* Store the availability bit if requested. */
>
> nir_if *availability_if = nir_if_create(b.shader);
> - availability_if->condition = nir_src_for_ssa(nir_iand(, flags,
> nir_imm_int(, VK_QUERY_RESULT_WITH_AVAILABILITY_BIT)));
> + availability_if->condition = nir_src_for_ssa(nir_flag_set(, flags,
> VK_QUERY_RESULT_WITH_AVAILABILITY_BIT));
> nir_cf_node_insert(b.cursor, _if->cf_node);
>
> b.cursor = nir_after_cf_list(_if->then_list);
> @@ -401,7 +405,7 @@ build_pipeline_statistics_query_shader(struct radv_device
> *device) {
> nir_store_var(, output_offset, output_base, 0x1);
> for (int i = 0; i < 11; ++i) {
> nir_if *store_if = nir_if_create(b.shader);
> - store_if->condition = nir_src_for_ssa(nir_iand(,
> stats_mask, nir_imm_int(, 1u << i)));
> + store_if->condition = nir_src_for_ssa(nir_flag_set(,
> stats_mask, 1u << i));
> nir_cf_node_insert(b.cursor, _if->cf_node);
>
> b.cursor = nir_after_cf_list(_if->then_list);
> @@ -463,8 +467,7 @@ build_pipeline_statistics_query_shader(struct radv_device
> *device) {
> b.cursor = nir_after_cf_list(_if->else_list);
>
> available_if = nir_if_create(b.shader);
> - available_if->condition = nir_src_for_ssa(nir_iand(, flags,
> -
> nir_imm_int(, VK_QUERY_RESULT_PARTIAL_BIT)));
> + available_if->condition = nir_src_for_ssa(nir_flag_set(, flags,
> VK_QUERY_RESULT_PARTIAL_BIT));
> nir_cf_node_insert(b.cursor, _if->cf_node);
>
> b.cursor =
[Mesa-dev] [PATCH v2 2/2] radv/query: Use 1-bit booleans in query shaders
Fixes: 44227453ec03f "nir: Switch to using 1-bit Booleans for almost..."
Reviewed-by: Rhys Perry
---
src/amd/vulkan/radv_query.c | 42 ++---
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 6e88de691d6..89e70224630 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -54,7 +54,7 @@ static unsigned get_max_db(struct radv_device *device)
static nir_ssa_def *nir_flag_set(nir_builder *b, nir_ssa_def *flags, uint32_t
flag)
{
- return nir_iand(b, flags, nir_imm_int(b, flag));
+ return nir_i2b(b, nir_iand(b, flags, nir_imm_int(b, flag)));
}
static void radv_break_on_count(nir_builder *b, nir_variable *var, nir_ssa_def
*count)
@@ -138,7 +138,7 @@ build_occlusion_query_shader(struct radv_device *device) {
nir_variable *outer_counter = nir_local_variable_create(b.impl,
glsl_int_type(), "outer_counter");
nir_variable *start = nir_local_variable_create(b.impl,
glsl_uint64_t_type(), "start");
nir_variable *end = nir_local_variable_create(b.impl,
glsl_uint64_t_type(), "end");
- nir_variable *available = nir_local_variable_create(b.impl,
glsl_int_type(), "available");
+ nir_variable *available = nir_local_variable_create(b.impl,
glsl_bool_type(), "available");
unsigned db_count = get_max_db(device);
nir_ssa_def *flags = radv_load_push_int(, 0, "flags");
@@ -176,7 +176,7 @@ build_occlusion_query_shader(struct radv_device *device) {
nir_store_var(, result, nir_imm_int64(, 0), 0x1);
nir_store_var(, outer_counter, nir_imm_int(, 0), 0x1);
- nir_store_var(, available, nir_imm_int(, 1), 0x1);
+ nir_store_var(, available, nir_imm_true(), 0x1);
nir_loop *outer_loop = nir_loop_create(b.shader);
nir_builder_cf_insert(, _loop->cf_node);
@@ -214,14 +214,14 @@ build_occlusion_query_shader(struct radv_device *device) {
b.cursor = nir_after_cf_list(_if->else_list);
- nir_store_var(, available, nir_imm_int(, 0), 0x1);
+ nir_store_var(, available, nir_imm_false(), 0x1);
b.cursor = nir_after_cf_node(_loop->cf_node);
/* Store the result if complete or if partial results have been
requested. */
nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
VK_QUERY_RESULT_64_BIT);
- nir_ssa_def *result_size = nir_b32csel(, result_is_64bit,
nir_imm_int(, 8), nir_imm_int(, 4));
+ nir_ssa_def *result_size = nir_bcsel(, result_is_64bit,
nir_imm_int(, 8), nir_imm_int(, 4));
nir_if *store_if = nir_if_create(b.shader);
store_if->condition = nir_src_for_ssa(nir_ior(, nir_flag_set(,
flags, VK_QUERY_RESULT_PARTIAL_BIT), nir_load_var(, available)));
@@ -264,7 +264,7 @@ build_occlusion_query_shader(struct radv_device *device) {
b.cursor = nir_after_cf_list(_if->then_list);
store = nir_intrinsic_instr_create(b.shader, nir_intrinsic_store_ssbo);
- store->src[0] = nir_src_for_ssa(nir_load_var(, available));
+ store->src[0] = nir_src_for_ssa(nir_b2i32(, nir_load_var(,
available)));
store->src[1] = nir_src_for_ssa(_buf->dest.ssa);
store->src[2] = nir_src_for_ssa(nir_iadd(, result_size, output_base));
nir_intrinsic_set_write_mask(store, 0x1);
@@ -296,11 +296,11 @@ build_pipeline_statistics_query_shader(struct radv_device
*device) {
* uint64_t dst_offset = dst_base;
* uint32_t elem_size = flags & VK_QUERY_RESULT_64_BIT ? 8 : 4;
* uint32_t elem_count = stats_mask >> 16;
-* uint32_t available = src_buf[avail_offset + 4 * global_id.x];
+* uint32_t available32 = src_buf[avail_offset + 4 * global_id.x];
* if (flags & VK_QUERY_RESULT_WITH_AVAILABILITY_BIT) {
-* dst_buf[dst_offset + elem_count * elem_size] =
available;
+* dst_buf[dst_offset + elem_count * elem_size] =
available32;
* }
-* if (available) {
+* if ((bool)available32) {
* // repeat 11 times:
* if (stats_mask & (1 << 0)) {
* uint64_t start = src_buf[src_offset + 8 *
indices[0]];
@@ -372,10 +372,10 @@ build_pipeline_statistics_query_shader(struct radv_device
*device) {
nir_ssa_dest_init(>instr, >dest, 1, 32, NULL);
load->num_components = 1;
nir_builder_instr_insert(, >instr);
- nir_ssa_def *available = >dest.ssa;
+ nir_ssa_def *available32 = >dest.ssa;
nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
VK_QUERY_RESULT_64_BIT);
- nir_ssa_def *elem_size = nir_b32csel(, result_is_64bit,
nir_imm_int(, 8), nir_imm_int(, 4));
+ nir_ssa_def *elem_size = nir_bcsel(, result_is_64bit, nir_imm_int(,
8), nir_imm_int(, 4));
nir_ssa_def *elem_count = nir_ushr(, stats_mask, nir_imm_int(, 16));
/* Store the
Re: [Mesa-dev] [PATCH 01/38] ac: add various helpers for float16/int16/int8
I would expect these helpers to be much more efficient than the
functions you suggested. They are also (in my opinion) more readable
than the suggested functions.
I don't think it matters much though, so I'm fine either way.
On Tue, 18 Dec 2018 at 02:48, Marek Olšák wrote:
>
> On Fri, Dec 7, 2018 at 12:22 PM Rhys Perry wrote:
>>
>> Signed-off-by: Rhys Perry
>> ---
>> src/amd/common/ac_llvm_build.c | 123 ++--
>> src/amd/common/ac_llvm_build.h | 22 +-
>> src/amd/common/ac_nir_to_llvm.c | 30
>> 3 files changed, 154 insertions(+), 21 deletions(-)
>>
>> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
>> index 154cc696a2..cc7c6da5a4 100644
>> --- a/src/amd/common/ac_llvm_build.c
>> +++ b/src/amd/common/ac_llvm_build.c
>> @@ -87,12 +87,16 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
>> ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
>> ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
>>
>> + ctx->i8_0 = LLVMConstInt(ctx->i8, 0, false);
>> + ctx->i8_1 = LLVMConstInt(ctx->i8, 1, false);
>> ctx->i16_0 = LLVMConstInt(ctx->i16, 0, false);
>> ctx->i16_1 = LLVMConstInt(ctx->i16, 1, false);
>> ctx->i32_0 = LLVMConstInt(ctx->i32, 0, false);
>> ctx->i32_1 = LLVMConstInt(ctx->i32, 1, false);
>> ctx->i64_0 = LLVMConstInt(ctx->i64, 0, false);
>> ctx->i64_1 = LLVMConstInt(ctx->i64, 1, false);
>> + ctx->f16_0 = LLVMConstReal(ctx->f16, 0.0);
>> + ctx->f16_1 = LLVMConstReal(ctx->f16, 1.0);
>> ctx->f32_0 = LLVMConstReal(ctx->f32, 0.0);
>> ctx->f32_1 = LLVMConstReal(ctx->f32, 1.0);
>> ctx->f64_0 = LLVMConstReal(ctx->f64, 0.0);
>> @@ -201,7 +205,9 @@ ac_get_type_size(LLVMTypeRef type)
>>
>> static LLVMTypeRef to_integer_type_scalar(struct ac_llvm_context *ctx,
>> LLVMTypeRef t)
>> {
>> - if (t == ctx->f16 || t == ctx->i16)
>> + if (t == ctx->i8)
>> + return ctx->i8;
>> + else if (t == ctx->f16 || t == ctx->i16)
>> return ctx->i16;
>> else if (t == ctx->f32 || t == ctx->i32)
>> return ctx->i32;
>> @@ -268,6 +274,110 @@ ac_to_float(struct ac_llvm_context *ctx, LLVMValueRef
>> v)
>> return LLVMBuildBitCast(ctx->builder, v, ac_to_float_type(ctx,
>> type), "");
>> }
>>
>> +LLVMValueRef ac_get_zerof(struct ac_llvm_context *ctx, LLVMTypeRef t)
>> +{
>> + if (t == ctx->f16)
>> + return ctx->f16_0;
>> + else if (t == ctx->f32)
>> + return ctx->f32_0;
>> + else if (t == ctx->f64)
>> + return ctx->f64_0;
>> + else
>> + unreachable("Unhandled float size");
>> +}
>> +
>> +LLVMValueRef ac_get_onef(struct ac_llvm_context *ctx, LLVMTypeRef t)
>> +{
>> + if (t == ctx->f16)
>> + return ctx->f16_1;
>> + else if (t == ctx->f32)
>> + return ctx->f32_1;
>> + else if (t == ctx->f64)
>> + return ctx->f64_1;
>> + else
>> + unreachable("Unhandled float size");
>> +}
>> +
>> +LLVMValueRef ac_get_zero(struct ac_llvm_context *ctx, LLVMTypeRef t)
>> +{
>> + if (t == ctx->i8)
>> + return ctx->i8_0;
>> + else if (t == ctx->i16)
>> + return ctx->i16_0;
>> + else if (t == ctx->i32)
>> + return ctx->i32_0;
>> + else if (t == ctx->i64)
>> + return ctx->i64_0;
>> + else
>> + unreachable("Unhandled bit size");
>> +}
>> +
>> +LLVMValueRef ac_get_one(struct ac_llvm_context *ctx, LLVMTypeRef t)
>> +{
>> + if (t == ctx->i8)
>> + return ctx->i8_1;
>> + else if (t == ctx->i16)
>> + return ctx->i16_1;
>> + else if (t == ctx->i32)
>> + return ctx->i32_1;
>> + else if (t == ctx->i64)
>> + return ctx->i64_1;
>> + else
>> + unreachable("Unhandled bit size");
>> +}
>
>
> You don't need these helpers. You can just use LLVMConstInt and LLVMConstReal.
>
>>
>> +
>> +LLVMTypeRef ac_float_of_size(struct ac_llvm_context *ctx, unsigned bit_size)
>> +{
>> + switch (bit_size) {
>> + case 16:
>> + return ctx->f16;
>> + case 32:
>> + return ctx->f32;
>> + case 64:
>> + return ctx->f64;
>> + default:
>> + unreachable("Unhandled bit size");
>> + }
>> +}
>> +
>> +LLVMTypeRef ac_int_of_size(struct ac_llvm_context *ctx, unsigned bit_size)
>> +{
>> + switch (bit_size) {
>> + case 8:
>> + return ctx->i8;
>> + case 16:
>> + return ctx->i16;
>> + case 32:
>> + return ctx->i32;
>> + case 64:
>> + return ctx->i64;
>> + default:
>> + unreachable("Unhandled bit size");
>> + }
>> +}
>
>
> This is the same as LLVMIntTypeInContext.
>
> Marek
>
Re: [Mesa-dev] [PATCH 0/2] radv/query: Use 1-bit booleans in query shaders
You missed this change (or something functionally similar): diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c index e7bb81489f6..5d35af05579 100644 --- a/src/amd/vulkan/radv_query.c +++ b/src/amd/vulkan/radv_query.c @@ -630,8 +630,8 @@ build_tfb_query_shader(struct radv_device *device) avails[1] = nir_iand(, nir_channel(, >dest.ssa, 1), nir_channel(, >dest.ssa, 3)); nir_ssa_def *result_is_available = - nir_iand(, nir_iand(, avails[0], avails[1]), -nir_imm_int(, 0x8000)); + nir_i2b(, nir_iand(, nir_iand(, avails[0], avails[1]), +nir_imm_int(, 0x8000))); /* Only compute result if available. */ nir_if *available_if = nir_if_create(b.shader); Other than that, this looks fine and seems to work correctly on my Vega. With that change (and for what it's worth), this is: Reviewed-by: Rhys Perry On Wed, 19 Dec 2018 at 19:45, Jason Ekstrand wrote: > > When we switched over to 1-bit booleans, the radv query shaders ended up > still using 32-bit booleans for most stuff. While this is technically > valid from an IR perspective, most of the NIR passes don't really support > 32-bit booleans correctly anymore now that we've moved to 1-bit. This tiny > series attempts to convert the radv query shaders over to using 1-bit > Booleans. > > I've only compile-tested it and read through it a couple times but am not > really set up for testing radv. I would very much appreciate if someone > more familiar with radv could review and test these patches (and possibly > rewrite them if appropriate). > > Cc: Dave Airlie > Cc: Timothy Arceri > Cc: Bas Nieuwenhuizen > > Jason Ekstrand (2): > radv/query: Add a nir_flag_set helper > radv/query: Use 1-bit booleans in query shaders > > src/amd/vulkan/radv_query.c | 67 +++-- > 1 file changed, 34 insertions(+), 33 deletions(-) > > -- > 2.19.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] docs/meson: Don't recommend CFLAGS and friends
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/33 signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/16] freedreno: a2xx: enable early-Z testing
On Wed, Dec 19, 2018, 3:32 PM Eric Anholt Jonathan marek writes: > > > Hi, > > > > I didn't verify it, but both r600 and a3xx disable earlyZ when alpha > > test is enabled, so this is almost certainly right. > > > > We don't need to worry about the shader writing Z, it is not part of > > OpenGL ES 2.0 and not implemented by the driver (although the hardware > > should allow it). > > > > Why should we need to check if the shader does discards? > > On a lot of hardware, early Z also does the depth write at that time. I > see a3xx disables EZ when discards are present. (There is a piglit test > for this) > Yes, kill/discard disables early Z/S. Marek ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] freedreno/ir3: Handle GL_NONE in get_num_components_for_glformat()
On 12/19/18 9:23 PM, Ilia Mirkin wrote:
> On Wed, Dec 19, 2018 at 3:18 AM Eduardo Lima Mitev wrote:
>>
>> An earlier patch that introduced the function failed to handle the case
>> where an image format layout qualifier is not specified, which is allowed
>> in Core profiles. In these cases, nir_variable's image format is
>> GL_NONE, and we don't need to print a debug message for those.
>> ---
>> src/freedreno/ir3/ir3_compiler_nir.c | 11 ---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/freedreno/ir3/ir3_compiler_nir.c
>> b/src/freedreno/ir3/ir3_compiler_nir.c
>> index 19aef3eb27e..4b309fb3c84 100644
>> --- a/src/freedreno/ir3/ir3_compiler_nir.c
>> +++ b/src/freedreno/ir3/ir3_compiler_nir.c
>> @@ -1306,11 +1306,16 @@ get_num_components_for_glformat(GLuint format)
>> case GL_RGB10_A2:
>> return 4;
>>
>> + case GL_NONE:
>> + /* Omitting the image format qualifier is allowed on GL
>> profiles.
>
> I realize you're trying to make the distinction against GL ES, but
> that may not be clear. You could say "... on desktop GL profiles", for
> example. Your call. Either way,
>
Yeah, I use GL vs. GLES profiles to make that distinction, but agree it
might not be clear outside my head, so I will clarify the comment before
pushing.
Thanks!
> Reviewed-by: Ilia Mirkin
>
>> +* Assuming 4 components is always safe.
>> +*/
>> + return 4;
>> +
>> default:
>> /* Return 4 components also for all other formats we don't
>> know
>> -* about. This is always safe. Also, the format should have
>> been
>> -* validated already by the higher level API. Drop a debug
>> message
>> -* just in case.
>> +* about. The format should have been validated already by
>> +* the higher level API, but drop a debug message just in
>> case.
>> */
>> debug_printf("Unhandled GL format %u while emitting
>> imageStore()\n",
>> format);
>> --
>> 2.19.2
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
Am Mittwoch, den 19.12.2018, 12:19 -0500 schrieb Ilia Mirkin: > On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny > wrote: > > > > Since Meson will eventually be the only build system deprecate > > autotools > > now. It can still be used by invoking configure with the flag > > --enable-autotools > > > > Signed-off-by: Gert Wollny > > In case it's not clear from the later discussion: > > Strongly NAKed-by: Ilia Mirkin > This should not be applied to the repository. You should probably add this to the patch proposals that want to remove autotools then. I'm certainly not going to push this patch with your NAK, but I'd like to ask you to reconsider: All this patch does is require to add -- enable-autotools to the configure call once - a little hickup in the workflow of those who do not yet use exclusively meson, but it gets the message out to the others that things are going to change. Best, Gert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/16] freedreno: a2xx: enable early-Z testing
Jonathan marek writes: > Hi, > > I didn't verify it, but both r600 and a3xx disable earlyZ when alpha > test is enabled, so this is almost certainly right. > > We don't need to worry about the shader writing Z, it is not part of > OpenGL ES 2.0 and not implemented by the driver (although the hardware > should allow it). > > Why should we need to check if the shader does discards? On a lot of hardware, early Z also does the depth write at that time. I see a3xx disables EZ when discards are present. (There is a piglit test for this) 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] freedreno/ir3: Handle GL_NONE in get_num_components_for_glformat()
On Wed, Dec 19, 2018 at 3:18 AM Eduardo Lima Mitev wrote:
>
> An earlier patch that introduced the function failed to handle the case
> where an image format layout qualifier is not specified, which is allowed
> in Core profiles. In these cases, nir_variable's image format is
> GL_NONE, and we don't need to print a debug message for those.
> ---
> src/freedreno/ir3/ir3_compiler_nir.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/src/freedreno/ir3/ir3_compiler_nir.c
> b/src/freedreno/ir3/ir3_compiler_nir.c
> index 19aef3eb27e..4b309fb3c84 100644
> --- a/src/freedreno/ir3/ir3_compiler_nir.c
> +++ b/src/freedreno/ir3/ir3_compiler_nir.c
> @@ -1306,11 +1306,16 @@ get_num_components_for_glformat(GLuint format)
> case GL_RGB10_A2:
> return 4;
>
> + case GL_NONE:
> + /* Omitting the image format qualifier is allowed on GL
> profiles.
I realize you're trying to make the distinction against GL ES, but
that may not be clear. You could say "... on desktop GL profiles", for
example. Your call. Either way,
Reviewed-by: Ilia Mirkin
> +* Assuming 4 components is always safe.
> +*/
> + return 4;
> +
> default:
> /* Return 4 components also for all other formats we don't
> know
> -* about. This is always safe. Also, the format should have
> been
> -* validated already by the higher level API. Drop a debug
> message
> -* just in case.
> +* about. The format should have been validated already by
> +* the higher level API, but drop a debug message just in
> case.
> */
> debug_printf("Unhandled GL format %u while emitting
> imageStore()\n",
> format);
> --
> 2.19.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/16] glsl/nir: int constants as float for native_integers=false
On Wed, Dec 19, 2018 at 12:22 PM Eric Anholt wrote: > Jonathan Marek writes: > > > Note: the backend must take care that uniform index is now a float > > This makes me think that lowering ints to float should be done near the > end of the compile (followed by maybe an algebraic and a dce). As is, I > think nir_lower_io() is going to do bad things to dereferences of i/o > arrays. > > That said, it looks like this will be fixing way more than it regresses, > so I would go along with it. > I used to agree but I'm actually inclined to go the other way. Because NIR is typeles, you have no idea in a lower pass whether a particular value is an int or a float. In particular, you have no idea for immediates. Of course, doing it this early would mean that we'd need a version of nir_lower_io that produces floats but that doesn't seem entirely unreasonable. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radv/query: Use 1-bit booleans in query shaders
Fixes: 44227453ec03f "nir: Switch to using 1-bit Booleans for almost..."
---
src/amd/vulkan/radv_query.c | 38 ++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 6e88de691d6..e7bb81489f6 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -54,7 +54,7 @@ static unsigned get_max_db(struct radv_device *device)
static nir_ssa_def *nir_flag_set(nir_builder *b, nir_ssa_def *flags, uint32_t
flag)
{
- return nir_iand(b, flags, nir_imm_int(b, flag));
+ return nir_i2b(b, nir_iand(b, flags, nir_imm_int(b, flag)));
}
static void radv_break_on_count(nir_builder *b, nir_variable *var, nir_ssa_def
*count)
@@ -138,7 +138,7 @@ build_occlusion_query_shader(struct radv_device *device) {
nir_variable *outer_counter = nir_local_variable_create(b.impl,
glsl_int_type(), "outer_counter");
nir_variable *start = nir_local_variable_create(b.impl,
glsl_uint64_t_type(), "start");
nir_variable *end = nir_local_variable_create(b.impl,
glsl_uint64_t_type(), "end");
- nir_variable *available = nir_local_variable_create(b.impl,
glsl_int_type(), "available");
+ nir_variable *available = nir_local_variable_create(b.impl,
glsl_bool_type(), "available");
unsigned db_count = get_max_db(device);
nir_ssa_def *flags = radv_load_push_int(, 0, "flags");
@@ -176,7 +176,7 @@ build_occlusion_query_shader(struct radv_device *device) {
nir_store_var(, result, nir_imm_int64(, 0), 0x1);
nir_store_var(, outer_counter, nir_imm_int(, 0), 0x1);
- nir_store_var(, available, nir_imm_int(, 1), 0x1);
+ nir_store_var(, available, nir_imm_true(), 0x1);
nir_loop *outer_loop = nir_loop_create(b.shader);
nir_builder_cf_insert(, _loop->cf_node);
@@ -214,14 +214,14 @@ build_occlusion_query_shader(struct radv_device *device) {
b.cursor = nir_after_cf_list(_if->else_list);
- nir_store_var(, available, nir_imm_int(, 0), 0x1);
+ nir_store_var(, available, nir_imm_false(), 0x1);
b.cursor = nir_after_cf_node(_loop->cf_node);
/* Store the result if complete or if partial results have been
requested. */
nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
VK_QUERY_RESULT_64_BIT);
- nir_ssa_def *result_size = nir_b32csel(, result_is_64bit,
nir_imm_int(, 8), nir_imm_int(, 4));
+ nir_ssa_def *result_size = nir_bcsel(, result_is_64bit,
nir_imm_int(, 8), nir_imm_int(, 4));
nir_if *store_if = nir_if_create(b.shader);
store_if->condition = nir_src_for_ssa(nir_ior(, nir_flag_set(,
flags, VK_QUERY_RESULT_PARTIAL_BIT), nir_load_var(, available)));
@@ -264,7 +264,7 @@ build_occlusion_query_shader(struct radv_device *device) {
b.cursor = nir_after_cf_list(_if->then_list);
store = nir_intrinsic_instr_create(b.shader, nir_intrinsic_store_ssbo);
- store->src[0] = nir_src_for_ssa(nir_load_var(, available));
+ store->src[0] = nir_src_for_ssa(nir_b2i32(, nir_load_var(,
available)));
store->src[1] = nir_src_for_ssa(_buf->dest.ssa);
store->src[2] = nir_src_for_ssa(nir_iadd(, result_size, output_base));
nir_intrinsic_set_write_mask(store, 0x1);
@@ -296,11 +296,11 @@ build_pipeline_statistics_query_shader(struct radv_device
*device) {
* uint64_t dst_offset = dst_base;
* uint32_t elem_size = flags & VK_QUERY_RESULT_64_BIT ? 8 : 4;
* uint32_t elem_count = stats_mask >> 16;
-* uint32_t available = src_buf[avail_offset + 4 * global_id.x];
+* uint32_t available32 = src_buf[avail_offset + 4 * global_id.x];
* if (flags & VK_QUERY_RESULT_WITH_AVAILABILITY_BIT) {
-* dst_buf[dst_offset + elem_count * elem_size] =
available;
+* dst_buf[dst_offset + elem_count * elem_size] =
available32;
* }
-* if (available) {
+* if ((bool)available32) {
* // repeat 11 times:
* if (stats_mask & (1 << 0)) {
* uint64_t start = src_buf[src_offset + 8 *
indices[0]];
@@ -372,10 +372,10 @@ build_pipeline_statistics_query_shader(struct radv_device
*device) {
nir_ssa_dest_init(>instr, >dest, 1, 32, NULL);
load->num_components = 1;
nir_builder_instr_insert(, >instr);
- nir_ssa_def *available = >dest.ssa;
+ nir_ssa_def *available32 = >dest.ssa;
nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
VK_QUERY_RESULT_64_BIT);
- nir_ssa_def *elem_size = nir_b32csel(, result_is_64bit,
nir_imm_int(, 8), nir_imm_int(, 4));
+ nir_ssa_def *elem_size = nir_bcsel(, result_is_64bit, nir_imm_int(,
8), nir_imm_int(, 4));
nir_ssa_def *elem_count = nir_ushr(, stats_mask, nir_imm_int(, 16));
/* Store the availability bit if
[Mesa-dev] [PATCH 0/2] radv/query: Use 1-bit booleans in query shaders
When we switched over to 1-bit booleans, the radv query shaders ended up still using 32-bit booleans for most stuff. While this is technically valid from an IR perspective, most of the NIR passes don't really support 32-bit booleans correctly anymore now that we've moved to 1-bit. This tiny series attempts to convert the radv query shaders over to using 1-bit Booleans. I've only compile-tested it and read through it a couple times but am not really set up for testing radv. I would very much appreciate if someone more familiar with radv could review and test these patches (and possibly rewrite them if appropriate). Cc: Dave Airlie Cc: Timothy Arceri Cc: Bas Nieuwenhuizen Jason Ekstrand (2): radv/query: Add a nir_flag_set helper radv/query: Use 1-bit booleans in query shaders src/amd/vulkan/radv_query.c | 67 +++-- 1 file changed, 34 insertions(+), 33 deletions(-) -- 2.19.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radv/query: Add a nir_flag_set helper
This is little more than an iadd_imm right now but it will help in the
next commit where we refactor things further.
---
src/amd/vulkan/radv_query.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 9797d156c88..6e88de691d6 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -51,6 +51,12 @@ static unsigned get_max_db(struct radv_device *device)
return num_db;
}
+
+static nir_ssa_def *nir_flag_set(nir_builder *b, nir_ssa_def *flags, uint32_t
flag)
+{
+ return nir_iand(b, flags, nir_imm_int(b, flag));
+}
+
static void radv_break_on_count(nir_builder *b, nir_variable *var, nir_ssa_def
*count)
{
nir_ssa_def *counter = nir_load_var(b, var);
@@ -214,12 +220,11 @@ build_occlusion_query_shader(struct radv_device *device) {
/* Store the result if complete or if partial results have been
requested. */
- nir_ssa_def *result_is_64bit = nir_iand(, flags,
- nir_imm_int(,
VK_QUERY_RESULT_64_BIT));
+ nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
VK_QUERY_RESULT_64_BIT);
nir_ssa_def *result_size = nir_b32csel(, result_is_64bit,
nir_imm_int(, 8), nir_imm_int(, 4));
nir_if *store_if = nir_if_create(b.shader);
- store_if->condition = nir_src_for_ssa(nir_ior(, nir_iand(, flags,
nir_imm_int(, VK_QUERY_RESULT_PARTIAL_BIT)), nir_load_var(, available)));
+ store_if->condition = nir_src_for_ssa(nir_ior(, nir_flag_set(,
flags, VK_QUERY_RESULT_PARTIAL_BIT), nir_load_var(, available)));
nir_cf_node_insert(b.cursor, _if->cf_node);
b.cursor = nir_after_cf_list(_if->then_list);
@@ -253,7 +258,7 @@ build_occlusion_query_shader(struct radv_device *device) {
/* Store the availability bit if requested. */
nir_if *availability_if = nir_if_create(b.shader);
- availability_if->condition = nir_src_for_ssa(nir_iand(, flags,
nir_imm_int(, VK_QUERY_RESULT_WITH_AVAILABILITY_BIT)));
+ availability_if->condition = nir_src_for_ssa(nir_flag_set(, flags,
VK_QUERY_RESULT_WITH_AVAILABILITY_BIT));
nir_cf_node_insert(b.cursor, _if->cf_node);
b.cursor = nir_after_cf_list(_if->then_list);
@@ -369,15 +374,14 @@ build_pipeline_statistics_query_shader(struct radv_device
*device) {
nir_builder_instr_insert(, >instr);
nir_ssa_def *available = >dest.ssa;
- nir_ssa_def *result_is_64bit = nir_iand(, flags,
- nir_imm_int(,
VK_QUERY_RESULT_64_BIT));
+ nir_ssa_def *result_is_64bit = nir_flag_set(, flags,
VK_QUERY_RESULT_64_BIT);
nir_ssa_def *elem_size = nir_b32csel(, result_is_64bit,
nir_imm_int(, 8), nir_imm_int(, 4));
nir_ssa_def *elem_count = nir_ushr(, stats_mask, nir_imm_int(, 16));
/* Store the availability bit if requested. */
nir_if *availability_if = nir_if_create(b.shader);
- availability_if->condition = nir_src_for_ssa(nir_iand(, flags,
nir_imm_int(, VK_QUERY_RESULT_WITH_AVAILABILITY_BIT)));
+ availability_if->condition = nir_src_for_ssa(nir_flag_set(, flags,
VK_QUERY_RESULT_WITH_AVAILABILITY_BIT));
nir_cf_node_insert(b.cursor, _if->cf_node);
b.cursor = nir_after_cf_list(_if->then_list);
@@ -401,7 +405,7 @@ build_pipeline_statistics_query_shader(struct radv_device
*device) {
nir_store_var(, output_offset, output_base, 0x1);
for (int i = 0; i < 11; ++i) {
nir_if *store_if = nir_if_create(b.shader);
- store_if->condition = nir_src_for_ssa(nir_iand(, stats_mask,
nir_imm_int(, 1u << i)));
+ store_if->condition = nir_src_for_ssa(nir_flag_set(,
stats_mask, 1u << i));
nir_cf_node_insert(b.cursor, _if->cf_node);
b.cursor = nir_after_cf_list(_if->then_list);
@@ -463,8 +467,7 @@ build_pipeline_statistics_query_shader(struct radv_device
*device) {
b.cursor = nir_after_cf_list(_if->else_list);
available_if = nir_if_create(b.shader);
- available_if->condition = nir_src_for_ssa(nir_iand(, flags,
- nir_imm_int(,
VK_QUERY_RESULT_PARTIAL_BIT)));
+ available_if->condition = nir_src_for_ssa(nir_flag_set(, flags,
VK_QUERY_RESULT_PARTIAL_BIT));
nir_cf_node_insert(b.cursor, _if->cf_node);
b.cursor = nir_after_cf_list(_if->then_list);
@@ -667,7 +670,7 @@ build_tfb_query_shader(struct radv_device *device)
/* Determine if result is 64 or 32 bit. */
nir_ssa_def *result_is_64bit =
- nir_iand(, flags, nir_imm_int(, VK_QUERY_RESULT_64_BIT));
+ nir_flag_set(, flags, VK_QUERY_RESULT_64_BIT);
nir_ssa_def *result_size =
nir_b32csel(, result_is_64bit, nir_imm_int(, 16),
nir_imm_int(, 8));
@@ -675,8
[Mesa-dev] [Bug 109071] meson --wipe results in Exception: "FileNotFoundError: [Errno 2] No such file or directory"
https://bugs.freedesktop.org/show_bug.cgi?id=109071 --- Comment #5 from Dylan Baker --- Meson PR that resolves the issue. I've tagged it for inclusion in 0.49.1 as well https://github.com/mesonbuild/meson/pull/4665 -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: create 32-bit bcsel for 32-bit conditions
On Wed, Dec 19, 2018 at 1:12 PM Alan Swanson wrote: > On Mon, 2018-12-17 at 16:16 +, Rhys Perry wrote: > > Signed-off-by: Rhys Perry > > --- > > src/compiler/nir/nir_opt_peephole_select.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/src/compiler/nir/nir_opt_peephole_select.c > > b/src/compiler/nir/nir_opt_peephole_select.c > > index ad9d0abec0..241627ed99 100644 > > --- a/src/compiler/nir/nir_opt_peephole_select.c > > +++ b/src/compiler/nir/nir_opt_peephole_select.c > > @@ -205,7 +205,9 @@ nir_opt_peephole_select_block(nir_block *block, > > nir_shader *shader, > > break; > > > >nir_phi_instr *phi = nir_instr_as_phi(instr); > > - nir_alu_instr *sel = nir_alu_instr_create(shader, > > nir_op_bcsel); > > + nir_op sel_op = nir_src_bit_size(if_stmt->condition) == 1 ? > > + nir_op_bcsel : nir_op_b32csel; > > + nir_alu_instr *sel = nir_alu_instr_create(shader, sel_op); > >nir_src_copy(>src[0].src, _stmt->condition, sel); > >/* Splat the condition to all channels */ > >memset(sel->src[0].swizzle, 0, sizeof sel->src[0].swizzle); > > Just to note that I currently need this on radv with git head to run > Total War: Warhammer 2 and probably other vulkan based games, else I > get the following validation error (though it was suggested validator > wouldn't complain in follow on emails); > Yeah, I'm working on a more proper patch. Unfortunately, I'm kind-of coding blind because I don't know and/or can't test radv very well. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: create 32-bit bcsel for 32-bit conditions
On Mon, 2018-12-17 at 16:16 +, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/compiler/nir/nir_opt_peephole_select.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/compiler/nir/nir_opt_peephole_select.c
> b/src/compiler/nir/nir_opt_peephole_select.c
> index ad9d0abec0..241627ed99 100644
> --- a/src/compiler/nir/nir_opt_peephole_select.c
> +++ b/src/compiler/nir/nir_opt_peephole_select.c
> @@ -205,7 +205,9 @@ nir_opt_peephole_select_block(nir_block *block,
> nir_shader *shader,
> break;
>
>nir_phi_instr *phi = nir_instr_as_phi(instr);
> - nir_alu_instr *sel = nir_alu_instr_create(shader,
> nir_op_bcsel);
> + nir_op sel_op = nir_src_bit_size(if_stmt->condition) == 1 ?
> + nir_op_bcsel : nir_op_b32csel;
> + nir_alu_instr *sel = nir_alu_instr_create(shader, sel_op);
>nir_src_copy(>src[0].src, _stmt->condition, sel);
>/* Splat the condition to all channels */
>memset(sel->src[0].swizzle, 0, sizeof sel->src[0].swizzle);
Just to note that I currently need this on radv with git head to run
Total War: Warhammer 2 and probably other vulkan based games, else I
get the following validation error (though it was suggested validator
wouldn't complain in follow on emails);
NIR validation failed after nir_opt_peephole_select
3 errors:
shader: MESA_SHADER_COMPUTE
name: tfb_query
local-size: 64, 1, 1
shared-size: 0
inputs: 0
outputs: 0
uniforms: 0
shared: 0
decl_function main (0 params)
impl main {
block block_0:
/* preds: */
vec1 64 ssa_0 = load_const (0x 0 /* 0.00 */)
vec1 32 ssa_4 = load_const (0x /* 0.00 */)
/* flags */ vec1 32 ssa_7 = intrinsic load_push_constant
(ssa_4) (0, 16) /* base=0 */ /* range=16 */
vec1 32 ssa_9 = intrinsic vulkan_resource_index (ssa_4) (0, 0)
/* desc-set=0 */ /* binding=0 */
vec1 32 ssa_11 = intrinsic vulkan_resource_index (ssa_4) (0, 1)
/* desc-set=0 */ /* binding=1 */
vec3 32 ssa_12 = intrinsic load_local_invocation_id () ()
vec3 32 ssa_13 = intrinsic load_work_group_id () ()
vec1 32 ssa_14 = load_const (0x0040 /* 0.00 */)
vec1 32 ssa_91 = imul ssa_13.x, ssa_14
vec1 32 ssa_96 = iadd ssa_91, ssa_12.x
vec1 32 ssa_22 = load_const (0x0020 /* 0.00 */)
vec1 32 ssa_23 = imul ssa_22, ssa_96
vec1 32 ssa_24 = load_const (0x0004 /* 0.00 */)
/* output_stride */ vec1 32 ssa_25 = intrinsic
load_push_constant (ssa_24) (0, 16) /* base=0 */ /* range=16 */
vec1 32 ssa_26 = imul /* output_stride */ ssa_25, ssa_96
vec4 32 ssa_27 = intrinsic load_ssbo (ssa_11, ssa_23) (0, 0, 0)
/* access=0 */ /* align_mul=0 */ /* align_offset=0 */
vec1 32 ssa_28 = load_const (0x0010 /* 0.00 */)
vec1 32 ssa_29 = iadd ssa_23, ssa_28
vec4 32 ssa_30 = intrinsic load_ssbo (ssa_11, ssa_29) (0, 0, 0)
/* access=0 */ /* align_mul=0 */ /* align_offset=0 */
vec1 32 ssa_33 = iand ssa_27.y, ssa_27.w
vec1 32 ssa_36 = iand ssa_30.y, ssa_30.w
vec1 32 ssa_37 = load_const (0x8000 /* -0.00 */)
vec1 32 ssa_38 = iand ssa_33, ssa_36
vec1 32 ssa_39 = iand ssa_38, ssa_37
vec1 64 ssa_45 = pack_64_2x32_split ssa_27.x, ssa_27.y
vec1 64 ssa_51 = pack_64_2x32_split ssa_27.z, ssa_27.w
vec1 64 ssa_57 = pack_64_2x32_split ssa_30.x, ssa_30.y
vec1 64 ssa_63 = pack_64_2x32_split ssa_30.z, ssa_30.w
vec1 64 ssa_64 = isub ssa_63, ssa_51
vec1 64 ssa_65 = isub ssa_57, ssa_45
vec1 32 ssa_68 = load_const (0x0001 /* 0.00 */)
vec1 32 ssa_120 = bcsel ssa_39, ssa_68, ssa_4
error: src_bit_size == nir_alu_type_get_type_size(src_type) (../mesa-
/src/compiler/nir/nir_validate.c:360)
vec1 64 ssa_121 = bcsel ssa_39, ssa_64, ssa_0
error: src_bit_size == nir_alu_type_get_type_size(src_type) (../mesa-
/src/compiler/nir/nir_validate.c:360)
vec1 64 ssa_122 = bcsel ssa_39, ssa_65, ssa_0
error: src_bit_size == nir_alu_type_get_type_size(src_type) (../mesa-
/src/compiler/nir/nir_validate.c:360)
vec1 32 ssa_72 = load_const (0x0001 /* 0.00 */)
vec1 32 ssa_73 = iand /* flags */ ssa_7, ssa_72
vec1 32 ssa_74 = load_const (0x0008 /* 0.00 */)
vec1 32 ssa_76 = b32csel ssa_73, ssa_28, ssa_74
vec1 32 ssa_79 = iand /* flags */ ssa_7, ssa_74
vec1 32 ssa_80 = ior ssa_79, ssa_120
/* succs: block_1 block_5 */
if ssa_80 {
block block_1:
/* preds: block_0 */
/* succs: block_2 block_3 */
if ssa_73 {
block block_2:
/* preds: block_1 */
vec2 64 ssa_106 = vec2 ssa_121, ssa_122
intrinsic store_ssbo (ssa_106, ssa_9, ssa_26)
(3, 0, 0, 0) /* wrmask=xy */ /* access=0 */
[Mesa-dev] [Bug 109071] meson --wipe results in Exception: "FileNotFoundError: [Errno 2] No such file or directory"
https://bugs.freedesktop.org/show_bug.cgi?id=109071 --- Comment #4 from Gert Wollny --- Indeed, when I do meson --wipe . build it works :) -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 11/53] compiler/spirv: use 32-bit polynomial approximation for 16-bit asin()
I've sent a nit or two but the first 11 patches are
Reviewed-by: Jason Ekstrand
I'd be very happy for you to push them ahead of the rest of the series so
they don't end up in a v3 unless someone else requests significant changes.
On Wed, Dec 19, 2018 at 5:51 AM Iago Toral Quiroga
wrote:
> The 16-bit polynomial execution doesn't meet Khronos precision
> requirements.
> Also, the half-float denorm range starts at 2^(-14) and with asin taking
> input
> values in the range [0, 1], polynomial approximations can lead to flushing
> relatively easy.
>
> An alternative is to use the atan2 formula to compute asin, which is the
> reference taken by Khronos to determine precision requirements, but that
> ends up generating too many additional instructions when compared to the
> polynomial approximation. Specifically, for the Intel case, doing this
> adds +41 instructions to the program for each asin/acos call, which looks
> like an undesirable trade off.
>
> So for now we take the easy way out and fallback to using the 32-bit
> polynomial approximation, which is better (faster) than the 16-bit atan2
> implementation and gives us better precision that matches Khronos
> requirements.
>
> v2:
> - Fallback to 32-bit using recursion (Jason).
> ---
> src/compiler/spirv/vtn_glsl450.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/src/compiler/spirv/vtn_glsl450.c
> b/src/compiler/spirv/vtn_glsl450.c
> index 2540331b6cc..0a641077513 100644
> --- a/src/compiler/spirv/vtn_glsl450.c
> +++ b/src/compiler/spirv/vtn_glsl450.c
> @@ -202,6 +202,20 @@ build_log(nir_builder *b, nir_ssa_def *x)
> static nir_ssa_def *
> build_asin(nir_builder *b, nir_ssa_def *x, float p0, float p1)
> {
> + if (x->bit_size == 16) {
> + /* The polynomial approximation isn't precise enough to meet
> half-float
> + * precision requirements. Alternatively, we could implement this
> using
> + * the formula:
> + *
> + * asin(x) = atan2(x, sqrt(1 - x*x))
> + *
> + * But that is very expensive, so instead we just do the polynomial
> + * approximation in 32-bit math and then we convert the result back
> to
> + * 16-bit.
> + */
> + return nir_f2f16(b, build_asin(b, nir_f2f32(b, x), p0, p1));
> + }
> +
> nir_ssa_def *one = nir_imm_floatN_t(b, 1.0f, x->bit_size);
> nir_ssa_def *abs_x = nir_fabs(b, x);
>
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109071] meson --wipe results in Exception: "FileNotFoundError: [Errno 2] No such file or directory"
https://bugs.freedesktop.org/show_bug.cgi?id=109071 --- Comment #3 from Dylan Baker --- It's much simpler than that, calling meson --wipe from the build dir doesn't work! I can fix this -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 09/53] compiler/spirv: implement 16-bit hyperbolic trigonometric functions
On Wed, Dec 19, 2018 at 5:51 AM Iago Toral Quiroga
wrote:
> v2:
> - use nir_fadd_imm and nir_fmul_imm helpers (Jason)
> ---
> src/compiler/spirv/vtn_glsl450.c | 44 +++-
> 1 file changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/src/compiler/spirv/vtn_glsl450.c
> b/src/compiler/spirv/vtn_glsl450.c
> index ec91d9308c5..c8400d6c80f 100644
> --- a/src/compiler/spirv/vtn_glsl450.c
> +++ b/src/compiler/spirv/vtn_glsl450.c
> @@ -654,17 +654,17 @@ handle_glsl450_alu(struct vtn_builder *b, enum
> GLSLstd450 entrypoint,
> case GLSLstd450Sinh:
>/* 0.5 * (e^x - e^(-x)) */
>val->ssa->def =
> - nir_fmul(nb, nir_imm_float(nb, 0.5f),
> - nir_fsub(nb, build_exp(nb, src[0]),
> - build_exp(nb, nir_fneg(nb, src[0];
> + nir_fmul_imm(nb, nir_fsub(nb, build_exp(nb, src[0]),
> + build_exp(nb, nir_fneg(nb,
> src[0]))),
> + 0.5f);
>return;
>
> case GLSLstd450Cosh:
>/* 0.5 * (e^x + e^(-x)) */
>val->ssa->def =
> - nir_fmul(nb, nir_imm_float(nb, 0.5f),
> - nir_fadd(nb, build_exp(nb, src[0]),
> - build_exp(nb, nir_fneg(nb, src[0];
> + nir_fmul_imm(nb, nir_fadd(nb, build_exp(nb, src[0]),
> + build_exp(nb, nir_fneg(nb,
> src[0]))),
> + 0.5f);
>return;
>
> case GLSLstd450Tanh: {
> @@ -675,30 +675,38 @@ handle_glsl450_alu(struct vtn_builder *b, enum
> GLSLstd450 entrypoint,
> * We clamp x to (-inf, +10] to avoid precision problems. When x >
> 10,
> * e^2x is so much larger than 1.0 that 1.0 gets flushed to zero in
> the
> * computation e^2x +/- 1 so it can be ignored.
> + *
> + * For 16-bit precision we clamp x to (-inf, +4.2] since the maximum
> + * representable number is only 65,504 and e^(2*6) exceeds that.
> Also,
> + * if x > 4.2, tanh(x) will return 1.0 in fp16.
> */
> - nir_ssa_def *x = nir_fmin(nb, src[0], nir_imm_float(nb, 10));
> - nir_ssa_def *exp2x = build_exp(nb, nir_fmul(nb, x,
> nir_imm_float(nb, 2)));
> - val->ssa->def = nir_fdiv(nb, nir_fsub(nb, exp2x, nir_imm_float(nb,
> 1)),
> - nir_fadd(nb, exp2x, nir_imm_float(nb,
> 1)));
> + const uint32_t bit_size = src[0]->bit_size;
> + const double clamped_x = bit_size > 16 ? 10.0 : 4.2;
> + nir_ssa_def *x = nir_fmin(nb, src[0],
> +nir_imm_floatN_t(nb, clamped_x,
> bit_size));
> + nir_ssa_def *exp2x = build_exp(nb, nir_fmul_imm(nb, x, 2.0));
> + val->ssa->def = nir_fdiv(nb, nir_fadd_imm(nb, exp2x, -1.0),
> + nir_fadd_imm(nb, exp2x, 1.0));
>return;
> }
>
> case GLSLstd450Asinh:
>val->ssa->def = nir_fmul(nb, nir_fsign(nb, src[0]),
> build_log(nb, nir_fadd(nb, nir_fabs(nb, src[0]),
> - nir_fsqrt(nb, nir_fadd(nb, nir_fmul(nb, src[0],
> src[0]),
> - nir_imm_float(nb,
> 1.0f));
> + nir_fsqrt(nb, nir_fadd_imm(nb, nir_fmul(nb,
> src[0], src[0]),
> + 1.0f);
>return;
> case GLSLstd450Acosh:
>val->ssa->def = build_log(nb, nir_fadd(nb, src[0],
> - nir_fsqrt(nb, nir_fsub(nb, nir_fmul(nb, src[0], src[0]),
> -nir_imm_float(nb, 1.0f);
> + nir_fsqrt(nb, nir_fadd_imm(nb, nir_fmul(nb, src[0], src[0]),
> +-1.0f;
>return;
> case GLSLstd450Atanh: {
> - nir_ssa_def *one = nir_imm_float(nb, 1.0);
> - val->ssa->def = nir_fmul(nb, nir_imm_float(nb, 0.5f),
> - build_log(nb, nir_fdiv(nb, nir_fadd(nb, one, src[0]),
> -nir_fsub(nb, one, src[0];
> + nir_ssa_def *one = nir_imm_floatN_t(nb, 1.0, src[0]->bit_size);
> + val->ssa->def =
> + nir_fmul_imm(nb, build_log(nb, nir_fdiv(nb, nir_fadd_imm(nb,
> src[0], 1.0f),
>
Since you had to declare one for the line below, you could just use it
here. Doesn't really matter though.
> +nir_fsub(nb, one, src[0]))),
> + 0.5f);
>return;
> }
>
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109071] meson --wipe results in Exception: "FileNotFoundError: [Errno 2] No such file or directory"
https://bugs.freedesktop.org/show_bug.cgi?id=109071 --- Comment #2 from Gert Wollny --- I did not call "meson build" but just "meson like below" from the empty build directory, and then I simply tried "meson --wipe ", I didn't touch the mesa tree. The CFLAGS and CXXFLAGS are not important it still fails when I unset them. My latest test was with meson ../ -Ddri-drivers=i915 -Dgallium-drivers=r600,virgl,swrast\ -Dvulkan-drivers=intel \ -Dbuildtype=debug -Dplatforms=x11,surfaceless,drm \ -Dlibdir=lib -Dprefix=/tmp/install \ -Dvalgrind=true because I though that the empty drivers list might be the problem, but no, it also fails like this. -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/16] glsl/nir: int constants as float for native_integers=false
I haven't encountered such dereference issues, but lowering integers later is a good idea (as with bools which are now lowered later). On 12/19/2018 01:22 PM, Eric Anholt wrote: Jonathan Marek writes: Note: the backend must take care that uniform index is now a float This makes me think that lowering ints to float should be done near the end of the compile (followed by maybe an algebraic and a dce). As is, I think nir_lower_io() is going to do bad things to dereferences of i/o arrays. That said, it looks like this will be fixing way more than it regresses, so I would go along with it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] last call for autotools
Quoting Nicolai Hähnle (2018-12-18 09:37:43)
> On 17.12.18 23:46, Dylan Baker wrote:
> > Quoting Marek Olšák (2018-12-17 12:25:29)
> >> On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt wrote:
> >>
> >> Eero Tamminen writes:
> >>
> >> > Hi,
> >> >
> >> > On 17.12.2018 8.08, Marek Olšák wrote:
> >> > [...]
> >> >> I think one of the serious usability issues is that environment
> >> >> variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH
> >> are not
> >> >> saved by meson for future reconfigures.
> >> >
> >> > I don't know what Meson is supposed to do, but to me that would be
> >> > a bug in a build tool.
> >> >
> >> > Re-configure is supposed to adapt SW to the changes in the build
> >> > environment, and environment variables are part of that (along with
> >> > command line options and SW installed to to the system). Build
> >> > configure tool deciding to "remember" some of those things instead
> >> > of checking the new situation, seems like a great opportunity for
> >> > confusion.
> >>
> >> A user-triggered reconfigure, sure. Recapture env vars then. But
> >> "git
> >> pull; ninja -C build" losing track of the configuration state is
> >> broken.
> >> We don't have to specify all of your meson -Doption=state
> >> configuration
> >> on every build, why should you need to specify your PKG_CONFIG_PATH
> >> configure options on every build?
> >>
> >>
> >> Thanks, Eric.
> >>
> >> Yes, meson behaves such that users have to set all environment variables
> >> for
> >> every "ninja" command that might reconfigure.
> >>
> >> I see 2 solutions:
> >> 1) meson needs to remember the relevant env vars
> >> 2) meson should FAIL to configure if any of the env vars are set (if it
> >> wants
> >> to ignore them)
> >>
> >> Marek
> >
> > Meson does remember the *_FLAGS variables. Those are translated on configure
> > into meson's internal ${lang}_args and ${lang}_link args. It does look like
> > those aren't remembered when --wipe is called though, I filed a bug for
> > that:
> > https://github.com/mesonbuild/meson/issues/4650
>
> I ran into this same problem and noticed that Meson is already able to
> *warn* about such changes.
>
> It should either ignore the changes, or better yet, fail.
>
> (Or even better: ignore environment variables entirely; IMO sourcing the
> environment implicitly in a build system with an explicit configure is
> just a broken design that was unfortunately inherited from plain make
> without really considering the UI implications.)
I agree with this, as do most of the upstream meson developers. So do the
autotools developers, who recommend passing CFLAGS (and friends) as arguments
instead of as env variables:
./configure CFLAGS='-march=native -03' LDFLAGS='-O3' --enable-foo
meson supports this using:
meson -Dc_args='-march-native' -Dc_link_args='-O3' -Dfoo=true
Meson basically inherited this from autotools, and in hindsight we shouldn't
have.
I'm going to do 3 things I think:
- Update our documentation to strongly recommend -Dc_args and not CLFAGS
- Push for meson to warn about using environment variables and recommend command
line options.
- Push for meson to remove CFLAGS and friends support:
https://github.com/mesonbuild/meson/issues/4664
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 04/53] compiler/spirv: implement 16-bit asin
On Wed, Dec 19, 2018 at 5:51 AM Iago Toral Quiroga
wrote:
> v2:
> - use nir_fmul_imm and nir_fadd_imm helpers (Jason)
> ---
> src/compiler/spirv/vtn_glsl450.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/src/compiler/spirv/vtn_glsl450.c
> b/src/compiler/spirv/vtn_glsl450.c
> index b54aeb9b217..f411d17cfe4 100644
> --- a/src/compiler/spirv/vtn_glsl450.c
> +++ b/src/compiler/spirv/vtn_glsl450.c
> @@ -202,17 +202,22 @@ build_log(nir_builder *b, nir_ssa_def *x)
> static nir_ssa_def *
> build_asin(nir_builder *b, nir_ssa_def *x, float p0, float p1)
> {
> + nir_ssa_def *one = nir_imm_floatN_t(b, 1.0f, x->bit_size);
> nir_ssa_def *abs_x = nir_fabs(b, x);
> +
> + nir_ssa_def *p0_plus_xp1 = nir_fadd_imm(b, nir_fmul_imm(b, abs_x, p1),
> p0);
> +
> + nir_ssa_def *expr_tail =
> + nir_fadd_imm(b, nir_fmul(b, abs_x,
> + nir_fadd_imm(b, nir_fmul(b, abs_x,
> +
> p0_plus_xp1),
> + M_PI_4f - 1.0f)),
> + M_PI_2f);
> +
> return nir_fmul(b, nir_fsign(b, x),
> - nir_fsub(b, nir_imm_float(b, M_PI_2f),
> -nir_fmul(b, nir_fsqrt(b, nir_fsub(b,
> nir_imm_float(b, 1.0f), abs_x)),
> - nir_fadd(b, nir_imm_float(b,
> M_PI_2f),
> - nir_fmul(b, abs_x,
> - nir_fadd(b,
> nir_imm_float(b, M_PI_4f - 1.0f),
> -
> nir_fmul(b, abs_x,
> -
> nir_fadd(b, nir_imm_float(b, p0),
> -
> nir_fmul(b, abs_x,
> -
> nir_imm_float(b, p1));
> + nir_fsub(b, nir_imm_float(b, M_PI_2f),
>
This needs to be nir_imm_floatN_t. Fortunately, I don't think it'll line
wrap.
> + nir_fmul(b, nir_fsqrt(b, nir_fsub(b,
> one, abs_x)),
> + expr_tail)));
> }
>
> /**
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/16] glsl/nir: int constants as float for native_integers=false
Jonathan Marek writes: > Note: the backend must take care that uniform index is now a float This makes me think that lowering ints to float should be done near the end of the compile (followed by maybe an algebraic and a dce). As is, I think nir_lower_io() is going to do bad things to dereferences of i/o arrays. That said, it looks like this will be fixing way more than it regresses, so I would go along with 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 08/16] freedreno: a2xx: enable early-Z testing
Hi, I didn't verify it, but both r600 and a3xx disable earlyZ when alpha test is enabled, so this is almost certainly right. We don't need to worry about the shader writing Z, it is not part of OpenGL ES 2.0 and not implemented by the driver (although the hardware should allow it). Why should we need to check if the shader does discards? On 12/19/2018 01:05 PM, Eric Anholt wrote: Jonathan Marek writes: Enable earlyZ when alpha test is disabled. Signed-off-by: Jonathan Marek --- src/gallium/drivers/freedreno/a2xx/fd2_zsa.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c b/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c index 64b31b677b..d3c19b4450 100644 --- a/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c +++ b/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c @@ -49,7 +49,8 @@ fd2_zsa_state_create(struct pipe_context *pctx, A2XX_RB_DEPTHCONTROL_ZFUNC(cso->depth.func); /* maps 1:1 */ if (cso->depth.enabled) - so->rb_depthcontrol |= A2XX_RB_DEPTHCONTROL_Z_ENABLE; + so->rb_depthcontrol |= A2XX_RB_DEPTHCONTROL_Z_ENABLE | + COND(!cso->alpha.enabled, A2XX_RB_DEPTHCONTROL_EARLY_Z_ENABLE); Why when alpha test is disabled? Should you also be checking if the shader does discards? How about if the shader writes Z, is anything preventing early Z then? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] drop autotools
Quoting Jason Ekstrand (2018-12-19 08:07:23) > On Tue, Dec 18, 2018 at 2:51 AM Juan A. Suarez Romero > wrote: > > On Mon, 2018-12-17 at 19:51 +0100, Bas Nieuwenhuizen wrote: > > On Mon, Dec 17, 2018 at 6:33 PM Juan A. Suarez Romero > > wrote: > > > On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote: > > > > Cc: Emil Velikov > > > > Cc: Andres Gomez > > > > Cc: Juan A. Suarez Romero > > > > Cc: Dylan Baker > > > > Signed-off-by: Eric Engestrom > > > > --- > > > > This patch depends on the releasing procedure in docs/releasing.html > to > > > > be updated to not rely on autotools anymore. > > > > > > > > I think our release managers (cc'ed) should work together and figure > out > > > > the procedure they want to go by; only once that's done can we > delete > > > > these 200+ files and 14k+ lines :) > > > > > > I'll let others to talk. But my preference would be to land this for > next 19.0 > > > branchpoint, just a couple of days before the branchpoint, so 19.0.x > releases > > > get rid of autotools. > > > > > > This way we have time to fix any remaining issue, and make like easier > for those > > > in charge of 18.3.x releases, which I think should support autotools > until the > > > end of its life. > > > > Can I suggest the inverse, pushing this long before any branchpoint? > > > > As with any migration, users only start using when you force them too, > > and that means a bunch of non-working usecases are going to be > > detected once this patch is pushed and some more people are forced to > > it. Sure, the last call discussion served to tease some of these out, > > but I expect even more will turn up if you submit this. > > > > The bad part is that this make life more complex for the person in charge > of the > stable release, because it means that any patch that touches the build > system > will only touch the meson, but not the autotools, which means either the > original author or the release manager should fix the part of the > autotools > in > order to avoid breaking it. > > > How common is it to have build system patches back-ported to stable? I > genuinely don't know but I would suspect it's not all that frequent of a > thing. For meson it happens fairly regularly, it happens for android as well, for Scons and autotools it does happen but not often. It's starting to happen now more than it did before as there are at least a couple of drivers where the developer(s) all use meson primarily, and only touch test autotools at best. I suspect that will get worse as time goes by. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/16] freedreno: a2xx: enable early-Z testing
Jonathan Marek writes: > Enable earlyZ when alpha test is disabled. > > Signed-off-by: Jonathan Marek > --- > src/gallium/drivers/freedreno/a2xx/fd2_zsa.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c > b/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c > index 64b31b677b..d3c19b4450 100644 > --- a/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c > +++ b/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c > @@ -49,7 +49,8 @@ fd2_zsa_state_create(struct pipe_context *pctx, > A2XX_RB_DEPTHCONTROL_ZFUNC(cso->depth.func); /* maps 1:1 */ > > if (cso->depth.enabled) > - so->rb_depthcontrol |= A2XX_RB_DEPTHCONTROL_Z_ENABLE; > + so->rb_depthcontrol |= A2XX_RB_DEPTHCONTROL_Z_ENABLE | > + COND(!cso->alpha.enabled, > A2XX_RB_DEPTHCONTROL_EARLY_Z_ENABLE); Why when alpha test is disabled? Should you also be checking if the shader does discards? How about if the shader writes Z, is anything preventing early Z then? 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] autotools: Deprecate the use of autotools
FWIW, with all the feedback I've given, I think autotools is not better than meson. The issues that I reported won't make me switch back to autotools. Marek On Wed, Dec 19, 2018, 12:45 PM Jason Ekstrand On Wed, Dec 19, 2018 at 10:32 AM Ilia Mirkin wrote: > >> On Wed, Dec 19, 2018 at 11:03 AM Jason Ekstrand >> wrote: >> > >> > On Wed, Dec 19, 2018 at 9:32 AM Ilia Mirkin >> wrote: >> >> >> >> On Wed, Dec 19, 2018 at 10:25 AM Matt Turner >> wrote: >> >> > >> >> > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin >> wrote: >> >> > > >> >> > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner >> wrote: >> >> > > > WTF would you have us do? >> >> > > >> >> > > Same thing as for any change with an impact this wide -- >> >> > > >> >> > > 1. Identify stakeholders. In this case, probably the sub-project >> >> > > maintainers, major contributors, and a smattering of distro >> >> > > maintainers. >> >> > > 2. Make them happy, or at least get them, as a group, to agree that >> >> > > it's "good enough". >> >> > >> >> > So we're trying to get better coverage than what you're suggesting. >> >> > >> >> > > 3. Apply. >> >> > > >> >> > > This is the point at which you can make autotools less visible. >> We're >> >> > > not at that point yet. >> >> > >> >> > Ilia, it's an extra flag. I think you'll survive. >> >> >> >> It's an advertising strategy for meson (hello world, check this out, >> >> it's going to be the default soon). It can be done at the final stage. >> >> We're not at that stage. >> >> >> >> We're at the stage of "hello community, we'd like to replace >> >> autotools", and the community coming back to you with feedback. >> > >> > >> > I disagree. I think we were at that stage 6-8 months ago and a bunch >> of the community didn't come back with feedback until we sent a patch to >> delete autotools. Identify stakeholders? Done; the distros are all cool >> with it or have already switched. Agree it's "good enough"? We thought >> we'd done that and then people raised issues at the 11th hour. Even with >> those issues, the ones that are real issues with meson are all in-progress >> to fix. The others are just "make it look like autotools so I can pretend >> meson doesn't exist". Please pardon my frustration but we thought we'd >> done our due diligence and it wasn't until we took a step very much like >> this one that we actually got feedback from certain people such as >> yourself. To say that we're only now getting to the "hello community, we'd >> like to replace autotools" stage is a bit disingenuous. >> > >> > That said, that doesn't mean I think this patch is the right way to >> go. I think the referenced e-mail conversaion has flushed out enough of >> the remaining issues that we need to fix a couple of remaining things in >> meson and then just delete autotools. Maybe this means that autotools >> stays around for one more release but then I think we should just can it >> without bothering with the extra deprecation step. >> >> First -- I want you (and Dylan, and others who are pushing this) to >> know that I understand your frustration. Making big changes is a giant >> pain. Not only is the change itself difficult (aka 80% of the work), >> but then you have to herd all the cats to make it all happen. And cats >> don't like to be herded (which is why 20% of the work takes 80% of the >> time). >> >> Second -- you're not just getting to "hello community" -- you've been >> there for a while. But it's not a signpost to move past (like an >> announcement might be), it's a stage to complete. The community has to >> be happy. You're saying the concerns are last-second, but I've been >> seeing these complaints going on for a while (stuff about saving env >> vars, inability to see how you configured something, etc). I was >> expecting these would all be addressed before I had to have another >> look. And then all of a sudden, "let's drop autotools!" and variants >> thereof. >> > > I thought I recalled some fairly big "meson is ready; please try it out > and report issues" e-mails in the past but I'm having trouble finding them > today. I do recall you having some complaints early on but, to be honest, > I don't remember what form those took or how/if they got dealt with. I > think one of the failings here is that we really need some sort of a > check-list of things that need to happen prior to autotools deprecation > which people can lobby to get things added to. I think dylan has a > checklist somewhere but it may not be sufficiently public/obvious such that > some of your complaints never got logged there. > > What do you suggest to solve this communication issue? If autotools > survives another release, so be it. However, I want to get us out of the > vicious cycle of long e-mail threads and endless debates and on to a model > where Dylan is working towards something and is able to actually close the > gap. The cynic in me says that if the last week's exchanges teach us > anything, it's that we'll
Re: [Mesa-dev] [PATCH 04/16] nir: add nir_lower_bool_to_float
Hi,
No I did not see that. That version should work for me, although I don't
like the lowering of nir_op_inot it has, since the backend might have
something smarter to implement a "fnot" (and ior could also just be a
fmax instead).
On 12/19/2018 12:44 PM, Christian Gmeiner wrote:
Am Mi., 19. Dez. 2018 um 17:44 Uhr schrieb Jonathan Marek :
Mainly a copy of nir_lower_bool_to_int32, but with float opcodes.
Hmmm.. are you aware of https://patchwork.freedesktop.org/patch/257867/ and
https://gitlab.freedesktop.org/jekstrand/mesa/commit/cf819c8a3fa99ccedf423ea77cf710dbd852066b
?
I am going to send out a lager patch series with that version of bool
to float during my christmas break.
Keep in mind that I did not looked very closely at your lowering pass.
Signed-off-by: Jonathan Marek
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/meson.build | 3 +-
src/compiler/nir/nir.h | 1 +
src/compiler/nir/nir_lower_bool_to_float.c | 165 +
4 files changed, 169 insertions(+), 1 deletion(-)
create mode 100644 src/compiler/nir/nir_lower_bool_to_float.c
diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index ef47bdb33b..39eaedc658 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -231,6 +231,7 @@ NIR_FILES = \
nir/nir_lower_atomics_to_ssbo.c \
nir/nir_lower_bitmap.c \
nir/nir_lower_bit_size.c \
+ nir/nir_lower_bool_to_float.c \
nir/nir_lower_bool_to_int32.c \
nir/nir_lower_clamp_color_outputs.c \
nir/nir_lower_clip.c \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index e252f64539..f1016104af 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -114,6 +114,7 @@ files_libnir = files(
'nir_lower_alpha_test.c',
'nir_lower_atomics_to_ssbo.c',
'nir_lower_bitmap.c',
+ 'nir_lower_bool_to_float.c',
'nir_lower_bool_to_int32.c',
'nir_lower_clamp_color_outputs.c',
'nir_lower_clip.c',
@@ -248,7 +249,7 @@ if with_tests
include_directories : [inc_common],
dependencies : [dep_thread, idep_gtest, idep_nir],
link_with : libmesa_util,
-),
+),
suite : ['compiler', 'nir'],
)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 54f9c64a3a..f6d0bdf7ec 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2905,6 +2905,7 @@ void nir_lower_alpha_test(nir_shader *shader, enum
compare_func func,
bool alpha_to_one);
bool nir_lower_alu(nir_shader *shader);
bool nir_lower_alu_to_scalar(nir_shader *shader);
+bool nir_lower_bool_to_float(nir_shader *shader);
bool nir_lower_bool_to_int32(nir_shader *shader);
bool nir_lower_load_const_to_scalar(nir_shader *shader);
bool nir_lower_read_invocation_to_scalar(nir_shader *shader);
diff --git a/src/compiler/nir/nir_lower_bool_to_float.c
b/src/compiler/nir/nir_lower_bool_to_float.c
new file mode 100644
index 00..2756a1815f
--- /dev/null
+++ b/src/compiler/nir/nir_lower_bool_to_float.c
@@ -0,0 +1,165 @@
+/*
+ * 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 (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"
+
+static bool
+assert_ssa_def_is_not_1bit(nir_ssa_def *def, UNUSED void *unused)
+{
+ assert(def->bit_size > 1);
+ return true;
+}
+
+static bool
+rewrite_1bit_ssa_def_to_32bit(nir_ssa_def *def, void *_progress)
+{
+ bool *progress = _progress;
+ if (def->bit_size == 1) {
+ def->bit_size = 32;
+ *progress = true;
+ }
+ return true;
+}
+
+static bool
+lower_alu_instr(nir_alu_instr *alu)
+{
+ const nir_op_info *op_info = _op_infos[alu->op];
+
+ switch (alu->op) {
+ case nir_op_vec2:
+ case nir_op_vec3:
+ case nir_op_vec4:
+ /* These we expect to have booleans but the opcode doesn't change */
+
[Mesa-dev] [Bug 109071] meson --wipe results in Exception: "FileNotFoundError: [Errno 2] No such file or directory"
https://bugs.freedesktop.org/show_bug.cgi?id=109071 --- Comment #1 from Dylan Baker --- I'm trying hard to replicate this and having a really hard time, it looks like your meson configure line looks something like: CFLAGS='-Wall -Wextra -Wdeprecated-declarations -O2 -g -funroll-loops -ftree-vectorize -pthread -march=native -mtune=native -mno-xop' CXXFLAGS='-Wall -Wextra -Wdeprecated-declarations -O2 -g -funroll-loops -ftree-vectorize -pthread -march=native -mtune=native -mno-xop' meson build -Ddri-drivers= -Dgallium-drivers=r600,virgl,swrast -Dvulkan-drivers= -Dbuildtype=debug -Dplatforms=x11,surfaceless,drm -Dlibdir=lib -Dprefix=/tmp/install -Dvalgrind=true Does that look right? Also, did do any git operations like checkout, pull, or rebase between the initial configuration and the --wipe call? -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 10:32 AM Ilia Mirkin wrote: > On Wed, Dec 19, 2018 at 11:03 AM Jason Ekstrand > wrote: > > > > On Wed, Dec 19, 2018 at 9:32 AM Ilia Mirkin > wrote: > >> > >> On Wed, Dec 19, 2018 at 10:25 AM Matt Turner > wrote: > >> > > >> > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin > wrote: > >> > > > >> > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner > wrote: > >> > > > WTF would you have us do? > >> > > > >> > > Same thing as for any change with an impact this wide -- > >> > > > >> > > 1. Identify stakeholders. In this case, probably the sub-project > >> > > maintainers, major contributors, and a smattering of distro > >> > > maintainers. > >> > > 2. Make them happy, or at least get them, as a group, to agree that > >> > > it's "good enough". > >> > > >> > So we're trying to get better coverage than what you're suggesting. > >> > > >> > > 3. Apply. > >> > > > >> > > This is the point at which you can make autotools less visible. > We're > >> > > not at that point yet. > >> > > >> > Ilia, it's an extra flag. I think you'll survive. > >> > >> It's an advertising strategy for meson (hello world, check this out, > >> it's going to be the default soon). It can be done at the final stage. > >> We're not at that stage. > >> > >> We're at the stage of "hello community, we'd like to replace > >> autotools", and the community coming back to you with feedback. > > > > > > I disagree. I think we were at that stage 6-8 months ago and a bunch of > the community didn't come back with feedback until we sent a patch to > delete autotools. Identify stakeholders? Done; the distros are all cool > with it or have already switched. Agree it's "good enough"? We thought > we'd done that and then people raised issues at the 11th hour. Even with > those issues, the ones that are real issues with meson are all in-progress > to fix. The others are just "make it look like autotools so I can pretend > meson doesn't exist". Please pardon my frustration but we thought we'd > done our due diligence and it wasn't until we took a step very much like > this one that we actually got feedback from certain people such as > yourself. To say that we're only now getting to the "hello community, we'd > like to replace autotools" stage is a bit disingenuous. > > > > That said, that doesn't mean I think this patch is the right way to go. > I think the referenced e-mail conversaion has flushed out enough of the > remaining issues that we need to fix a couple of remaining things in meson > and then just delete autotools. Maybe this means that autotools stays > around for one more release but then I think we should just can it without > bothering with the extra deprecation step. > > First -- I want you (and Dylan, and others who are pushing this) to > know that I understand your frustration. Making big changes is a giant > pain. Not only is the change itself difficult (aka 80% of the work), > but then you have to herd all the cats to make it all happen. And cats > don't like to be herded (which is why 20% of the work takes 80% of the > time). > > Second -- you're not just getting to "hello community" -- you've been > there for a while. But it's not a signpost to move past (like an > announcement might be), it's a stage to complete. The community has to > be happy. You're saying the concerns are last-second, but I've been > seeing these complaints going on for a while (stuff about saving env > vars, inability to see how you configured something, etc). I was > expecting these would all be addressed before I had to have another > look. And then all of a sudden, "let's drop autotools!" and variants > thereof. > I thought I recalled some fairly big "meson is ready; please try it out and report issues" e-mails in the past but I'm having trouble finding them today. I do recall you having some complaints early on but, to be honest, I don't remember what form those took or how/if they got dealt with. I think one of the failings here is that we really need some sort of a check-list of things that need to happen prior to autotools deprecation which people can lobby to get things added to. I think dylan has a checklist somewhere but it may not be sufficiently public/obvious such that some of your complaints never got logged there. What do you suggest to solve this communication issue? If autotools survives another release, so be it. However, I want to get us out of the vicious cycle of long e-mail threads and endless debates and on to a model where Dylan is working towards something and is able to actually close the gap. The cynic in me says that if the last week's exchanges teach us anything, it's that we'll never make the naysayers happy and we're wasting our time trying. I badly don't want that to be true. However, for my internal cynic to be proven wrong, we need a more productive model for how we close that gap and agree that it's "good enough." What do you suggest? > What you've been doing thus far is getting all
Re: [Mesa-dev] [PATCH 04/16] nir: add nir_lower_bool_to_float
Am Mi., 19. Dez. 2018 um 17:44 Uhr schrieb Jonathan Marek :
>
> Mainly a copy of nir_lower_bool_to_int32, but with float opcodes.
>
Hmmm.. are you aware of https://patchwork.freedesktop.org/patch/257867/ and
https://gitlab.freedesktop.org/jekstrand/mesa/commit/cf819c8a3fa99ccedf423ea77cf710dbd852066b
?
I am going to send out a lager patch series with that version of bool
to float during my christmas break.
Keep in mind that I did not looked very closely at your lowering pass.
> Signed-off-by: Jonathan Marek
> ---
> src/compiler/Makefile.sources | 1 +
> src/compiler/nir/meson.build | 3 +-
> src/compiler/nir/nir.h | 1 +
> src/compiler/nir/nir_lower_bool_to_float.c | 165 +
> 4 files changed, 169 insertions(+), 1 deletion(-)
> create mode 100644 src/compiler/nir/nir_lower_bool_to_float.c
>
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index ef47bdb33b..39eaedc658 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -231,6 +231,7 @@ NIR_FILES = \
> nir/nir_lower_atomics_to_ssbo.c \
> nir/nir_lower_bitmap.c \
> nir/nir_lower_bit_size.c \
> + nir/nir_lower_bool_to_float.c \
> nir/nir_lower_bool_to_int32.c \
> nir/nir_lower_clamp_color_outputs.c \
> nir/nir_lower_clip.c \
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index e252f64539..f1016104af 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -114,6 +114,7 @@ files_libnir = files(
>'nir_lower_alpha_test.c',
>'nir_lower_atomics_to_ssbo.c',
>'nir_lower_bitmap.c',
> + 'nir_lower_bool_to_float.c',
>'nir_lower_bool_to_int32.c',
>'nir_lower_clamp_color_outputs.c',
>'nir_lower_clip.c',
> @@ -248,7 +249,7 @@ if with_tests
>include_directories : [inc_common],
>dependencies : [dep_thread, idep_gtest, idep_nir],
>link_with : libmesa_util,
> -),
> +),
> suite : ['compiler', 'nir'],
>)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 54f9c64a3a..f6d0bdf7ec 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2905,6 +2905,7 @@ void nir_lower_alpha_test(nir_shader *shader, enum
> compare_func func,
>bool alpha_to_one);
> bool nir_lower_alu(nir_shader *shader);
> bool nir_lower_alu_to_scalar(nir_shader *shader);
> +bool nir_lower_bool_to_float(nir_shader *shader);
> bool nir_lower_bool_to_int32(nir_shader *shader);
> bool nir_lower_load_const_to_scalar(nir_shader *shader);
> bool nir_lower_read_invocation_to_scalar(nir_shader *shader);
> diff --git a/src/compiler/nir/nir_lower_bool_to_float.c
> b/src/compiler/nir/nir_lower_bool_to_float.c
> new file mode 100644
> index 00..2756a1815f
> --- /dev/null
> +++ b/src/compiler/nir/nir_lower_bool_to_float.c
> @@ -0,0 +1,165 @@
> +/*
> + * 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 (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"
> +
> +static bool
> +assert_ssa_def_is_not_1bit(nir_ssa_def *def, UNUSED void *unused)
> +{
> + assert(def->bit_size > 1);
> + return true;
> +}
> +
> +static bool
> +rewrite_1bit_ssa_def_to_32bit(nir_ssa_def *def, void *_progress)
> +{
> + bool *progress = _progress;
> + if (def->bit_size == 1) {
> + def->bit_size = 32;
> + *progress = true;
> + }
> + return true;
> +}
> +
> +static bool
> +lower_alu_instr(nir_alu_instr *alu)
> +{
> + const nir_op_info *op_info = _op_infos[alu->op];
> +
> + switch (alu->op) {
> + case nir_op_vec2:
> + case nir_op_vec3:
> + case nir_op_vec4:
> + /* These we expect to have booleans but the opcode doesn't change */
> + break;
> +
> + case nir_op_b2f32: alu->op = nir_op_fmov; break;
> +
> + /*
Re: [Mesa-dev] [PATCH 06/16] nir: improve convert_yuv_to_rgb when fuse_ffma=true
Hey Jonathan,
I'm kind of curious as to whether we can have a single expression that
pretty much generates the same final code (through some of the algebraic
lowering/optimizations).
I'll give it a try on Intel HW, see what it does.
-
Lionel
On 19/12/2018 16:39, Jonathan Marek wrote:
When ffma is available, we can use a different arrangement of constants to
get a better result. On freedreno/ir3, this reduces the YUV->RGB to 7
scalar ffma. On freedreno/a2xx, it will allow YUV->RGB to be 3 vec4 ffma.
Signed-off-by: Jonathan Marek
---
src/compiler/nir/nir_lower_tex.c | 62 ++--
1 file changed, 43 insertions(+), 19 deletions(-)
diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c
index 6a6b6c41a7..f7c821bb34 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -342,25 +342,49 @@ convert_yuv_to_rgb(nir_builder *b, nir_tex_instr *tex,
nir_ssa_def *y, nir_ssa_def *u, nir_ssa_def *v,
nir_ssa_def *a)
{
- nir_const_value m[3] = {
- { .f32 = { 1.0f, 0.0f, 1.59602678f, 0.0f } },
- { .f32 = { 1.0f, -0.39176229f, -0.81296764f, 0.0f } },
- { .f32 = { 1.0f, 2.01723214f, 0.0f,0.0f } }
- };
-
- nir_ssa_def *yuv =
- nir_vec4(b,
- nir_fmul(b, nir_imm_float(b, 1.16438356f),
-nir_fadd(b, y, nir_imm_float(b, -16.0f / 255.0f))),
- nir_channel(b, nir_fadd(b, u, nir_imm_float(b, -128.0f /
255.0f)), 0),
- nir_channel(b, nir_fadd(b, v, nir_imm_float(b, -128.0f /
255.0f)), 0),
- nir_imm_float(b, 0.0));
-
- nir_ssa_def *red = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[0]));
- nir_ssa_def *green = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[1]));
- nir_ssa_def *blue = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[2]));
-
- nir_ssa_def *result = nir_vec4(b, red, green, blue, a);
+ nir_ssa_def *result;
+
+
+ if (b->shader->options->fuse_ffma) {
+ nir_const_value m[4] = {
+ { .f32 = { 1.16438356f, 1.16438356f, 1.16438356f, 0.0f } },
+ { .f32 = { 0.0f, -0.39176229f, 2.01723214f, 0.0f } },
+ { .f32 = { 1.59602678f,-0.81296764f, 0.0f,0.0f } },
+ };
+ static const float y_off = -16.0f * 1.16438356f / 255.0f;
+ static const float sc = 128.0f / 255.0f;
+
+ nir_ssa_def *offset =
+ nir_vec4(b,
+ nir_imm_float(b, y_off - sc * 1.59602678f),
+ nir_imm_float(b, y_off + sc * (0.81296764f + 0.39176229f)),
+ nir_imm_float(b, y_off - sc * 2.01723214f),
+ a);
+
+ result = nir_ffma(b, y, nir_build_imm(b, 4, 32, m[0]),
+ nir_ffma(b, u, nir_build_imm(b, 4, 32, m[1]),
+nir_ffma(b, v, nir_build_imm(b, 4, 32, m[2]),
offset)));
+ } else {
+ nir_const_value m[3] = {
+ { .f32 = { 1.0f, 0.0f, 1.59602678f, 0.0f } },
+ { .f32 = { 1.0f, -0.39176229f, -0.81296764f, 0.0f } },
+ { .f32 = { 1.0f, 2.01723214f, 0.0f,0.0f } }
+ };
+
+ nir_ssa_def *yuv =
+ nir_vec4(b,
+ nir_fmul(b, nir_imm_float(b, 1.16438356f),
+ nir_fadd(b, y, nir_imm_float(b, -16.0f / 255.0f))),
+ nir_channel(b, nir_fadd(b, u, nir_imm_float(b, -128.0f /
255.0f)), 0),
+ nir_channel(b, nir_fadd(b, v, nir_imm_float(b, -128.0f /
255.0f)), 0),
+ nir_imm_float(b, 0.0));
+
+ nir_ssa_def *red = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[0]));
+ nir_ssa_def *green = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[1]));
+ nir_ssa_def *blue = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[2]));
+
+ result = nir_vec4(b, red, green, blue, a);
+ }
nir_ssa_def_rewrite_uses(>dest.ssa, nir_src_for_ssa(result));
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/16] freedreno: a2xx: add partial lower_scalar pass for ir2
Quoting Jonathan Marek (2018-12-19 08:40:04)
> Some instructions can only be scalar on a2xx, lower these only
>
> Signed-off-by: Jonathan Marek
> ---
> .../drivers/freedreno/Makefile.sources| 1 +
> src/gallium/drivers/freedreno/a2xx/ir2_nir.c | 3 +
> .../freedreno/a2xx/ir2_nir_lower_scalar.c | 174 ++
> .../drivers/freedreno/a2xx/ir2_private.h | 1 +
> src/gallium/drivers/freedreno/meson.build | 1 +
> 5 files changed, 180 insertions(+)
> create mode 100644 src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
>
> diff --git a/src/gallium/drivers/freedreno/Makefile.sources
> b/src/gallium/drivers/freedreno/Makefile.sources
> index f4979953e8..fed5b5bd17 100644
> --- a/src/gallium/drivers/freedreno/Makefile.sources
> +++ b/src/gallium/drivers/freedreno/Makefile.sources
> @@ -73,6 +73,7 @@ a2xx_SOURCES := \
> a2xx/ir2_assemble.c \
> a2xx/ir2_cp.c \
> a2xx/ir2_nir.c \
> + a2xx/ir2_nir_lower_scalar.c \
> a2xx/ir2_private.h \
> a2xx/ir2_ra.c
>
> diff --git a/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
> b/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
> index 8162479341..10fa0c765f 100644
> --- a/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
> +++ b/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
> @@ -1124,6 +1124,9 @@ ir2_nir_compile(struct ir2_context *ctx, bool binning)
>
> OPT_V(ctx->nir, nir_lower_bool_to_float);
>
> + /* lower to scalar instructions that can only be scalar on a2xx */
> + OPT_V(ctx->nir, ir2_nir_lower_scalar);
> +
> OPT_V(ctx->nir, nir_lower_locals_to_regs);
>
> OPT_V(ctx->nir, nir_convert_from_ssa, true);
> diff --git a/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
> b/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
> new file mode 100644
> index 00..2b72a86b3e
> --- /dev/null
> +++ b/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
> @@ -0,0 +1,174 @@
> +/*
> + * Copyright (C) 2018 Jonathan Marek
> + *
> + * 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.
> + *
> + * Authors:
> + *Jonathan Marek
> + */
> +
> +/* some operations can only be scalar on a2xx:
> + * rsq, rcp, log2, exp2, cos, sin, sqrt
> + * mostly copy-pasted from nir_lower_alu_to_scalar.c
> + */
> +
> +#include "ir2_private.h"
> +#include "compiler/nir/nir_builder.h"
> +
> +static void
> +nir_alu_ssa_dest_init(nir_alu_instr * instr, unsigned num_components,
> + unsigned bit_size)
> +{
> + nir_ssa_dest_init(>instr, >dest.dest, num_components,
> + bit_size, NULL);
> + instr->dest.write_mask = (1 << num_components) - 1;
> +}
> +
> +static void
> +lower_reduction(nir_alu_instr * instr, nir_op chan_op, nir_op merge_op,
> + nir_builder * builder)
> +{
> + unsigned num_components = nir_op_infos[instr->op].input_sizes[0];
> +
> + nir_ssa_def *last = NULL;
> + for (unsigned i = 0; i < num_components; i++) {
> + nir_alu_instr *chan =
> + nir_alu_instr_create(builder->shader, chan_op);
> + nir_alu_ssa_dest_init(chan, 1, instr->dest.dest.ssa.bit_size);
> + nir_alu_src_copy(>src[0], >src[0], chan);
> + chan->src[0].swizzle[0] = chan->src[0].swizzle[i];
> + if (nir_op_infos[chan_op].num_inputs > 1) {
> + assert(nir_op_infos[chan_op].num_inputs == 2);
> + nir_alu_src_copy(>src[1], >src[1], chan);
> + chan->src[1].swizzle[0] = chan->src[1].swizzle[i];
> + }
> + chan->exact = instr->exact;
> +
> + nir_builder_instr_insert(builder, >instr);
> +
> + if (i == 0) {
> + last = >dest.dest.ssa;
> +
Re: [Mesa-dev] [PATCH 04/16] nir: add nir_lower_bool_to_float
Quoting Jonathan Marek (2018-12-19 08:39:53)
> Mainly a copy of nir_lower_bool_to_int32, but with float opcodes.
>
> Signed-off-by: Jonathan Marek
> ---
> src/compiler/Makefile.sources | 1 +
> src/compiler/nir/meson.build | 3 +-
> src/compiler/nir/nir.h | 1 +
> src/compiler/nir/nir_lower_bool_to_float.c | 165 +
> 4 files changed, 169 insertions(+), 1 deletion(-)
> create mode 100644 src/compiler/nir/nir_lower_bool_to_float.c
>
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index ef47bdb33b..39eaedc658 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -231,6 +231,7 @@ NIR_FILES = \
> nir/nir_lower_atomics_to_ssbo.c \
> nir/nir_lower_bitmap.c \
> nir/nir_lower_bit_size.c \
> + nir/nir_lower_bool_to_float.c \
> nir/nir_lower_bool_to_int32.c \
> nir/nir_lower_clamp_color_outputs.c \
> nir/nir_lower_clip.c \
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index e252f64539..f1016104af 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -114,6 +114,7 @@ files_libnir = files(
>'nir_lower_alpha_test.c',
>'nir_lower_atomics_to_ssbo.c',
>'nir_lower_bitmap.c',
> + 'nir_lower_bool_to_float.c',
>'nir_lower_bool_to_int32.c',
>'nir_lower_clamp_color_outputs.c',
>'nir_lower_clip.c',
> @@ -248,7 +249,7 @@ if with_tests
>include_directories : [inc_common],
>dependencies : [dep_thread, idep_gtest, idep_nir],
>link_with : libmesa_util,
> -),
> +),
This looks like stray whitespace?
other than that, for the build system bits:
Reviewed-by: Dylan Baker
> suite : ['compiler', 'nir'],
>)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 54f9c64a3a..f6d0bdf7ec 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2905,6 +2905,7 @@ void nir_lower_alpha_test(nir_shader *shader, enum
> compare_func func,
>bool alpha_to_one);
> bool nir_lower_alu(nir_shader *shader);
> bool nir_lower_alu_to_scalar(nir_shader *shader);
> +bool nir_lower_bool_to_float(nir_shader *shader);
> bool nir_lower_bool_to_int32(nir_shader *shader);
> bool nir_lower_load_const_to_scalar(nir_shader *shader);
> bool nir_lower_read_invocation_to_scalar(nir_shader *shader);
> diff --git a/src/compiler/nir/nir_lower_bool_to_float.c
> b/src/compiler/nir/nir_lower_bool_to_float.c
> new file mode 100644
> index 00..2756a1815f
> --- /dev/null
> +++ b/src/compiler/nir/nir_lower_bool_to_float.c
> @@ -0,0 +1,165 @@
> +/*
> + * 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 (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"
> +
> +static bool
> +assert_ssa_def_is_not_1bit(nir_ssa_def *def, UNUSED void *unused)
> +{
> + assert(def->bit_size > 1);
> + return true;
> +}
> +
> +static bool
> +rewrite_1bit_ssa_def_to_32bit(nir_ssa_def *def, void *_progress)
> +{
> + bool *progress = _progress;
> + if (def->bit_size == 1) {
> + def->bit_size = 32;
> + *progress = true;
> + }
> + return true;
> +}
> +
> +static bool
> +lower_alu_instr(nir_alu_instr *alu)
> +{
> + const nir_op_info *op_info = _op_infos[alu->op];
> +
> + switch (alu->op) {
> + case nir_op_vec2:
> + case nir_op_vec3:
> + case nir_op_vec4:
> + /* These we expect to have booleans but the opcode doesn't change */
> + break;
> +
> + case nir_op_b2f32: alu->op = nir_op_fmov; break;
> +
> + /* Note: we only expect these 5 opcodes with bools */
> + case nir_op_imov: alu->op = nir_op_fmov; break;
> + case nir_op_inot: alu->op = nir_op_fnot; break;
> + case nir_op_iand: alu->op = nir_op_fand; break;
> + case nir_op_ior: alu->op = nir_op_for;
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wednesday, December 19, 2018 8:10:49 AM PST Eric Engestrom wrote: > The point of this patch is for people to not be able to ignore this, and > have to become aware of the existence of Meson and our intention to > remove autotools, whenever this may happen. > > Some people have already noticed, probably because they keep up with > mesa-dev@, but the point is that some people haven't. > > Without this patch: > - people will continue being unaware, until > - autotools gets removed, and these people are going to try their > use-cases, and probably find issues > - issues will get fixed, hopefully quickly, but blocking them completely > in the mean time > > With this patch: > - people will *have to notice* that something's changing > - they'll choose to either ignore it, use the flag, and *choose* to go > with the option above > - or they can choose to try meson, get any issues fixed *while still > being able to work with their old setup in the mean time* > > This last bit is the entire point of this patch, so let me repeat it: > people will report meson issues while there's still time to use their > old autotools setup. > > I'm definitely in favour: > Acked-by: Eric Engestrom Eric's reasoning here makes sense. In case there is anyone out there who has been putting off trying Meson, this will properly exhort them to try it, and identify any problems, yet still let them continue using their old system for a little while longer. Acked-by: Kenneth Graunke I've been using Meson for a long time, and it is dramatically better to work with - both to write, and to use. It is a little bit different, and that took some getting used to. But it was absolutely worth it. We need a way to make progress here. Matt's concern is very valid - people can simply keep moving the goal posts. And that's incredibly frustrating for the people doing the work. Given that we've had the Meson build system for over a year, I think time is up. Marek once received review feedback to a patch a year after he wrote it, and he responded with something like "I've moved on, feel free to write a patch." I think that applies here. The Meson build has had many contributors at this point. If it's not good enough, feel free to help fix it. It's worth noting that it is good enough for the major distros, which have switched, and a large portion of the community uses it exclusively. Dylan has done a ton of work to upstream Meson to address our needs and improve the usability of the project. The rest of the Meson developers have been very responsible as well. We have every reason to believe it will keep getting better. We can't keep kicking the autotools can down the road indefinitely. We need a forcing function like this patch, then eventual removal. Expecting new contributors to write 4 build systems is just...bad. I'm hopeful that we can get down to two (Meson and Android) soon. For what it's worth, I'm hoping to merge Iris soon, and it does not have an autotools build system, nor do I intend to write one. At that point, you won't be able to build the new Intel OpenGL drivers with autotools. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny wrote: > > Since Meson will eventually be the only build system deprecate autotools > now. It can still be used by invoking configure with the flag > --enable-autotools > > Signed-off-by: Gert Wollny In case it's not clear from the later discussion: Strongly NAKed-by: Ilia Mirkin This should not be applied to the repository. > --- > IMO autotools should be properly deprecated prior it its removal, so here > is a patch to do just that. I think autotools should be marked as deprecated > for the 19.0 release and, depending on feedback, it could be removed with > 19.1. > Anyway, in the end it's up to the release team how to handle this. > > Best, > Gert > > configure.ac | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/configure.ac b/configure.ac > index 9b437a252c..73f5978bb7 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -52,6 +52,19 @@ mingw*) > ;; > esac > > +AC_ARG_ENABLE(autotools, > + [AS_HELP_STRING([--enable-autotools], > + [Enable the use of this autotools based build > configuration])], > + [enable_autotools=$enableval], [enable_autotools=no]) > + > +if test "x$enable_autotools" != "xyes" ; then > +AC_MSG_ERROR([the autotools build system has been deprecated in favour of > +meson and will be removed eventually. For instructions on how to use > meson > +see https://www.mesa3d.org/meson.html. > +If you still want to use the autotools build, then add --enable-autotools > +to the configure command line.]) > +fi > + > # Support silent build rules, requires at least automake-1.11. Disable > # by either passing --disable-silent-rules to configure or passing V=1 > # to make > -- > 2.19.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 12:15 PM Matt Turner wrote: > > On Wed, Dec 19, 2018 at 12:06 PM Ilia Mirkin wrote: > > > We're simply trying to get the feedback from users sooner. And the > > > cost to you is very small: Use an extra flag. It's not a burden. > > > > Before the community is happy? Premature. The way you build consensus > > for a new thing is not by shooting the old thing in the foot. That > > just encourages me to pick up a shotgun too. > > This reply has convinced me that you're not to be reasoned with. Funny - this is where I'm tending towards with the whole meson effort. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 12:06 PM Ilia Mirkin wrote: > > We're simply trying to get the feedback from users sooner. And the > > cost to you is very small: Use an extra flag. It's not a burden. > > Before the community is happy? Premature. The way you build consensus > for a new thing is not by shooting the old thing in the foot. That > just encourages me to pick up a shotgun too. This reply has convinced me that you're not to be reasoned with. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: drop the amdgpu-skip-threshold=1 workaround for LLVM 8
This workaround has been introduced by 135e4d434f6 for fixing
DXVK GPU hangs with many games. It is no longer needed since
LLVM r345718.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 2eb5164ac97..5c72890aa8e 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -548,9 +548,15 @@ static void radv_init_llvm_target()
*
* "mesa" is the prefix for error messages.
*/
- const char *argv[3] = { "mesa", "-simplifycfg-sink-common=false",
- "-amdgpu-skip-threshold=1" };
- LLVMParseCommandLineOptions(3, argv, NULL);
+ if (HAVE_LLVM >= 0x0800) {
+ const char *argv[2] = { "mesa",
"-simplifycfg-sink-common=false" };
+ LLVMParseCommandLineOptions(2, argv, NULL);
+
+ } else {
+ const char *argv[3] = { "mesa",
"-simplifycfg-sink-common=false",
+ "-amdgpu-skip-threshold=1" };
+ LLVMParseCommandLineOptions(3, argv, NULL);
+ }
}
static once_flag radv_init_llvm_target_once_flag = ONCE_FLAG_INIT;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 11:12 AM Matt Turner wrote: > Regardless of all of that, what you're suggesting is only marking > autotools as deprecated (i.e., this patch) after all known problems > with the Meson build are fixed. At that point in 3 months down the > line if we get another bug report from a user that only learned of > Meson from this patch, you're going to advocate for keeping autotools > for another release. Rinse, repeat. It's a multi-step process. > > We're simply trying to get the feedback from users sooner. And the > cost to you is very small: Use an extra flag. It's not a burden. Before the community is happy? Premature. The way you build consensus for a new thing is not by shooting the old thing in the foot. That just encourages me to pick up a shotgun too. You want something in the final banner that configure prints out about suggesting users try out meson? Fine by me. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ac/nir: remove the bitfield_extract workaround for LLVM 8
This workaround has been introduced by 3d41757788a and it
is no longer needed since LLVM r346422.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 225c930d896..81b76f65b82 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -429,16 +429,22 @@ static LLVMValueRef emit_bitfield_extract(struct
ac_llvm_context *ctx,
{
LLVMValueRef result;
- /* FIXME: LLVM 7+ returns incorrect result when count is 0.
-* https://bugs.freedesktop.org/show_bug.cgi?id=107276
-*/
- LLVMValueRef zero = ctx->i32_0;
- LLVMValueRef icond1 = LLVMBuildICmp(ctx->builder, LLVMIntEQ, srcs[2],
LLVMConstInt(ctx->i32, 32, false), "");
- LLVMValueRef icond2 = LLVMBuildICmp(ctx->builder, LLVMIntEQ, srcs[2],
zero, "");
+ if (HAVE_LLVM >= 0x0800) {
+ LLVMValueRef icond = LLVMBuildICmp(ctx->builder, LLVMIntEQ,
srcs[2], LLVMConstInt(ctx->i32, 32, false), "");
+ result = ac_build_bfe(ctx, srcs[0], srcs[1], srcs[2],
is_signed);
+ result = LLVMBuildSelect(ctx->builder, icond, srcs[0], result,
"");
+ } else {
+ /* FIXME: LLVM 7+ returns incorrect result when count is 0.
+* https://bugs.freedesktop.org/show_bug.cgi?id=107276
+*/
+ LLVMValueRef zero = ctx->i32_0;
+ LLVMValueRef icond1 = LLVMBuildICmp(ctx->builder, LLVMIntEQ,
srcs[2], LLVMConstInt(ctx->i32, 32, false), "");
+ LLVMValueRef icond2 = LLVMBuildICmp(ctx->builder, LLVMIntEQ,
srcs[2], zero, "");
- result = ac_build_bfe(ctx, srcs[0], srcs[1], srcs[2], is_signed);
- result = LLVMBuildSelect(ctx->builder, icond1, srcs[0], result, "");
- result = LLVMBuildSelect(ctx->builder, icond2, zero, result, "");
+ result = ac_build_bfe(ctx, srcs[0], srcs[1], srcs[2],
is_signed);
+ result = LLVMBuildSelect(ctx->builder, icond1, srcs[0], result,
"");
+ result = LLVMBuildSelect(ctx->builder, icond2, zero, result,
"");
+ }
return result;
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: allow glDrawElements to work with GL_SELECT feedback
Fix looks good to me.
Reviewed-by: Roland Scheidegger
Am 19.12.18 um 04:50 schrieb Ilia Mirkin:
> Not sure if this ever worked, but the current logic for setting the
> min/max index is definitely wrong for indexed draws. While we're at it,
> bring in all the usual logic from the non-indirect drawing path.
>
> Bugzilla:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109086data=02%7C01%7Csroland%40vmware.com%7C6caf58471242445a386a08d665652d9a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636807882600665064sdata=YCu%2FJsZbUMvGJsiVDW916xYWVbY8P3hCh%2BADCVU%2BiDk%3Dreserved=0
> Signed-off-by: Ilia Mirkin
> ---
>
> This makes it more or less mirror st_draw_vbo. As the comment in the
> code says, would be nice to refactor, but ... meh.
>
> Note that I haven't tested any of the interactions with additional
> features, like primitive restart or instancing or any of that. However I
> don't think that this would make things *worse*.
>
> src/mesa/state_tracker/st_draw_feedback.c | 61 +++
> 1 file changed, 39 insertions(+), 22 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_draw_feedback.c
> b/src/mesa/state_tracker/st_draw_feedback.c
> index 6ec6d5c16f4..49fdecf7e38 100644
> --- a/src/mesa/state_tracker/st_draw_feedback.c
> +++ b/src/mesa/state_tracker/st_draw_feedback.c
> @@ -84,27 +84,6 @@ set_feedback_vertex_format(struct gl_context *ctx)
> }
>
>
> -/**
> - * Helper for drawing current vertex arrays.
> - */
> -static void
> -draw_arrays(struct draw_context *draw, unsigned mode,
> -unsigned start, unsigned count)
> -{
> - struct pipe_draw_info info;
> -
> - util_draw_init_info();
> -
> - info.mode = mode;
> - info.start = start;
> - info.count = count;
> - info.min_index = start;
> - info.max_index = start + count - 1;
> -
> - draw_vbo(draw, );
> -}
> -
> -
> /**
> * Called by VBO to draw arrays when in selection or feedback mode and
> * to implement glRasterPos.
> @@ -136,10 +115,18 @@ st_feedback_draw_vbo(struct gl_context *ctx,
> struct pipe_transfer *ib_transfer = NULL;
> GLuint i;
> const void *mapped_indices = NULL;
> + struct pipe_draw_info info;
>
> if (!draw)
>return;
>
> + /* Initialize pipe_draw_info. */
> + info.primitive_restart = false;
> + info.vertices_per_patch = ctx->TessCtrlProgram.patch_vertices;
> + info.indirect = NULL;
> + info.count_from_stream_output = NULL;
> + info.restart_index = 0;
> +
> st_flush_bitmap_cache(st);
> st_invalidate_readpix_cache(st);
>
> @@ -213,9 +200,23 @@ st_feedback_draw_vbo(struct gl_context *ctx,
> mapped_indices = ib->ptr;
>}
>
> + info.index_size = ib->index_size;
> + info.min_index = min_index;
> + info.max_index = max_index;
> + info.has_user_indices = true;
> + info.index.user = mapped_indices;
> +
>draw_set_indexes(draw,
> (ubyte *) mapped_indices,
> index_size, ~0);
> +
> + if (ctx->Array._PrimitiveRestart) {
> + info.primitive_restart = true;
> + info.restart_index = _mesa_primitive_restart_index(ctx,
> info.index_size);
> + }
> + } else {
> + info.index_size = 0;
> + info.has_user_indices = false;
> }
>
> /* set the constant buffer */
> @@ -226,7 +227,23 @@ st_feedback_draw_vbo(struct gl_context *ctx,
>
> /* draw here */
> for (i = 0; i < nr_prims; i++) {
> - draw_arrays(draw, prims[i].mode, start + prims[i].start,
> prims[i].count);
> + info.count = prims[i].count;
> +
> + if (!info.count)
> + continue;
> +
> + info.mode = prims[i].mode;
> + info.start = start + prims[i].start;
> + info.start_instance = prims[i].base_instance;
> + info.instance_count = prims[i].num_instances;
> + info.index_bias = prims[i].basevertex;
> + info.drawid = prims[i].draw_id;
> + if (!ib) {
> + info.min_index = info.start;
> + info.max_index = info.start + info.count - 1;
> + }
> +
> + draw_vbo(draw, );
> }
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/16] freedreno: a2xx: use fd_resource_offset for base in emit_texture
Fixup for the texture update patch. Signed-off-by: Jonathan Marek --- src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c index ce275a78a6..ac2a02dfae 100644 --- a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c +++ b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c @@ -137,7 +137,7 @@ emit_texture(struct fd_ringbuffer *ring, struct fd_context *ctx, OUT_RING(ring, sampler->tex0 | view->tex0); if (rsc) - OUT_RELOC(ring, rsc->bo, 0, view->tex1, 0); + OUT_RELOC(ring, rsc->bo, fd_resource_offset(rsc, 0, 0), view->tex1, 0); else OUT_RING(ring, 0); -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/16] freedreno: a2xx: sysmem rendering
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_gmem.c | 62 +++
1 file changed, 62 insertions(+)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
b/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
index d9aad16b4a..77c8d80055 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
@@ -367,6 +367,67 @@ fd2_emit_tile_mem2gmem(struct fd_batch *batch, struct
fd_tile *tile)
/* TODO blob driver seems to toss in a CACHE_FLUSH after each
DRAW_INDX.. */
}
+static void
+fd2_emit_sysmem_prep(struct fd_batch *batch)
+{
+ struct fd_context *ctx = batch->ctx;
+ struct fd_ringbuffer *ring = batch->gmem;
+ struct pipe_framebuffer_state *pfb = >framebuffer;
+ struct pipe_surface *psurf = pfb->cbufs[0];
+
+ if (!psurf)
+ return;
+
+ struct fd_resource *rsc = fd_resource(psurf->texture);
+ struct fd_resource_slice *slice =
+ fd_resource_slice(rsc, psurf->u.tex.level);
+ uint32_t offset =
+ fd_resource_offset(rsc, psurf->u.tex.level,
psurf->u.tex.first_layer);
+
+ assert((slice->pitch & 31) == 0);
+ assert((offset & 0xfff) == 0);
+
+ fd2_emit_restore(ctx, ring);
+
+ OUT_PKT0(ring, REG_A2XX_COHER_SIZE_PM4, 1);
+ OUT_RING(ring, slice->size0);
+ OUT_PKT0(ring, REG_A2XX_COHER_STATUS_PM4, 1);
+ OUT_RING(ring, 0x02000200);
+ OUT_PKT0(ring, REG_A2XX_COHER_BASE_PM4, 1);
+ OUT_RELOCW(ring, rsc->bo, offset, 0, 0);
+
+ OUT_PKT3(ring, CP_WAIT_REG_EQ, 4);
+ OUT_RING(ring, REG_A2XX_COHER_STATUS_PM4);
+ OUT_RING(ring, 0);
+ OUT_RING(ring, 0x8000);
+ OUT_RING(ring, 1);
+
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_RB_SURFACE_INFO));
+ OUT_RING(ring, A2XX_RB_SURFACE_INFO_SURFACE_PITCH(slice->pitch));
+
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_RB_COLOR_INFO));
+ OUT_RELOCW(ring, rsc->bo, offset, A2XX_RB_COLOR_INFO_LINEAR |
+ A2XX_RB_COLOR_INFO_SWAP(fmt2swap(psurf->format)) |
+ A2XX_RB_COLOR_INFO_FORMAT(fd2_pipe2color(psurf->format)), 0);
+
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_COHER_DEST_BASE_0));
+ OUT_RELOCW(ring, rsc->bo, offset, 0, 0);
+
+ OUT_PKT3(ring, CP_SET_CONSTANT, 3);
+ OUT_RING(ring, CP_REG(REG_A2XX_PA_SC_SCREEN_SCISSOR_TL));
+ OUT_RING(ring, A2XX_PA_SC_SCREEN_SCISSOR_TL_WINDOW_OFFSET_DISABLE);
+ OUT_RING(ring, A2XX_PA_SC_SCREEN_SCISSOR_BR_X(pfb->width) |
+ A2XX_PA_SC_SCREEN_SCISSOR_BR_Y(pfb->height));
+
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_PA_SC_WINDOW_OFFSET));
+ OUT_RING(ring, A2XX_PA_SC_WINDOW_OFFSET_X(0) |
+ A2XX_PA_SC_WINDOW_OFFSET_Y(0));
+}
+
/* before first tile */
static void
fd2_emit_tile_init(struct fd_batch *batch)
@@ -440,6 +501,7 @@ fd2_gmem_init(struct pipe_context *pctx)
{
struct fd_context *ctx = fd_context(pctx);
+ ctx->emit_sysmem_prep = fd2_emit_sysmem_prep;
ctx->emit_tile_init = fd2_emit_tile_init;
ctx->emit_tile_prep = fd2_emit_tile_prep;
ctx->emit_tile_mem2gmem = fd2_emit_tile_mem2gmem;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/16] freedreno: a2xx: a20x hw binning
---
src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 32 +++-
src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 52 ++
src/gallium/drivers/freedreno/a2xx/fd2_emit.h | 3 +-
src/gallium/drivers/freedreno/a2xx/fd2_gmem.c | 150 ++
.../drivers/freedreno/a2xx/fd2_program.c | 11 +-
.../drivers/freedreno/freedreno_batch.c | 3 +
.../drivers/freedreno/freedreno_batch.h | 7 +
.../drivers/freedreno/freedreno_draw.h| 3 +
.../drivers/freedreno/freedreno_gmem.c| 29 +++-
.../drivers/freedreno/freedreno_gmem.h| 1 +
.../drivers/freedreno/freedreno_screen.h | 6 +
11 files changed, 281 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
index 4e91267080..d3e440d144 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
@@ -75,11 +75,12 @@ emit_vertexbufs(struct fd_context *ctx)
// CONST(20,0) (or CONST(26,0) in soliv_vp)
fd2_emit_vertex_bufs(ctx->batch->draw, 0x78, bufs, vtx->num_elements);
+ fd2_emit_vertex_bufs(ctx->batch->binning, 0x78, bufs,
vtx->num_elements);
}
static void
draw_impl(struct fd_context *ctx, const struct pipe_draw_info *info,
- struct fd_ringbuffer *ring, unsigned index_offset)
+ struct fd_ringbuffer *ring, unsigned index_offset, bool
binning)
{
OUT_PKT3(ring, CP_SET_CONSTANT, 2);
OUT_RING(ring, CP_REG(REG_A2XX_VGT_INDX_OFFSET));
@@ -119,8 +120,22 @@ draw_impl(struct fd_context *ctx, const struct
pipe_draw_info *info,
OUT_RING(ring, info->min_index);/* VGT_MIN_VTX_INDX */
}
+ /* binning shader will take offset from C64 */
+ if (binning && is_a20x(ctx->screen)) {
+ OUT_PKT3(ring, CP_SET_CONSTANT, 5);
+ OUT_RING(ring, 0x0180);
+ OUT_RING(ring, fui(ctx->batch->num_vertices));
+ OUT_RING(ring, fui(0.0f));
+ OUT_RING(ring, fui(0.0f));
+ OUT_RING(ring, fui(0.0f));
+ }
+
+ enum pc_di_vis_cull_mode vismode = USE_VISIBILITY;
+ if (binning || info->mode == PIPE_PRIM_POINTS)
+ vismode = IGNORE_VISIBILITY;
+
fd_draw_emit(ctx->batch, ring, ctx->primtypes[info->mode],
-IGNORE_VISIBILITY, info, index_offset);
+vismode, info, index_offset);
if (is_a20x(ctx->screen)) {
/* not sure why this is required, but it fixes some hangs */
@@ -145,6 +160,9 @@ fd2_draw_vbo(struct fd_context *ctx, const struct
pipe_draw_info *pinfo,
if (ctx->dirty & FD_DIRTY_VTXBUF)
emit_vertexbufs(ctx);
+ if (!(fd_mesa_debug & FD_DBG_NOBIN))
+ fd2_emit_state_binning(ctx, ctx->dirty);
+
fd2_emit_state(ctx, ctx->dirty);
/* a2xx can draw only 65535 vertices at once
@@ -166,17 +184,23 @@ fd2_draw_vbo(struct fd_context *ctx, const struct
pipe_draw_info *pinfo,
struct pipe_draw_info info = *pinfo;
unsigned count = info.count;
unsigned step = step_tbl[info.mode];
+ unsigned num_vertices = ctx->batch->num_vertices;
if (!step)
return false;
for (; count + step > 32766; count -= step) {
info.count = MIN2(count, 32766);
- draw_impl(ctx, , ctx->batch->draw, index_offset);
+ draw_impl(ctx, , ctx->batch->draw, index_offset,
false);
+ draw_impl(ctx, , ctx->batch->binning,
index_offset, true);
info.start += step;
+ ctx->batch->num_vertices += step;
}
+ /* changing this value is a hack, restore it */
+ ctx->batch->num_vertices = num_vertices;
} else {
- draw_impl(ctx, pinfo, ctx->batch->draw, index_offset);
+ draw_impl(ctx, pinfo, ctx->batch->draw, index_offset, false);
+ draw_impl(ctx, pinfo, ctx->batch->binning, index_offset, true);
}
fd_context_all_clean(ctx);
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
index 9628f26736..7371fa6e8c 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
@@ -185,6 +185,58 @@ fd2_emit_vertex_bufs(struct fd_ringbuffer *ring, uint32_t
val,
}
}
+void
+fd2_emit_state_binning(struct fd_context *ctx, const enum fd_dirty_3d_state
dirty)
+{
+ struct fd2_blend_stateobj *blend = fd2_blend_stateobj(ctx->blend);
+ struct fd_ringbuffer *ring = ctx->batch->binning;
+
+ /* subset of fd2_emit_state needed for hw binning on a20x */
+
+ if (dirty & (FD_DIRTY_PROG | FD_DIRTY_VTXSTATE))
+
[Mesa-dev] [PATCH 07/16] freedreno: a2xx: improve REG_A2XX_PA_CL_VTE_CNTL management
Doesn't change much, but reduces the size of fd2_emit_state
gmem2mem does not need to change the value: no Z clipping on resolve
mem2gmem now needs to restore the common value after rendering
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 20 +--
src/gallium/drivers/freedreno/a2xx/fd2_gmem.c | 18 +
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
index 60bc9fad4c..7dcd31cbcb 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
@@ -272,16 +272,6 @@ fd2_emit_state(struct fd_context *ctx, const enum
fd_dirty_3d_state dirty)
OUT_RING(ring, fui(ctx->viewport.translate[1])); /*
PA_CL_VPORT_YOFFSET */
OUT_RING(ring, fui(ctx->viewport.scale[2])); /*
PA_CL_VPORT_ZSCALE */
OUT_RING(ring, fui(ctx->viewport.translate[2])); /*
PA_CL_VPORT_ZOFFSET */
-
- OUT_PKT3(ring, CP_SET_CONSTANT, 2);
- OUT_RING(ring, CP_REG(REG_A2XX_PA_CL_VTE_CNTL));
- OUT_RING(ring, A2XX_PA_CL_VTE_CNTL_VTX_W0_FMT |
- A2XX_PA_CL_VTE_CNTL_VPORT_X_SCALE_ENA |
- A2XX_PA_CL_VTE_CNTL_VPORT_X_OFFSET_ENA |
- A2XX_PA_CL_VTE_CNTL_VPORT_Y_SCALE_ENA |
- A2XX_PA_CL_VTE_CNTL_VPORT_Y_OFFSET_ENA |
- A2XX_PA_CL_VTE_CNTL_VPORT_Z_SCALE_ENA |
- A2XX_PA_CL_VTE_CNTL_VPORT_Z_OFFSET_ENA);
}
if (dirty & (FD_DIRTY_PROG | FD_DIRTY_VTXSTATE | FD_DIRTY_TEXSTATE)) {
@@ -475,6 +465,16 @@ fd2_emit_restore(struct fd_context *ctx, struct
fd_ringbuffer *ring)
OUT_RING(ring, 0x);/* RB_BLEND_GREEN */
OUT_RING(ring, 0x);/* RB_BLEND_BLUE */
OUT_RING(ring, 0x00ff);/* RB_BLEND_ALPHA */
+
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_PA_CL_VTE_CNTL));
+ OUT_RING(ring, A2XX_PA_CL_VTE_CNTL_VTX_W0_FMT |
+ A2XX_PA_CL_VTE_CNTL_VPORT_X_SCALE_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_X_OFFSET_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_Y_SCALE_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_Y_OFFSET_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_Z_SCALE_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_Z_OFFSET_ENA);
}
static void
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
b/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
index e98ae7334a..3c54e2c6c0 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
@@ -156,14 +156,6 @@ fd2_emit_tile_gmem2mem(struct fd_batch *batch, struct
fd_tile *tile)
OUT_RING(ring, xy2d(0, 0)); /*
PA_SC_WINDOW_SCISSOR_TL */
OUT_RING(ring, xy2d(pfb->width, pfb->height));/*
PA_SC_WINDOW_SCISSOR_BR */
- OUT_PKT3(ring, CP_SET_CONSTANT, 2);
- OUT_RING(ring, CP_REG(REG_A2XX_PA_CL_VTE_CNTL));
- OUT_RING(ring, A2XX_PA_CL_VTE_CNTL_VTX_W0_FMT |
- A2XX_PA_CL_VTE_CNTL_VPORT_X_SCALE_ENA |
- A2XX_PA_CL_VTE_CNTL_VPORT_X_OFFSET_ENA |
- A2XX_PA_CL_VTE_CNTL_VPORT_Y_SCALE_ENA |
- A2XX_PA_CL_VTE_CNTL_VPORT_Y_OFFSET_ENA);
-
OUT_PKT3(ring, CP_SET_CONSTANT, 2);
OUT_RING(ring, CP_REG(REG_A2XX_PA_CL_CLIP_CNTL));
OUT_RING(ring, 0x);
@@ -350,6 +342,16 @@ fd2_emit_tile_mem2gmem(struct fd_batch *batch, struct
fd_tile *tile)
if (fd_gmem_needs_restore(batch, tile, FD_BUFFER_COLOR))
emit_mem2gmem_surf(batch, gmem->cbuf_base[0], pfb->cbufs[0]);
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_PA_CL_VTE_CNTL));
+ OUT_RING(ring, A2XX_PA_CL_VTE_CNTL_VTX_W0_FMT |
+ A2XX_PA_CL_VTE_CNTL_VPORT_X_SCALE_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_X_OFFSET_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_Y_SCALE_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_Y_OFFSET_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_Z_SCALE_ENA |
+ A2XX_PA_CL_VTE_CNTL_VPORT_Z_OFFSET_ENA);
+
/* TODO blob driver seems to toss in a CACHE_FLUSH after each
DRAW_INDX.. */
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/16] nir: improve convert_yuv_to_rgb when fuse_ffma=true
When ffma is available, we can use a different arrangement of constants to
get a better result. On freedreno/ir3, this reduces the YUV->RGB to 7
scalar ffma. On freedreno/a2xx, it will allow YUV->RGB to be 3 vec4 ffma.
Signed-off-by: Jonathan Marek
---
src/compiler/nir/nir_lower_tex.c | 62 ++--
1 file changed, 43 insertions(+), 19 deletions(-)
diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c
index 6a6b6c41a7..f7c821bb34 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -342,25 +342,49 @@ convert_yuv_to_rgb(nir_builder *b, nir_tex_instr *tex,
nir_ssa_def *y, nir_ssa_def *u, nir_ssa_def *v,
nir_ssa_def *a)
{
- nir_const_value m[3] = {
- { .f32 = { 1.0f, 0.0f, 1.59602678f, 0.0f } },
- { .f32 = { 1.0f, -0.39176229f, -0.81296764f, 0.0f } },
- { .f32 = { 1.0f, 2.01723214f, 0.0f,0.0f } }
- };
-
- nir_ssa_def *yuv =
- nir_vec4(b,
- nir_fmul(b, nir_imm_float(b, 1.16438356f),
-nir_fadd(b, y, nir_imm_float(b, -16.0f / 255.0f))),
- nir_channel(b, nir_fadd(b, u, nir_imm_float(b, -128.0f /
255.0f)), 0),
- nir_channel(b, nir_fadd(b, v, nir_imm_float(b, -128.0f /
255.0f)), 0),
- nir_imm_float(b, 0.0));
-
- nir_ssa_def *red = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[0]));
- nir_ssa_def *green = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[1]));
- nir_ssa_def *blue = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[2]));
-
- nir_ssa_def *result = nir_vec4(b, red, green, blue, a);
+ nir_ssa_def *result;
+
+
+ if (b->shader->options->fuse_ffma) {
+ nir_const_value m[4] = {
+ { .f32 = { 1.16438356f, 1.16438356f, 1.16438356f, 0.0f } },
+ { .f32 = { 0.0f, -0.39176229f, 2.01723214f, 0.0f } },
+ { .f32 = { 1.59602678f,-0.81296764f, 0.0f,0.0f } },
+ };
+ static const float y_off = -16.0f * 1.16438356f / 255.0f;
+ static const float sc = 128.0f / 255.0f;
+
+ nir_ssa_def *offset =
+ nir_vec4(b,
+ nir_imm_float(b, y_off - sc * 1.59602678f),
+ nir_imm_float(b, y_off + sc * (0.81296764f + 0.39176229f)),
+ nir_imm_float(b, y_off - sc * 2.01723214f),
+ a);
+
+ result = nir_ffma(b, y, nir_build_imm(b, 4, 32, m[0]),
+ nir_ffma(b, u, nir_build_imm(b, 4, 32, m[1]),
+nir_ffma(b, v, nir_build_imm(b, 4, 32, m[2]),
offset)));
+ } else {
+ nir_const_value m[3] = {
+ { .f32 = { 1.0f, 0.0f, 1.59602678f, 0.0f } },
+ { .f32 = { 1.0f, -0.39176229f, -0.81296764f, 0.0f } },
+ { .f32 = { 1.0f, 2.01723214f, 0.0f,0.0f } }
+ };
+
+ nir_ssa_def *yuv =
+ nir_vec4(b,
+ nir_fmul(b, nir_imm_float(b, 1.16438356f),
+ nir_fadd(b, y, nir_imm_float(b, -16.0f / 255.0f))),
+ nir_channel(b, nir_fadd(b, u, nir_imm_float(b, -128.0f /
255.0f)), 0),
+ nir_channel(b, nir_fadd(b, v, nir_imm_float(b, -128.0f /
255.0f)), 0),
+ nir_imm_float(b, 0.0));
+
+ nir_ssa_def *red = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[0]));
+ nir_ssa_def *green = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[1]));
+ nir_ssa_def *blue = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[2]));
+
+ result = nir_vec4(b, red, green, blue, a);
+ }
nir_ssa_def_rewrite_uses(>dest.ssa, nir_src_for_ssa(result));
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/16] nir: combine fmul and fadd across ffma operations
This works by moving the fadd up across the ffma operations, so that it
can eventually can be combined with a fmul. I'm not sure it works in all
cases, but it works in all the common cases.
This will only affect freedreno since it is the only driver using the
fuse_ffma option.
Example:
matrix * vec4(coord, 1.0)
is compiled as:
fmul, ffma, ffma, fadd
and with this patch:
ffma, ffma, ffma
Signed-off-by: Jonathan Marek
---
src/compiler/nir/nir_opt_algebraic.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index 506d45e55b..97a6c0d8dc 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -137,6 +137,7 @@ optimizations = [
(('~fadd@64', a, ('fmul', c , ('fadd', b, ('fneg', a, ('flrp',
a, b, c), '!options->lower_flrp64'),
(('ffma', a, b, c), ('fadd', ('fmul', a, b), c), 'options->lower_ffma'),
(('~fadd', ('fmul', a, b), c), ('ffma', a, b, c), 'options->fuse_ffma'),
+ (('~fadd', ('ffma', a, b, c), d), ('ffma', a, b, ('fadd', c, d)),
'options->fuse_ffma'),
(('fdot4', ('vec4', a, b, c, 1.0), d), ('fdph', ('vec3', a, b, c), d)),
(('fdot4', ('vec4', a, 0.0, 0.0, 0.0), b), ('fmul', a, b)),
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/16] freedreno: a2xx: add partial lower_scalar pass for ir2
Some instructions can only be scalar on a2xx, lower these only
Signed-off-by: Jonathan Marek
---
.../drivers/freedreno/Makefile.sources| 1 +
src/gallium/drivers/freedreno/a2xx/ir2_nir.c | 3 +
.../freedreno/a2xx/ir2_nir_lower_scalar.c | 174 ++
.../drivers/freedreno/a2xx/ir2_private.h | 1 +
src/gallium/drivers/freedreno/meson.build | 1 +
5 files changed, 180 insertions(+)
create mode 100644 src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
diff --git a/src/gallium/drivers/freedreno/Makefile.sources
b/src/gallium/drivers/freedreno/Makefile.sources
index f4979953e8..fed5b5bd17 100644
--- a/src/gallium/drivers/freedreno/Makefile.sources
+++ b/src/gallium/drivers/freedreno/Makefile.sources
@@ -73,6 +73,7 @@ a2xx_SOURCES := \
a2xx/ir2_assemble.c \
a2xx/ir2_cp.c \
a2xx/ir2_nir.c \
+ a2xx/ir2_nir_lower_scalar.c \
a2xx/ir2_private.h \
a2xx/ir2_ra.c
diff --git a/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
b/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
index 8162479341..10fa0c765f 100644
--- a/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
+++ b/src/gallium/drivers/freedreno/a2xx/ir2_nir.c
@@ -1124,6 +1124,9 @@ ir2_nir_compile(struct ir2_context *ctx, bool binning)
OPT_V(ctx->nir, nir_lower_bool_to_float);
+ /* lower to scalar instructions that can only be scalar on a2xx */
+ OPT_V(ctx->nir, ir2_nir_lower_scalar);
+
OPT_V(ctx->nir, nir_lower_locals_to_regs);
OPT_V(ctx->nir, nir_convert_from_ssa, true);
diff --git a/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
b/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
new file mode 100644
index 00..2b72a86b3e
--- /dev/null
+++ b/src/gallium/drivers/freedreno/a2xx/ir2_nir_lower_scalar.c
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2018 Jonathan Marek
+ *
+ * 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.
+ *
+ * Authors:
+ *Jonathan Marek
+ */
+
+/* some operations can only be scalar on a2xx:
+ * rsq, rcp, log2, exp2, cos, sin, sqrt
+ * mostly copy-pasted from nir_lower_alu_to_scalar.c
+ */
+
+#include "ir2_private.h"
+#include "compiler/nir/nir_builder.h"
+
+static void
+nir_alu_ssa_dest_init(nir_alu_instr * instr, unsigned num_components,
+ unsigned bit_size)
+{
+ nir_ssa_dest_init(>instr, >dest.dest, num_components,
+ bit_size, NULL);
+ instr->dest.write_mask = (1 << num_components) - 1;
+}
+
+static void
+lower_reduction(nir_alu_instr * instr, nir_op chan_op, nir_op merge_op,
+ nir_builder * builder)
+{
+ unsigned num_components = nir_op_infos[instr->op].input_sizes[0];
+
+ nir_ssa_def *last = NULL;
+ for (unsigned i = 0; i < num_components; i++) {
+ nir_alu_instr *chan =
+ nir_alu_instr_create(builder->shader, chan_op);
+ nir_alu_ssa_dest_init(chan, 1, instr->dest.dest.ssa.bit_size);
+ nir_alu_src_copy(>src[0], >src[0], chan);
+ chan->src[0].swizzle[0] = chan->src[0].swizzle[i];
+ if (nir_op_infos[chan_op].num_inputs > 1) {
+ assert(nir_op_infos[chan_op].num_inputs == 2);
+ nir_alu_src_copy(>src[1], >src[1], chan);
+ chan->src[1].swizzle[0] = chan->src[1].swizzle[i];
+ }
+ chan->exact = instr->exact;
+
+ nir_builder_instr_insert(builder, >instr);
+
+ if (i == 0) {
+ last = >dest.dest.ssa;
+ } else {
+ last = nir_build_alu(builder, merge_op,
+last,
>dest.dest.ssa, NULL, NULL);
+ }
+ }
+
+ assert(instr->dest.write_mask == 1);
+
[Mesa-dev] [PATCH 14/16] freedreno: a2xx: add ir2 copy propagation
Two cases:
* replacing srcs which refer to MOV instructions
* replacing MOVs used to write to exports
Signed-off-by: Jonathan Marek
---
.../drivers/freedreno/Makefile.sources| 1 +
src/gallium/drivers/freedreno/a2xx/ir2.c | 6 +
src/gallium/drivers/freedreno/a2xx/ir2_cp.c | 225 ++
.../drivers/freedreno/a2xx/ir2_private.h | 3 +
src/gallium/drivers/freedreno/meson.build | 1 +
5 files changed, 236 insertions(+)
create mode 100644 src/gallium/drivers/freedreno/a2xx/ir2_cp.c
diff --git a/src/gallium/drivers/freedreno/Makefile.sources
b/src/gallium/drivers/freedreno/Makefile.sources
index 8421318081..f4979953e8 100644
--- a/src/gallium/drivers/freedreno/Makefile.sources
+++ b/src/gallium/drivers/freedreno/Makefile.sources
@@ -71,6 +71,7 @@ a2xx_SOURCES := \
a2xx/ir2.c \
a2xx/ir2.h \
a2xx/ir2_assemble.c \
+ a2xx/ir2_cp.c \
a2xx/ir2_nir.c \
a2xx/ir2_private.h \
a2xx/ir2_ra.c
diff --git a/src/gallium/drivers/freedreno/a2xx/ir2.c
b/src/gallium/drivers/freedreno/a2xx/ir2.c
index 344f62defe..bc1d7c23b8 100644
--- a/src/gallium/drivers/freedreno/a2xx/ir2.c
+++ b/src/gallium/drivers/freedreno/a2xx/ir2.c
@@ -422,9 +422,15 @@ ir2_compile(struct fd2_shader_stateobj *so, unsigned
variant,
/* convert nir to internal representation */
ir2_nir_compile(, binning);
+ /* copy propagate srcs */
+ cp_src();
+
/* get ref_counts and kill non-needed instructions */
ra_count_refs();
+ /* remove movs used to write outputs */
+ cp_export();
+
/* instruction order.. and vector->scalar conversions */
schedule_instrs();
diff --git a/src/gallium/drivers/freedreno/a2xx/ir2_cp.c
b/src/gallium/drivers/freedreno/a2xx/ir2_cp.c
new file mode 100644
index 00..fa155887f8
--- /dev/null
+++ b/src/gallium/drivers/freedreno/a2xx/ir2_cp.c
@@ -0,0 +1,225 @@
+/*
+ * Copyright (C) 2018 Jonathan Marek
+ *
+ * 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.
+ *
+ * Authors:
+ *Jonathan Marek
+ */
+
+#include "ir2_private.h"
+
+static bool is_mov(struct ir2_instr *instr)
+{
+ return instr->type == IR2_ALU && instr->alu.vector_opc == MAXv &&
+ instr->src_count == 1;
+}
+
+static void src_combine(struct ir2_src *src, struct ir2_src b)
+{
+ src->num = b.num;
+ src->type = b.type;
+ src->swizzle = swiz_merge(b.swizzle, src->swizzle);
+ if (!src->abs) /* if we have abs we don't care about previous negate */
+ src->negate ^= b.negate;
+ src->abs |= b.abs;
+}
+
+/* cp_src: replace src regs when they refer to a mov instruction
+ * example:
+ * ALU: MAXvR7 = C7, C7
+ * ALU: MULADDv R7 = R7, R10, R0.
+ * becomes:
+ * ALU: MULADDv R7 = C7, R10, R0.
+ */
+void cp_src(struct ir2_context *ctx)
+{
+ struct ir2_instr *p;
+
+ ir2_foreach_instr(instr, ctx) {
+ ir2_foreach_src(src, instr) {
+ /* loop to replace recursively */
+ do {
+ if (src->type != IR2_SRC_SSA)
+ break;
+
+ p = >instr[src->num];
+ /* don't work across blocks to avoid possible
issues */
+ if (p->block_idx != instr->block_idx)
+ break;
+
+ if (!is_mov(p))
+ break;
+
+ /* cant apply abs to const src, const src only
for alu */
+ if (p->src[0].type == IR2_SRC_CONST &&
+ (src->abs || instr->type != IR2_ALU))
+ break;
+
+ src_combine(src, p->src[0]);
+
[Mesa-dev] [PATCH 10/16] freedreno: a2xx: fix VERTEX_REUSE/DEALLOC on a20x
On a20x, set VGT_VERTEX_REUSE_BLOCK_CNTL to 2 and don't change it. Small
rearrangement on a220 to reduce the size of draw commands.
Only set DEALLOC_CNTL on a20x because the correct a220 value is not known.
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 18 +++---
src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 16
src/gallium/drivers/freedreno/a2xx/fd2_gmem.c | 18 +++---
3 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
index 6dac8ca6a9..db8b022f8d 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
@@ -85,10 +85,6 @@ draw_impl(struct fd_context *ctx, const struct
pipe_draw_info *info,
OUT_RING(ring, CP_REG(REG_A2XX_VGT_INDX_OFFSET));
OUT_RING(ring, info->index_size ? 0 : info->start);
- OUT_PKT3(ring, CP_SET_CONSTANT, 2);
- OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
- OUT_RING(ring, is_a20x(ctx->screen) ? 0x0002 : 0x003b);
-
OUT_PKT0(ring, REG_A2XX_TC_CNTL_STATUS, 1);
OUT_RING(ring, A2XX_TC_CNTL_STATUS_L2_INVALIDATE);
@@ -214,9 +210,11 @@ fd2_clear(struct fd_context *ctx, unsigned buffers,
OUT_RING(ring, CP_REG(REG_A2XX_VGT_INDX_OFFSET));
OUT_RING(ring, 0);
- OUT_PKT3(ring, CP_SET_CONSTANT, 2);
- OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
- OUT_RING(ring, 0x028f);
+ if (!is_a20x(ctx->screen)) {
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
+ OUT_RING(ring, 0x028f);
+ }
fd2_program_emit(ring, >solid_prog);
@@ -357,6 +355,12 @@ fd2_clear(struct fd_context *ctx, unsigned buffers,
OUT_RING(ring, CP_REG(REG_A2XX_RB_COPY_CONTROL));
OUT_RING(ring, 0x);
+ if (!is_a20x(ctx->screen)) {
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
+ OUT_RING(ring, 0x003b);
+ }
+
ctx->dirty |= FD_DIRTY_ZSA |
FD_DIRTY_VIEWPORT |
FD_DIRTY_RASTERIZER |
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
index 7dcd31cbcb..ce275a78a6 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
@@ -341,6 +341,18 @@ fd2_emit_restore(struct fd_context *ctx, struct
fd_ringbuffer *ring)
OUT_PKT3(ring, CP_SET_CONSTANT, 2);
OUT_RING(ring, CP_REG(REG_A2XX_PA_SC_VIZ_QUERY));
OUT_RING(ring, A2XX_PA_SC_VIZ_QUERY_VIZ_QUERY_ID(16));
+
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
+ OUT_RING(ring, 0x0002);
+
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_VGT_OUT_DEALLOC_CNTL));
+ OUT_RING(ring, 0x0002);
+ } else {
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
+ OUT_RING(ring, 0x003b);
}
OUT_PKT0(ring, REG_A2XX_TP0_CHICKEN, 1);
@@ -368,10 +380,6 @@ fd2_emit_restore(struct fd_context *ctx, struct
fd_ringbuffer *ring)
OUT_RING(ring, CP_REG(REG_A2XX_VGT_INDX_OFFSET));
OUT_RING(ring, 0x);
- OUT_PKT3(ring, CP_SET_CONSTANT, 2);
- OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
- OUT_RING(ring, 0x003b);
-
OUT_PKT3(ring, CP_SET_CONSTANT, 2);
OUT_RING(ring, CP_REG(REG_A2XX_SQ_CONTEXT_MISC));
OUT_RING(ring, A2XX_SQ_CONTEXT_MISC_SC_SAMPLE_CNTL(CENTERS_ONLY));
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
b/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
index 8469e827b9..d9aad16b4a 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c
@@ -131,9 +131,11 @@ fd2_emit_tile_gmem2mem(struct fd_batch *batch, struct
fd_tile *tile)
OUT_RING(ring, CP_REG(REG_A2XX_VGT_INDX_OFFSET));
OUT_RING(ring, 0);
- OUT_PKT3(ring, CP_SET_CONSTANT, 2);
- OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
- OUT_RING(ring, 0x028f);
+ if (!is_a20x(ctx->screen)) {
+ OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+ OUT_RING(ring, CP_REG(REG_A2XX_VGT_VERTEX_REUSE_BLOCK_CNTL));
+ OUT_RING(ring, 0x028f);
+ }
fd2_program_emit(ring, >solid_prog);
@@ -186,6 +188,12 @@ fd2_emit_tile_gmem2mem(struct fd_batch *batch, struct
fd_tile *tile)
OUT_PKT3(ring, CP_SET_CONSTANT, 2);
[Mesa-dev] [PATCH 09/16] freedreno: a2xx: set viewport in gmem2mem
Fixes cases where previous viewport values might case gmem2mem to fail. Signed-off-by: Jonathan Marek --- src/gallium/drivers/freedreno/a2xx/fd2_gmem.c | 8 1 file changed, 8 insertions(+) diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c b/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c index 3c54e2c6c0..8469e827b9 100644 --- a/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c +++ b/src/gallium/drivers/freedreno/a2xx/fd2_gmem.c @@ -160,6 +160,14 @@ fd2_emit_tile_gmem2mem(struct fd_batch *batch, struct fd_tile *tile) OUT_RING(ring, CP_REG(REG_A2XX_PA_CL_CLIP_CNTL)); OUT_RING(ring, 0x); + /* make sure the rectangle covers the entire screen */ + OUT_PKT3(ring, CP_SET_CONSTANT, 5); + OUT_RING(ring, CP_REG(REG_A2XX_PA_CL_VPORT_XSCALE)); + OUT_RING(ring, fui(4096.0)); + OUT_RING(ring, fui(4096.0)); + OUT_RING(ring, fui(4096.0)); + OUT_RING(ring, fui(4096.0)); + OUT_PKT3(ring, CP_SET_CONSTANT, 2); OUT_RING(ring, CP_REG(REG_A2XX_RB_MODECONTROL)); OUT_RING(ring, A2XX_RB_MODECONTROL_EDRAM_MODE(EDRAM_COPY)); -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/16] glsl/nir: int constants as float for native_integers=false
Note: the backend must take care that uniform index is now a float
Signed-off-by: Jonathan Marek
---
src/compiler/glsl/glsl_to_nir.cpp | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index c5ba47d9e3..c8a7f3bd6c 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -94,6 +94,8 @@ private:
nir_deref_instr *evaluate_deref(ir_instruction *ir);
+ nir_constant *constant_copy(ir_constant *ir, void *mem_ctx);
+
/* most recent deref instruction created */
nir_deref_instr *deref;
@@ -194,8 +196,8 @@ nir_visitor::evaluate_deref(ir_instruction *ir)
return this->deref;
}
-static nir_constant *
-constant_copy(ir_constant *ir, void *mem_ctx)
+nir_constant *
+nir_visitor::constant_copy(ir_constant *ir, void *mem_ctx)
{
if (ir == NULL)
return NULL;
@@ -213,7 +215,10 @@ constant_copy(ir_constant *ir, void *mem_ctx)
assert(cols == 1);
for (unsigned r = 0; r < rows; r++)
- ret->values[0].u32[r] = ir->value.u[r];
+ if (supports_ints)
+ret->values[0].u32[r] = ir->value.u[r];
+ else
+ret->values[0].f32[r] = ir->value.u[r];
break;
@@ -222,7 +227,10 @@ constant_copy(ir_constant *ir, void *mem_ctx)
assert(cols == 1);
for (unsigned r = 0; r < rows; r++)
- ret->values[0].i32[r] = ir->value.i[r];
+ if (supports_ints)
+ret->values[0].i32[r] = ir->value.i[r];
+ else
+ret->values[0].f32[r] = ir->value.i[r];
break;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/16] freedreno: a2xx: enable early-Z testing
Enable earlyZ when alpha test is disabled. Signed-off-by: Jonathan Marek --- src/gallium/drivers/freedreno/a2xx/fd2_zsa.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c b/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c index 64b31b677b..d3c19b4450 100644 --- a/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c +++ b/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c @@ -49,7 +49,8 @@ fd2_zsa_state_create(struct pipe_context *pctx, A2XX_RB_DEPTHCONTROL_ZFUNC(cso->depth.func); /* maps 1:1 */ if (cso->depth.enabled) - so->rb_depthcontrol |= A2XX_RB_DEPTHCONTROL_Z_ENABLE; + so->rb_depthcontrol |= A2XX_RB_DEPTHCONTROL_Z_ENABLE | + COND(!cso->alpha.enabled, A2XX_RB_DEPTHCONTROL_EARLY_Z_ENABLE); if (cso->depth.writemask) so->rb_depthcontrol |= A2XX_RB_DEPTHCONTROL_Z_WRITE_ENABLE; -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/16] glsl/nir: keep bool types when native_integers=false
We should now lower bool to float later.
Signed-off-by: Jonathan Marek
---
src/compiler/glsl/glsl_to_nir.cpp | 175 --
1 file changed, 71 insertions(+), 104 deletions(-)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index d88289f682..29702abf75 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -86,6 +86,7 @@ private:
nir_ssa_def *src2, nir_ssa_def *src3);
bool supports_ints;
+ bool type_force_float(glsl_base_type type);
nir_shader *shader;
nir_function_impl *impl;
@@ -1261,6 +1262,12 @@ nir_visitor::visit(ir_call *ir)
unreachable("glsl_to_nir only handles function calls to intrinsics");
}
+bool
+nir_visitor::type_force_float(glsl_base_type type)
+{
+ return !supports_ints && type != GLSL_TYPE_BOOL;
+}
+
void
nir_visitor::visit(ir_assignment *ir)
{
@@ -1298,7 +1305,8 @@ nir_visitor::visit(ir_assignment *ir)
for (unsigned i = 0; i < 4; i++) {
swiz[i] = ir->write_mask & (1 << i) ? component++ : 0;
}
- src = nir_swizzle(, src, swiz, num_components, !supports_ints);
+ src = nir_swizzle(, src, swiz, num_components,
+type_force_float(ir->rhs->type->base_type));
}
if (ir->condition) {
@@ -1495,22 +1503,21 @@ nir_visitor::visit(ir_expression *ir)
srcs[i] = evaluate_rvalue(ir->operands[i]);
glsl_base_type types[4];
- for (unsigned i = 0; i < ir->num_operands; i++)
- if (supports_ints)
- types[i] = ir->operands[i]->type->base_type;
- else
+ for (unsigned i = 0; i < ir->num_operands; i++) {
+ types[i] = ir->operands[i]->type->base_type;
+ if (type_force_float(types[i]))
types[i] = GLSL_TYPE_FLOAT;
+ }
- glsl_base_type out_type;
- if (supports_ints)
- out_type = ir->type->base_type;
- else
+ glsl_base_type out_type = ir->type->base_type;
+ if (type_force_float(out_type))
out_type = GLSL_TYPE_FLOAT;
switch (ir->operation) {
case ir_unop_bit_not: result = nir_inot(, srcs[0]); break;
case ir_unop_logic_not:
- result = supports_ints ? nir_inot(, srcs[0]) : nir_fnot(, srcs[0]);
+ result = type_is_float(types[0]) ? nir_fnot(, srcs[0])
+ : nir_inot(, srcs[0]);
break;
case ir_unop_neg:
result = type_is_float(types[0]) ? nir_fneg(, srcs[0])
@@ -1542,7 +1549,7 @@ nir_visitor::visit(ir_expression *ir)
result = supports_ints ? nir_u2f32(, srcs[0]) : nir_fmov(, srcs[0]);
break;
case ir_unop_b2f:
- result = supports_ints ? nir_b2f32(, srcs[0]) : nir_fmov(, srcs[0]);
+ result = nir_b2f32(, srcs[0]);
break;
case ir_unop_f2i:
case ir_unop_f2u:
@@ -1788,16 +1795,16 @@ nir_visitor::visit(ir_expression *ir)
case ir_binop_bit_or: result = nir_ior(, srcs[0], srcs[1]); break;
case ir_binop_bit_xor: result = nir_ixor(, srcs[0], srcs[1]); break;
case ir_binop_logic_and:
- result = supports_ints ? nir_iand(, srcs[0], srcs[1])
- : nir_fand(, srcs[0], srcs[1]);
+ result = type_is_float(types[0]) ? nir_fand(, srcs[0], srcs[1])
+ : nir_iand(, srcs[0], srcs[1]);
break;
case ir_binop_logic_or:
- result = supports_ints ? nir_ior(, srcs[0], srcs[1])
- : nir_for(, srcs[0], srcs[1]);
+ result = type_is_float(types[0]) ? nir_for(, srcs[0], srcs[1])
+ : nir_ior(, srcs[0], srcs[1]);
break;
case ir_binop_logic_xor:
- result = supports_ints ? nir_ixor(, srcs[0], srcs[1])
- : nir_fxor(, srcs[0], srcs[1]);
+ result = type_is_float(types[0]) ? nir_fxor(, srcs[0], srcs[1])
+ : nir_ixor(, srcs[0], srcs[1]);
break;
case ir_binop_lshift: result = nir_ishl(, srcs[0], srcs[1]); break;
case ir_binop_rshift:
@@ -1811,108 +1818,70 @@ nir_visitor::visit(ir_expression *ir)
case ir_binop_carry: result = nir_uadd_carry(, srcs[0], srcs[1]); break;
case ir_binop_borrow: result = nir_usub_borrow(, srcs[0], srcs[1]); break;
case ir_binop_less:
- if (supports_ints) {
- if (type_is_float(types[0]))
-result = nir_flt(, srcs[0], srcs[1]);
- else if (type_is_signed(types[0]))
-result = nir_ilt(, srcs[0], srcs[1]);
- else
-result = nir_ult(, srcs[0], srcs[1]);
- } else {
- result = nir_slt(, srcs[0], srcs[1]);
- }
+ if (type_is_float(types[0]))
+ result = nir_flt(, srcs[0], srcs[1]);
+ else if (type_is_signed(types[0]))
+ result = nir_ilt(, srcs[0], srcs[1]);
+ else
+ result = nir_ult(, srcs[0], srcs[1]);
break;
case ir_binop_gequal:
- if (supports_ints) {
- if (type_is_float(types[0]))
-result = nir_fge(, srcs[0],
[Mesa-dev] [PATCH 04/16] nir: add nir_lower_bool_to_float
Mainly a copy of nir_lower_bool_to_int32, but with float opcodes.
Signed-off-by: Jonathan Marek
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/meson.build | 3 +-
src/compiler/nir/nir.h | 1 +
src/compiler/nir/nir_lower_bool_to_float.c | 165 +
4 files changed, 169 insertions(+), 1 deletion(-)
create mode 100644 src/compiler/nir/nir_lower_bool_to_float.c
diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index ef47bdb33b..39eaedc658 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -231,6 +231,7 @@ NIR_FILES = \
nir/nir_lower_atomics_to_ssbo.c \
nir/nir_lower_bitmap.c \
nir/nir_lower_bit_size.c \
+ nir/nir_lower_bool_to_float.c \
nir/nir_lower_bool_to_int32.c \
nir/nir_lower_clamp_color_outputs.c \
nir/nir_lower_clip.c \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index e252f64539..f1016104af 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -114,6 +114,7 @@ files_libnir = files(
'nir_lower_alpha_test.c',
'nir_lower_atomics_to_ssbo.c',
'nir_lower_bitmap.c',
+ 'nir_lower_bool_to_float.c',
'nir_lower_bool_to_int32.c',
'nir_lower_clamp_color_outputs.c',
'nir_lower_clip.c',
@@ -248,7 +249,7 @@ if with_tests
include_directories : [inc_common],
dependencies : [dep_thread, idep_gtest, idep_nir],
link_with : libmesa_util,
-),
+),
suite : ['compiler', 'nir'],
)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 54f9c64a3a..f6d0bdf7ec 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2905,6 +2905,7 @@ void nir_lower_alpha_test(nir_shader *shader, enum
compare_func func,
bool alpha_to_one);
bool nir_lower_alu(nir_shader *shader);
bool nir_lower_alu_to_scalar(nir_shader *shader);
+bool nir_lower_bool_to_float(nir_shader *shader);
bool nir_lower_bool_to_int32(nir_shader *shader);
bool nir_lower_load_const_to_scalar(nir_shader *shader);
bool nir_lower_read_invocation_to_scalar(nir_shader *shader);
diff --git a/src/compiler/nir/nir_lower_bool_to_float.c
b/src/compiler/nir/nir_lower_bool_to_float.c
new file mode 100644
index 00..2756a1815f
--- /dev/null
+++ b/src/compiler/nir/nir_lower_bool_to_float.c
@@ -0,0 +1,165 @@
+/*
+ * 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 (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"
+
+static bool
+assert_ssa_def_is_not_1bit(nir_ssa_def *def, UNUSED void *unused)
+{
+ assert(def->bit_size > 1);
+ return true;
+}
+
+static bool
+rewrite_1bit_ssa_def_to_32bit(nir_ssa_def *def, void *_progress)
+{
+ bool *progress = _progress;
+ if (def->bit_size == 1) {
+ def->bit_size = 32;
+ *progress = true;
+ }
+ return true;
+}
+
+static bool
+lower_alu_instr(nir_alu_instr *alu)
+{
+ const nir_op_info *op_info = _op_infos[alu->op];
+
+ switch (alu->op) {
+ case nir_op_vec2:
+ case nir_op_vec3:
+ case nir_op_vec4:
+ /* These we expect to have booleans but the opcode doesn't change */
+ break;
+
+ case nir_op_b2f32: alu->op = nir_op_fmov; break;
+
+ /* Note: we only expect these 5 opcodes with bools */
+ case nir_op_imov: alu->op = nir_op_fmov; break;
+ case nir_op_inot: alu->op = nir_op_fnot; break;
+ case nir_op_iand: alu->op = nir_op_fand; break;
+ case nir_op_ior: alu->op = nir_op_for; break;
+ case nir_op_ixor: alu->op = nir_op_fxor; break;
+
+ /* We might want a new opcode (for the (x != 0.0) f2b op) */
+ case nir_op_f2b1: alu->op = nir_op_f2b32; break;
+ case nir_op_i2b1: alu->op = nir_op_f2b32; break;
+
+ case nir_op_flt: alu->op = nir_op_slt; break;
+ case nir_op_fge: alu->op = nir_op_sge; break;
+ case nir_op_feq: alu->op = nir_op_seq; break;
+ case nir_op_fne:
[Mesa-dev] [PATCH 02/16] glsl/nir: ftrunc for native_integers=false float to int cast
out_type is always GLSL_TYPE_FLOAT, so we don't get the ftrunc otherwise
Signed-off-by: Jonathan Marek
---
src/compiler/glsl/glsl_to_nir.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index c8a7f3bd6c..d88289f682 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -1578,6 +1578,13 @@ nir_visitor::visit(ir_expression *ir)
case ir_unop_u2i:
case ir_unop_i642u64:
case ir_unop_u642i64: {
+ if (!supports_ints) {
+ if (ir->operation == ir_unop_f2i || ir->operation == ir_unop_f2u) {
+result = nir_ftrunc(, srcs[0]);
+break;
+ }
+ }
+
nir_alu_type src_type = nir_get_nir_type_for_glsl_base_type(types[0]);
nir_alu_type dst_type = nir_get_nir_type_for_glsl_base_type(out_type);
result = nir_build_alu(, nir_type_conversion_op(src_type, dst_type,
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: use llvm jit code for decoding s3tc
Am 19.12.18 um 08:35 schrieb Jose Fonseca:
> On 19/12/2018 03:51, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> This is (much) faster than using the util fallback.
>> (Note that there's two methods here, one would use a cache, similar to
>> the existing code (although the cache was disabled), except the block
>> decode is done with jit code, the other directly decodes the required
>> pixels. For now don't use the cache (being direct-mapped is suboptimal,
>> but it's difficult to come up with something better which doesn't have
>> too much overhead.)
>> ---
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
>> b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
>> index 018cca8f9df..a6662c5e01b 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
>> @@ -3549,10 +3549,6 @@ lp_build_sample_soa_func(struct gallivm_state
>> *gallivm,
>> const struct util_format_description *format_desc;
>> format_desc =
>> util_format_description(static_texture_state->format);
>> if (format_desc && format_desc->layout ==
>> UTIL_FORMAT_LAYOUT_S3TC) {
>> - /*
>> - * This is not 100% correct, if we have cache but the
>> - * util_format_s3tc_prefer is true the cache won't get used
>> - * regardless (could hook up the block decode there...) */
>> need_cache = TRUE;
>
> I'm a bit confused. Based on your comment description, shouldnt this be
> FALSE? Or is this dead code?
No that should be correct (note util_format_s3tc_prefer doesn't even
exist anymore). This is in if (cache_ptr) section - it just means that
we will pass the cache pointer (if it exists, that is if cache is
enabled) to the (separate) texture function.
Roland
>
>> }
>> }
>> diff --git a/src/gallium/auxiliary/meson.build
>> b/src/gallium/auxiliary/meson.build
>> index a4dbcf7b4ca..57f7e69050f 100644
>> --- a/src/gallium/auxiliary/meson.build
>> +++ b/src/gallium/auxiliary/meson.build
>> @@ -389,8 +389,8 @@ if with_llvm
>> 'gallivm/lp_bld_flow.h',
>> 'gallivm/lp_bld_format_aos_array.c',
>> 'gallivm/lp_bld_format_aos.c',
>> - 'gallivm/lp_bld_format_cached.c',
>> 'gallivm/lp_bld_format_float.c',
>> + 'gallivm/lp_bld_format_s3tc.c',
>> 'gallivm/lp_bld_format.c',
>> 'gallivm/lp_bld_format.h',
>> 'gallivm/lp_bld_format_soa.c',
>>
>
>
> Otherwise looks great. Thanks!
>
> Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 11:03 AM Jason Ekstrand wrote: > > On Wed, Dec 19, 2018 at 9:32 AM Ilia Mirkin wrote: >> >> On Wed, Dec 19, 2018 at 10:25 AM Matt Turner wrote: >> > >> > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin wrote: >> > > >> > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner wrote: >> > > > WTF would you have us do? >> > > >> > > Same thing as for any change with an impact this wide -- >> > > >> > > 1. Identify stakeholders. In this case, probably the sub-project >> > > maintainers, major contributors, and a smattering of distro >> > > maintainers. >> > > 2. Make them happy, or at least get them, as a group, to agree that >> > > it's "good enough". >> > >> > So we're trying to get better coverage than what you're suggesting. >> > >> > > 3. Apply. >> > > >> > > This is the point at which you can make autotools less visible. We're >> > > not at that point yet. >> > >> > Ilia, it's an extra flag. I think you'll survive. >> >> It's an advertising strategy for meson (hello world, check this out, >> it's going to be the default soon). It can be done at the final stage. >> We're not at that stage. >> >> We're at the stage of "hello community, we'd like to replace >> autotools", and the community coming back to you with feedback. > > > I disagree. I think we were at that stage 6-8 months ago and a bunch of the > community didn't come back with feedback until we sent a patch to delete > autotools. Identify stakeholders? Done; the distros are all cool with it or > have already switched. Agree it's "good enough"? We thought we'd done that > and then people raised issues at the 11th hour. Even with those issues, the > ones that are real issues with meson are all in-progress to fix. The others > are just "make it look like autotools so I can pretend meson doesn't exist". > Please pardon my frustration but we thought we'd done our due diligence and > it wasn't until we took a step very much like this one that we actually got > feedback from certain people such as yourself. To say that we're only now > getting to the "hello community, we'd like to replace autotools" stage is a > bit disingenuous. > > That said, that doesn't mean I think this patch is the right way to go. I > think the referenced e-mail conversaion has flushed out enough of the > remaining issues that we need to fix a couple of remaining things in meson > and then just delete autotools. Maybe this means that autotools stays around > for one more release but then I think we should just can it without bothering > with the extra deprecation step. First -- I want you (and Dylan, and others who are pushing this) to know that I understand your frustration. Making big changes is a giant pain. Not only is the change itself difficult (aka 80% of the work), but then you have to herd all the cats to make it all happen. And cats don't like to be herded (which is why 20% of the work takes 80% of the time). Second -- you're not just getting to "hello community" -- you've been there for a while. But it's not a signpost to move past (like an announcement might be), it's a stage to complete. The community has to be happy. You're saying the concerns are last-second, but I've been seeing these complaints going on for a while (stuff about saving env vars, inability to see how you configured something, etc). I was expecting these would all be addressed before I had to have another look. And then all of a sudden, "let's drop autotools!" and variants thereof. What you've been doing thus far is getting all the yaysayers to be happy (people who are enthusiastic about the change, such as yourself) -- making sure it all basically works, etc. Now you have to get the naysayers to be happy, like me, who are pretty happy with the status quo, and see limited/no benefit in the change. The way you do that is to make the new system no worse than the old one. Given that some people are interested, the naysayers aren't going to just shut it down, but their concerns should be addressed or ruled invalid. I've outlined what I'm looking for in a replacement to autotools in another thread [which you've responded to]. I'd recommend reaching out to some of the other stakeholders directly and getting their take. (And perhaps privately in case some fear anything public may affect their jobs, as I think most stakeholders are employed to contribute to mesa.) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 02/53] compiler/nir: add nir_fadd_imm() and nir_fadd_imm() helpers
The commit message says fadd twice.
On Wed, Dec 19, 2018 at 5:51 AM Iago Toral Quiroga
wrote:
> ---
> src/compiler/nir/nir_builder.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/src/compiler/nir/nir_builder.h
> b/src/compiler/nir/nir_builder.h
> index 74ecde798d5..14f3baab20b 100644
> --- a/src/compiler/nir/nir_builder.h
> +++ b/src/compiler/nir/nir_builder.h
> @@ -571,6 +571,18 @@ nir_imul_imm(nir_builder *build, nir_ssa_def *x,
> uint64_t y)
> return nir_imul(build, x, nir_imm_intN_t(build, y, x->bit_size));
> }
>
> +static inline nir_ssa_def *
> +nir_fadd_imm(nir_builder *build, nir_ssa_def *x, double y)
> +{
> + return nir_fadd(build, x, nir_imm_floatN_t(build, y, x->bit_size));
> +}
> +
> +static inline nir_ssa_def *
> +nir_fmul_imm(nir_builder *build, nir_ssa_def *x, double y)
> +{
> + return nir_fmul(build, x, nir_imm_floatN_t(build, y, x->bit_size));
> +}
> +
> static inline nir_ssa_def *
> nir_pack_bits(nir_builder *b, nir_ssa_def *src, unsigned dest_bit_size)
> {
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wednesday, 2018-12-19 10:32:44 -0500, Ilia Mirkin wrote: > On Wed, Dec 19, 2018 at 10:25 AM Matt Turner wrote: > > > > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin wrote: > > > > > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner wrote: > > > > WTF would you have us do? > > > > > > Same thing as for any change with an impact this wide -- > > > > > > 1. Identify stakeholders. In this case, probably the sub-project > > > maintainers, major contributors, and a smattering of distro > > > maintainers. > > > 2. Make them happy, or at least get them, as a group, to agree that > > > it's "good enough". > > > > So we're trying to get better coverage than what you're suggesting. > > > > > 3. Apply. > > > > > > This is the point at which you can make autotools less visible. We're > > > not at that point yet. > > > > Ilia, it's an extra flag. I think you'll survive. > > It's an advertising strategy for meson (hello world, check this out, > it's going to be the default soon). It can be done at the final stage. > We're not at that stage. > > We're at the stage of "hello community, we'd like to replace > autotools", and the community coming back to you with feedback. The point of this patch is for people to not be able to ignore this, and have to become aware of the existence of Meson and our intention to remove autotools, whenever this may happen. Some people have already noticed, probably because they keep up with mesa-dev@, but the point is that some people haven't. Without this patch: - people will continue being unaware, until - autotools gets removed, and these people are going to try their use-cases, and probably find issues - issues will get fixed, hopefully quickly, but blocking them completely in the mean time With this patch: - people will *have to notice* that something's changing - they'll choose to either ignore it, use the flag, and *choose* to go with the option above - or they can choose to try meson, get any issues fixed *while still being able to work with their old setup in the mean time* This last bit is the entire point of this patch, so let me repeat it: people will report meson issues while there's still time to use their old autotools setup. I'm definitely in favour: Acked-by: Eric Engestrom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 10:32 AM Ilia Mirkin wrote: > > On Wed, Dec 19, 2018 at 10:25 AM Matt Turner wrote: > > > > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin wrote: > > > > > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner wrote: > > > > WTF would you have us do? > > > > > > Same thing as for any change with an impact this wide -- > > > > > > 1. Identify stakeholders. In this case, probably the sub-project > > > maintainers, major contributors, and a smattering of distro > > > maintainers. > > > 2. Make them happy, or at least get them, as a group, to agree that > > > it's "good enough". > > > > So we're trying to get better coverage than what you're suggesting. > > > > > 3. Apply. > > > > > > This is the point at which you can make autotools less visible. We're > > > not at that point yet. > > > > Ilia, it's an extra flag. I think you'll survive. > > It's an advertising strategy for meson (hello world, check this out, > it's going to be the default soon). It can be done at the final stage. > We're not at that stage. It's an attempt to get testing from users that might not know about it yet. It's not as simple as advertising. If you're confused about the intention of the patch, consider that it's from Gert who has not been enthusiastic about removing autotools. > We're at the stage of "hello community, we'd like to replace > autotools", and the community coming back to you with feedback. People have been using Meson quite successfully for more than a year now. It's now used in Gentoo's mesa ebuild for six months and is used in the stable version. Your claim is subjective, but I think it's pretty clear that it's not accurate. Regardless of all of that, what you're suggesting is only marking autotools as deprecated (i.e., this patch) after all known problems with the Meson build are fixed. At that point in 3 months down the line if we get another bug report from a user that only learned of Meson from this patch, you're going to advocate for keeping autotools for another release. Rinse, repeat. We're simply trying to get the feedback from users sooner. And the cost to you is very small: Use an extra flag. It's not a burden. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] drop autotools
On Tue, Dec 18, 2018 at 2:51 AM Juan A. Suarez Romero wrote: > On Mon, 2018-12-17 at 19:51 +0100, Bas Nieuwenhuizen wrote: > > On Mon, Dec 17, 2018 at 6:33 PM Juan A. Suarez Romero > > wrote: > > > On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote: > > > > Cc: Emil Velikov > > > > Cc: Andres Gomez > > > > Cc: Juan A. Suarez Romero > > > > Cc: Dylan Baker > > > > Signed-off-by: Eric Engestrom > > > > --- > > > > This patch depends on the releasing procedure in docs/releasing.html > to > > > > be updated to not rely on autotools anymore. > > > > > > > > I think our release managers (cc'ed) should work together and figure > out > > > > the procedure they want to go by; only once that's done can we delete > > > > these 200+ files and 14k+ lines :) > > > > > > I'll let others to talk. But my preference would be to land this for > next 19.0 > > > branchpoint, just a couple of days before the branchpoint, so 19.0.x > releases > > > get rid of autotools. > > > > > > This way we have time to fix any remaining issue, and make like easier > for those > > > in charge of 18.3.x releases, which I think should support autotools > until the > > > end of its life. > > > > Can I suggest the inverse, pushing this long before any branchpoint? > > > > As with any migration, users only start using when you force them too, > > and that means a bunch of non-working usecases are going to be > > detected once this patch is pushed and some more people are forced to > > it. Sure, the last call discussion served to tease some of these out, > > but I expect even more will turn up if you submit this. > > > > The bad part is that this make life more complex for the person in charge > of the > stable release, because it means that any patch that touches the build > system > will only touch the meson, but not the autotools, which means either the > original author or the release manager should fix the part of the > autotools in > order to avoid breaking it. > How common is it to have build system patches back-ported to stable? I genuinely don't know but I would suspect it's not all that frequent of a thing. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 9:32 AM Ilia Mirkin wrote: > On Wed, Dec 19, 2018 at 10:25 AM Matt Turner wrote: > > > > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin > wrote: > > > > > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner > wrote: > > > > WTF would you have us do? > > > > > > Same thing as for any change with an impact this wide -- > > > > > > 1. Identify stakeholders. In this case, probably the sub-project > > > maintainers, major contributors, and a smattering of distro > > > maintainers. > > > 2. Make them happy, or at least get them, as a group, to agree that > > > it's "good enough". > > > > So we're trying to get better coverage than what you're suggesting. > > > > > 3. Apply. > > > > > > This is the point at which you can make autotools less visible. We're > > > not at that point yet. > > > > Ilia, it's an extra flag. I think you'll survive. > > It's an advertising strategy for meson (hello world, check this out, > it's going to be the default soon). It can be done at the final stage. > We're not at that stage. > > We're at the stage of "hello community, we'd like to replace > autotools", and the community coming back to you with feedback. > I disagree. I think we were at that stage 6-8 months ago and a bunch of the community didn't come back with feedback until we sent a patch to delete autotools. Identify stakeholders? Done; the distros are all cool with it or have already switched. Agree it's "good enough"? We thought we'd done that and then people raised issues at the 11th hour. Even with those issues, the ones that are real issues with meson are all in-progress to fix. The others are just "make it look like autotools so I can pretend meson doesn't exist". Please pardon my frustration but we thought we'd done our due diligence and it wasn't until we took a step very much like this one that we actually got feedback from certain people such as yourself. To say that we're only now getting to the "hello community, we'd like to replace autotools" stage is a bit disingenuous. That said, that doesn't mean I think this patch is the right way to go. I think the referenced e-mail conversaion has flushed out enough of the remaining issues that we need to fix a couple of remaining things in meson and then just delete autotools. Maybe this means that autotools stays around for one more release but then I think we should just can it without bothering with the extra deprecation step. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 10:25 AM Matt Turner wrote: > > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin wrote: > > > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner wrote: > > > WTF would you have us do? > > > > Same thing as for any change with an impact this wide -- > > > > 1. Identify stakeholders. In this case, probably the sub-project > > maintainers, major contributors, and a smattering of distro > > maintainers. > > 2. Make them happy, or at least get them, as a group, to agree that > > it's "good enough". > > So we're trying to get better coverage than what you're suggesting. > > > 3. Apply. > > > > This is the point at which you can make autotools less visible. We're > > not at that point yet. > > Ilia, it's an extra flag. I think you'll survive. It's an advertising strategy for meson (hello world, check this out, it's going to be the default soon). It can be done at the final stage. We're not at that stage. We're at the stage of "hello community, we'd like to replace autotools", and the community coming back to you with feedback. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/amdgpu: Pull in LLVM CFLAGS
On 19.12.18 16:05, Michel Dänzer wrote: From: Michel Dänzer Fixes build failure if the LLVM headers aren't in a standard include directory. Huh, interesting that I didn't run into this. Anyway: Reviewed-by: Nicolai Hähnle Fixes: ec22dd34c88f "radeonsi: move SI_FORCE_FAMILY functionality to winsys" Signed-off-by: Michel Dänzer --- src/gallium/winsys/amdgpu/drm/Makefile.am | 1 + src/gallium/winsys/amdgpu/drm/meson.build | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/amdgpu/drm/Makefile.am b/src/gallium/winsys/amdgpu/drm/Makefile.am index e35fa2cd0a2..1c2ec010fc6 100644 --- a/src/gallium/winsys/amdgpu/drm/Makefile.am +++ b/src/gallium/winsys/amdgpu/drm/Makefile.am @@ -4,6 +4,7 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CFLAGS = \ $(GALLIUM_WINSYS_CFLAGS) \ $(AMDGPU_CFLAGS) \ + $(LLVM_CFLAGS) \ -I$(top_srcdir)/src/amd/ AM_CXXFLAGS = $(AM_CFLAGS) diff --git a/src/gallium/winsys/amdgpu/drm/meson.build b/src/gallium/winsys/amdgpu/drm/meson.build index 8b6f69b2bdd..d3282ef412d 100644 --- a/src/gallium/winsys/amdgpu/drm/meson.build +++ b/src/gallium/winsys/amdgpu/drm/meson.build @@ -31,5 +31,5 @@ libamdgpuwinsys = static_library( c_args : [c_vis_args], cpp_args : [cpp_vis_args], link_with : libamdgpu_addrlib, - dependencies : dep_libdrm_amdgpu, + dependencies : [dep_llvm, dep_libdrm_amdgpu], ) -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/2] etnaviv: enable full overwrite in a few more cases
Take into account the render target format when checking if the color mask affects all channels of the RT. This allows to enable full override in a few cases where a non-alpha format is used. Signed-off-by: Lucas Stach --- v2: clarify comment --- src/gallium/drivers/etnaviv/etnaviv_blend.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.c b/src/gallium/drivers/etnaviv/etnaviv_blend.c index 0e2299a50b30..061c9af5247f 100644 --- a/src/gallium/drivers/etnaviv/etnaviv_blend.c +++ b/src/gallium/drivers/etnaviv/etnaviv_blend.c @@ -114,6 +114,7 @@ etna_update_blend(struct etna_context *ctx) struct pipe_blend_state *pblend = ctx->blend; struct etna_blend_state *blend = etna_blend_state(pblend); const struct pipe_rt_blend_state *rt0 = >rt[0]; + const struct util_format_description *desc; uint32_t colormask; if (pfb->cbufs[0] && @@ -128,11 +129,13 @@ etna_update_blend(struct etna_context *ctx) } /* If the complete render target is written, set full_overwrite: -* - The color mask is -* - No blending is used +* - The color mask covers all channels of the render target +* - No blending or logicop is used */ - bool full_overwrite = ((rt0->colormask == 0xf) && blend->fo_allowed) || - !pfb->cbufs[0]; + if (pfb->cbufs[0]) + desc = util_format_description(pfb->cbufs[0]->format); + bool full_overwrite = !pfb->cbufs[0] || ((blend->fo_allowed && + util_format_colormask_full(desc, colormask))); blend->PE_COLOR_FORMAT = VIVS_PE_COLOR_FORMAT_COMPONENTS(colormask) | COND(full_overwrite, VIVS_PE_COLOR_FORMAT_OVERWRITE); -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/2] etnaviv: annotate variables only used in debug build
Some of the status variables in the compiler are only used in asserts
and thus may be unused in release builds. Annotate them accordingly
to avoid 'unused but set' warnings from the compiler.
Signed-off-by: Lucas Stach
---
v2: get rid of superfluous variable initialization
---
src/gallium/drivers/etnaviv/etnaviv_compiler.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index bbc61a59fc67..ceca5b8af997 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -477,8 +477,7 @@ static void
etna_compile_parse_declarations(struct etna_compile *c)
{
struct tgsi_parse_context ctx = { };
- unsigned status = TGSI_PARSE_OK;
- status = tgsi_parse_init(, c->tokens);
+ MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
while (!tgsi_parse_end_of_tokens()) {
@@ -530,8 +529,7 @@ static void
etna_compile_pass_check_usage(struct etna_compile *c)
{
struct tgsi_parse_context ctx = { };
- unsigned status = TGSI_PARSE_OK;
- status = tgsi_parse_init(, c->tokens);
+ MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
for (int idx = 0; idx < c->total_decls; ++idx) {
@@ -662,8 +660,7 @@ etna_compile_pass_optimize_outputs(struct etna_compile *c)
{
struct tgsi_parse_context ctx = { };
int inst_idx = 0;
- unsigned status = TGSI_PARSE_OK;
- status = tgsi_parse_init(, c->tokens);
+ MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
while (!tgsi_parse_end_of_tokens()) {
@@ -1812,7 +1809,7 @@ static void
etna_compile_pass_generate_code(struct etna_compile *c)
{
struct tgsi_parse_context ctx = { };
- unsigned status = tgsi_parse_init(, c->tokens);
+ MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
int inst_idx = 0;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin wrote: > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner wrote: > > WTF would you have us do? > > Same thing as for any change with an impact this wide -- > > 1. Identify stakeholders. In this case, probably the sub-project > maintainers, major contributors, and a smattering of distro > maintainers. > 2. Make them happy, or at least get them, as a group, to agree that > it's "good enough". So we're trying to get better coverage than what you're suggesting. > 3. Apply. > > This is the point at which you can make autotools less visible. We're > not at that point yet. Ilia, it's an extra flag. I think you'll survive. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: allow glDrawElements to work with GL_SELECT feedback
On 12/19/2018 06:47 AM, Ilia Mirkin wrote:
> On Wed, Dec 19, 2018 at 8:38 AM Brian Paul wrote:
>>
>> On 12/18/2018 08:50 PM, Ilia Mirkin wrote:
>>> Not sure if this ever worked, but the current logic for setting the
>>> min/max index is definitely wrong for indexed draws. While we're at it,
>>> bring in all the usual logic from the non-indirect drawing path.
>>>
>>> Bugzilla:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109086data=02%7C01%7Cbrianp%40vmware.com%7C9b8ab75c977c458b597708d665b899b4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636808240937735266sdata=pHzFcdG8H%2F89D3rdD2gs7CZ%2BE12BRgGT0uzsuxWDC68%3Dreserved=0
>>> Signed-off-by: Ilia Mirkin
>>> ---
>>>
>>> This makes it more or less mirror st_draw_vbo. As the comment in the
>>> code says, would be nice to refactor, but ... meh.
>>>
>>> Note that I haven't tested any of the interactions with additional
>>> features, like primitive restart or instancing or any of that. However I
>>> don't think that this would make things *worse*.
>>>
>>>src/mesa/state_tracker/st_draw_feedback.c | 61 +++
>>>1 file changed, 39 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/src/mesa/state_tracker/st_draw_feedback.c
>>> b/src/mesa/state_tracker/st_draw_feedback.c
>>> index 6ec6d5c16f4..49fdecf7e38 100644
>>> --- a/src/mesa/state_tracker/st_draw_feedback.c
>>> +++ b/src/mesa/state_tracker/st_draw_feedback.c
>>> @@ -84,27 +84,6 @@ set_feedback_vertex_format(struct gl_context *ctx)
>>>}
>>>
>>>
>>> -/**
>>> - * Helper for drawing current vertex arrays.
>>> - */
>>> -static void
>>> -draw_arrays(struct draw_context *draw, unsigned mode,
>>> -unsigned start, unsigned count)
>>> -{
>>> - struct pipe_draw_info info;
>>> -
>>> - util_draw_init_info();
>>> -
>>> - info.mode = mode;
>>> - info.start = start;
>>> - info.count = count;
>>> - info.min_index = start;
>>> - info.max_index = start + count - 1;
>>> -
>>> - draw_vbo(draw, );
>>> -}
>>> -
>>> -
>>>/**
>>> * Called by VBO to draw arrays when in selection or feedback mode and
>>> * to implement glRasterPos.
>>> @@ -136,10 +115,18 @@ st_feedback_draw_vbo(struct gl_context *ctx,
>>> struct pipe_transfer *ib_transfer = NULL;
>>> GLuint i;
>>> const void *mapped_indices = NULL;
>>> + struct pipe_draw_info info;
>>>
>>> if (!draw)
>>> return;
>>>
>>> + /* Initialize pipe_draw_info. */
>>> + info.primitive_restart = false;
>>> + info.vertices_per_patch = ctx->TessCtrlProgram.patch_vertices;
>>> + info.indirect = NULL;
>>> + info.count_from_stream_output = NULL;
>>> + info.restart_index = 0;
>>
>> Shouldn't we use util_draw_init_info() to make this future-proof?
>>
>> Looks good otherwise. Thanks for fixing this!
>>
>> Reviewed-by: Brian Paul
>
> I'm just copying what st_draw_vbo does. I think keeping them looking
> similar is important so that any updates to one are easily ported. Why
> doesn't that use the util_draw_init_info? Not sure.
I think Marek did that to squeeze out a few drops of performance. I
don't think we have to do that in the feedback code. But your call.
>
> At this point, the only differences are in ib setup -- this function
> will forcefully map the ib (which I think is fine) -- and lack of
> support for count_from_stream_output. The latter would take a bit of
> work, since we can't just pass it in directly -- it's a pipe_query
> from a (potentially) different driver. When someone complains about
> glDrawTransformFeedback not working with GL_SELECT, we can reconsider.
Sure.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/amdgpu: Pull in LLVM CFLAGS
From: Michel Dänzer Fixes build failure if the LLVM headers aren't in a standard include directory. Fixes: ec22dd34c88f "radeonsi: move SI_FORCE_FAMILY functionality to winsys" Signed-off-by: Michel Dänzer --- src/gallium/winsys/amdgpu/drm/Makefile.am | 1 + src/gallium/winsys/amdgpu/drm/meson.build | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/amdgpu/drm/Makefile.am b/src/gallium/winsys/amdgpu/drm/Makefile.am index e35fa2cd0a2..1c2ec010fc6 100644 --- a/src/gallium/winsys/amdgpu/drm/Makefile.am +++ b/src/gallium/winsys/amdgpu/drm/Makefile.am @@ -4,6 +4,7 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CFLAGS = \ $(GALLIUM_WINSYS_CFLAGS) \ $(AMDGPU_CFLAGS) \ + $(LLVM_CFLAGS) \ -I$(top_srcdir)/src/amd/ AM_CXXFLAGS = $(AM_CFLAGS) diff --git a/src/gallium/winsys/amdgpu/drm/meson.build b/src/gallium/winsys/amdgpu/drm/meson.build index 8b6f69b2bdd..d3282ef412d 100644 --- a/src/gallium/winsys/amdgpu/drm/meson.build +++ b/src/gallium/winsys/amdgpu/drm/meson.build @@ -31,5 +31,5 @@ libamdgpuwinsys = static_library( c_args : [c_vis_args], cpp_args : [cpp_vis_args], link_with : libamdgpu_addrlib, - dependencies : dep_libdrm_amdgpu, + dependencies : [dep_llvm, dep_libdrm_amdgpu], ) -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided
https://bugs.freedesktop.org/show_bug.cgi?id=109102 Chris Wilson changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Mesa core |Drivers/DRI/i915 --- Comment #2 from Chris Wilson --- -EDEADLOCK = userspace tried to use more fence registers than the HW supports. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided
https://bugs.freedesktop.org/show_bug.cgi?id=109102 --- Comment #1 from Gert vd Kraats --- Created attachment 142856 --> https://bugs.freedesktop.org/attachment.cgi?id=142856=edit ubuntu-cogl-patch -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided
https://bugs.freedesktop.org/show_bug.cgi?id=109102 Bug ID: 109102 Summary: At dual monitor intel_do_flush_locked failed: Resource deadlock avoided Product: Mesa Version: 18.2 Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: vd.kra...@hccnet.nl QA Contact: mesa-dev@lists.freedesktop.org Created attachment 142855 --> https://bugs.freedesktop.org/attachment.cgi?id=142855=edit stacktrace This is a copy of ubuntu bug 1797882. It should be directly submitted to mesa. Using ubuntu 18.10 wayland with dual monitors, configured above each other. Dock is configured at both displays, not hiding. Icons for "terminal" and "libreofffice Writer" are present at the dock. Start terminal on primary screen by mouseclick on dock. Start libreoffice Writer on primary screen by mouseclick on dock. Terminate libreoffice Witer by mouseclick on X. Repeat the starting and stopping of Writer. Login-screen will appear. Syslog shows: Oct 15 00:09:51 Gert2 org.gnome.Shell.desktop[5892]: intel_do_flush_locked failed: Resource deadlock avoided Oct 15 00:09:51 Gert2 gnome-terminal-[6439]: Error reading events from display: Connection reset by peer Oct 15 00:09:51 Gert2 systemd[5755]: gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE This problem doesnot occur in a dual monitor-session without wayland. It also doesnot occur, if only one monitor used with wayland It also doesnot occur, if the dock is only present at the primary screen. It also doesnot occur if second started application is present at the dock and doesnot add an icon to the dock (as libreoffice does). All other dual monitor/dock configurations seem to have this problem. No idea if this is helpful info, but the used graphics card does not support OpenGL version 2.1: Oct 15 00:02:32 Gert2 org.gnome.Shell.desktop[4426]: Require OpenGL version 2.1 or later. Oct 15 00:02:32 Gert2 org.gnome.Shell.desktop[4426]: Failed to initialize glamor Oct 15 00:02:32 Gert2 org.gnome.Shell.desktop[4426]: Failed to initialize glamor, falling back to sw glxinfo: OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 128 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.2.2 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.1 Mesa 18.2.2 OpenGL shading language version string: 1.40 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.2.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: Extra info: Without solving this problem, wayland cannot be used after logon, when using dual monitor. The sesssion stops very easy and often. Work is lost; you have to logon again. E.g. the simple switching between 2 overlapping windows causes the end of the session. I changed src/mesa/drivers/dri/i915/intel_batchbuffer.c to force a coredump in this case. The stacktrace is added to this bug-report. Linenumbers might deviate a little bit because of extra coding of tracing. The deadlock always occurs at cogl_onscreen_swap_buffers calling cogl_flush(), at the first journal-batch-flush for the offscreen-framebuffer. The deadlock disappeared as soon as cogl is compiled with disabled batching! To minimize this disabling of batching, I made a very dirty but working patch, which is attached to this bug. At program clutter_stage_cogl_redraw_view routine paint_stage is called for the "Unclipped stage paint". This call is manipulated to flush immedately the first journal-entry of the default onscreen framebuffer. This is done by misusing and changing program cogl_framebuffer_set_viewport and by changing _cogl_journal_flush. Apparenly this early flushing causes a lock to be set which avoids the deadlock. I do not know how to see which locks are held and by which process, so I cannot solve the root-cause of the problem, but I assume some extra lock must be set in this case to avoid deadlock. With this dirty patch combined with other suggested (simple) patches at #1790525, #1795774 and #1795760 wayland can be run without any problems on dual monitor and "old" intel graphic card. It performs better than lightdm, specially if the monitors are positioned aside of each other. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: move nir_lower_bool_to_int32 before nir_lower_locals_to_regs
Rb
On December 19, 2018 02:15:59 Iago Toral Quiroga wrote:
The former expects to see SSA-only things, but the latter injects registers.
The assertions in the lowering where not seeing this because they asserted
on the bit_size values only, not on the is_ssa field, so add that assertion
too.
Fixes: 11dc1307794e "nir: Add a bool to int32 lowering pass"
CC: mesa-sta...@lists.freedesktop.org
---
src/compiler/nir/nir_lower_bool_to_int32.c | 2 ++
src/intel/compiler/brw_nir.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_lower_bool_to_int32.c
b/src/compiler/nir/nir_lower_bool_to_int32.c
index 064b27b9025..fdd2f55175d 100644
--- a/src/compiler/nir/nir_lower_bool_to_int32.c
+++ b/src/compiler/nir/nir_lower_bool_to_int32.c
@@ -46,6 +46,8 @@ lower_alu_instr(nir_alu_instr *alu)
{
const nir_op_info *op_info = _op_infos[alu->op];
+ assert(alu->dest.dest.is_ssa);
+
switch (alu->op) {
case nir_op_imov:
case nir_op_vec2:
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index ab88a5f1fc7..4fdc98b6cf4 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -832,6 +832,8 @@ brw_postprocess_nir(nir_shader *nir, const struct
brw_compiler *compiler,
OPT(nir_opt_dce);
OPT(nir_opt_move_comparisons);
+ OPT(nir_lower_bool_to_int32);
+
OPT(nir_lower_locals_to_regs);
if (unlikely(debug_enabled)) {
@@ -846,8 +848,6 @@ brw_postprocess_nir(nir_shader *nir, const struct
brw_compiler *compiler,
nir_print_shader(nir, stderr);
}
- OPT(nir_lower_bool_to_int32);
-
OPT(nir_convert_from_ssa, true);
if (!is_scalar) {
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: allow glDrawElements to work with GL_SELECT feedback
On Wed, Dec 19, 2018 at 8:38 AM Brian Paul wrote:
>
> On 12/18/2018 08:50 PM, Ilia Mirkin wrote:
> > Not sure if this ever worked, but the current logic for setting the
> > min/max index is definitely wrong for indexed draws. While we're at it,
> > bring in all the usual logic from the non-indirect drawing path.
> >
> > Bugzilla:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109086data=02%7C01%7Cbrianp%40vmware.com%7C6caf58471242445a386a08d665652d9a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636807882586735220sdata=ekxW8vXjInP6H7vsVCdLJ4GD9y%2BN8MYpzWYRY87utEA%3Dreserved=0
> > Signed-off-by: Ilia Mirkin
> > ---
> >
> > This makes it more or less mirror st_draw_vbo. As the comment in the
> > code says, would be nice to refactor, but ... meh.
> >
> > Note that I haven't tested any of the interactions with additional
> > features, like primitive restart or instancing or any of that. However I
> > don't think that this would make things *worse*.
> >
> > src/mesa/state_tracker/st_draw_feedback.c | 61 +++
> > 1 file changed, 39 insertions(+), 22 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_draw_feedback.c
> > b/src/mesa/state_tracker/st_draw_feedback.c
> > index 6ec6d5c16f4..49fdecf7e38 100644
> > --- a/src/mesa/state_tracker/st_draw_feedback.c
> > +++ b/src/mesa/state_tracker/st_draw_feedback.c
> > @@ -84,27 +84,6 @@ set_feedback_vertex_format(struct gl_context *ctx)
> > }
> >
> >
> > -/**
> > - * Helper for drawing current vertex arrays.
> > - */
> > -static void
> > -draw_arrays(struct draw_context *draw, unsigned mode,
> > -unsigned start, unsigned count)
> > -{
> > - struct pipe_draw_info info;
> > -
> > - util_draw_init_info();
> > -
> > - info.mode = mode;
> > - info.start = start;
> > - info.count = count;
> > - info.min_index = start;
> > - info.max_index = start + count - 1;
> > -
> > - draw_vbo(draw, );
> > -}
> > -
> > -
> > /**
> >* Called by VBO to draw arrays when in selection or feedback mode and
> >* to implement glRasterPos.
> > @@ -136,10 +115,18 @@ st_feedback_draw_vbo(struct gl_context *ctx,
> > struct pipe_transfer *ib_transfer = NULL;
> > GLuint i;
> > const void *mapped_indices = NULL;
> > + struct pipe_draw_info info;
> >
> > if (!draw)
> > return;
> >
> > + /* Initialize pipe_draw_info. */
> > + info.primitive_restart = false;
> > + info.vertices_per_patch = ctx->TessCtrlProgram.patch_vertices;
> > + info.indirect = NULL;
> > + info.count_from_stream_output = NULL;
> > + info.restart_index = 0;
>
> Shouldn't we use util_draw_init_info() to make this future-proof?
>
> Looks good otherwise. Thanks for fixing this!
>
> Reviewed-by: Brian Paul
I'm just copying what st_draw_vbo does. I think keeping them looking
similar is important so that any updates to one are easily ported. Why
doesn't that use the util_draw_init_info? Not sure.
At this point, the only differences are in ib setup -- this function
will forcefully map the ib (which I think is fine) -- and lack of
support for count_from_stream_output. The latter would take a bit of
work, since we can't just pass it in directly -- it's a pipe_query
from a (potentially) different driver. When someone complains about
glDrawTransformFeedback not working with GL_SELECT, we can reconsider.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: allow glDrawElements to work with GL_SELECT feedback
On 12/18/2018 08:50 PM, Ilia Mirkin wrote:
> Not sure if this ever worked, but the current logic for setting the
> min/max index is definitely wrong for indexed draws. While we're at it,
> bring in all the usual logic from the non-indirect drawing path.
>
> Bugzilla:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109086data=02%7C01%7Cbrianp%40vmware.com%7C6caf58471242445a386a08d665652d9a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636807882586735220sdata=ekxW8vXjInP6H7vsVCdLJ4GD9y%2BN8MYpzWYRY87utEA%3Dreserved=0
> Signed-off-by: Ilia Mirkin
> ---
>
> This makes it more or less mirror st_draw_vbo. As the comment in the
> code says, would be nice to refactor, but ... meh.
>
> Note that I haven't tested any of the interactions with additional
> features, like primitive restart or instancing or any of that. However I
> don't think that this would make things *worse*.
>
> src/mesa/state_tracker/st_draw_feedback.c | 61 +++
> 1 file changed, 39 insertions(+), 22 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_draw_feedback.c
> b/src/mesa/state_tracker/st_draw_feedback.c
> index 6ec6d5c16f4..49fdecf7e38 100644
> --- a/src/mesa/state_tracker/st_draw_feedback.c
> +++ b/src/mesa/state_tracker/st_draw_feedback.c
> @@ -84,27 +84,6 @@ set_feedback_vertex_format(struct gl_context *ctx)
> }
>
>
> -/**
> - * Helper for drawing current vertex arrays.
> - */
> -static void
> -draw_arrays(struct draw_context *draw, unsigned mode,
> -unsigned start, unsigned count)
> -{
> - struct pipe_draw_info info;
> -
> - util_draw_init_info();
> -
> - info.mode = mode;
> - info.start = start;
> - info.count = count;
> - info.min_index = start;
> - info.max_index = start + count - 1;
> -
> - draw_vbo(draw, );
> -}
> -
> -
> /**
>* Called by VBO to draw arrays when in selection or feedback mode and
>* to implement glRasterPos.
> @@ -136,10 +115,18 @@ st_feedback_draw_vbo(struct gl_context *ctx,
> struct pipe_transfer *ib_transfer = NULL;
> GLuint i;
> const void *mapped_indices = NULL;
> + struct pipe_draw_info info;
>
> if (!draw)
> return;
>
> + /* Initialize pipe_draw_info. */
> + info.primitive_restart = false;
> + info.vertices_per_patch = ctx->TessCtrlProgram.patch_vertices;
> + info.indirect = NULL;
> + info.count_from_stream_output = NULL;
> + info.restart_index = 0;
Shouldn't we use util_draw_init_info() to make this future-proof?
Looks good otherwise. Thanks for fixing this!
Reviewed-by: Brian Paul
> +
> st_flush_bitmap_cache(st);
> st_invalidate_readpix_cache(st);
>
> @@ -213,9 +200,23 @@ st_feedback_draw_vbo(struct gl_context *ctx,
>mapped_indices = ib->ptr;
> }
>
> + info.index_size = ib->index_size;
> + info.min_index = min_index;
> + info.max_index = max_index;
> + info.has_user_indices = true;
> + info.index.user = mapped_indices;
> +
> draw_set_indexes(draw,
> (ubyte *) mapped_indices,
> index_size, ~0);
> +
> + if (ctx->Array._PrimitiveRestart) {
> + info.primitive_restart = true;
> + info.restart_index = _mesa_primitive_restart_index(ctx,
> info.index_size);
> + }
> + } else {
> + info.index_size = 0;
> + info.has_user_indices = false;
> }
>
> /* set the constant buffer */
> @@ -226,7 +227,23 @@ st_feedback_draw_vbo(struct gl_context *ctx,
>
> /* draw here */
> for (i = 0; i < nr_prims; i++) {
> - draw_arrays(draw, prims[i].mode, start + prims[i].start,
> prims[i].count);
> + info.count = prims[i].count;
> +
> + if (!info.count)
> + continue;
> +
> + info.mode = prims[i].mode;
> + info.start = start + prims[i].start;
> + info.start_instance = prims[i].base_instance;
> + info.instance_count = prims[i].num_instances;
> + info.index_bias = prims[i].basevertex;
> + info.drawid = prims[i].draw_id;
> + if (!ib) {
> + info.min_index = info.start;
> + info.max_index = info.start + info.count - 1;
> + }
> +
> + draw_vbo(draw, );
> }
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
On Wed, Dec 19, 2018 at 1:01 AM Matt Turner wrote: > WTF would you have us do? Same thing as for any change with an impact this wide -- 1. Identify stakeholders. In this case, probably the sub-project maintainers, major contributors, and a smattering of distro maintainers. 2. Make them happy, or at least get them, as a group, to agree that it's "good enough". 3. Apply. This is the point at which you can make autotools less visible. We're not at that point yet. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108935] [LLVM Regression, bisected] Witcher 3 Corrupted Terrain
https://bugs.freedesktop.org/show_bug.cgi?id=108935 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Samuel Pitoiset --- The regression should be fixed with LLVM r349611. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/11] radv: Add multiview clears.
On Wed, 2017-08-23 at 22:51 +0200, Bas Nieuwenhuizen wrote:
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 1 +
> src/amd/vulkan/radv_meta_clear.c | 65
>
> src/amd/vulkan/radv_private.h| 1 +
> 3 files changed, 48 insertions(+), 19 deletions(-)
>
Hi. This landed in master as f67dea5e19e ("radv: Fix multiview depth clears"),
fixing 2e86f6b2597 ("radv: Add multiview clears."), which is part of 18.2 stable
branch. Thus this commit is also a candidate for the same branch.
Nevertheless, I'm rejecting it as it does not apply in the branch. Apparently it
would require at least aeaf8dbd097 ("radv: add radv_image_can_fast_clear()
helper") and 7484bc894b9 ("radv: refactor the fast clear path for better re-
use"), but very likely more changes.
If you can provide a backport for 18.2 stable branch, I could enqueue it.
Otherwise, I'll keep it out.
Thanks
J.A.
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 94453094eb6..ed11a4aa35e 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -1867,6 +1867,7 @@ radv_cmd_state_setup_attachments(struct radv_cmd_buffer
> *cmd_buffer,
> }
>
> state->attachments[i].pending_clear_aspects = clear_aspects;
> + state->attachments[i].cleared_views = 0;
> if (clear_aspects && info) {
> assert(info->clearValueCount > i);
> state->attachments[i].clear_value =
> info->pClearValues[i];
> diff --git a/src/amd/vulkan/radv_meta_clear.c
> b/src/amd/vulkan/radv_meta_clear.c
> index af76a517aaf..ea777d9979c 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -337,7 +337,8 @@ radv_device_finish_meta_clear_state(struct radv_device
> *device)
> static void
> emit_color_clear(struct radv_cmd_buffer *cmd_buffer,
> const VkClearAttachment *clear_att,
> - const VkClearRect *clear_rect)
> + const VkClearRect *clear_rect,
> + uint32_t view_mask)
> {
> struct radv_device *device = cmd_buffer->device;
> const struct radv_subpass *subpass = cmd_buffer->state.subpass;
> @@ -400,7 +401,14 @@ emit_color_clear(struct radv_cmd_buffer *cmd_buffer,
>
> radv_CmdSetScissor(radv_cmd_buffer_to_handle(cmd_buffer), 0, 1,
> _rect->rect);
>
> - radv_CmdDraw(cmd_buffer_h, 3, clear_rect->layerCount, 0,
> clear_rect->baseArrayLayer);
> + if (view_mask) {
> + for (unsigned i = 0; (1u << i) <= view_mask; ++i)
> + if ((1u << i) & view_mask) {
> + radv_CmdDraw(cmd_buffer_h, 3, 1, 0, i);
> + }
> + } else {
> + radv_CmdDraw(cmd_buffer_h, 3, clear_rect->layerCount, 0,
> clear_rect->baseArrayLayer);
> + }
>
> radv_cmd_buffer_set_subpass(cmd_buffer, subpass, false);
> }
> @@ -945,7 +953,8 @@ emit_fast_color_clear(struct radv_cmd_buffer *cmd_buffer,
> const VkClearAttachment *clear_att,
> const VkClearRect *clear_rect,
> enum radv_cmd_flush_bits *pre_flush,
> - enum radv_cmd_flush_bits *post_flush)
> + enum radv_cmd_flush_bits *post_flush,
> + uint32_t view_mask)
> {
> const struct radv_subpass *subpass = cmd_buffer->state.subpass;
> const uint32_t subpass_att = clear_att->colorAttachment;
> @@ -989,9 +998,12 @@ emit_fast_color_clear(struct radv_cmd_buffer *cmd_buffer,
> clear_rect->rect.extent.height != iview->image->info.height)
> goto fail;
>
> - if (clear_rect->baseArrayLayer != 0)
> + if (view_mask && (iview->image->info.array_size >= 32 ||
> + (1u << iview->image->info.array_size) - 1u !=
> view_mask))
> goto fail;
> - if (clear_rect->layerCount != iview->image->info.array_size)
> + if (!view_mask && clear_rect->baseArrayLayer != 0)
> + goto fail;
> + if (!view_mask && clear_rect->layerCount !=
> iview->image->info.array_size)
> goto fail;
>
> /* RB+ doesn't work with CMASK fast clear on Stoney. */
> @@ -1060,13 +1072,13 @@ emit_clear(struct radv_cmd_buffer *cmd_buffer,
> const VkClearAttachment *clear_att,
> const VkClearRect *clear_rect,
> enum radv_cmd_flush_bits *pre_flush,
> - enum radv_cmd_flush_bits *post_flush)
> + enum radv_cmd_flush_bits *post_flush,
> + uint32_t view_mask)
> {
> if (clear_att->aspectMask & VK_IMAGE_ASPECT_COLOR_BIT) {
> -
> if (!emit_fast_color_clear(cmd_buffer, clear_att, clear_rect,
> -pre_flush, post_flush))
> - emit_color_clear(cmd_buffer, clear_att, clear_rect);
> +pre_flush,
Re: [Mesa-dev] [PATCH mesa] drop autotools
On Tuesday, 2018-12-18 09:51:19 +0100, Juan A. Suarez Romero wrote: > On Mon, 2018-12-17 at 19:51 +0100, Bas Nieuwenhuizen wrote: > > On Mon, Dec 17, 2018 at 6:33 PM Juan A. Suarez Romero > > wrote: > > > On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote: > > > > Cc: Emil Velikov > > > > Cc: Andres Gomez > > > > Cc: Juan A. Suarez Romero > > > > Cc: Dylan Baker > > > > Signed-off-by: Eric Engestrom > > > > --- > > > > This patch depends on the releasing procedure in docs/releasing.html to > > > > be updated to not rely on autotools anymore. > > > > > > > > I think our release managers (cc'ed) should work together and figure out > > > > the procedure they want to go by; only once that's done can we delete > > > > these 200+ files and 14k+ lines :) > > > > > > I'll let others to talk. But my preference would be to land this for next > > > 19.0 > > > branchpoint, just a couple of days before the branchpoint, so 19.0.x > > > releases > > > get rid of autotools. > > > > > > This way we have time to fix any remaining issue, and make like easier > > > for those > > > in charge of 18.3.x releases, which I think should support autotools > > > until the > > > end of its life. > > > > Can I suggest the inverse, pushing this long before any branchpoint? > > > > As with any migration, users only start using when you force them too, > > and that means a bunch of non-working usecases are going to be > > detected once this patch is pushed and some more people are forced to > > it. Sure, the last call discussion served to tease some of these out, > > but I expect even more will turn up if you submit this. > > I agreed here, something this big should be done as far in advance as possible. > > The bad part is that this make life more complex for the person in charge of > the > stable release, because it means that any patch that touches the build system > will only touch the meson, but not the autotools, which means either the > original author or the release manager should fix the part of the autotools in > order to avoid breaking it. I agree, but also we're deleting it, we're already past the point of deprecating it, which means IMO it's fine to not fix it anymore (exceptions can always be made, but that would be the general rule). > > Of course, I'm assuming that once we remove the autotools, this must be kept > in > the entire life of the stable cycle branch. Of course, if it is fine to > remove > autotools between versions of the same X.Y releases, then go ahead. No, I don't think something like this should be done in the middle of a stable branch. BTW just to be clear, Dylan's patch superseeds mine and we'll land his (and he actually deserves the credit for getting rid of autotools): https://patchwork.freedesktop.org/patch/265715/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 24/53] intel/compiler: lower 16-bit flrp
Reviewed-by: Jason Ekstrand --- src/intel/compiler/brw_compiler.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/intel/compiler/brw_compiler.c b/src/intel/compiler/brw_compiler.c index f885e79c3e6..04a1a7cac4e 100644 --- a/src/intel/compiler/brw_compiler.c +++ b/src/intel/compiler/brw_compiler.c @@ -33,6 +33,7 @@ .lower_sub = true, \ .lower_fdiv = true,\ .lower_scmp = true,\ + .lower_flrp16 = true, \ .lower_fmod16 = true, \ .lower_fmod32 = true, \ .lower_fmod64 = false, \ -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 34/53] intel/compiler: fix ddy for half-float in gen8
We use ALign16 mode for this, since it is more convenient, but the PRM
for Broadwell states in Volume 3D Media GPGPU, Chapter 'Register region
restrictions', Section '1. Special Restrictions':
"In Align16 mode, the channel selects and channel enables apply to a
pair of half-floats, because these parameters are defined for DWord
elements ONLY. This is applicable when both source and destination
are half-floats."
This means that we cannot select individual HF elements using swizzles
like we do with 32-bit floats so we can't implement the required
regioning for this.
Use the gen11 path for this instead, which uses Align1 mode.
The restriction is not present in gen9 or gen10, where the Align16
implementation seems to work just fine.
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_generator.cpp | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_fs_generator.cpp
b/src/intel/compiler/brw_fs_generator.cpp
index 0802e80f54b..a5f93f20938 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -1280,8 +1280,14 @@ fs_generator::generate_ddy(const fs_inst *inst,
const uint32_t type_size = type_sz(src.type);
if (inst->opcode == FS_OPCODE_DDY_FINE) {
- /* produce accurate derivatives */
- if (devinfo->gen >= 11) {
+ /* produce accurate derivatives. We can do this easily in Align16
+ * but this is not supported in gen11+ and gen8 Align16 swizzles
+ * for Half-Float operands work in units of 32-bit and always
+ * select pairs of consecutive half-float elements, so we can't use
+ * use it for this.
+ */
+ if (devinfo->gen >= 11 ||
+ (devinfo->gen == 8 && src.type == BRW_REGISTER_TYPE_HF)) {
src = stride(src, 0, 2, 1);
struct brw_reg src_0 = byte_offset(src, 0 * type_size);
struct brw_reg src_2 = byte_offset(src, 2 * type_size);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
