[Mesa-dev] [Bug 107022] [RADV] The Witcher 3: Trembling of trees
https://bugs.freedesktop.org/show_bug.cgi?id=107022 --- Comment #21 from Samuel Pitoiset --- What settings are you using? -- 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] ac/surface: remove the overallocation workaround for Vega12
Reviewed-by: Samuel Pitoiset
On 11/8/18 3:13 AM, Marek Olšák wrote:
From: Marek Olšák
not needed anymore (probably since the tile_swizzle fix)
---
src/amd/common/ac_surface.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 1f7e2344625..edd710a968c 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -1587,24 +1587,20 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
case ADDR_SW_4KB_Z_X:
case ADDR_SW_64KB_Z_X:
case ADDR_SW_VAR_Z_X:
surf->micro_tile_mode = RADEON_MICRO_MODE_DEPTH;
break;
default:
assert(0);
}
- /* Temporary workaround to prevent VM faults and hangs. */
- if (info->family == CHIP_VEGA12)
- surf->fmask_size *= 8;
-
return 0;
}
int ac_compute_surface(ADDR_HANDLE addrlib, const struct radeon_info *info,
const struct ac_surf_config *config,
enum radeon_surf_mode mode,
struct radeon_surf *surf)
{
int r;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: add support for removing redundant stores to copy prop var
For example the following type of thing is seen in TCS from
a number of Vulkan and DXVK games:
vec1 32 ssa_557 = deref_var &oPatch (shader_out float)
vec1 32 ssa_558 = intrinsic load_deref (ssa_557) ()
vec1 32 ssa_559 = deref_var &oPatch@42 (shader_out float)
vec1 32 ssa_560 = intrinsic load_deref (ssa_559) ()
vec1 32 ssa_561 = deref_var &oPatch@43 (shader_out float)
vec1 32 ssa_562 = intrinsic load_deref (ssa_561) ()
intrinsic store_deref (ssa_557, ssa_558) (1) /* wrmask=x */
intrinsic store_deref (ssa_559, ssa_560) (1) /* wrmask=x */
intrinsic store_deref (ssa_561, ssa_562) (1) /* wrmask=x */
No shader-db changes on i965 (SKL).
vkpipeline-db results RADV (VEGA):
Totals from affected shaders:
SGPRS: 8152 -> 8016 (-1.67 %)
VGPRS: 6780 -> 7068 (4.25 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 480420 -> 468576 (-2.47 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 1027 -> 992 (-3.41 %)
Wait states: 0 -> 0 (0.00 %)
The Max Waves and VGPRS changes here are misleading. What is
happening is a bunch of TCS outputs are being optimised away as
they are now recognised as unused. This results in more varyings
being compacted via nir_compact_varyings() which can results in
more register pressure. This is an existing problem independent
of this patch. I've run some benchmarks and haven't noticed any
regrssions in affected games.
---
src/compiler/nir/nir_opt_copy_prop_vars.c | 30 +++
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c
b/src/compiler/nir/nir_opt_copy_prop_vars.c
index 7a21ad56c79..fdabc1769a5 100644
--- a/src/compiler/nir/nir_opt_copy_prop_vars.c
+++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
@@ -676,18 +676,28 @@ copy_prop_vars_block(struct copy_prop_var_state *state,
}
case nir_intrinsic_store_deref: {
- struct value value = {
-.is_ssa = true
- };
-
- for (unsigned i = 0; i < intrin->num_components; i++)
-value.ssa[i] = intrin->src[1].ssa;
-
nir_deref_instr *dst = nir_src_as_deref(intrin->src[0]);
- unsigned wrmask = nir_intrinsic_write_mask(intrin);
struct copy_entry *entry =
-get_entry_and_kill_aliases(copies, dst, wrmask);
- store_to_entry(state, entry, &value, wrmask);
+lookup_entry_for_deref(copies, dst, nir_derefs_equal_bit);
+ if (entry && entry->src.ssa[0] == intrin->src[1].ssa) {
+/* If we are storing the value from a load of the same var the
+ * store is redundant so remove it.
+ */
+nir_instr_remove(instr);
+ } else {
+struct value value = {
+ .is_ssa = true
+};
+
+for (unsigned i = 0; i < intrin->num_components; i++)
+ value.ssa[i] = intrin->src[1].ssa;
+
+unsigned wrmask = nir_intrinsic_write_mask(intrin);
+struct copy_entry *entry =
+ get_entry_and_kill_aliases(copies, dst, wrmask);
+store_to_entry(state, entry, &value, wrmask);
+ }
+
break;
}
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir/constant_folding: fix incorrect bit-size check
Reviewed-by: Samuel Iglesias Gonsálvez
Sam
On Wednesday, 31 October 2018 12:18:34 (CET) Iago Toral Quiroga wrote:
> nir_alu_type_get_type_size takes a type as parameter and we were
> passing a bit-size instead, which did what we wanted by accident,
> since a bit-size of zero matches nir_type_invalid, which has a
> size of 0 too.
> ---
> src/compiler/nir/nir_opt_constant_folding.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_constant_folding.c
> b/src/compiler/nir/nir_opt_constant_folding.c index
> e5ec5e9583f..c91e7e16855 100644
> --- a/src/compiler/nir/nir_opt_constant_folding.c
> +++ b/src/compiler/nir/nir_opt_constant_folding.c
> @@ -63,10 +63,8 @@ constant_fold_alu_instr(nir_alu_instr *instr, void
> *mem_ctx) if (!instr->src[i].src.is_ssa)
> return false;
>
> - if (bit_size == 0 &&
> -
> !nir_alu_type_get_type_size(nir_op_infos[instr->op].input_sizes[i])) { +
> if (bit_size == 0 && nir_op_infos[instr->op].input_sizes[i] == 0)
> bit_size = instr->src[i].src.ssa->bit_size;
> - }
>
>nir_instr *src_instr = instr->src[i].src.ssa->parent_instr;
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] intel/compiler: fix node interference of simd16 instructions
On Wednesday, 17 October 2018 12:05:42 (CET) Iago Toral Quiroga wrote:
> SIMD16 instructions need to have additional interferences to prevent
> source / destination hazards when the source and destination registers
> are off by one register.
>
> While we already have code to handle this, it was only running for SIMD16
> dispatches, however, we can have SIDM16 instructions in a SIMD8 dispatch.
> An example of this are pull constant loads since commit b56fa830c6095,
> but there are more cases.
>
> This fixes a number of CTS test failues found in work-in-progress
failures
> tests that were hitting this situation for 16-wide pull constants
> in a SIMD8 program.
> ---
> src/intel/compiler/brw_fs_reg_allocate.cpp | 36 ++
> 1 file changed, 17 insertions(+), 19 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_reg_allocate.cpp
> b/src/intel/compiler/brw_fs_reg_allocate.cpp index 42ccb28de6..f72826bc41
> 100644
> --- a/src/intel/compiler/brw_fs_reg_allocate.cpp
> +++ b/src/intel/compiler/brw_fs_reg_allocate.cpp
> @@ -632,26 +632,24 @@ fs_visitor::assign_regs(bool allow_spilling, bool
> spill_all) }
> }
>
> - if (dispatch_width > 8) {
> - /* In 16-wide dispatch we have an issue where a compressed
> - * instruction is actually two instructions executed simultaneiously.
> - * It's actually ok to have the source and destination registers be
> - * the same. In this case, each instruction over-writes its own -
> * source and there's no problem. The real problem here is if the -
> * source and destination registers are off by one. Then you can end -
>* up in a scenario where the first instruction over-writes the - *
> source of the second instruction. Since the compiler doesn't know -
> * about this level of granularity, we simply make the source and - *
> destination interfere.
> - */
> - foreach_block_and_inst(block, fs_inst, inst, cfg) {
> - if (inst->dst.file != VGRF)
> -continue;
> + /* In 16-wide instructions we have an issue where a compressed
> +* instruction is actually two instructions executed simultaneiously.
simultaneously
With these two changes,
Reviewed-by: Samuel Iglesias Gonsálvez
Sam
> +* It's actually ok to have the source and destination registers be
> +* the same. In this case, each instruction over-writes its own
> +* source and there's no problem. The real problem here is if the
> +* source and destination registers are off by one. Then you can end
> +* up in a scenario where the first instruction over-writes the
> +* source of the second instruction. Since the compiler doesn't know
> +* about this level of granularity, we simply make the source and
> +* destination interfere.
> +*/
> + foreach_block_and_inst(block, fs_inst, inst, cfg) {
> + if (inst->exec_size < 16 || inst->dst.file != VGRF)
> + continue;
>
> - for (int i = 0; i < inst->sources; ++i) {
> -if (inst->src[i].file == VGRF) {
> - ra_add_node_interference(g, inst->dst.nr, inst->src[i].nr);
> -}
> + for (int i = 0; i < inst->sources; ++i) {
> + if (inst->src[i].file == VGRF) {
> +ra_add_node_interference(g, inst->dst.nr, inst->src[i].nr);
> }
>}
> }
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] nir/constant_folding: fix incorrect bit-size check
This is still waiting for a review.
Iago
On Wed, 2018-10-31 at 12:18 +0100, Iago Toral Quiroga wrote:
> nir_alu_type_get_type_size takes a type as parameter and we were
> passing a bit-size instead, which did what we wanted by accident,
> since a bit-size of zero matches nir_type_invalid, which has a
> size of 0 too.
> ---
> src/compiler/nir/nir_opt_constant_folding.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_constant_folding.c
> b/src/compiler/nir/nir_opt_constant_folding.c
> index e5ec5e9583f..c91e7e16855 100644
> --- a/src/compiler/nir/nir_opt_constant_folding.c
> +++ b/src/compiler/nir/nir_opt_constant_folding.c
> @@ -63,10 +63,8 @@ constant_fold_alu_instr(nir_alu_instr *instr, void
> *mem_ctx)
>if (!instr->src[i].src.is_ssa)
> return false;
>
> - if (bit_size == 0 &&
> - !nir_alu_type_get_type_size(nir_op_infos[instr-
> >op].input_sizes[i])) {
> + if (bit_size == 0 && nir_op_infos[instr->op].input_sizes[i] ==
> 0)
> bit_size = instr->src[i].src.ssa->bit_size;
> - }
>
>nir_instr *src_instr = instr->src[i].src.ssa->parent_instr;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl/test: Fix use after free in test_optpass.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108636
Reviewed-by: Tapani Pälli
On 11/7/18 10:01 AM, Hanno Böck wrote:
The variable state is free'd and afterwards state->error is used
as the return value, resulting in a use after free bug detected
by memory safety tools like address sanitizer.
Signed-off-by: Hanno Böck
---
src/compiler/glsl/test_optpass.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/compiler/glsl/test_optpass.cpp
b/src/compiler/glsl/test_optpass.cpp
index 735129d..638ffeb 100644
--- a/src/compiler/glsl/test_optpass.cpp
+++ b/src/compiler/glsl/test_optpass.cpp
@@ -166,6 +166,7 @@ int test_optpass(int argc, char **argv)
int loop = 0;
int shader_type = GL_VERTEX_SHADER;
int quiet = 0;
+ int error;
const struct option optpass_opts[] = {
{ "input-ir", no_argument, &input_format_ir, 1 },
@@ -264,9 +265,11 @@ int test_optpass(int argc, char **argv)
printf("--\n");
}
+ error = state->error;
+
ralloc_free(state);
ralloc_free(shader);
- return state->error;
+ return error;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] query validation fixes
FYI there's a whole lot of tests that start to fail when this series running on Intel CI. It includes dEQP but also Piglit tests, can you do Intel CI run or do you want me to send you results? // Tapani On 11/7/18 5:58 PM, Erik Faye-Lund wrote: Here's a bunch of patches for missing error generation in the query buffer code. The general pattern, is that code that directly checks ctx->Extensions.FOO_bar instead of using _mesa_has_FOO_bar(ctx) will often end up drawing the wrong conclusion on ES, because the flag in ctx->Extensions only tells us that the *driver* supports this, not the target-API. This was noticed when porting the NV_conditional_rendering piglit tests to ES 2, where the observation was that using GL_SAMPLES_PASSED worked in ES 3, but not when run on ES 2. Some other related issues that was noticed while fixing this are also included. Erik Faye-Lund (13): mesa/main: correct requirement for EXT_occlusion_query_boolean mesa/main: correct year for EXT_occlusion_query_boolean mesa/main: use non-prefixed enums for consistency mesa/main: simplify pipeline-statistics query validation mesa/main: fix validation of GL_SAMPLES_PASSED mesa/main: fix validation of GL_ANY_SAMPLES_PASSED mesa/main: fix validation of GL_ANY_SAMPLES_PASSED_CONSERVATIVE mesa/main: fix validation of GL_TIME_ELAPSED mesa/main: fix validation of transform-feedback queries mesa/main: fix validation of transform-feedback overflow queries mesa/main: fix validation of ARB_query_buffer_object mesa/main: fix validation of GL_TIMESTAMP mesa/main: remove overly strict query-validation src/mesa/main/extensions_table.h | 2 +- src/mesa/main/queryobj.c | 108 ++- 2 files changed, 48 insertions(+), 62 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Lift restriction in external textures for EGLImage support
On 11/7/18 9:51 PM, Kenneth Graunke wrote:
On Wednesday, October 31, 2018 5:12:40 PM PST Aditya Swarup wrote:
For Intel platforms, we support external textures only for EGLImages
created with EGL_EXT_image_dma_buf_import. This restriction seems to
be Intel specific and not present for other platforms.
While running SKQP test - unitTest_EGLImageTest, GL_INVALID is sent
to the test because of this restriction.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105301
Fixes Skqp's unitTest_EGLImageTest test.
Change-Id: I54a162db534d54858319fdb98ba502314d28fc27
Signed-off-by: Aditya Swarup
---
src/mesa/drivers/dri/i965/intel_image.h | 3 ---
src/mesa/drivers/dri/i965/intel_screen.c| 2 --
src/mesa/drivers/dri/i965/intel_tex_image.c | 10 --
3 files changed, 15 deletions(-)
I'm pretty convinced by the spec quotes from Dongseong and Aditya
in Bugzilla - I think this needs to be allowed. Jason seems to think
that we're already turning off compression. I checked the OES_EGL_image
spec and it discusses how mipmapping works - basically, if the client
has any that aren't included in the EGL image, pitch them. If the
client later makes more, it ceases to be an EGL image target, and...
you keep the broken pieces? That seems pretty doable.
Jason and I are unsure whether we've handled all the corners, but it
seems like a matter of raising errors in the right places...something
we can probably do if we encounter issues later.
Tapani, what do you think? It seems OK to me, and so I'd give this
patch my Reviewed-by, but I want you to be happy with it before we
land anything.
Android team has done full validation round and haven't seen any issues
so it looks we are safe to lift this restriction.
Reviewed-by: Tapani Pälli
diff --git a/src/mesa/drivers/dri/i965/intel_image.h
b/src/mesa/drivers/dri/i965/intel_image.h
index a8193c6def96..ca604159dc20 100644
--- a/src/mesa/drivers/dri/i965/intel_image.h
+++ b/src/mesa/drivers/dri/i965/intel_image.h
@@ -89,9 +89,6 @@ struct __DRIimageRec {
GLuint tile_y;
bool has_depthstencil;
- /** The image was created with EGL_EXT_image_dma_buf_import. */
- bool dma_buf_imported;
-
/** Offset of the auxiliary compression surface in the bo. */
uint32_t aux_offset;
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c b/src/mesa/drivers/dri/i965/intel_screen.c
index b117928f18ec..26ec42b4c8b1 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -958,7 +958,6 @@ intel_dup_image(__DRIimage *orig_image, void *loaderPrivate)
image->tile_y = orig_image->tile_y;
image->has_depthstencil = orig_image->has_depthstencil;
image->data= loaderPrivate;
- image->dma_buf_imported = orig_image->dma_buf_imported;
image->aux_offset = orig_image->aux_offset;
image->aux_pitch = orig_image->aux_pitch;
@@ -1238,7 +1237,6 @@ intel_create_image_from_dma_bufs2(__DRIscreen *dri_screen,
return NULL;
}
- image->dma_buf_imported = true;
image->yuv_color_space = yuv_color_space;
image->sample_range = sample_range;
image->horizontal_siting = horizontal_siting;
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index fae179214dd3..1b4083af530d 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -616,16 +616,6 @@ intel_image_target_texture_2d(struct gl_context *ctx,
GLenum target,
if (image == NULL)
return;
- /* We support external textures only for EGLImages created with
-* EGL_EXT_image_dma_buf_import. We may lift that restriction in the future.
-*/
- if (target == GL_TEXTURE_EXTERNAL_OES && !image->dma_buf_imported) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
-"glEGLImageTargetTexture2DOES(external target is enabled only "
- "for images created with EGL_EXT_image_dma_buf_import");
- return;
- }
-
/* Disallow depth/stencil textures: we don't have a way to pass the
* separate stencil miptree of a GL_DEPTH_STENCIL texture through.
*/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: don't do L3 thread pinning for Blender
Thanks a lot man. I'll reconsider this depending on the results I receive. I may also just pin the Mesa threads and keep the app thread intact. It should perform OK with glthread, but not without glthread. Another option is to have the gallium and winsys threads "chase" the main thread within the CPU by changing the thread affinity based on getcpu(). Marek On Tue, Nov 6, 2018 at 4:50 PM Edmondo Tommasina < edmondo.tommas...@gmail.com> wrote: > Hi Marek > > It would be nice to have the driconf part of this patch committed in > master to make it easy to test with and without the L3 pinning, so this > patch is: > > Reviewed-by: Edmondo Tommasina > > Now with this patch in place I'm starting to collect some numbers with > and without the CCX affinity on my setup: > > CPU: AMD Ryzen 5 2600 Six-Core Processor > GFX: AMD Radeon (TM) RX 470 Graphics (POLARIS10, DRM 3.27.0, 4.19.0-rc4, > LLVM 8.0.0) > RAM: G.Skill Flare X 3200 CL14 > > drawoverhead > > As expected great numbers with drawoverhead. For example: > > With L3 thread pinning: > 29: DrawElements ( 1 VBO, 8 UBO, 8 Tex) w/ sample mask enable change: > 6.91 million (99.5%) > > Without: > 29: DrawElements ( 1 VBO, 8 UBO, 8 Tex) w/ sample mask enable change: > 5.55 million (89.0%) > > > Hitman Benchmark > > Here we have a performance loss. > > With L3 thread pinning: > > 5765 frames > 50.21fps Average > 10.16fps Min > 137.31fps Max > 19.92ms Average > 7.28ms Min > 98.42ms Max > > > Without L3 thread pinning: > > 6024 frames > 52.45fps Average > 10.28fps Min > 129.85fps Max > 19.07ms Average > 7.70ms Min > 97.24ms Max > > With thread pinning I lose about 2 FPS on average. > > Looking at the CPU load of Hitman Benchmark: > > With thread pinnig we see as expected the first 3 cores (SMT active) > working > and the cores on the other CCX doing nothing: > > 09:46:50 PM CPU%usr %nice%sys %iowait%irq %soft %steal > %guest %gnice %idle > 09:46:53 PM all 33.430.001.850.000.000.030.00 > 0.000.00 64.70 > 09:46:53 PM0 68.790.004.030.000.000.000.00 > 0.000.00 27.18 > 09:46:53 PM1 64.630.003.400.000.000.000.00 > 0.000.00 31.97 > 09:46:53 PM2 68.460.003.690.000.000.000.00 > 0.000.00 27.85 > 09:46:53 PM3 66.670.002.690.000.000.000.00 > 0.000.00 30.64 > 09:46:53 PM4 66.890.003.040.000.000.000.00 > 0.000.00 30.07 > 09:46:53 PM5 64.070.003.730.000.000.000.00 > 0.000.00 32.20 > 09:46:53 PM60.670.000.340.000.000.000.00 > 0.000.00 98.99 > 09:46:53 PM70.660.000.000.000.000.330.00 > 0.000.00 99.01 > 09:46:53 PM80.330.000.000.000.000.000.00 > 0.000.00 99.67 > 09:46:53 PM91.330.001.000.000.000.000.00 > 0.000.00 97.67 > 09:46:53 PM 100.330.000.000.000.000.000.00 > 0.000.00 99.67 > 09:46:53 PM 110.330.000.330.000.000.000.00 > 0.000.00 99.33 > > Without pinning all cores are working: > > 09:32:07 PM CPU%usr %nice%sys %iowait%irq %soft %steal > %guest %gnice %idle > 09:32:10 PM all 42.770.003.480.030.000.030.00 > 0.000.00 53.70 > 09:32:10 PM0 48.140.004.410.000.000.340.00 > 0.000.00 47.12 > 09:32:10 PM1 37.710.003.370.000.000.000.00 > 0.000.00 58.92 > 09:32:10 PM2 42.810.003.770.000.000.000.00 > 0.000.00 53.42 > 09:32:10 PM3 44.630.003.020.000.000.000.00 > 0.000.00 52.35 > 09:32:10 PM4 44.440.002.690.000.000.000.00 > 0.000.00 52.86 > 09:32:10 PM5 43.480.003.340.000.000.000.00 > 0.000.00 53.18 > 09:32:10 PM6 45.300.003.690.000.000.000.00 > 0.000.00 51.01 > 09:32:10 PM7 46.310.003.020.000.000.000.00 > 0.000.00 50.67 > 09:32:10 PM8 38.460.004.350.000.000.000.00 > 0.000.00 57.19 > 09:32:10 PM9 35.350.004.040.340.000.000.00 > 0.000.00 60.27 > 09:32:10 PM 10 43.810.003.340.000.000.000.00 > 0.000.00 52.84 > 09:32:10 PM 11 42.810.002.680.000.000.000.00 > 0.000.00 54.52 > > So it could be if an application takes advantage of many cores, the > L3 thread pinning could negate the internal mesa benefits on my CPU. > > I'll try to collect more numbers, but right now I have the feeling, it > would be good to commit the driconf option an
[Mesa-dev] [PATCH] ac/surface: remove the overallocation workaround for Vega12
From: Marek Olšák
not needed anymore (probably since the tile_swizzle fix)
---
src/amd/common/ac_surface.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 1f7e2344625..edd710a968c 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -1587,24 +1587,20 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
case ADDR_SW_4KB_Z_X:
case ADDR_SW_64KB_Z_X:
case ADDR_SW_VAR_Z_X:
surf->micro_tile_mode = RADEON_MICRO_MODE_DEPTH;
break;
default:
assert(0);
}
- /* Temporary workaround to prevent VM faults and hangs. */
- if (info->family == CHIP_VEGA12)
- surf->fmask_size *= 8;
-
return 0;
}
int ac_compute_surface(ADDR_HANDLE addrlib, const struct radeon_info *info,
const struct ac_surf_config *config,
enum radeon_surf_mode mode,
struct radeon_surf *surf)
{
int r;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: fix improper clamping of vertex index when fetching gs inputs
From: Roland Scheidegger
Because we only have one file_max for the (2d) gs input file, the value
actually represents the max of attrib and vertex index (although I'm
not entirely sure if we really want the max, since the max valid value
of the vertex dimension can be easily deduced from the input primitive).
Thus in cases where the number of inputs is higher than the number of
vertices per prim, we did not properly clamp the vertex index, which
would result in out-of-bound fetches, potentially causing segfaults
(the segfaults seemed actually difficult to trigger, but valgrind
certainly wasn't happy). This might have happened even if the shader
did not actually try to fetch bogus vertices, if the fetching happened
in non-active conditional clauses.
To fix simply use the correct max vertex index value (derived from
the input prim type) instead when clamping for this case.
---
.../auxiliary/gallivm/lp_bld_tgsi_soa.c | 38 ++-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 83d7dbea9a..0db81b31ad 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -41,6 +41,7 @@
#include "util/u_debug.h"
#include "util/u_math.h"
#include "util/u_memory.h"
+#include "util/u_prim.h"
#include "tgsi/tgsi_dump.h"
#include "tgsi/tgsi_exec.h"
#include "tgsi/tgsi_info.h"
@@ -1059,7 +1060,8 @@ emit_mask_scatter(struct lp_build_tgsi_soa_context *bld,
static LLVMValueRef
get_indirect_index(struct lp_build_tgsi_soa_context *bld,
unsigned reg_file, unsigned reg_index,
- const struct tgsi_ind_register *indirect_reg)
+ const struct tgsi_ind_register *indirect_reg,
+ unsigned index_limit)
{
LLVMBuilderRef builder = bld->bld_base.base.gallivm->builder;
struct lp_build_context *uint_bld = &bld->bld_base.uint_bld;
@@ -1107,8 +1109,7 @@ get_indirect_index(struct lp_build_tgsi_soa_context *bld,
*/
if (reg_file != TGSI_FILE_CONSTANT) {
max_index = lp_build_const_int_vec(bld->bld_base.base.gallivm,
- uint_bld->type,
-
bld->bld_base.info->file_max[reg_file]);
+ uint_bld->type, index_limit);
assert(!uint_bld->type.sign);
index = lp_build_min(uint_bld, index, max_index);
@@ -1224,7 +1225,8 @@ emit_fetch_constant(
indirect_index = get_indirect_index(bld,
reg->Register.File,
reg->Register.Index,
- ®->Indirect);
+ ®->Indirect,
+
bld->bld_base.info->file_max[reg->Register.File]);
/* All fetches are from the same constant buffer, so
* we need to propagate the size to a vector to do a
@@ -1341,7 +1343,8 @@ emit_fetch_immediate(
indirect_index = get_indirect_index(bld,
reg->Register.File,
reg->Register.Index,
- ®->Indirect);
+ ®->Indirect,
+
bld->bld_base.info->file_max[reg->Register.File]);
/*
* Unlike for other reg classes, adding pixel offsets is unnecessary -
* immediates are stored as full vectors (FIXME??? - might be better
@@ -1414,7 +1417,8 @@ emit_fetch_input(
indirect_index = get_indirect_index(bld,
reg->Register.File,
reg->Register.Index,
- ®->Indirect);
+ ®->Indirect,
+
bld->bld_base.info->file_max[reg->Register.File]);
index_vec = get_soa_array_offsets(&bld_base->uint_bld,
indirect_index,
@@ -1502,7 +1506,15 @@ emit_fetch_gs_input(
attrib_index = get_indirect_index(bld,
reg->Register.File,
reg->Register.Index,
-®->Indirect);
+®->Indirect,
+ /*
+* XXX: this is possibly not quite the right value, since file_max may be
+* larger than the max attrib index, due to it being the max of declared
+* inputs AND the max vertices per prim (which is 6 for tri adj).
+* It should however be safe to use (since we always allocate
+* PIPE_MAX_SHADER_INPUTS (80) for it, which is overallocated quite a bit).
+*/
+info->file_max[reg->R
Re: [Mesa-dev] [PATCH v2] mesa: expose NV_conditional_render on GLES
Reviewed-by: Marek Olšák Marek On Wed, Nov 7, 2018 at 4:19 PM Erik Faye-Lund wrote: > The extension spec has been updated to include GLES 2 support, so let's > enable it there. > > Signed-off-by: Erik Faye-Lund > --- > Here's a V2 of this patch. The only difference is that this also expose > the extension on ES2. The piglit patches has also been updated: > https://patchwork.freedesktop.org/series/52039/ > > src/mapi/glapi/gen/NV_conditional_render.xml | 4 ++-- > src/mesa/main/extensions_table.h | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/mapi/glapi/gen/NV_conditional_render.xml > b/src/mapi/glapi/gen/NV_conditional_render.xml > index 926b2629412..4b28c466f7d 100644 > --- a/src/mapi/glapi/gen/NV_conditional_render.xml > +++ b/src/mapi/glapi/gen/NV_conditional_render.xml > @@ -13,12 +13,12 @@ > > > > - alias="BeginConditionalRender"> > + alias="BeginConditionalRender" es2="2.0"> > > > > > - > + es2="2.0"> > > > > diff --git a/src/mesa/main/extensions_table.h > b/src/mesa/main/extensions_table.h > index a516a1b17f8..04a319271e0 100644 > --- a/src/mesa/main/extensions_table.h > +++ b/src/mesa/main/extensions_table.h > @@ -345,7 +345,7 @@ EXT(MESA_ycbcr_texture , > MESA_ycbcr_texture > EXT(NVX_gpu_memory_info , NVX_gpu_memory_info > , GLL, GLC, x , x , 2013) > > EXT(NV_blend_square , dummy_true >, GLL, x , x , x , 1999) > -EXT(NV_conditional_render , NV_conditional_render > , GLL, GLC, x , x , 2008) > +EXT(NV_conditional_render , NV_conditional_render > , GLL, GLC, x , ES2, 2008) > EXT(NV_conservative_raster , NV_conservative_raster >, GLL, GLC, ES1, ES2, 2015) > EXT(NV_conservative_raster_dilate , > NV_conservative_raster_dilate , GLL, GLC, ES1, ES2, 2015) > EXT(NV_conservative_raster_pre_snap , > NV_conservative_raster_pre_snap, GLL, GLC, ES1, ES2, 2017) > -- > 2.19.1 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/9] intel/fs: Use the new nir_src_is_const and friends
On Wed, Nov 7, 2018 at 4:06 PM Kenneth Graunke wrote: > On Wednesday, November 7, 2018 1:45:59 PM PST Jason Ekstrand wrote: > > On Wed, Nov 7, 2018 at 12:20 PM Kenneth Graunke > > wrote: > > > > > On Saturday, October 20, 2018 10:55:44 AM PST Jason Ekstrand wrote: > > > > @@ -553,14 +552,18 @@ > > > fs_visitor::optimize_frontfacing_ternary(nir_alu_instr *instr, > > > > if (src0->intrinsic != nir_intrinsic_load_front_face) > > > >return false; > > > > > > > > - nir_const_value *value1 = > nir_src_as_const_value(instr->src[1].src); > > > > - if (!value1 || fabsf(value1->f32[0]) != 1.0f) > > > > + if (!nir_src_is_const(instr->src[1].src) || > > > > + !nir_src_is_const(instr->src[2].src)) > > > >return false; > > > > > > > > - nir_const_value *value2 = > nir_src_as_const_value(instr->src[2].src); > > > > - if (!value2 || fabsf(value2->f32[0]) != 1.0f) > > > > + const float value1 = nir_src_as_float(instr->src[1].src); > > > > + const float value2 = nir_src_as_float(instr->src[2].src); > > > > + if (fabsf(value1) != 1.0f || fabsf(value2) != 1.0f) > > > >return false; > > > > > > > > + /* nir_opt_algebraic should have gotten rid of bcsel(b, a, a) */ > > > > + assert(value1 == -value2); > > > > + > > > > > > This is likely true, but it doesn't seem like this belongs in this > > > refactoring patch - we weren't doing it before, and no new code appears > > > to depend on the condition. > > > > > > Right. No *new* code does; but old code definitely does. Mind if I just > > make it a separate commit? > > Sure, that's fine, feel free to put my R-b on that one as well. > Cool. Will do. I'll push once Jenkins is happy. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/9] intel/fs: Use the new nir_src_is_const and friends
On Wednesday, November 7, 2018 1:45:59 PM PST Jason Ekstrand wrote: > On Wed, Nov 7, 2018 at 12:20 PM Kenneth Graunke > wrote: > > > On Saturday, October 20, 2018 10:55:44 AM PST Jason Ekstrand wrote: > > > @@ -553,14 +552,18 @@ > > fs_visitor::optimize_frontfacing_ternary(nir_alu_instr *instr, > > > if (src0->intrinsic != nir_intrinsic_load_front_face) > > >return false; > > > > > > - nir_const_value *value1 = nir_src_as_const_value(instr->src[1].src); > > > - if (!value1 || fabsf(value1->f32[0]) != 1.0f) > > > + if (!nir_src_is_const(instr->src[1].src) || > > > + !nir_src_is_const(instr->src[2].src)) > > >return false; > > > > > > - nir_const_value *value2 = nir_src_as_const_value(instr->src[2].src); > > > - if (!value2 || fabsf(value2->f32[0]) != 1.0f) > > > + const float value1 = nir_src_as_float(instr->src[1].src); > > > + const float value2 = nir_src_as_float(instr->src[2].src); > > > + if (fabsf(value1) != 1.0f || fabsf(value2) != 1.0f) > > >return false; > > > > > > + /* nir_opt_algebraic should have gotten rid of bcsel(b, a, a) */ > > > + assert(value1 == -value2); > > > + > > > > This is likely true, but it doesn't seem like this belongs in this > > refactoring patch - we weren't doing it before, and no new code appears > > to depend on the condition. > > > Right. No *new* code does; but old code definitely does. Mind if I just > make it a separate commit? Sure, that's fine, feel free to put my R-b on that one as well. 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 08/12] meson doesn't use env vars, WAS: configure.ac: deprecate --with-llvm-prefix
Quoting Jan Vesely (2018-11-07 12:56:30) > On Wed, 2018-11-07 at 11:34 -0800, Dylan Baker wrote: > > Quoting Jan Vesely (2018-11-07 10:39:48) > > > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote: > > > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer wrote: > > > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote: > > > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote: > > > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely > > > > > > > wrote: > > > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote: > > > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer > > > > > > > > > wrote: > > > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote: > > > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env > > > > > > > > > > > var remembered > > > > > > > > > > > between reconfigure (touch configure.ac; make) or do I > > > > > > > > > > > need to provide > > > > > > > > > > > it explicitly every time configure is run? > > > > > > > > > > > > > > > > > > > > I don't know the answer, but agree that would be a minimum > > > > > > > > > > requirement > > > > > > > > > > for this change. > > > > > > > > > > > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been > > > > > > > > > around for > > > > > > > > > years, it will work for any Mesa checkout since its inception. > > > > > > > > > You can safely bisect Mesa and things will just work. > > > > > > > > > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every > > > > > > > > time > > > > > > > > bisect changes configure.ac? > > > > > > > > > > > > > > > You can do (although there's other options if this one seems > > > > > > > weird) > > > > > > > > > > > > > > $ LLVM_CONFIG=... ../autogen.sh > > > > > > > > > > > > That does not answer my question. > > > > > > > > > > > > suppose the following sequence: > > > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config > > > > > > ../mesa-src/autogen.sh > > > > > > ... > > > > > > llvm:yes > > > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config > > > > > > llvm-version:4.0.1 > > > > > > ... > > > > > > $ make -j128 > > > > > > $ touch ../mesa-src/configure.ac > > > > > > $ make -j128 > > > > > > ... > > > > > > llvm:yes > > > > > > llvm-config: /usr/bin/llvm-config > > > > > > llvm-version:7.0.0 > > > > > > ... > > > > > > > > > > > > the second reconfigure silently reverted back to system default > > > > > > llvm. > > > > > > That's a loss of capabilty for me. > > > > > > > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the > > > > > current form. > > > > > > > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might > > > > > not be too hard to make this work with the environment variable. I > > > > > don't > > > > > know the preferred way to do that however. > > > > > > > > > Right, I misread the usecase :-( Sorry about that. > > > > The following works like a charm: > > > > > > > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/... > > > > make > > > > touch .../configure.ac > > > > make > > > > > > ouch, that's rather ugly. What is the reason to prefer env var vs. > > > proper option (like --with-llvm-config)? > > > meson also seems to prefer env var for some reason. > > > > Actually, we (meson) made the concious choice not to use env vars, our > > solution > > is config files (like cross files) for native compilation. They work just > > like > > cross file, but for native compilation (load at initial configuration, don't > > reload change on subsequent reconfigurations): > > > > $ cat llvm-4.0 > > [binaries] > > llvm-config = /usr/local/lib/llvm-4.0/bin/llvm-config > > > > $ meson build --native-file llvm-4.0 > > > > Hopefully this series in the in the final stretch and can land shortly, and > > be > > present in 0.49.0 > > thanks for the clarification. as long as the setting survives > reconfigure+rebuild I'm fine. > just out of curiosity. can meson combine multiple native files, or do > you need to crate a new one with the desired combination of settings? You'll be able to load multiple native files, values in the next file will replace the previous (if they conflict), like: $ cat overridden [binaries] c = /bin/gcc llvm-config = /usr/local/bin/llvm-config $ cat overrides [binaries] c = /usr/local/bin/clang $ meson build --native-file overridden --native-file overrides Results in /usr/local/bin/clang for a C compiler, and llvm-config as /usr/local/bin/llvm-config 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 1/3] nir: add new linking opt nir_move_out_const_to_consumer()
Timothy Arceri writes: > On 7/11/18 7:40 pm, Samuel Pitoiset wrote: >> IIRC, I wrote a pass similar to this one a while ago, but never finished >> it. >> >> I don't really like the helper name though, how about >> nir_link_immediate_varyings()? or nir_link_constant_varyings()? > > Sure. Happy to change the name. I''ll go with > nir_link_constant_varyings() unless there are any other objections. Haven't reviewed the code, but I like that name. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108611] [radv] [regression, bisected]: LLVM 8.0 breaks lighting in Mass Effect Andromeda
https://bugs.freedesktop.org/show_bug.cgi?id=108611 Nicolai Hähnle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 108611] [radv] [regression, bisected]: LLVM 8.0 breaks lighting in Mass Effect Andromeda
https://bugs.freedesktop.org/show_bug.cgi?id=108611 --- Comment #6 from Nicolai Hähnle --- I'm reverting the commit to LLVM for now. The change exposed a bug in how divergence analysis info is passed through code generation, and it looks like I will have to touch common code to fix that bug. -- 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 6/9] intel/fs: Use the new nir_src_is_const and friends
On Wed, Nov 7, 2018 at 12:20 PM Kenneth Graunke wrote: > On Saturday, October 20, 2018 10:55:44 AM PST Jason Ekstrand wrote: > > @@ -553,14 +552,18 @@ > fs_visitor::optimize_frontfacing_ternary(nir_alu_instr *instr, > > if (src0->intrinsic != nir_intrinsic_load_front_face) > >return false; > > > > - nir_const_value *value1 = nir_src_as_const_value(instr->src[1].src); > > - if (!value1 || fabsf(value1->f32[0]) != 1.0f) > > + if (!nir_src_is_const(instr->src[1].src) || > > + !nir_src_is_const(instr->src[2].src)) > >return false; > > > > - nir_const_value *value2 = nir_src_as_const_value(instr->src[2].src); > > - if (!value2 || fabsf(value2->f32[0]) != 1.0f) > > + const float value1 = nir_src_as_float(instr->src[1].src); > > + const float value2 = nir_src_as_float(instr->src[2].src); > > + if (fabsf(value1) != 1.0f || fabsf(value2) != 1.0f) > >return false; > > > > + /* nir_opt_algebraic should have gotten rid of bcsel(b, a, a) */ > > + assert(value1 == -value2); > > + > > This is likely true, but it doesn't seem like this belongs in this > refactoring patch - we weren't doing it before, and no new code appears > to depend on the condition. Right. No *new* code does; but old code definitely does. Mind if I just make it a separate commit? > Normally I wouldn't mind, but I'm a bit > paranoid about float equality in assertions. It's probably fine, > though, since we ensured fabsf is 1.0f earlier... > Patches 5-9 are: > Reviewed-by: Kenneth Graunke > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107022] [RADV] The Witcher 3: Trembling of trees
https://bugs.freedesktop.org/show_bug.cgi?id=107022 --- Comment #20 from zefkerri...@gmail.com --- (In reply to Samuel Pitoiset from comment #18) > Are you guys still able to reproduce that problem? I'm trying to reproduce > it. With commit 16f10230 this bug unfortunately is still present. -- 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 107022] [RADV] The Witcher 3: Trembling of trees
https://bugs.freedesktop.org/show_bug.cgi?id=107022 --- Comment #19 from zefkerri...@gmail.com --- Created attachment 142402 --> https://bugs.freedesktop.org/attachment.cgi?id=142402&action=edit The Witcher 3 savegame file in the location where easy to reproduce this bug. -- 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 08/12] configure.ac: deprecate --with-llvm-prefix
On Wed, 2018-11-07 at 13:05 -0800, Matt Turner wrote: > On Wed, Nov 7, 2018 at 12:53 PM Jan Vesely wrote: > > On Wed, 2018-11-07 at 18:51 +, Emil Velikov wrote: > > > On Wed, 7 Nov 2018 at 18:39, Jan Vesely wrote: > > > > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote: > > > > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer wrote: > > > > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote: > > > > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote: > > > > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely > > > > > > > > wrote: > > > > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote: > > > > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer > > > > > > > > > > wrote: > > > > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote: > > > > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env > > > > > > > > > > > > var remembered > > > > > > > > > > > > between reconfigure (touch configure.ac; make) or do I > > > > > > > > > > > > need to provide > > > > > > > > > > > > it explicitly every time configure is run? > > > > > > > > > > > > > > > > > > > > > > I don't know the answer, but agree that would be a > > > > > > > > > > > minimum requirement > > > > > > > > > > > for this change. > > > > > > > > > > > > > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been > > > > > > > > > > around for > > > > > > > > > > years, it will work for any Mesa checkout since its > > > > > > > > > > inception. > > > > > > > > > > You can safely bisect Mesa and things will just work. > > > > > > > > > > > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every > > > > > > > > > time > > > > > > > > > bisect changes configure.ac? > > > > > > > > > > > > > > > > > You can do (although there's other options if this one seems > > > > > > > > weird) > > > > > > > > > > > > > > > > $ LLVM_CONFIG=... ../autogen.sh > > > > > > > > > > > > > > That does not answer my question. > > > > > > > > > > > > > > suppose the following sequence: > > > > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config > > > > > > > ../mesa-src/autogen.sh > > > > > > > ... > > > > > > > llvm:yes > > > > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config > > > > > > > llvm-version:4.0.1 > > > > > > > ... > > > > > > > $ make -j128 > > > > > > > $ touch ../mesa-src/configure.ac > > > > > > > $ make -j128 > > > > > > > ... > > > > > > > llvm:yes > > > > > > > llvm-config: /usr/bin/llvm-config > > > > > > > llvm-version:7.0.0 > > > > > > > ... > > > > > > > > > > > > > > the second reconfigure silently reverted back to system default > > > > > > > llvm. > > > > > > > That's a loss of capabilty for me. > > > > > > > > > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the > > > > > > current form. > > > > > > > > > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it > > > > > > might > > > > > > not be too hard to make this work with the environment variable. I > > > > > > don't > > > > > > know the preferred way to do that however. > > > > > > > > > > > Right, I misread the usecase :-( Sorry about that. > > > > > The following works like a charm: > > > > > > > > > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/... > > > > > make > > > > > touch .../configure.ac > > > > > make > > > > > > > > ouch, that's rather ugly. What is the reason to prefer env var vs. > > > > proper option (like --with-llvm-config)? > > > > meson also seems to prefer env var for some reason. > > > > I don't mind spending the time to send out the patches, but I'd like to > > > > make sure it's not a wasted effort. > > > > > > > From a general distribution POV, adding llvm-config to every project > > > 'feels' wasteful IMHO. Even if we ignore the "feels" part, there's the > > > aspect of duplicating the same code in XX projects. > > > Which with due time will result in a behavioural shift as copies diverge. > > > > > > In Mesa the toggle conflicts, in some weird ways, with the existing > > > --with-clang-libdir > > > > The idea would be to have one --with-llvm-config switch that subsumes > > all llvm related options (except maybe static vs. dynamic linking). > > > > I don't get the argument about other projects. > > Not all projects need to support multiple llvm versions. For those that > > do provide that option, having a configure, ehm, option sounds like the > > most straightforward way. > > Does Meson behave in the way you prefer? Can we make sure it does so > we don't need to go through this again soon? > > It doesn't make sense to me to debate an autotools clean up like this > when the plan is for autotools to go away in the next few months. yes. as long as the setting survives reconfigure+rebuild I'm fine. Postponing this patch until meson 49 is out (with the changes) and available in fedora/gentoo is good enough for me. Jan sig
[Mesa-dev] [Bug 108508] Graphic glitches with stream output support on OLAND AMD GPU GCN 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=108508 --- Comment #26 from Ahmed Elsayed --- One more thing that I forgot to add: All the games that I used with Wined3d, the textures are so dark. It is described in this issue: https://bugs.winehq.org/show_bug.cgi?id=46073 -- 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] [PATCH v2] mesa: expose NV_conditional_render on GLES
The extension spec has been updated to include GLES 2 support, so let's enable it there. Signed-off-by: Erik Faye-Lund --- Here's a V2 of this patch. The only difference is that this also expose the extension on ES2. The piglit patches has also been updated: https://patchwork.freedesktop.org/series/52039/ src/mapi/glapi/gen/NV_conditional_render.xml | 4 ++-- src/mesa/main/extensions_table.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mapi/glapi/gen/NV_conditional_render.xml b/src/mapi/glapi/gen/NV_conditional_render.xml index 926b2629412..4b28c466f7d 100644 --- a/src/mapi/glapi/gen/NV_conditional_render.xml +++ b/src/mapi/glapi/gen/NV_conditional_render.xml @@ -13,12 +13,12 @@ - + - + diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h index a516a1b17f8..04a319271e0 100644 --- a/src/mesa/main/extensions_table.h +++ b/src/mesa/main/extensions_table.h @@ -345,7 +345,7 @@ EXT(MESA_ycbcr_texture , MESA_ycbcr_texture EXT(NVX_gpu_memory_info , NVX_gpu_memory_info , GLL, GLC, x , x , 2013) EXT(NV_blend_square , dummy_true , GLL, x , x , x , 1999) -EXT(NV_conditional_render , NV_conditional_render , GLL, GLC, x , x , 2008) +EXT(NV_conditional_render , NV_conditional_render , GLL, GLC, x , ES2, 2008) EXT(NV_conservative_raster , NV_conservative_raster , GLL, GLC, ES1, ES2, 2015) EXT(NV_conservative_raster_dilate , NV_conservative_raster_dilate , GLL, GLC, ES1, ES2, 2015) EXT(NV_conservative_raster_pre_snap , NV_conservative_raster_pre_snap , GLL, GLC, ES1, ES2, 2017) -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108508] Graphic glitches with stream output support on OLAND AMD GPU GCN 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=108508 Ahmed Elsayed changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #25 from Ahmed Elsayed --- With kernel 4.19 all the games need transform_feedback work well except Mafia III which I don't have it any more. Sorry for bothering you and thanks for trying to help me. Have a good day. -- 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 EGL/MESA] EGL/mesa: Initial writeup for MESA_query_renderer
Hi all, Thanks Adam for your interest in this. > +New Tokens > > + > > +Accepted as an in EGLQueryRendererIntegerMESA and > > +EGLQueryCurrentRendererIntegerMESA: > > + > > +EGL_RENDERER_VENDOR_ID_MESA 0x > > +EGL_RENDERER_DEVICE_ID_MESA 0x > except the above 2 tokens we aren't using any tokens in adriconf( https://github.com/jlHertel/adriconf/blob/master/DRIQuery.cpp#L46) If we don't need all the below ones, I'll remove them. > > +EGL_RENDERER_VERSION_MESA0x > > +EGL_RENDERER_ACCELERATED_MESA0x > > +EGL_RENDERER_VIDEO_MEMORY_MESA 0x > > +EGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA0x > > +EGL_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA0x > > +EGL_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA0x > > + > > > Normally these are reserved by creating a request against the EGL > registry on github. However we happen to have a block of 16 enum values > already reserved: > > > comment="Reserved for John Kåre Alsaker (Public bug 757)"> > > > > > > That "public bug 757" is for the abandoned EGL_MESA_image_sRGB > extension: > > https://www.khronos.org/bugzilla/show_bug.cgi?id=757 > > So I think it's safe to use enums from that range, and we'll still have > two free. I'll assign these, once we finalize all the tokens. > +Bool EGLQueryRendererIntegerMESA(EGLDisplay *dpy, int screen, > int renderer, > > + int attribute, unsigned int > *value); > @Nicolai Hähnle , @Rob Clark we are using only this queryRenderInteger function in adriconf. The rest 3 funcions can be exempted?? > The corresponding eglQueryCurrentRendererIntegerMESA is not documented. > I'm not entirely sure it should even exist, to be honest; I'd prefer if > these attributes were instead newly legal values to pass to > eglQueryContext. Too late to make that change for GLX I suppose. > What is the difference between EGLContext and EGLSurface? If you look at the usage of query fun in adriocnf( https://github.com/jlHertel/adriconf/blob/master/DRIQuery.cpp#L43). we are iterating with all the available screens. In Wayland do we need to iterate through contexts?? @Jean Hertel In the above provided link, why are we passing 3rd argument(renderer) as 0 for all the screens? > > > +[Add to section section 3.3.7 "Rendering Contexts"] > > + > > +The attribute name EGL_RENDERER_ID_MESA specified the index of the > render > > +against which the context should be created. The default value of > > +EGL_RENDERER_ID_MESA is 0. > > This startled me to read, I didn't think GLX_MESA_query_renderer had > this. Turns out it does have this text in the extension spec, but the > functionality is not actually implemented. Worse, there's no way to > enumerate how many renderers a display (or display/screen in GLX) has. > > To address this, I would: > > 1) Remove this text from both GLX and EGL extension specs >(Both here and above where the enums are listed) > 2) Update both specs with an explicit way to enumerate renderers >(probably something like "if renderer is -1 and the attribute is >XXX_RENDERER_COUNT_MESA, return one integer") > 3) Add a layered extension to add this functionality to CreateContext > > #2 and #3 are optional, I suppose. Probably it's better to have only > one way to do that, and in EGL that way is probably using the EGL > device extensions instead. But GLX doesn't have anything like that, so > this functionality might make sense there. > > Thanks, Veluri. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 35268] initial-exec TLS model breaks dlopen'ed libGL
https://bugs.freedesktop.org/show_bug.cgi?id=35268 --- Comment #28 from Rich Felker --- Note that removing the asm would also fix sparc, for which I don't feel qualified to fix the asm. It would also make it possible to support x86 targets that lack TLSDESC support at the ldso level (maybe some or all BSDs?) without forcing them to revert to the slow TSD key based fallback, since the compiler could just be allowed to use the less-efficient GD dialect rather than needing a variant of the asm for it. -- You are receiving this mail because: 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 105328] Can't include gl and gles headers simultaneously on non-64 bit architectures
https://bugs.freedesktop.org/show_bug.cgi?id=105328 Matt Turner changed: What|Removed |Added Assignee|fdo-b...@engestrom.ch |emil.l.veli...@gmail.com Blocks||108530 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108530 [Bug 108530] [Tracker] Mesa 18.3 Release Tracker -- 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
[Mesa-dev] [Bug 108530] [Tracker] Mesa 18.3 Release Tracker
https://bugs.freedesktop.org/show_bug.cgi?id=108530 Matt Turner changed: What|Removed |Added Depends on||105328 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=105328 [Bug 105328] Can't include gl and gles headers simultaneously on non-64 bit architectures -- 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 108530] [Tracker] Mesa 18.3 Release Tracker
https://bugs.freedesktop.org/show_bug.cgi?id=108530 Matt Turner changed: What|Removed |Added Alias||mesa-18.3 -- 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 08/12] configure.ac: deprecate --with-llvm-prefix
On Wed, Nov 7, 2018 at 12:53 PM Jan Vesely wrote: > > On Wed, 2018-11-07 at 18:51 +, Emil Velikov wrote: > > On Wed, 7 Nov 2018 at 18:39, Jan Vesely wrote: > > > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote: > > > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer wrote: > > > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote: > > > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote: > > > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely > > > > > > > wrote: > > > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote: > > > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer > > > > > > > > > wrote: > > > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote: > > > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env > > > > > > > > > > > var remembered > > > > > > > > > > > between reconfigure (touch configure.ac; make) or do I > > > > > > > > > > > need to provide > > > > > > > > > > > it explicitly every time configure is run? > > > > > > > > > > > > > > > > > > > > I don't know the answer, but agree that would be a minimum > > > > > > > > > > requirement > > > > > > > > > > for this change. > > > > > > > > > > > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been > > > > > > > > > around for > > > > > > > > > years, it will work for any Mesa checkout since its inception. > > > > > > > > > You can safely bisect Mesa and things will just work. > > > > > > > > > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every > > > > > > > > time > > > > > > > > bisect changes configure.ac? > > > > > > > > > > > > > > > You can do (although there's other options if this one seems > > > > > > > weird) > > > > > > > > > > > > > > $ LLVM_CONFIG=... ../autogen.sh > > > > > > > > > > > > That does not answer my question. > > > > > > > > > > > > suppose the following sequence: > > > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config > > > > > > ../mesa-src/autogen.sh > > > > > > ... > > > > > > llvm:yes > > > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config > > > > > > llvm-version:4.0.1 > > > > > > ... > > > > > > $ make -j128 > > > > > > $ touch ../mesa-src/configure.ac > > > > > > $ make -j128 > > > > > > ... > > > > > > llvm:yes > > > > > > llvm-config: /usr/bin/llvm-config > > > > > > llvm-version:7.0.0 > > > > > > ... > > > > > > > > > > > > the second reconfigure silently reverted back to system default > > > > > > llvm. > > > > > > That's a loss of capabilty for me. > > > > > > > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the > > > > > current form. > > > > > > > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might > > > > > not be too hard to make this work with the environment variable. I > > > > > don't > > > > > know the preferred way to do that however. > > > > > > > > > Right, I misread the usecase :-( Sorry about that. > > > > The following works like a charm: > > > > > > > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/... > > > > make > > > > touch .../configure.ac > > > > make > > > > > > ouch, that's rather ugly. What is the reason to prefer env var vs. > > > proper option (like --with-llvm-config)? > > > meson also seems to prefer env var for some reason. > > > I don't mind spending the time to send out the patches, but I'd like to > > > make sure it's not a wasted effort. > > > > > From a general distribution POV, adding llvm-config to every project > > 'feels' wasteful IMHO. Even if we ignore the "feels" part, there's the > > aspect of duplicating the same code in XX projects. > > Which with due time will result in a behavioural shift as copies diverge. > > > > In Mesa the toggle conflicts, in some weird ways, with the existing > > --with-clang-libdir > > The idea would be to have one --with-llvm-config switch that subsumes > all llvm related options (except maybe static vs. dynamic linking). > > I don't get the argument about other projects. > Not all projects need to support multiple llvm versions. For those that > do provide that option, having a configure, ehm, option sounds like the > most straightforward way. Does Meson behave in the way you prefer? Can we make sure it does so we don't need to go through this again soon? It doesn't make sense to me to debate an autotools clean up like this when the plan is for autotools to go away in the next few months. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 35268] initial-exec TLS model breaks dlopen'ed libGL
https://bugs.freedesktop.org/show_bug.cgi?id=35268
--- Comment #27 from Rich Felker ---
A couple issues with latest patches by Sora Lee:
1. There is no need for __attribute__((__tls_model__("global-dynamic"))). It's
rightly the default whenever it's needed by the ABI. The attribute should just
be removed.
2. There's at least one more place where the invalid initial-exec asm is
duplicated, in src/mapi/entry_x86{,-64}_tls.h.
3. Per the ABI, calling the TLSDESC function requires the stack pointer to be
aligned mod 16 (as for all function calls). This might not break in practice
but should be done.
I have a draft patch with all of these changes that seems to be working. Once I
check it over again I'll post it here.
Perhaps more to the point, though, the asm seems largely useless and I think it
should just be removed. Modern GCC generates exactly the same code for the C
stubs as what you get by doing the TLSDESC access in asm, except for some
functions that take char args where gcc performs a spurious zero/sign-extend
operation on the argument regissters before tail-calling through the dispatch.
Supposedly this is a known gcc bug that's going to be improved in gcc 9.
--
You are receiving this mail because:
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] [PATCH v2] radv: use LOAD_CONTEXT_REG when loading fast clear values
This avoids syncing the Micro Engine. This is only supported
for VI+ currently. There is probably a way for using
LOAD_CONTEXT_REG on previous chips but that could be done later.
v2: - always use LOAD_CONTEXT_REG for depth/stencil values
- remove radv_device::has_load_context_reg
Signed-off-by: Samuel Pitoiset
---
src/amd/common/sid.h | 1 +
src/amd/vulkan/radv_cmd_buffer.c | 45 ++--
2 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index 5c53133147..35782046dd 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -217,6 +217,7 @@
#define PKT3_INCREMENT_CE_COUNTER 0x84
#define PKT3_INCREMENT_DE_COUNTER 0x85
#define PKT3_WAIT_ON_CE_COUNTER0x86
+#define PKT3_LOAD_CONTEXT_REG 0x9F /* new for VI */
#define PKT_TYPE_S(x) (((unsigned)(x) & 0x3) << 30)
#define PKT_TYPE_G(x) (((x) >> 30) & 0x3)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index de67a8a363..9fd9e81b3c 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -37,6 +37,8 @@
#include "ac_debug.h"
+#include "addrlib/gfx9/chip/gfx9_enum.h"
+
enum {
RADV_PREFETCH_VBO_DESCRIPTORS = (1 << 0),
RADV_PREFETCH_VS= (1 << 1),
@@ -1313,17 +1315,13 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer
*cmd_buffer,
if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
++reg_count;
- radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
- radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
- COPY_DATA_DST_SEL(COPY_DATA_REG) |
- (reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
+ uint32_t reg = R_028028_DB_STENCIL_CLEAR + 4 * reg_offset;
+
+ radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 0));
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
- radeon_emit(cs, (R_028028_DB_STENCIL_CLEAR + 4 * reg_offset) >> 2);
- radeon_emit(cs, 0);
-
- radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
- radeon_emit(cs, 0);
+ radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+ radeon_emit(cs, reg_count);
}
/*
@@ -1443,17 +1441,26 @@ radv_load_color_clear_metadata(struct radv_cmd_buffer
*cmd_buffer,
uint32_t reg = R_028C8C_CB_COLOR0_CLEAR_WORD0 + cb_idx * 0x3c;
- radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, cmd_buffer->state.predicating));
- radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
- COPY_DATA_DST_SEL(COPY_DATA_REG) |
- COPY_DATA_COUNT_SEL);
- radeon_emit(cs, va);
- radeon_emit(cs, va >> 32);
- radeon_emit(cs, reg >> 2);
- radeon_emit(cs, 0);
+ if (cmd_buffer->device->physical_device->rad_info.chip_class >= VI) {
+ radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3,
cmd_buffer->state.predicating));
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+ radeon_emit(cs, 2);
+ } else {
+ /* TODO: Figure out how to use LOAD_CONTEXT_REG on SI/CIK. */
+ radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4,
cmd_buffer->state.predicating));
+ radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
+ COPY_DATA_DST_SEL(COPY_DATA_REG) |
+ COPY_DATA_COUNT_SEL);
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, reg >> 2);
+ radeon_emit(cs, 0);
- radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0,
cmd_buffer->state.predicating));
- radeon_emit(cs, 0);
+ radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0,
cmd_buffer->state.predicating));
+ radeon_emit(cs, 0);
+ }
}
static void
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/12] meson doesn't use env vars, WAS: configure.ac: deprecate --with-llvm-prefix
On Wed, 2018-11-07 at 11:34 -0800, Dylan Baker wrote: > Quoting Jan Vesely (2018-11-07 10:39:48) > > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote: > > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer wrote: > > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote: > > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote: > > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely > > > > > > wrote: > > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote: > > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer > > > > > > > > wrote: > > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote: > > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env var > > > > > > > > > > remembered > > > > > > > > > > between reconfigure (touch configure.ac; make) or do I need > > > > > > > > > > to provide > > > > > > > > > > it explicitly every time configure is run? > > > > > > > > > > > > > > > > > > I don't know the answer, but agree that would be a minimum > > > > > > > > > requirement > > > > > > > > > for this change. > > > > > > > > > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been > > > > > > > > around for > > > > > > > > years, it will work for any Mesa checkout since its inception. > > > > > > > > You can safely bisect Mesa and things will just work. > > > > > > > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every time > > > > > > > bisect changes configure.ac? > > > > > > > > > > > > > You can do (although there's other options if this one seems weird) > > > > > > > > > > > > $ LLVM_CONFIG=... ../autogen.sh > > > > > > > > > > That does not answer my question. > > > > > > > > > > suppose the following sequence: > > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh > > > > > ... > > > > > llvm:yes > > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config > > > > > llvm-version:4.0.1 > > > > > ... > > > > > $ make -j128 > > > > > $ touch ../mesa-src/configure.ac > > > > > $ make -j128 > > > > > ... > > > > > llvm:yes > > > > > llvm-config: /usr/bin/llvm-config > > > > > llvm-version:7.0.0 > > > > > ... > > > > > > > > > > the second reconfigure silently reverted back to system default llvm. > > > > > That's a loss of capabilty for me. > > > > > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the > > > > current form. > > > > > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might > > > > not be too hard to make this work with the environment variable. I don't > > > > know the preferred way to do that however. > > > > > > > Right, I misread the usecase :-( Sorry about that. > > > The following works like a charm: > > > > > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/... > > > make > > > touch .../configure.ac > > > make > > > > ouch, that's rather ugly. What is the reason to prefer env var vs. > > proper option (like --with-llvm-config)? > > meson also seems to prefer env var for some reason. > > Actually, we (meson) made the concious choice not to use env vars, our > solution > is config files (like cross files) for native compilation. They work just like > cross file, but for native compilation (load at initial configuration, don't > reload change on subsequent reconfigurations): > > $ cat llvm-4.0 > [binaries] > llvm-config = /usr/local/lib/llvm-4.0/bin/llvm-config > > $ meson build --native-file llvm-4.0 > > Hopefully this series in the in the final stretch and can land shortly, and be > present in 0.49.0 thanks for the clarification. as long as the setting survives reconfigure+rebuild I'm fine. just out of curiosity. can meson combine multiple native files, or do you need to crate a new one with the desired combination of settings? thanks, Jan > > Dylan 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 08/12] configure.ac: deprecate --with-llvm-prefix
On Wed, 2018-11-07 at 18:51 +, Emil Velikov wrote: > On Wed, 7 Nov 2018 at 18:39, Jan Vesely wrote: > > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote: > > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer wrote: > > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote: > > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote: > > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely > > > > > > wrote: > > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote: > > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer > > > > > > > > wrote: > > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote: > > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env var > > > > > > > > > > remembered > > > > > > > > > > between reconfigure (touch configure.ac; make) or do I need > > > > > > > > > > to provide > > > > > > > > > > it explicitly every time configure is run? > > > > > > > > > > > > > > > > > > I don't know the answer, but agree that would be a minimum > > > > > > > > > requirement > > > > > > > > > for this change. > > > > > > > > > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been > > > > > > > > around for > > > > > > > > years, it will work for any Mesa checkout since its inception. > > > > > > > > You can safely bisect Mesa and things will just work. > > > > > > > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every time > > > > > > > bisect changes configure.ac? > > > > > > > > > > > > > You can do (although there's other options if this one seems weird) > > > > > > > > > > > > $ LLVM_CONFIG=... ../autogen.sh > > > > > > > > > > That does not answer my question. > > > > > > > > > > suppose the following sequence: > > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh > > > > > ... > > > > > llvm:yes > > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config > > > > > llvm-version:4.0.1 > > > > > ... > > > > > $ make -j128 > > > > > $ touch ../mesa-src/configure.ac > > > > > $ make -j128 > > > > > ... > > > > > llvm:yes > > > > > llvm-config: /usr/bin/llvm-config > > > > > llvm-version:7.0.0 > > > > > ... > > > > > > > > > > the second reconfigure silently reverted back to system default llvm. > > > > > That's a loss of capabilty for me. > > > > > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the > > > > current form. > > > > > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might > > > > not be too hard to make this work with the environment variable. I don't > > > > know the preferred way to do that however. > > > > > > > Right, I misread the usecase :-( Sorry about that. > > > The following works like a charm: > > > > > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/... > > > make > > > touch .../configure.ac > > > make > > > > ouch, that's rather ugly. What is the reason to prefer env var vs. > > proper option (like --with-llvm-config)? > > meson also seems to prefer env var for some reason. > > I don't mind spending the time to send out the patches, but I'd like to > > make sure it's not a wasted effort. > > > From a general distribution POV, adding llvm-config to every project > 'feels' wasteful IMHO. Even if we ignore the "feels" part, there's the > aspect of duplicating the same code in XX projects. > Which with due time will result in a behavioural shift as copies diverge. > > In Mesa the toggle conflicts, in some weird ways, with the existing > --with-clang-libdir The idea would be to have one --with-llvm-config switch that subsumes all llvm related options (except maybe static vs. dynamic linking). I don't get the argument about other projects. Not all projects need to support multiple llvm versions. For those that do provide that option, having a configure, ehm, option sounds like the most straightforward way. If divergence from other projects is a worry, then the solution can be upstreamed to the autoconf archive to replace the current ax_llvm [0]. libclc (another piece of the mesa based OpenCL stack) has provided ' --with-llvm-config' option since Jan 2012, so it'd be nice to follow suite. I don't understand how using env var addresses any of that. > Now stepping back to look at the big picture: > Ideally LLVM/Clang would provide .pc files like nearly every project > in wild. LLVM 7.0 doesn't seem to be shipping any, so we need [ideally > very small] solution in the meanwhile. The reality is that LLVM doesn't, and probably won't ever provide .pc file. The bug for this was open in 2011 against LLVM 2.8 [1]. I don't know if there's a policy or just lack of volunteers, but hoping that mesa only needs a stop gap solution until it happens is unrealistic. regards, Jan [0] https://www.gnu.org/software/autoconf-archive/ax_llvm.html#ax_llvm [1] https://bugs.llvm.org/show_bug.cgi?id=9405 > > HTH > Emil signature.asc Description: T
[Mesa-dev] [Bug 108508] Graphic glitches with stream output support on OLAND AMD GPU GCN 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=108508 --- Comment #24 from Samuel Pitoiset --- You closed the DXVK issue, what's the status of this bug report? -- 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] [PATCH] EGL/mesa: Initial write up for MESA_query_renderer
--- docs/specs/EGL_MESA_query_renderer.txt | 186 + 1 file changed, 186 insertions(+) create mode 100644 docs/specs/EGL_MESA_query_renderer.txt diff --git a/docs/specs/EGL_MESA_query_renderer.txt b/docs/specs/EGL_MESA_query_renderer.txt new file mode 100644 index 00..4711e3dadb --- /dev/null +++ b/docs/specs/EGL_MESA_query_renderer.txt @@ -0,0 +1,186 @@ +Name + +MESA_query_renderer + +Name Strings + +EGL_MESA_query_renderer + +Contact + +Rob Clark +Nicolai H??hnle + +Contributors + +Veluri Mithun + +Status + +XXX - Not complete yet!!! (draft) + +Version + +Version 1, 2018-08-24 + +Number + +EGL Extension ### + +Dependencies + +EGL 1.0 is required. + +New Procedures and Functions + +Bool eglQueryRendererIntegerMESA(EGLDisplay *dpy, int renderer, + int attribute, unsigned int *value); + +Bool eglQueryCurrentRendererIntegerMESA(int attribute, unsigned int *value); + +const char *eglQueryRendererStringMESA(EGLDisplay *dpy,int renderer, + int attribute); + +const char *eglQueryCurrentRendererStringMESA(int attribute); + +Overview + +In many situations, applications want to detect characteristics of a +rendering device before creating a context for that device. Information +gathered at this stage may guide choices the application makes about +color depth, number of samples per-pixel, texture quality, and so on. +In addition, versions of supported APIs and implementation API +preference may also guide start-up decisions made by the application. +For example, one implementation may prefer vertex data be supplied using +methods only available in a compatibility profile, but another +implementation may only support the desired version in a core profile. + +There are also cases where more than one renderer may be available per +display. For example, there is typically a hardware implementation and +a software based implementation. There are cases where an application +may want to pick one over the other. One such situation is when the +software implementation supports more features than the hardware +implementation. Another situation is when a particular version of the +hardware implementation is blacklisted due to known bugs. + +This extension provides a mechanism for the application to query all of +the available renderers for a particular display. In addition, this +extension provides a mechanism for applications to create contexts with +respect to a specific renderer. + +IP Status + +No IP claims + +New Tokens + +Accepted as an in eglQueryRendererIntegerMESA and +eglQueryCurrentRendererIntegerMESA: + +EGL_RENDERER_VENDOR_ID_MESA 0x +EGL_RENDERER_DEVICE_ID_MESA 0x +EGL_RENDERER_VERSION_MESA0x +EGL_RENDERER_ACCELERATED_MESA0x +EGL_RENDERER_VIDEO_MEMORY_MESA 0x +EGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA0x +EGL_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA0x +EGL_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA0x + +Accepted as an in EGLQueryRendererStringMESA and +EGLQueryCurrentRendererStringMESA: + +EGL_RENDERER_VENDOR_ID_MESA +EGL_RENDERER_DEVICE_ID_MESA + +Additions to the EGL 1.0 Specification + +[Add the following to Section 3.3 of the EGL Versioning] + +To obtain information about the available renderers for a particular +display, + +Bool eglQueryRendererIntegerMESA(EGLDisplay *dpy, int renderer, + int attribute, unsigned int *value); + +can be used. The value for will be returned in one or more +integers specified by . The values, data sizes, and descriptions +of each renderer attribute are listed in the table below. + +EGL renderer attribute number description + of values +--- --- +EGL_RENDERER_VENDOR_ID_MESA 1 PCI ID of the device vendor +EGL_RENDERER_DEVICE_ID_MESA 1 PCI ID of the device +EGL_RENDERER_VERSION_MESA 3 Major, minor, and patch level of + the renderer implementation +EGL_RENDERER_ACCELERATED_MESA 1 Boolean indicating whether or + not the renderer is hardware + accelerated +EGL_RENDERER_VIDEO_MEMORY_MESA 1 Number of megabytes of video + memory available to the renderer +EGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA + 1 Boolean in
Re: [Mesa-dev] [PATCH] i965: Lift restriction in external textures for EGLImage support
On Wednesday, October 31, 2018 5:12:40 PM PST Aditya Swarup wrote:
> For Intel platforms, we support external textures only for EGLImages
> created with EGL_EXT_image_dma_buf_import. This restriction seems to
> be Intel specific and not present for other platforms.
>
> While running SKQP test - unitTest_EGLImageTest, GL_INVALID is sent
> to the test because of this restriction.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105301
> Fixes Skqp's unitTest_EGLImageTest test.
>
> Change-Id: I54a162db534d54858319fdb98ba502314d28fc27
> Signed-off-by: Aditya Swarup
> ---
> src/mesa/drivers/dri/i965/intel_image.h | 3 ---
> src/mesa/drivers/dri/i965/intel_screen.c| 2 --
> src/mesa/drivers/dri/i965/intel_tex_image.c | 10 --
> 3 files changed, 15 deletions(-)
I'm pretty convinced by the spec quotes from Dongseong and Aditya
in Bugzilla - I think this needs to be allowed. Jason seems to think
that we're already turning off compression. I checked the OES_EGL_image
spec and it discusses how mipmapping works - basically, if the client
has any that aren't included in the EGL image, pitch them. If the
client later makes more, it ceases to be an EGL image target, and...
you keep the broken pieces? That seems pretty doable.
Jason and I are unsure whether we've handled all the corners, but it
seems like a matter of raising errors in the right places...something
we can probably do if we encounter issues later.
Tapani, what do you think? It seems OK to me, and so I'd give this
patch my Reviewed-by, but I want you to be happy with it before we
land anything.
>
> diff --git a/src/mesa/drivers/dri/i965/intel_image.h
> b/src/mesa/drivers/dri/i965/intel_image.h
> index a8193c6def96..ca604159dc20 100644
> --- a/src/mesa/drivers/dri/i965/intel_image.h
> +++ b/src/mesa/drivers/dri/i965/intel_image.h
> @@ -89,9 +89,6 @@ struct __DRIimageRec {
> GLuint tile_y;
> bool has_depthstencil;
>
> - /** The image was created with EGL_EXT_image_dma_buf_import. */
> - bool dma_buf_imported;
> -
> /** Offset of the auxiliary compression surface in the bo. */
> uint32_t aux_offset;
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index b117928f18ec..26ec42b4c8b1 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -958,7 +958,6 @@ intel_dup_image(__DRIimage *orig_image, void
> *loaderPrivate)
> image->tile_y = orig_image->tile_y;
> image->has_depthstencil = orig_image->has_depthstencil;
> image->data= loaderPrivate;
> - image->dma_buf_imported = orig_image->dma_buf_imported;
> image->aux_offset = orig_image->aux_offset;
> image->aux_pitch = orig_image->aux_pitch;
>
> @@ -1238,7 +1237,6 @@ intel_create_image_from_dma_bufs2(__DRIscreen
> *dri_screen,
>return NULL;
> }
>
> - image->dma_buf_imported = true;
> image->yuv_color_space = yuv_color_space;
> image->sample_range = sample_range;
> image->horizontal_siting = horizontal_siting;
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
> b/src/mesa/drivers/dri/i965/intel_tex_image.c
> index fae179214dd3..1b4083af530d 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_image.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
> @@ -616,16 +616,6 @@ intel_image_target_texture_2d(struct gl_context *ctx,
> GLenum target,
> if (image == NULL)
>return;
>
> - /* We support external textures only for EGLImages created with
> -* EGL_EXT_image_dma_buf_import. We may lift that restriction in the
> future.
> -*/
> - if (target == GL_TEXTURE_EXTERNAL_OES && !image->dma_buf_imported) {
> - _mesa_error(ctx, GL_INVALID_OPERATION,
> -"glEGLImageTargetTexture2DOES(external target is enabled only "
> - "for images created with EGL_EXT_image_dma_buf_import");
> - return;
> - }
> -
> /* Disallow depth/stencil textures: we don't have a way to pass the
> * separate stencil miptree of a GL_DEPTH_STENCIL texture through.
> */
>
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
[Mesa-dev] [Bug 107022] [RADV] The Witcher 3: Trembling of trees
https://bugs.freedesktop.org/show_bug.cgi?id=107022 --- Comment #18 from Samuel Pitoiset --- Are you guys still able to reproduce that problem? I'm trying to reproduce it. -- 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 08/12] meson doesn't use env vars, WAS: configure.ac: deprecate --with-llvm-prefix
Quoting Jan Vesely (2018-11-07 10:39:48) > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote: > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer wrote: > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote: > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote: > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely > > > > > wrote: > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote: > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer > > > > > > > wrote: > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote: > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env var > > > > > > > > > remembered > > > > > > > > > between reconfigure (touch configure.ac; make) or do I need > > > > > > > > > to provide > > > > > > > > > it explicitly every time configure is run? > > > > > > > > > > > > > > > > I don't know the answer, but agree that would be a minimum > > > > > > > > requirement > > > > > > > > for this change. > > > > > > > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been around > > > > > > > for > > > > > > > years, it will work for any Mesa checkout since its inception. > > > > > > > You can safely bisect Mesa and things will just work. > > > > > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every time > > > > > > bisect changes configure.ac? > > > > > > > > > > > You can do (although there's other options if this one seems weird) > > > > > > > > > > $ LLVM_CONFIG=... ../autogen.sh > > > > > > > > That does not answer my question. > > > > > > > > suppose the following sequence: > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh > > > > ... > > > > llvm:yes > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config > > > > llvm-version:4.0.1 > > > > ... > > > > $ make -j128 > > > > $ touch ../mesa-src/configure.ac > > > > $ make -j128 > > > > ... > > > > llvm:yes > > > > llvm-config: /usr/bin/llvm-config > > > > llvm-version:7.0.0 > > > > ... > > > > > > > > the second reconfigure silently reverted back to system default llvm. > > > > That's a loss of capabilty for me. > > > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the > > > current form. > > > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might > > > not be too hard to make this work with the environment variable. I don't > > > know the preferred way to do that however. > > > > > Right, I misread the usecase :-( Sorry about that. > > The following works like a charm: > > > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/... > > make > > touch .../configure.ac > > make > > ouch, that's rather ugly. What is the reason to prefer env var vs. > proper option (like --with-llvm-config)? > meson also seems to prefer env var for some reason. Actually, we (meson) made the concious choice not to use env vars, our solution is config files (like cross files) for native compilation. They work just like cross file, but for native compilation (load at initial configuration, don't reload change on subsequent reconfigurations): $ cat llvm-4.0 [binaries] llvm-config = /usr/local/lib/llvm-4.0/bin/llvm-config $ meson build --native-file llvm-4.0 Hopefully this series in the in the final stretch and can land shortly, and be present in 0.49.0 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 4/4] bin/get-pick-list.sh: add fixes handling
On Wed, 7 Nov 2018 at 12:08, Emil Velikov wrote: > - fixes=`git show --pretty=medium -s $sha | tr -d "\n" | sed -e > 's/fixes:[[:space:]]*/\nfixes:/Ig' | grep "fixes:" | sed -e > 's/\(fixes:[a-zA-Z0-9]*\).*$/\1/'` > + grep "fixes:" | sed -e 's/\(fixes:[a-fA-F0-9]*\).*$/\1/'` I've changed the pattern here, I'll revert to the original and tweak as follow up. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix
On Wed, 7 Nov 2018 at 18:39, Jan Vesely wrote: > > On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote: > > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer wrote: > > > On 2018-11-01 5:03 p.m., Jan Vesely wrote: > > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote: > > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely > > > > > wrote: > > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote: > > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer > > > > > > > wrote: > > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote: > > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env var > > > > > > > > > remembered > > > > > > > > > between reconfigure (touch configure.ac; make) or do I need > > > > > > > > > to provide > > > > > > > > > it explicitly every time configure is run? > > > > > > > > > > > > > > > > I don't know the answer, but agree that would be a minimum > > > > > > > > requirement > > > > > > > > for this change. > > > > > > > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been around > > > > > > > for > > > > > > > years, it will work for any Mesa checkout since its inception. > > > > > > > You can safely bisect Mesa and things will just work. > > > > > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every time > > > > > > bisect changes configure.ac? > > > > > > > > > > > You can do (although there's other options if this one seems weird) > > > > > > > > > > $ LLVM_CONFIG=... ../autogen.sh > > > > > > > > That does not answer my question. > > > > > > > > suppose the following sequence: > > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh > > > > ... > > > > llvm:yes > > > > llvm-config: /usr/local/llvm-4/bin/llvm-config > > > > llvm-version:4.0.1 > > > > ... > > > > $ make -j128 > > > > $ touch ../mesa-src/configure.ac > > > > $ make -j128 > > > > ... > > > > llvm:yes > > > > llvm-config: /usr/bin/llvm-config > > > > llvm-version:7.0.0 > > > > ... > > > > > > > > the second reconfigure silently reverted back to system default llvm. > > > > That's a loss of capabilty for me. > > > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the > > > current form. > > > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might > > > not be too hard to make this work with the environment variable. I don't > > > know the preferred way to do that however. > > > > > Right, I misread the usecase :-( Sorry about that. > > The following works like a charm: > > > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/... > > make > > touch .../configure.ac > > make > > ouch, that's rather ugly. What is the reason to prefer env var vs. > proper option (like --with-llvm-config)? > meson also seems to prefer env var for some reason. > I don't mind spending the time to send out the patches, but I'd like to > make sure it's not a wasted effort. > From a general distribution POV, adding llvm-config to every project 'feels' wasteful IMHO. Even if we ignore the "feels" part, there's the aspect of duplicating the same code in XX projects. Which with due time will result in a behavioural shift as copies diverge. In Mesa the toggle conflicts, in some weird ways, with the existing --with-clang-libdir Now stepping back to look at the big picture: Ideally LLVM/Clang would provide .pc files like nearly every project in wild. LLVM 7.0 doesn't seem to be shipping any, so we need [ideally very small] solution in the meanwhile. HTH Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix
On Tue, 2018-11-06 at 12:09 +, Emil Velikov wrote: > On Thu, 1 Nov 2018 at 16:13, Michel Dänzer wrote: > > On 2018-11-01 5:03 p.m., Jan Vesely wrote: > > > On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote: > > > > On Wed, 31 Oct 2018 at 17:41, Jan Vesely wrote: > > > > > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote: > > > > > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer > > > > > > wrote: > > > > > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote: > > > > > > > > This might be a stupid question; is the LLVM_CONFIG env var > > > > > > > > remembered > > > > > > > > between reconfigure (touch configure.ac; make) or do I need to > > > > > > > > provide > > > > > > > > it explicitly every time configure is run? > > > > > > > > > > > > > > I don't know the answer, but agree that would be a minimum > > > > > > > requirement > > > > > > > for this change. > > > > > > > > > > > > > Nope, yet it's not really a minimum. LLVM_CONFIG has been around for > > > > > > years, it will work for any Mesa checkout since its inception. > > > > > > You can safely bisect Mesa and things will just work. > > > > > > > > > > The question is; Do I have to do "LLVM_CONFIG=..." make every time > > > > > bisect changes configure.ac? > > > > > > > > > You can do (although there's other options if this one seems weird) > > > > > > > > $ LLVM_CONFIG=... ../autogen.sh > > > > > > That does not answer my question. > > > > > > suppose the following sequence: > > > $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh > > > ... > > > llvm:yes > > > llvm-config: /usr/local/llvm-4/bin/llvm-config > > > llvm-version:4.0.1 > > > ... > > > $ make -j128 > > > $ touch ../mesa-src/configure.ac > > > $ make -j128 > > > ... > > > llvm:yes > > > llvm-config: /usr/bin/llvm-config > > > llvm-version:7.0.0 > > > ... > > > > > > the second reconfigure silently reverted back to system default llvm. > > > That's a loss of capabilty for me. > > > > Thanks for checking, Jan. That's a NAK from me for this patch in the > > current form. > > > > FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might > > not be too hard to make this work with the environment variable. I don't > > know the preferred way to do that however. > > > Right, I misread the usecase :-( Sorry about that. > The following works like a charm: > > .../autogen.sh ac_cv_path_LLVM_CONFIG=/... > make > touch .../configure.ac > make ouch, that's rather ugly. What is the reason to prefer env var vs. proper option (like --with-llvm-config)? meson also seems to prefer env var for some reason. I don't mind spending the time to send out the patches, but I'd like to make sure it's not a wasted effort. thanks, Jan > > > P.S. I only just now noticed the discrepancy between the commit log > > talking about "deprecation", whereas the patch actually makes the option > > ineffective. That's not what deprecation means. Also, I'm not sure how > > this patch is related to the series' general theme of bumping the > > minimum required LLVM version. Please don't bury unrelated patches in > > large series. > > > Merely following suite - see commit e2afa154e99071e8d51be88494cd1347ad113035 > The series does the following: > - bumps the version > - removes build-wise LLVM hacks - now dead > - removes old LLVM codepaths - now dea > > I could have split it in three, yet it seems like be a serious overkill. > > That said, can we hear some directions/preferences of how to move > things forward? > I'm slightly worries that we may end up in the XKCD Workflow case :-( > > Thanks > Emil 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 6/9] intel/fs: Use the new nir_src_is_const and friends
On Saturday, October 20, 2018 10:55:44 AM PST Jason Ekstrand wrote: > @@ -553,14 +552,18 @@ fs_visitor::optimize_frontfacing_ternary(nir_alu_instr > *instr, > if (src0->intrinsic != nir_intrinsic_load_front_face) >return false; > > - nir_const_value *value1 = nir_src_as_const_value(instr->src[1].src); > - if (!value1 || fabsf(value1->f32[0]) != 1.0f) > + if (!nir_src_is_const(instr->src[1].src) || > + !nir_src_is_const(instr->src[2].src)) >return false; > > - nir_const_value *value2 = nir_src_as_const_value(instr->src[2].src); > - if (!value2 || fabsf(value2->f32[0]) != 1.0f) > + const float value1 = nir_src_as_float(instr->src[1].src); > + const float value2 = nir_src_as_float(instr->src[2].src); > + if (fabsf(value1) != 1.0f || fabsf(value2) != 1.0f) >return false; > > + /* nir_opt_algebraic should have gotten rid of bcsel(b, a, a) */ > + assert(value1 == -value2); > + This is likely true, but it doesn't seem like this belongs in this refactoring patch - we weren't doing it before, and no new code appears to depend on the condition. Normally I wouldn't mind, but I'm a bit paranoid about float equality in assertions. It's probably fine, though, since we ensured fabsf is 1.0f earlier... Patches 5-9 are: Reviewed-by: Kenneth Graunke 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 mesa 1/3] mesa: drop unused & deprecated lib
Quoting Eric Engestrom (2018-11-07 05:20:20) > DeprecationWarning: the imp module is deprecated in favour of importlib > > Signed-off-by: Eric Engestrom > --- > src/mesa/main/get_hash_generator.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/main/get_hash_generator.py > b/src/mesa/main/get_hash_generator.py > index 37dae45e0b39f06be6a2..f742ebff4b84cd64a9fa 100644 > --- a/src/mesa/main/get_hash_generator.py > +++ b/src/mesa/main/get_hash_generator.py > @@ -30,7 +30,7 @@ > > from __future__ import print_function > > -import os, sys, imp, getopt > +import os, sys, getopt > from collections import defaultdict > import get_hash_params > > -- > Cheers, > Eric > for this patch: Reviewed-by: Dylan Baker 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] radv: use LOAD_CONTEXT_REG when loading fast clear values
On 11/7/18 3:29 PM, Samuel Pitoiset wrote:
This avoids syncing the Micro Engine. This is only supported
for VI+ currently. There is probably a way for using
LOAD_CONTEXT_REG on previous chips but that could be done later.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/sid.h | 1 +
src/amd/vulkan/radv_cmd_buffer.c | 60 +---
src/amd/vulkan/radv_device.c | 4 +++
src/amd/vulkan/radv_private.h| 1 +
4 files changed, 46 insertions(+), 20 deletions(-)
diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index 5c53133147..35782046dd 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -217,6 +217,7 @@
#define PKT3_INCREMENT_CE_COUNTER 0x84
#define PKT3_INCREMENT_DE_COUNTER 0x85
#define PKT3_WAIT_ON_CE_COUNTER0x86
+#define PKT3_LOAD_CONTEXT_REG 0x9F /* new for VI */
#define PKT_TYPE_S(x) (((unsigned)(x) & 0x3) << 30)
#define PKT_TYPE_G(x) (((x) >> 30) & 0x3)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index de67a8a363..4e10470357 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -37,6 +37,8 @@
#include "ac_debug.h"
+#include "addrlib/gfx9/chip/gfx9_enum.h"
+
enum {
RADV_PREFETCH_VBO_DESCRIPTORS = (1 << 0),
RADV_PREFETCH_VS= (1 << 1),
@@ -1313,17 +1315,27 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer
*cmd_buffer,
if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
++reg_count;
- radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
- radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
- COPY_DATA_DST_SEL(COPY_DATA_REG) |
- (reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
- radeon_emit(cs, va);
- radeon_emit(cs, va >> 32);
- radeon_emit(cs, (R_028028_DB_STENCIL_CLEAR + 4 * reg_offset) >> 2);
- radeon_emit(cs, 0);
+ uint32_t reg = R_028028_DB_STENCIL_CLEAR + 4 * reg_offset;
- radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
- radeon_emit(cs, 0);
+ if (cmd_buffer->device->has_load_context_reg) {
+ radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 0));
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+ radeon_emit(cs, reg_count);
+ } else {
+ radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
+ radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
+ COPY_DATA_DST_SEL(COPY_DATA_REG) |
+ (reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, reg >> 2);
+ radeon_emit(cs, 0);
+
+ radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
+ radeon_emit(cs, 0);
+ }
Just figured that is useless because HTILE is only available for VI+.
}
/*
@@ -1443,17 +1455,25 @@ radv_load_color_clear_metadata(struct radv_cmd_buffer
*cmd_buffer,
uint32_t reg = R_028C8C_CB_COLOR0_CLEAR_WORD0 + cb_idx * 0x3c;
- radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, cmd_buffer->state.predicating));
- radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
- COPY_DATA_DST_SEL(COPY_DATA_REG) |
- COPY_DATA_COUNT_SEL);
- radeon_emit(cs, va);
- radeon_emit(cs, va >> 32);
- radeon_emit(cs, reg >> 2);
- radeon_emit(cs, 0);
+ if (cmd_buffer->device->has_load_context_reg) {
+ radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3,
cmd_buffer->state.predicating));
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+ radeon_emit(cs, 2);
+ } else {
+ radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4,
cmd_buffer->state.predicating));
+ radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
+ COPY_DATA_DST_SEL(COPY_DATA_REG) |
+ COPY_DATA_COUNT_SEL);
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, reg >> 2);
+ radeon_emit(cs, 0);
- radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, cmd_buffer->state.predicating));
- radeon_emit(cs, 0);
+ radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0,
cmd_buffer->state.predicating));
+ radeon_emit(cs, 0);
+ }
}
static void
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index d68111c25b..33a1b5bc1b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1680,6 +1680,10 @@ VkResult radv_CreateDevice(
device->p
Re: [Mesa-dev] [PATCH mesa 3/3] egl: remove dead code in glvnd dispatch generation code
On Wed, 7 Nov 2018 at 13:20, Eric Engestrom wrote: > > g_egldispatchstubs.[ch] are completely identical before and after this > patch. > In theory I agree with the idea here, but I'm quite wary about this. While the moment nobody uses this code, as we do ... it'll be rather unlikely that we'll fish through git log and revert. I suspect that we'll reinvent something new or simply wire the functions correctly. How about we improve the comment why/when we'll need this instead? -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 12/32] intel/isl: Disallow Yf and Ys for 1D depth surfaces
On Wed, Nov 07, 2018 at 11:17:38AM -0600, Jason Ekstrand wrote:
> On Wed, Nov 7, 2018 at 10:38 AM Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
> > On Fri, Oct 12, 2018 at 01:46:42PM -0500, Jason Ekstrand wrote:
> > > ---
> > > src/intel/isl/isl_gen7.c | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
> > > index f6f7e1ba7dc..fe420e4fbd8 100644
> > > --- a/src/intel/isl/isl_gen7.c
> > > +++ b/src/intel/isl/isl_gen7.c
> > > @@ -217,6 +217,15 @@ isl_gen6_filter_tiling(const struct isl_device *dev,
> > > if (isl_surf_usage_is_depth(info->usage)) {
> > >/* Depth requires Y. */
> > >*flags &= ISL_TILING_ANY_Y_MASK;
> > > +
> > > + /* The Yf and Ys tilings for 1D can't be easily faked as a 2D
> > surface
> > > + * because there's no calculable qpitch.
> >
> > Why is this problem for depth only?
> >
>
> Because the depth hardware doesn't allow 1D. For classic Y, we fake it as
> a 2D surface with a height of 1. We can't do that with Yf and Ys so we
> have to disallow them.
>
> Same applies to stencil but it's always W so it doesn't matter.
Ah, ok. It is actually the first thing documented in isl_emit_depth_stencil.c :)
I thought this was blit related. This patch is:
Reviewed-by: Topi Pohjolainen
>
> --Jason
>
>
> > > + *
> > > + * TODO: In theory, on could fake it with surface offset tricks
> > but
> > > + * that's currently being left as an exercise to the reader.
> > > + */
> > > + if (info->dim == ISL_SURF_DIM_1D)
> > > + *flags &= ~ISL_TILING_STD_Y_MASK;
> > > }
> > >
> > > /* Separate stencil requires W tiling, and W tiling requires separate
> > > --
> > > 2.19.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 v2 12/32] intel/isl: Disallow Yf and Ys for 1D depth surfaces
On Wed, Nov 7, 2018 at 10:38 AM Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Fri, Oct 12, 2018 at 01:46:42PM -0500, Jason Ekstrand wrote:
> > ---
> > src/intel/isl/isl_gen7.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
> > index f6f7e1ba7dc..fe420e4fbd8 100644
> > --- a/src/intel/isl/isl_gen7.c
> > +++ b/src/intel/isl/isl_gen7.c
> > @@ -217,6 +217,15 @@ isl_gen6_filter_tiling(const struct isl_device *dev,
> > if (isl_surf_usage_is_depth(info->usage)) {
> >/* Depth requires Y. */
> >*flags &= ISL_TILING_ANY_Y_MASK;
> > +
> > + /* The Yf and Ys tilings for 1D can't be easily faked as a 2D
> surface
> > + * because there's no calculable qpitch.
>
> Why is this problem for depth only?
>
Because the depth hardware doesn't allow 1D. For classic Y, we fake it as
a 2D surface with a height of 1. We can't do that with Yf and Ys so we
have to disallow them.
Same applies to stencil but it's always W so it doesn't matter.
--Jason
> > + *
> > + * TODO: In theory, on could fake it with surface offset tricks
> but
> > + * that's currently being left as an exercise to the reader.
> > + */
> > + if (info->dim == ISL_SURF_DIM_1D)
> > + *flags &= ~ISL_TILING_STD_Y_MASK;
> > }
> >
> > /* Separate stencil requires W tiling, and W tiling requires separate
> > --
> > 2.19.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 mesa 2/3] egl: fix python lib deprecation warning
On Wednesday, 2018-11-07 09:51:12 -0700, Kyle Brenneman wrote:
> On 11/07/2018 06:20 AM, Eric Engestrom wrote:
> >DeprecationWarning: the imp module is deprecated in favour of importlib
> >
> > importlib is available since python 2.7 and 3.1, and we already require
> > 2.7 and 3.4 so we can simply use the new lib.
> >
> > Signed-off-by: Eric Engestrom
> > ---
> > src/egl/generate/gen_egl_dispatch.py | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/egl/generate/gen_egl_dispatch.py
> > b/src/egl/generate/gen_egl_dispatch.py
> > index eeb3f3f9a5a2051b9585..0c4d2956eff28911336c 100644
> > --- a/src/egl/generate/gen_egl_dispatch.py
> > +++ b/src/egl/generate/gen_egl_dispatch.py
> > @@ -34,7 +34,7 @@
> > import argparse
> > import collections
> > -import imp
> > +import importlib.machinery
> > import sys
> > import textwrap
> > @@ -51,7 +51,7 @@ def main():
> > # The function list is a Python module, but it's specified on the
> > command
> > # line.
> > -eglFunctionList = imp.load_source("eglFunctionList",
> > args.func_list_file)
> > +eglFunctionList =
> > importlib.machinery.SourceFileLoader("eglFunctionList",
> > args.func_list_file).load_module()
> > xmlFunctions = genCommon.getFunctions(args.xml_files)
> > xmlByName = dict((f.name, f) for f in xmlFunctions)
> I think importlib.machinery.SourceFileLoader is only available starting with
> Python 3.3, so the script would break if you tried to run it with Python 2.
>
> For what it's worth, though, loading the eglFunctionList module dynamically
> like that was originally intended just to make it easier for a vendor
> library to use the gen_egl_dispatch.py script from libglvnd, but with its
> own function list. In Mesa's case, just a simple "import eglFunctionList"
> would probably work just as well.
Good point, I didn't think about it hard enough. I'll send a v2 with
that tomorrow.
What do you think about patch 3? Am I butchering something we should
be keeping around?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 3/3] egl: remove dead code in glvnd dispatch generation code
On 11/07/2018 06:20 AM, Eric Engestrom wrote:
g_egldispatchstubs.[ch] are completely identical before and after this
patch.
Signed-off-by: Eric Engestrom
---
src/egl/generate/eglFunctionList.py | 203 +++
src/egl/generate/gen_egl_dispatch.py | 61 ++--
2 files changed, 91 insertions(+), 173 deletions(-)
diff --git a/src/egl/generate/eglFunctionList.py
b/src/egl/generate/eglFunctionList.py
index 667704eb2cb46fd06ff2..a480efca0d77a956dd78 100644
--- a/src/egl/generate/eglFunctionList.py
+++ b/src/egl/generate/eglFunctionList.py
@@ -5,36 +5,10 @@
This is used from gen_egl_dispatch.py.
-EGL_FUNCTIONS is a sequence of (name, eglData) pairs, where name is the name
-of the function, and eglData is a dictionary containing data about that
-function.
+EGL_FUNCTIONS is a sequence of (name, method) pairs, where name is the name
+of the function, and method is a string describing how to select a vendor
+library for that function:
-The values in the eglData dictionary are:
-- method (string):
-How to select a vendor library. See "Method values" below.
-
-- prefix (string):
-This string is prepended to the name of the dispatch function. If
-unspecified, the default is "" (an empty string).
-
-- static (boolean)
- If True, this function should be declared static.
-
-- "public" (boolean)
-If True, the function should be exported from the library. Vendor libraries
-generally should not use this.
-
-- extension (string):
-If specified, this is the name of a macro to check for before defining a
-function. Used for checking for extension macros and such.
-
-- retval (string):
-If specified, this is a C expression with the default value to return if we
-can't find a function to call. By default, it will try to guess from the
-return type: EGL_NO_whatever for the various handle types, NULL for
-pointers, and zero for everything else.
-
-method values:
- "custom"
The dispatch stub will be hand-written instead of generated.
@@ -53,158 +27,139 @@
Select the vendor that owns the current context.
"""
-def _eglFunc(name, method, static=None, public=False, inheader=None, prefix="dispatch_", extension=None, retval=None):
-"""
-A convenience function to define an entry in the EGL function list.
-"""
-if static is None:
-static = (not public and method != "custom")
-if inheader is None:
-inheader = (not static)
-values = {
-"method" : method,
-"prefix" : prefix,
-"extension" : extension,
-"retval" : retval,
-"static" : static,
-"public" : public,
-"inheader" : inheader,
-}
-return (name, values)
-
EGL_FUNCTIONS = (
# EGL_VERSION_1_0
-_eglFunc("eglChooseConfig", "none"),
-_eglFunc("eglCopyBuffers", "none"),
-_eglFunc("eglCreateContext", "none"),
-_eglFunc("eglCreatePbufferSurface", "none"),
-_eglFunc("eglCreatePixmapSurface", "none"),
-_eglFunc("eglCreateWindowSurface", "none"),
-_eglFunc("eglDestroyContext","none"),
-_eglFunc("eglDestroySurface","none"),
-_eglFunc("eglGetConfigAttrib", "none"),
-_eglFunc("eglGetConfigs","none"),
-_eglFunc("eglQueryContext", "none"),
-_eglFunc("eglQuerySurface", "none"),
-_eglFunc("eglSwapBuffers", "none"),
-_eglFunc("eglWaitGL","none"),
-_eglFunc("eglWaitNative","none"),
-_eglFunc("eglTerminate", "none"),
-_eglFunc("eglInitialize","none"),
+("eglChooseConfig", "none"),
+("eglCopyBuffers", "none"),
+("eglCreateContext", "none"),
+("eglCreatePbufferSurface", "none"),
+("eglCreatePixmapSurface", "none"),
+("eglCreateWindowSurface", "none"),
+("eglDestroyContext","none"),
+("eglDestroySurface","none"),
+("eglGetConfigAttrib", "none"),
+("eglGetConfigs","none"),
+("eglQueryContext", "none"),
+("eglQuerySurface", "none"),
+("eglSwapBuffers", "none"),
+("eglWaitGL","none"),
+("eglWaitNative","none"),
+("eglTerminate", "none"),
+("eglInitialize","none"),
-_eglFunc("eglGetCurrentDisplay", "none"),
-_eglFunc("eglGetCurrentSurface", "none"),
-_eglFunc("eglGetDisplay","none"),
-_eglFunc("eglGe
Re: [Mesa-dev] [PATCH v2 25/32] intel/isl: Add a max_miptail_levels field to isl_tile_info
On Fri, Oct 12, 2018 at 01:46:55PM -0500, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl.c | 5 +
> src/intel/isl/isl.h | 7 +++
> 2 files changed, 12 insertions(+)
Matches PRM:
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 4a8380ad540..3657b11ee00 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -181,6 +181,7 @@ isl_tiling_get_info(enum isl_tiling tiling,
>return;
> }
>
> + uint32_t max_miptail_levels = 0;
> switch (tiling) {
> case ISL_TILING_LINEAR:
>assert(bs > 0);
> @@ -239,6 +240,7 @@ isl_tiling_get_info(enum isl_tiling tiling,
> .d = 1,
> .a = 1,
> };
> + max_miptail_levels = is_Ys ? 16 : 12;
> break;
>
>case ISL_SURF_DIM_2D:
> @@ -262,6 +264,7 @@ isl_tiling_get_info(enum isl_tiling tiling,
> logical_el.h >>= (ffs(samples) - 1) / 2;
> logical_el.a = samples;
> }
> + max_miptail_levels = is_Ys ? 16 - ffs(samples) : 11;
> break;
>
>case ISL_SURF_DIM_3D:
> @@ -279,6 +282,7 @@ isl_tiling_get_info(enum isl_tiling tiling,
> .d = 1 << (4 - ((ffs(format_bpb) - 3) / 3) + (1 * is_Ys)),
> .a = 1,
> };
> + max_miptail_levels = is_Ys ? 16 : 12;
> break;
>}
>
> @@ -331,6 +335,7 @@ isl_tiling_get_info(enum isl_tiling tiling,
>.format_bpb = format_bpb,
>.logical_extent_el = logical_el,
>.phys_extent_B = phys_B,
> + .max_miptail_levels = max_miptail_levels,
> };
> }
>
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index 4fb212e33d5..0bcb7edc899 100644
> --- a/src/intel/isl/isl.h
> +++ b/src/intel/isl/isl.h
> @@ -1085,6 +1085,13 @@ struct isl_tile_info {
> */
> struct isl_extent4d logical_extent_el;
>
> + /** The maximum number of miplevels that will fit in the miptail.
> +*
> +* This does not guarantee that the given number of miplevels will fit in
> +* the miptail as that is also dependent on the size of the miplevels.
> +*/
> + uint32_t max_miptail_levels;
> +
> /** The physical size of the tile in bytes and rows of bytes
> *
> * This field determines how the tiles of a surface are physically layed
> --
> 2.19.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 mesa 2/3] egl: fix python lib deprecation warning
On 11/07/2018 06:20 AM, Eric Engestrom wrote:
DeprecationWarning: the imp module is deprecated in favour of importlib
importlib is available since python 2.7 and 3.1, and we already require
2.7 and 3.4 so we can simply use the new lib.
Signed-off-by: Eric Engestrom
---
src/egl/generate/gen_egl_dispatch.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/egl/generate/gen_egl_dispatch.py
b/src/egl/generate/gen_egl_dispatch.py
index eeb3f3f9a5a2051b9585..0c4d2956eff28911336c 100644
--- a/src/egl/generate/gen_egl_dispatch.py
+++ b/src/egl/generate/gen_egl_dispatch.py
@@ -34,7 +34,7 @@
import argparse
import collections
-import imp
+import importlib.machinery
import sys
import textwrap
@@ -51,7 +51,7 @@ def main():
# The function list is a Python module, but it's specified on the command
# line.
-eglFunctionList = imp.load_source("eglFunctionList", args.func_list_file)
+eglFunctionList = importlib.machinery.SourceFileLoader("eglFunctionList",
args.func_list_file).load_module()
xmlFunctions = genCommon.getFunctions(args.xml_files)
xmlByName = dict((f.name, f) for f in xmlFunctions)
I think importlib.machinery.SourceFileLoader is only available starting
with Python 3.3, so the script would break if you tried to run it with
Python 2.
For what it's worth, though, loading the eglFunctionList module
dynamically like that was originally intended just to make it easier for
a vendor library to use the gen_egl_dispatch.py script from libglvnd,
but with its own function list. In Mesa's case, just a simple "import
eglFunctionList" would probably work just as well.
-Kyle
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gm107/ir: fix compile time warning in getTEXSMask
On Wed, Nov 7, 2018 at 3:21 PM Ilia Mirkin wrote: > > Reviewed-by: Ilia Mirkin > > Although I'd rather the return go into the "default:" case, after the > assert, which is the reason for the warning. sure, I'll move it. > On Wed, Nov 7, 2018 at 7:50 AM Karol Herbst wrote: > > > > In function 'uint8_t nv50_ir::getTEXSMask(uint8_t)': > > warning: control reaches end of non-void function [-Wreturn-type] > > > > Reported-by: Moiman@freenode > > Fixes: f821e80213e38e93f96255b3deacb737a600ed40 > >"gm107/ir: use scalar tex instructions where possible" > > Signed-off-by: Karol Herbst > > --- > > src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > > index 241061ab837..842cf5cb250 100644 > > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > > @@ -2739,6 +2739,7 @@ getTEXSMask(uint8_t mask) > > default: > >assert(!"invalid mask"); > > } > > + return 0; > > } > > > > static uint8_t > > -- > > 2.19.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 v2 04/13] intel/genxml: Add engine definition to render engine instructions (gen4)
On Tue, Nov 06, 2018 at 12:40:43PM +, Lionel Landwerlin wrote: > On 31/10/2018 13:12, Toni Lönnberg wrote: > > Instructions meant for the render engine now have a definition > > specifying that so that can differentiate instructions meant for > > different engines due to shared opcodes. v2: Divided into individual > > patches for each gen --- > > Just responding to this one, but this applies to all the xml changes. > > I think you can set the engine="render" on the following commands : > CONSTANT_BUFFER > CS_URB_STATE > MI_CLFLUSH > MI_FLUSH > MI_LOAD_SCAN_LINES_INCL > MI_REPORT_PERF_COUNT > MI_URB_ATOMIC_ALLOC > MI_URB_CLEAR > MI_SET_CONTEXT > MI_STORE_URB_MEM > MI_RS_CONTEXT > MI_RS_CONTROL > MI_RS_STORE_DATA_IMM > SWTESS_BASE_ADDRESS > URB_FENCE > > Blitter only commands : > XY_COLOR_BLT > XY_SETUP_BLT > XY_SRC_COPY_BLT > XY_TEXT_IMMEDIATE_BLT > > Then some special cases : > MI_MATH : Only render on Gen7.5 > MI_WAIT_FOR_EVENT : Render only < SKL, Render & Blitter >= SKL > MI_DISPLAY_FLIP : Blitter & Render > > We're also missing MI_FLUSH_DW which is available everywhere but render > engine (replacing MI_FLUSH). Yeah I know as that's the first one I stumbled on when looking at some media workloads. There's also blitter instructions missing from a lot of the platforms as well as all the media instructions. There's also other instructions missing which are shared between engines but use certain bits of the data differently. > > Thanks! > > - > Lionel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 24/32] intel/isl: Add initial data-structure support for miptails
On Fri, Oct 12, 2018 at 01:46:54PM -0500, Jason Ekstrand wrote:
> This commit just adds a miptail start field to isl_surf and wires it up
> in the RENDER_SURFACE_STATE and 3DSTATE_DEPTH code. We also add a
> minimum miptail LOD so that client drivers have a knob to control the
> miptails a bit.
> ---
> src/intel/isl/isl.c| 1 +
> src/intel/isl/isl.h| 11 +++
> src/intel/isl/isl_emit_depth_stencil.c | 2 +-
> src/intel/isl/isl_surface_state.c | 5 +
> 4 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 3d0741bc207..4a8380ad540 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -1653,6 +1653,7 @@ isl_surf_init_s(const struct isl_device *dev,
>.row_pitch_B = row_pitch_B,
>.array_pitch_el_rows = array_pitch_el_rows,
>.array_pitch_span = array_pitch_span,
> + .miptail_start_level = 15,
>
>.usage = info->usage,
> };
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index 213f5b408e2..4fb212e33d5 100644
> --- a/src/intel/isl/isl.h
> +++ b/src/intel/isl/isl.h
> @@ -1145,6 +1145,9 @@ struct isl_surf_init_info {
> /** Lower bound for isl_surf::alignment, in bytes. */
> uint32_t min_alignment_B;
>
> + /** Lower bound for where to start the miptail */
> + uint32_t min_miptail_start_level;
> +
> /**
> * Exact value for isl_surf::row_pitch. Ignored if zero. isl_surf_init()
> * will fail if this is misaligned or out of bounds.
> @@ -1219,6 +1222,14 @@ struct isl_surf {
>
> enum isl_array_pitch_span array_pitch_span;
>
> + /**
> +* Level at which the miptail starts.
> +*
> +* This value is inclusive in the sense that the miptail contains this
> +* level.
> +*/
> + uint32_t miptail_start_level;
> +
> /** Copy of isl_surf_init_info::usage. */
> isl_surf_usage_flags_t usage;
> };
> diff --git a/src/intel/isl/isl_emit_depth_stencil.c
> b/src/intel/isl/isl_emit_depth_stencil.c
> index b07da781be8..c1a40ee20f0 100644
> --- a/src/intel/isl/isl_emit_depth_stencil.c
> +++ b/src/intel/isl/isl_emit_depth_stencil.c
> @@ -115,7 +115,7 @@ isl_genX(emit_depth_stencil_hiz_s)(const struct
> isl_device *dev, void *batch,
>/* We don't use miptails yet. The PRM recommends that you set "Mip
> Tail
> * Start LOD" to 15 to prevent the hardware from trying to use them.
> */
> - db.MipTailStartLOD = 15;
> + db.MipTailStartLOD = info->depth_surf->miptail_start_level;
> #elif GEN_GEN >= 7
>/* Gen7+ depth is always Y-tiled. We don't even have a bit for it */
> #else
> diff --git a/src/intel/isl/isl_surface_state.c
> b/src/intel/isl/isl_surface_state.c
> index abd4767acd7..b3e51d6f5e0 100644
> --- a/src/intel/isl/isl_surface_state.c
> +++ b/src/intel/isl/isl_surface_state.c
> @@ -423,10 +423,7 @@ isl_genX(surf_fill_state_s)(const struct isl_device
> *dev, void *state,
> }
>
> #if GEN_GEN >= 9
> - /* We don't use miptails yet. The PRM recommends that you set "Mip Tail
> -* Start LOD" to 15 to prevent the hardware from trying to use them.
> -*/
Maybe add the "The PRM recommends..." part into isl_surf_init_s() to document
the magic value 15 now there.
Reviewed-by: Topi Pohjolainen
> - s.MipTailStartLOD = 15;
> + s.MipTailStartLOD = info->surf->miptail_start_level;
> #endif
>
> #if GEN_GEN >= 6
> --
> 2.19.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] [PATCH v3 09/10] intel/genxml: Add engine definition to render engine instructions (gen10)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen10.xml | 224 ++--- 1 file changed, 112 insertions(+), 112 deletions(-) diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml index abd5da297d6..1c95f224754 100644 --- a/src/intel/genxml/gen10.xml +++ b/src/intel/genxml/gen10.xml @@ -813,7 +813,7 @@ - + @@ -839,7 +839,7 @@ - + @@ -855,7 +855,7 @@ - + @@ -872,7 +872,7 @@ - + @@ -889,7 +889,7 @@ - + @@ -906,7 +906,7 @@ - + @@ -923,7 +923,7 @@ - + @@ -940,7 +940,7 @@ - + @@ -949,7 +949,7 @@ - + @@ -958,7 +958,7 @@ - + @@ -967,7 +967,7 @@ - + @@ -976,7 +976,7 @@ - + @@ -985,7 +985,7 @@ - + @@ -999,7 +999,7 @@ - + @@ -1009,7 +1009,7 @@ - + @@ -1019,7 +1019,7 @@ - + @@ -1030,7 +1030,7 @@ - + @@ -1040,7 +1040,7 @@ - + @@ -1080,7 +1080,7 @@ - + @@ -1090,7 +1090,7 @@ - + @@ -1100,7 +1100,7 @@ - + @@ -1110,7 +1110,7 @@ - + @@ -1121,7 +1121,7 @@ - + @@ -1131,7 +1131,7 @@ - + @@ -1169,7 +1169,7 @@ - + @@ -1188,7 +1188,7 @@ - + @@ -1236,7 +1236,7 @@ - + @@ -1260,7 +1260,7 @@ - + @@ -1284,7 +1284,7 @@ - + @@ -1308,7 +1308,7 @@ - + @@ -1334,7 +1334,7 @@ - + @@ -1360,7 +1360,7 @@ - + @@ -1372,7 +1372,7 @@ - + @@ -1441,7 +1441,7 @@ - + @@ -1454,7 +1454,7 @@ - + @@ -1500,7 +1500,7 @@ - + @@ -1517,7 +1517,7 @@ - + @@ -1531,7 +1531,7 @@ - + @@ -1541,7 +1541,7 @@ - + @@ -1555,7 +1555,7 @@ - + @@ -1565,7 +1565,7 @@ - + @@ -1576,7 +1576,7 @@ - + @@ -1639,7 +1639,7 @@ - + @@ -1656,7 +1656,7 @@ - + @@ -1694,7 +1694,7 @@ - + @@ -1704,7 +1704,7 @@ - + @@ -1714,7 +1714,7 @@ - + @@ -1724,7 +1724,7 @@ - + @@ -1734,7 +1734,7 @@ - + @@ -1744,7 +1744,7 @@ - + @@ -1805,7 +1805,7 @@ - + @@ -1823,7 +1823,7 @@ - + @@ -1834,7 +1834,7 @@ - + @@ -1848,7 +1848,7 @@ - + @@ -1857,7 +1857,7 @@ - + @@ -1866,7 +1866,7 @@ - + @@ -1875,7 +1875,7 @@ - + @@ -1884,7 +1884,7 @@ - + @@ -1893,7 +1893,7 @@ - + @@ -1902,7 +1902,7 @@ - + @@ -1972,7 +1972,7 @@ - + @@ -2005,7 +2005,7 @@ - + @@ -2019,7 +2019,7 @@ - + @@ -2028,7 +2028,7 @@ - + @@ -2060,7 +2060,7 @@ - + @@ -2078,7 +2078,7 @@ - + @@ -2097,7 +2097,7 @@ - + @@ -2111,7 +2111,7 @@ - + @@ -2144,7 +2144,7 @@ - + @@ -2174,7 +2174,7 @@ - + @@ -2184,7 +2184,7 @@ - + @@ -2195,7 +2195,7 @@ - + @@ -2206,7 +2206,7 @@ - + @@ -2217,7 +2217,7 @@ - + @@ -2228,7 +2228,7 @@
Re: [Mesa-dev] [PATCH v2 12/32] intel/isl: Disallow Yf and Ys for 1D depth surfaces
On Fri, Oct 12, 2018 at 01:46:42PM -0500, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl_gen7.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
> index f6f7e1ba7dc..fe420e4fbd8 100644
> --- a/src/intel/isl/isl_gen7.c
> +++ b/src/intel/isl/isl_gen7.c
> @@ -217,6 +217,15 @@ isl_gen6_filter_tiling(const struct isl_device *dev,
> if (isl_surf_usage_is_depth(info->usage)) {
>/* Depth requires Y. */
>*flags &= ISL_TILING_ANY_Y_MASK;
> +
> + /* The Yf and Ys tilings for 1D can't be easily faked as a 2D surface
> + * because there's no calculable qpitch.
Why is this problem for depth only?
> + *
> + * TODO: In theory, on could fake it with surface offset tricks but
> + * that's currently being left as an exercise to the reader.
> + */
> + if (info->dim == ISL_SURF_DIM_1D)
> + *flags &= ~ISL_TILING_STD_Y_MASK;
> }
>
> /* Separate stencil requires W tiling, and W tiling requires separate
> --
> 2.19.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] [PATCH v3 11/11] intel/genxml: Add engine definition to render engine instructions (gen11)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen11.xml | 230 ++--- 1 file changed, 115 insertions(+), 115 deletions(-) diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml index c69d7dc89c2..22d73fe1f48 100644 --- a/src/intel/genxml/gen11.xml +++ b/src/intel/genxml/gen11.xml @@ -823,7 +823,7 @@ - + @@ -849,7 +849,7 @@ - + @@ -858,7 +858,7 @@ - + @@ -874,7 +874,7 @@ - + @@ -891,7 +891,7 @@ - + @@ -908,7 +908,7 @@ - + @@ -925,7 +925,7 @@ - + @@ -942,7 +942,7 @@ - + @@ -959,7 +959,7 @@ - + @@ -968,7 +968,7 @@ - + @@ -977,7 +977,7 @@ - + @@ -986,7 +986,7 @@ - + @@ -995,7 +995,7 @@ - + @@ -1004,7 +1004,7 @@ - + @@ -1018,7 +1018,7 @@ - + @@ -1028,7 +1028,7 @@ - + @@ -1038,7 +1038,7 @@ - + @@ -1049,7 +1049,7 @@ - + @@ -1059,7 +1059,7 @@ - + @@ -1099,7 +1099,7 @@ - + @@ -1109,7 +1109,7 @@ - + @@ -1119,7 +1119,7 @@ - + @@ -1129,7 +1129,7 @@ - + @@ -1140,7 +1140,7 @@ - + @@ -1150,7 +1150,7 @@ - + @@ -1188,7 +1188,7 @@ - + @@ -1207,7 +1207,7 @@ - + @@ -1254,7 +1254,7 @@ - + @@ -1278,7 +1278,7 @@ - + @@ -1302,7 +1302,7 @@ - + @@ -1326,7 +1326,7 @@ - + @@ -1352,7 +1352,7 @@ - + @@ -1378,7 +1378,7 @@ - + @@ -1390,7 +1390,7 @@ - + @@ -1457,7 +1457,7 @@ - + @@ -1475,7 +1475,7 @@ - + @@ -1520,7 +1520,7 @@ - + @@ -1537,7 +1537,7 @@ - + @@ -1551,7 +1551,7 @@ - + @@ -1561,7 +1561,7 @@ - + @@ -1575,7 +1575,7 @@ - + @@ -1585,7 +1585,7 @@ - + @@ -1596,7 +1596,7 @@ - + @@ -1659,7 +1659,7 @@ - + @@ -1676,7 +1676,7 @@ - + @@ -1714,7 +1714,7 @@ - + @@ -1724,7 +1724,7 @@ - + @@ -1734,7 +1734,7 @@ - + @@ -1744,7 +1744,7 @@ - + @@ -1754,7 +1754,7 @@ - + @@ -1764,7 +1764,7 @@ - + @@ -1825,7 +1825,7 @@ - + @@ -1843,7 +1843,7 @@ - + @@ -1854,7 +1854,7 @@ - + @@ -1868,7 +1868,7 @@ - + @@ -1877,7 +1877,7 @@ - + @@ -1886,7 +1886,7 @@ - + @@ -1895,7 +1895,7 @@ - + @@ -1904,7 +1904,7 @@ - + @@ -1913,7 +1913,7 @@ - + @@ -1922,7 +1922,7 @@ - + @@ -1992,7 +1992,7 @@ - + @@ -2025,7 +2025,7 @@ - + @@ -2039,7 +2039,7 @@ - + @@ -2048,7 +2048,7 @@ - + @@ -2080,7 +2080,7 @@ - + @@ -2098,7 +2098,7 @@ - + @@ -2117,7 +2117,7 @@ - + @@ -2131,7 +2131,7 @@ - + @@ -2164,7 +2164,7 @@ - + @@ -2194,7 +2194,7 @@ - + @@ -2204,7 +2204,7 @@ - + @@ -2215,7 +2215,7 @@ - + @@ -2226,7 +2226,7 @@ - + @@ -2237,7 +2237,7 @@
[Mesa-dev] [PATCH v3 08/10] intel/genxml: Add engine definition to render engine instructions (gen9)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen9.xml | 226 +++--- 1 file changed, 113 insertions(+), 113 deletions(-) diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml index ca268254503..12ad3d9f592 100644 --- a/src/intel/genxml/gen9.xml +++ b/src/intel/genxml/gen9.xml @@ -776,7 +776,7 @@ - + @@ -798,7 +798,7 @@ - + @@ -814,7 +814,7 @@ - + @@ -831,7 +831,7 @@ - + @@ -848,7 +848,7 @@ - + @@ -865,7 +865,7 @@ - + @@ -882,7 +882,7 @@ - + @@ -899,7 +899,7 @@ - + @@ -908,7 +908,7 @@ - + @@ -917,7 +917,7 @@ - + @@ -926,7 +926,7 @@ - + @@ -935,7 +935,7 @@ - + @@ -944,7 +944,7 @@ - + @@ -958,7 +958,7 @@ - + @@ -968,7 +968,7 @@ - + @@ -978,7 +978,7 @@ - + @@ -989,7 +989,7 @@ - + @@ -999,7 +999,7 @@ - + @@ -1039,7 +1039,7 @@ - + @@ -1049,7 +1049,7 @@ - + @@ -1059,7 +1059,7 @@ - + @@ -1069,7 +1069,7 @@ - + @@ -1079,7 +1079,7 @@ - + @@ -1089,7 +1089,7 @@ - + @@ -1127,7 +1127,7 @@ - + @@ -1146,7 +1146,7 @@ - + @@ -1194,7 +1194,7 @@ - + @@ -1218,7 +1218,7 @@ - + @@ -1242,7 +1242,7 @@ - + @@ -1266,7 +1266,7 @@ - + @@ -1292,7 +1292,7 @@ - + @@ -1318,7 +1318,7 @@ - + @@ -1330,7 +1330,7 @@ - + @@ -1399,7 +1399,7 @@ - + @@ -1412,7 +1412,7 @@ - + @@ -1458,7 +1458,7 @@ - + @@ -1475,7 +1475,7 @@ - + @@ -1489,7 +1489,7 @@ - + @@ -1499,7 +1499,7 @@ - + @@ -1513,7 +1513,7 @@ - + @@ -1523,7 +1523,7 @@ - + @@ -1534,7 +1534,7 @@ - + @@ -1596,7 +1596,7 @@ - + @@ -1613,7 +1613,7 @@ - + @@ -1646,7 +1646,7 @@ - + @@ -1656,7 +1656,7 @@ - + @@ -1666,7 +1666,7 @@ - + @@ -1676,7 +1676,7 @@ - + @@ -1686,7 +1686,7 @@ - + @@ -1696,7 +1696,7 @@ - + @@ -1757,7 +1757,7 @@ - + @@ -1775,7 +1775,7 @@ - + @@ -1786,7 +1786,7 @@ - + @@ -1800,7 +1800,7 @@ - + @@ -1809,7 +1809,7 @@ - + @@ -1818,7 +1818,7 @@ - + @@ -1827,7 +1827,7 @@ - + @@ -1836,7 +1836,7 @@ - + @@ -1845,7 +1845,7 @@ - + @@ -1854,7 +1854,7 @@ - + @@ -1924,7 +1924,7 @@ - + @@ -1957,7 +1957,7 @@ - + @@ -1971,7 +1971,7 @@ - + @@ -1980,7 +1980,7 @@ - + @@ -2012,7 +2012,7 @@ - + @@ -2030,7 +2030,7 @@ - + @@ -2049,7 +2049,7 @@ - + @@ -2063,7 +2063,7 @@ - + @@ -2096,7 +2096,7 @@ - + @@ -2126,7 +2126,7 @@ - + @@ -2136,7 +2136,7 @@ - + @@ -2147,7 +2147,7 @@ - + @@ -2158,7 +2158,7 @@ - + @@ -2169,7 +2169,7 @@ - + @@ -2180,7 +2180,7 @@ -
[Mesa-dev] [PATCH v3 10/10] intel/genxml: Add engine definition to render engine instructions (gen11)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen11.xml | 230 ++--- 1 file changed, 115 insertions(+), 115 deletions(-) diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml index c69d7dc89c2..22d73fe1f48 100644 --- a/src/intel/genxml/gen11.xml +++ b/src/intel/genxml/gen11.xml @@ -823,7 +823,7 @@ - + @@ -849,7 +849,7 @@ - + @@ -858,7 +858,7 @@ - + @@ -874,7 +874,7 @@ - + @@ -891,7 +891,7 @@ - + @@ -908,7 +908,7 @@ - + @@ -925,7 +925,7 @@ - + @@ -942,7 +942,7 @@ - + @@ -959,7 +959,7 @@ - + @@ -968,7 +968,7 @@ - + @@ -977,7 +977,7 @@ - + @@ -986,7 +986,7 @@ - + @@ -995,7 +995,7 @@ - + @@ -1004,7 +1004,7 @@ - + @@ -1018,7 +1018,7 @@ - + @@ -1028,7 +1028,7 @@ - + @@ -1038,7 +1038,7 @@ - + @@ -1049,7 +1049,7 @@ - + @@ -1059,7 +1059,7 @@ - + @@ -1099,7 +1099,7 @@ - + @@ -1109,7 +1109,7 @@ - + @@ -1119,7 +1119,7 @@ - + @@ -1129,7 +1129,7 @@ - + @@ -1140,7 +1140,7 @@ - + @@ -1150,7 +1150,7 @@ - + @@ -1188,7 +1188,7 @@ - + @@ -1207,7 +1207,7 @@ - + @@ -1254,7 +1254,7 @@ - + @@ -1278,7 +1278,7 @@ - + @@ -1302,7 +1302,7 @@ - + @@ -1326,7 +1326,7 @@ - + @@ -1352,7 +1352,7 @@ - + @@ -1378,7 +1378,7 @@ - + @@ -1390,7 +1390,7 @@ - + @@ -1457,7 +1457,7 @@ - + @@ -1475,7 +1475,7 @@ - + @@ -1520,7 +1520,7 @@ - + @@ -1537,7 +1537,7 @@ - + @@ -1551,7 +1551,7 @@ - + @@ -1561,7 +1561,7 @@ - + @@ -1575,7 +1575,7 @@ - + @@ -1585,7 +1585,7 @@ - + @@ -1596,7 +1596,7 @@ - + @@ -1659,7 +1659,7 @@ - + @@ -1676,7 +1676,7 @@ - + @@ -1714,7 +1714,7 @@ - + @@ -1724,7 +1724,7 @@ - + @@ -1734,7 +1734,7 @@ - + @@ -1744,7 +1744,7 @@ - + @@ -1754,7 +1754,7 @@ - + @@ -1764,7 +1764,7 @@ - + @@ -1825,7 +1825,7 @@ - + @@ -1843,7 +1843,7 @@ - + @@ -1854,7 +1854,7 @@ - + @@ -1868,7 +1868,7 @@ - + @@ -1877,7 +1877,7 @@ - + @@ -1886,7 +1886,7 @@ - + @@ -1895,7 +1895,7 @@ - + @@ -1904,7 +1904,7 @@ - + @@ -1913,7 +1913,7 @@ - + @@ -1922,7 +1922,7 @@ - + @@ -1992,7 +1992,7 @@ - + @@ -2025,7 +2025,7 @@ - + @@ -2039,7 +2039,7 @@ - + @@ -2048,7 +2048,7 @@ - + @@ -2080,7 +2080,7 @@ - + @@ -2098,7 +2098,7 @@ - + @@ -2117,7 +2117,7 @@ - + @@ -2131,7 +2131,7 @@ - + @@ -2164,7 +2164,7 @@ - + @@ -2194,7 +2194,7 @@ - + @@ -2204,7 +2204,7 @@ - + @@ -2215,7 +2215,7 @@ - + @@ -2226,7 +2226,7 @@ - + @@ -2237,7 +2237,7 @@
[Mesa-dev] [PATCH v3 05/10] intel/genxml: Add engine definition to render engine instructions (gen7)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen7.xml | 166 +++--- 1 file changed, 83 insertions(+), 83 deletions(-) diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml index 6dde7973e69..49b08281993 100644 --- a/src/intel/genxml/gen7.xml +++ b/src/intel/genxml/gen7.xml @@ -568,7 +568,7 @@ - + @@ -589,7 +589,7 @@ - + @@ -601,7 +601,7 @@ - + @@ -610,7 +610,7 @@ - + @@ -619,7 +619,7 @@ - + @@ -628,7 +628,7 @@ - + @@ -637,7 +637,7 @@ - + @@ -646,7 +646,7 @@ - + @@ -656,7 +656,7 @@ - + @@ -666,7 +666,7 @@ - + @@ -677,7 +677,7 @@ - + @@ -687,7 +687,7 @@ - + @@ -740,7 +740,7 @@ - + @@ -749,7 +749,7 @@ - + @@ -758,7 +758,7 @@ - + @@ -767,7 +767,7 @@ - + @@ -776,7 +776,7 @@ - + @@ -785,7 +785,7 @@ - + @@ -822,7 +822,7 @@ - + @@ -832,7 +832,7 @@ - + @@ -846,7 +846,7 @@ - + @@ -881,7 +881,7 @@ - + @@ -943,7 +943,7 @@ - + @@ -955,7 +955,7 @@ - + @@ -991,7 +991,7 @@ - + @@ -1009,7 +1009,7 @@ - + @@ -1023,7 +1023,7 @@ - + @@ -1033,7 +1033,7 @@ - + @@ -1066,7 +1066,7 @@ - + @@ -1076,7 +1076,7 @@ - + @@ -1087,7 +1087,7 @@ - + @@ -1139,7 +1139,7 @@ - + @@ -1153,7 +1153,7 @@ - + @@ -1167,7 +1167,7 @@ - + @@ -1181,7 +1181,7 @@ - + @@ -1195,7 +1195,7 @@ - + @@ -1209,7 +1209,7 @@ - + @@ -1220,7 +1220,7 @@ - + @@ -1234,7 +1234,7 @@ - + @@ -1243,7 +1243,7 @@ - + @@ -1252,7 +1252,7 @@ - + @@ -1261,7 +1261,7 @@ - + @@ -1270,7 +1270,7 @@ - + @@ -1279,7 +1279,7 @@ - + @@ -1288,7 +1288,7 @@ - + @@ -1329,7 +1329,7 @@ - + @@ -1338,7 +1338,7 @@ - + @@ -1415,7 +1415,7 @@ - + @@ -1429,7 +1429,7 @@ - + @@ -1448,7 +1448,7 @@ - + @@ -1460,7 +1460,7 @@ - + @@ -1488,7 +1488,7 @@ - + @@ -1519,7 +1519,7 @@ - + @@ -1530,7 +1530,7 @@ - + @@ -1541,7 +1541,7 @@ - + @@ -1552,7 +1552,7 @@ - + @@ -1563,7 +1563,7 @@ - + @@ -1574,7 +1574,7 @@ - + @@ -1585,7 +1585,7 @@ - + @@ -1593,7 +1593,7 @@ - + @@ -1602,7 +1602,7 @@ - + @@ -1611,7 +1611,7 @@ - + @@ -1645,7 +1645,7 @@ - + @@ -1710,7 +1710,7 @@ - + @@ -1734,7 +1734,7 @@ - + @@ -1761,7 +1761,7 @@ - + @@ -1771,7 +1771,7 @@ - + @@ -1781,7 +1781,7 @@ - + @@ -1813,7 +1813,7 @@ - + @@ -1831,7 +1831,7 @@ - + @@ -1881,7 +1881,7 @@ - + @@ -1891,7 +1891,7 @@ - + @@ -1971,7 +1971,7 @@ - + @@ -1994,7 +1994,7 @@ - + @@ -2068,7 +2068,7 @@ - +
[Mesa-dev] [PATCH v3 06/10] intel/genxml: Add engine definition to render engine instructions (gen75)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen75.xml | 214 ++--- 1 file changed, 107 insertions(+), 107 deletions(-) diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml index dfc3d891498..6ce31b49241 100644 --- a/src/intel/genxml/gen75.xml +++ b/src/intel/genxml/gen75.xml @@ -654,7 +654,7 @@ - + @@ -676,7 +676,7 @@ - + @@ -688,7 +688,7 @@ - + @@ -705,7 +705,7 @@ - + @@ -722,7 +722,7 @@ - + @@ -739,7 +739,7 @@ - + @@ -756,7 +756,7 @@ - + @@ -773,7 +773,7 @@ - + @@ -782,7 +782,7 @@ - + @@ -791,7 +791,7 @@ - + @@ -800,7 +800,7 @@ - + @@ -809,7 +809,7 @@ - + @@ -818,7 +818,7 @@ - + @@ -830,7 +830,7 @@ - + @@ -840,7 +840,7 @@ - + @@ -850,7 +850,7 @@ - + @@ -861,7 +861,7 @@ - + @@ -871,7 +871,7 @@ - + @@ -924,7 +924,7 @@ - + @@ -933,7 +933,7 @@ - + @@ -942,7 +942,7 @@ - + @@ -951,7 +951,7 @@ - + @@ -960,7 +960,7 @@ - + @@ -969,7 +969,7 @@ - + @@ -1006,7 +1006,7 @@ - + @@ -1016,7 +1016,7 @@ - + @@ -1035,7 +1035,7 @@ - + @@ -1074,7 +1074,7 @@ - + @@ -1089,7 +1089,7 @@ - + @@ -1104,7 +1104,7 @@ - + @@ -1119,7 +1119,7 @@ - + @@ -1135,7 +1135,7 @@ - + @@ -1151,7 +1151,7 @@ - + @@ -1164,7 +1164,7 @@ - + @@ -1227,7 +1227,7 @@ - + @@ -1239,7 +1239,7 @@ - + @@ -1279,7 +1279,7 @@ - + @@ -1296,7 +1296,7 @@ - + @@ -1310,7 +1310,7 @@ - + @@ -1320,7 +1320,7 @@ - + @@ -1354,7 +1354,7 @@ - + @@ -1364,7 +1364,7 @@ - + @@ -1375,7 +1375,7 @@ - + @@ -1432,7 +1432,7 @@ - + @@ -1442,7 +1442,7 @@ - + @@ -1452,7 +1452,7 @@ - + @@ -1462,7 +1462,7 @@ - + @@ -1472,7 +1472,7 @@ - + @@ -1482,7 +1482,7 @@ - + @@ -1529,7 +1529,7 @@ - + @@ -1540,7 +1540,7 @@ - + @@ -1554,7 +1554,7 @@ - + @@ -1563,7 +1563,7 @@ - + @@ -1572,7 +1572,7 @@ - + @@ -1581,7 +1581,7 @@ - + @@ -1590,7 +1590,7 @@ - + @@ -1599,7 +1599,7 @@ - + @@ -1608,7 +1608,7 @@ - + @@ -1646,7 +1646,7 @@ - + @@ -1655,7 +1655,7 @@ - + @@ -1729,7 +1729,7 @@ - + @@ -1743,7 +1743,7 @@ - + @@ -1762,7 +1762,7 @@ - + @@ -1775,7 +1775,7 @@ - + @@ -1803,7 +1803,7 @@ - + @@ -1834,7 +1834,7 @@ - + @@ -1845,7 +1845,7 @@ - + @@ -1856,7 +1856,7 @@ - + @@ -1867,7 +1867,7 @@ - + @@ -1878,7 +1878,7 @@ - + @@ -1889,7 +1889,7 @@ - + @@ -1900,7 +1900,7 @@ - + @@ -1910,7 +1910,7 @@ - + @@ -1918,7 +1918,7 @@ - + @@ -1927,7 +1927,7 @@ - +
[Mesa-dev] [PATCH v3 07/10] intel/genxml: Add engine definition to render engine instructions (gen8)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen8.xml | 228 +++--- 1 file changed, 114 insertions(+), 114 deletions(-) diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml index d42c63aabd8..030af17a916 100644 --- a/src/intel/genxml/gen8.xml +++ b/src/intel/genxml/gen8.xml @@ -718,7 +718,7 @@ - + @@ -740,7 +740,7 @@ - + @@ -756,7 +756,7 @@ - + @@ -773,7 +773,7 @@ - + @@ -790,7 +790,7 @@ - + @@ -807,7 +807,7 @@ - + @@ -824,7 +824,7 @@ - + @@ -841,7 +841,7 @@ - + @@ -850,7 +850,7 @@ - + @@ -859,7 +859,7 @@ - + @@ -868,7 +868,7 @@ - + @@ -877,7 +877,7 @@ - + @@ -886,7 +886,7 @@ - + @@ -900,7 +900,7 @@ - + @@ -910,7 +910,7 @@ - + @@ -920,7 +920,7 @@ - + @@ -931,7 +931,7 @@ - + @@ -941,7 +941,7 @@ - + @@ -981,7 +981,7 @@ - + @@ -991,7 +991,7 @@ - + @@ -1001,7 +1001,7 @@ - + @@ -1011,7 +1011,7 @@ - + @@ -1021,7 +1021,7 @@ - + @@ -1031,7 +1031,7 @@ - + @@ -1065,7 +1065,7 @@ - + @@ -1084,7 +1084,7 @@ - + @@ -1131,7 +1131,7 @@ - + @@ -1147,7 +1147,7 @@ - + @@ -1163,7 +1163,7 @@ - + @@ -1179,7 +1179,7 @@ - + @@ -1196,7 +1196,7 @@ - + @@ -1213,7 +1213,7 @@ - + @@ -1225,7 +1225,7 @@ - + @@ -1293,7 +1293,7 @@ - + @@ -1306,7 +1306,7 @@ - + @@ -1345,7 +1345,7 @@ - + @@ -1362,7 +1362,7 @@ - + @@ -1376,7 +1376,7 @@ - + @@ -1386,7 +1386,7 @@ - + @@ -1400,7 +1400,7 @@ - + @@ -1410,7 +1410,7 @@ - + @@ -1421,7 +1421,7 @@ - + @@ -1479,7 +1479,7 @@ - + @@ -1496,7 +1496,7 @@ - + @@ -1522,7 +1522,7 @@ - + @@ -1532,7 +1532,7 @@ - + @@ -1542,7 +1542,7 @@ - + @@ -1552,7 +1552,7 @@ - + @@ -1562,7 +1562,7 @@ - + @@ -1572,7 +1572,7 @@ - + @@ -1631,7 +1631,7 @@ - + @@ -1642,7 +1642,7 @@ - + @@ -1656,7 +1656,7 @@ - + @@ -1665,7 +1665,7 @@ - + @@ -1674,7 +1674,7 @@ - + @@ -1683,7 +1683,7 @@ - + @@ -1692,7 +1692,7 @@ - + @@ -1701,7 +1701,7 @@ - + @@ -1710,7 +1710,7 @@ - + @@ -1748,7 +1748,7 @@ - + @@ -1773,7 +1773,7 @@ - + @@ -1787,7 +1787,7 @@ - + @@ -1796,7 +1796,7 @@ - + @@ -1829,7 +1829,7 @@ - + @@ -1847,7 +1847,7 @@ - + @@ -1866,7 +1866,7 @@ - + @@ -1880,7 +1880,7 @@ - + @@ -1913,7 +1913,7 @@ - + @@ -1944,7 +1944,7 @@ - + @@ -1955,7 +1955,7 @@ - + @@ -1966,7 +1966,7 @@ - + @@ -1977,7 +1977,7 @@ - + @@ -1988,7 +1988,7 @@ - + @@ -1999,7 +1999,7 @@ - + @@ -2010,7 +2010,7 @@ - +
[Mesa-dev] [PATCH v3 04/10] intel/genxml: Add engine definition to render engine instructions (gen6)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions --- src/intel/genxml/gen6.xml | 106 +++--- 1 file changed, 53 insertions(+), 53 deletions(-) diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml index 62d2574d480..cb3cbe3cf52 100644 --- a/src/intel/genxml/gen6.xml +++ b/src/intel/genxml/gen6.xml @@ -494,7 +494,7 @@ - + @@ -516,7 +516,7 @@ - + @@ -528,7 +528,7 @@ - + @@ -542,7 +542,7 @@ - + @@ -556,7 +556,7 @@ - + @@ -567,7 +567,7 @@ - + @@ -577,7 +577,7 @@ - + @@ -633,7 +633,7 @@ - + @@ -647,7 +647,7 @@ - + @@ -661,7 +661,7 @@ - + @@ -675,7 +675,7 @@ - + @@ -724,7 +724,7 @@ - + @@ -738,7 +738,7 @@ - + @@ -786,7 +786,7 @@ - + @@ -798,7 +798,7 @@ - + @@ -810,7 +810,7 @@ - + @@ -828,7 +828,7 @@ - + @@ -842,7 +842,7 @@ - + @@ -852,7 +852,7 @@ - + @@ -876,7 +876,7 @@ - + @@ -886,7 +886,7 @@ - + @@ -897,7 +897,7 @@ - + @@ -908,7 +908,7 @@ - + @@ -922,7 +922,7 @@ - + @@ -936,7 +936,7 @@ - + @@ -945,7 +945,7 @@ - + @@ -954,7 +954,7 @@ - + @@ -1062,7 +1062,7 @@ - + @@ -1074,7 +1074,7 @@ - + @@ -1086,7 +1086,7 @@ - + @@ -1097,7 +1097,7 @@ - + @@ -1108,7 +1108,7 @@ - + @@ -1116,7 +1116,7 @@ - + @@ -1130,7 +1130,7 @@ - + @@ -1164,7 +1164,7 @@ - + @@ -1257,7 +1257,7 @@ - + @@ -1278,7 +1278,7 @@ - + @@ -1288,7 +1288,7 @@ - + @@ -1315,7 +1315,7 @@ - + @@ -1333,7 +1333,7 @@ - + @@ -1383,7 +1383,7 @@ - + @@ -1396,7 +1396,7 @@ - + @@ -1473,7 +1473,7 @@ - + @@ -1495,7 +1495,7 @@ - + @@ -1527,7 +1527,7 @@ - + @@ -1564,7 +1564,7 @@ - + @@ -1611,7 +1611,7 @@ - + @@ -1624,7 +1624,7 @@ - + @@ -1642,7 +1642,7 @@ - + @@ -1653,7 +1653,7 @@ - + @@ -1689,7 +1689,7 @@ - + @@ -1728,7 +1728,7 @@ - + @@ -1738,7 +1738,7 @@ - + -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 03/10] intel/genxml: Add engine definition to render engine instructions (gen5)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen5.xml | 60 +++ 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/src/intel/genxml/gen5.xml b/src/intel/genxml/gen5.xml index 5bb5a2c3312..f2d945b8367 100644 --- a/src/intel/genxml/gen5.xml +++ b/src/intel/genxml/gen5.xml @@ -441,7 +441,7 @@ - + @@ -720,7 +720,7 @@ - + @@ -739,7 +739,7 @@ - + @@ -751,7 +751,7 @@ - + @@ -764,7 +764,7 @@ - + @@ -774,7 +774,7 @@ - + @@ -786,7 +786,7 @@ - + @@ -800,7 +800,7 @@ - + @@ -809,7 +809,7 @@ - + @@ -819,7 +819,7 @@ - + @@ -835,7 +835,7 @@ - + @@ -849,7 +849,7 @@ - + @@ -859,7 +859,7 @@ - + @@ -870,7 +870,7 @@ - + @@ -886,7 +886,7 @@ - + @@ -896,7 +896,7 @@ - + @@ -907,7 +907,7 @@ - + @@ -918,7 +918,7 @@ - + @@ -926,7 +926,7 @@ - + @@ -936,7 +936,7 @@ - + @@ -947,7 +947,7 @@ - + @@ -1000,7 +1000,7 @@ - + @@ -1031,7 +1031,7 @@ - + @@ -1043,7 +1043,7 @@ - + @@ -1065,7 +1065,7 @@ i - + @@ -1074,7 +1074,7 @@ i - + @@ -1094,7 +1094,7 @@ i - + @@ -1117,7 +1117,7 @@ i - + @@ -1143,7 +1143,7 @@ i - + @@ -1170,7 +1170,7 @@ i - + -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 02/10] intel/genxml: Add engine definition to render engine instructions (gen45)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added addition engine definitions. --- src/intel/genxml/gen45.xml | 54 +++--- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/src/intel/genxml/gen45.xml b/src/intel/genxml/gen45.xml index 4d2c1534d3f..9fd6e63721c 100644 --- a/src/intel/genxml/gen45.xml +++ b/src/intel/genxml/gen45.xml @@ -619,7 +619,7 @@ - + @@ -638,7 +638,7 @@ - + @@ -650,7 +650,7 @@ - + @@ -663,7 +663,7 @@ - + @@ -675,7 +675,7 @@ - + @@ -725,7 +725,7 @@ - + @@ -739,7 +739,7 @@ - + @@ -748,7 +748,7 @@ - + @@ -764,7 +764,7 @@ - + @@ -778,7 +778,7 @@ - + @@ -794,7 +794,7 @@ - + @@ -804,7 +804,7 @@ - + @@ -815,7 +815,7 @@ - + @@ -826,7 +826,7 @@ - + @@ -837,7 +837,7 @@ - + @@ -845,7 +845,7 @@ - + @@ -855,7 +855,7 @@ - + @@ -866,7 +866,7 @@ - + @@ -918,7 +918,7 @@ - + @@ -944,7 +944,7 @@ - + @@ -955,7 +955,7 @@ - + @@ -973,7 +973,7 @@ - + @@ -982,7 +982,7 @@ - + @@ -1002,7 +1002,7 @@ - + @@ -1025,7 +1025,7 @@ - + @@ -1051,7 +1051,7 @@ - + @@ -1078,7 +1078,7 @@ - + -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 01/10] intel/genxml: Add engine definition to render engine instructions (gen4)
Instructions meant for the render engine now have a definition specifying that so that can differentiate instructions meant for different engines due to shared opcodes. v2: Divided into individual patches for each gen v3: Added additional engine definitions. --- src/intel/genxml/gen4.xml | 50 +++ 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/src/intel/genxml/gen4.xml b/src/intel/genxml/gen4.xml index cd50a1012bc..ed45ca6744e 100644 --- a/src/intel/genxml/gen4.xml +++ b/src/intel/genxml/gen4.xml @@ -602,7 +602,7 @@ - + @@ -622,7 +622,7 @@ - + @@ -635,7 +635,7 @@ - + @@ -647,7 +647,7 @@ - + @@ -695,7 +695,7 @@ - + @@ -709,7 +709,7 @@ - + @@ -718,7 +718,7 @@ - + @@ -734,7 +734,7 @@ - + @@ -748,7 +748,7 @@ - + @@ -764,7 +764,7 @@ - + @@ -774,7 +774,7 @@ - + @@ -785,7 +785,7 @@ - + @@ -796,7 +796,7 @@ - + @@ -807,7 +807,7 @@ - + @@ -815,7 +815,7 @@ - + @@ -825,7 +825,7 @@ - + @@ -836,7 +836,7 @@ - + @@ -888,7 +888,7 @@ - + @@ -911,7 +911,7 @@ - + @@ -922,7 +922,7 @@ - + @@ -940,7 +940,7 @@ - + @@ -969,7 +969,7 @@ - + @@ -992,7 +992,7 @@ - + @@ -1018,7 +1018,7 @@ - + @@ -1045,7 +1045,7 @@ - + -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 17/32] intel/blorp: Adjust the compressed copy rectangle before convert_to_single_slice
On Fri, Oct 12, 2018 at 01:46:47PM -0500, Jason Ekstrand wrote:
> It doesn't matter for the actual copy rectangle and this makes the
> asserts a bit nicer as we don't need to bother with the intratile
> offsets because there aren't any yet.
Reviewed-by: Topi Pohjolainen
> ---
> src/intel/blorp/blorp_blit.c | 29 +++--
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 0ba08d9..dd43b8643b9 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -2454,22 +2454,16 @@ blorp_surf_convert_to_uncompressed(const struct
> isl_device *isl_dev,
>
> assert(fmtl->bw > 1 || fmtl->bh > 1);
>
> - /* This is a compressed surface. We need to convert it to a single
> -* slice (because compressed layouts don't perfectly match uncompressed
> -* ones with the same bpb) and divide x, y, width, and height by the
> -* block size.
> -*/
> - blorp_surf_convert_to_single_slice(isl_dev, info);
> + /* This should be the first modification made to the surface */
> + assert(info->tile_x_sa == 0 && info->tile_y_sa == 0);
>
> if (width && height) {
> -#ifndef NDEBUG
> - uint32_t right_edge_px = info->tile_x_sa + *x + *width;
> - uint32_t bottom_edge_px = info->tile_y_sa + *y + *height;
> - assert(*width % fmtl->bw == 0 ||
> - right_edge_px == info->surf.logical_level0_px.width);
> - assert(*height % fmtl->bh == 0 ||
> - bottom_edge_px == info->surf.logical_level0_px.height);
> -#endif
> + UNUSED const uint32_t level_width =
> + minify(info->surf.logical_level0_px.width, info->view.base_level);
> + UNUSED const uint32_t level_height =
> + minify(info->surf.logical_level0_px.height, info->view.base_level);
> + assert(*width % fmtl->bw == 0 || *x + *width == level_width);
> + assert(*height % fmtl->bh == 0 || *y + *height == level_height);
>*width = DIV_ROUND_UP(*width, fmtl->bw);
>*height = DIV_ROUND_UP(*height, fmtl->bh);
> }
> @@ -2481,6 +2475,13 @@ blorp_surf_convert_to_uncompressed(const struct
> isl_device *isl_dev,
>*y /= fmtl->bh;
> }
>
> + /* This is a compressed surface. We need to convert it to a single
> +* slice (because compressed layouts don't perfectly match uncompressed
> +* ones with the same bpb) and divide x, y, width, and height by the
> +* block size.
> +*/
> + blorp_surf_convert_to_single_slice(isl_dev, info);
> +
> info->surf.logical_level0_px.width =
>DIV_ROUND_UP(info->surf.logical_level0_px.width, fmtl->bw);
> info->surf.logical_level0_px.height =
> --
> 2.19.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 EGL/MESA] EGL/mesa: Initial write up for EGL_MESA_query_driver
On Mon, 2018-11-05 at 23:33 +0530, Veluri Mithun wrote: > +New Procedures and Functions > + > +const char* EGLGetDriverConfig(const char *driverName); This is difficult to implement in a GLVND environment. The frontend would need a way to distinguish responses from the vendor library for "I don't know of a driver by that name" and "I know that driver, but it has no configuration". Assuming we get EGL_EXT_device_base merged into Mesa it'd be cleaner to have the first parameter here be an EGLDeviceEXT. > +const char* EGLGetScreenDriver(EGLDisplay * dpy, int scrNum) As with EGL_MESA_query_renderer: EGL doesn't have screens, and these entrypoint names should start with 'egl' not 'EGL'. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 09/32] intel/isl: Implement correct tile size calculations for Ys/Yf
On Fri, Oct 12, 2018 at 01:46:39PM -0500, Jason Ekstrand wrote:
> The tile size calculations use a clever bit of math to make them short
> and simple. We add unit tests to assert that they identically match the
> tables in the PRM.
Compared both the equations and tests against the PRM:
Reviewed-by: Topi Pohjolainen
> ---
> src/intel/Makefile.isl.am | 9 +-
> src/intel/isl/isl.c | 66 ++-
> src/intel/isl/meson.build | 11 ++
> src/intel/isl/tests/isl_tile_std_y_test.c | 201 ++
> 4 files changed, 281 insertions(+), 6 deletions(-)
> create mode 100644 src/intel/isl/tests/isl_tile_std_y_test.c
>
> diff --git a/src/intel/Makefile.isl.am b/src/intel/Makefile.isl.am
> index f51294468cd..56d5404a056 100644
> --- a/src/intel/Makefile.isl.am
> +++ b/src/intel/Makefile.isl.am
> @@ -75,7 +75,9 @@ isl/isl_format_layout.c: isl/gen_format_layout.py \
> # Tests
> #
>
>
> -check_PROGRAMS += isl/tests/isl_surf_get_image_offset_test
> +check_PROGRAMS += \
> + isl/tests/isl_surf_get_image_offset_test \
> + isl/tests/isl_tile_std_y_test
>
> TESTS += $(check_PROGRAMS)
>
> @@ -85,6 +87,11 @@ isl_tests_isl_surf_get_image_offset_test_LDADD = \
> $(top_builddir)/src/util/libmesautil.la \
> -lm
>
> +isl_tests_isl_tile_std_y_test_LDADD = \
> + common/libintel_common.la \
> + isl/libisl.la \
> + -lm
> +
> #
>
>
> EXTRA_DIST += \
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 3ffc6f627b2..21d2babdb56 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -223,13 +223,69 @@ isl_tiling_get_info(enum isl_tiling tiling,
> case ISL_TILING_GEN10_Ys: {
>bool is_Ys = tiling == ISL_TILING_GEN9_Ys ||
> tiling == ISL_TILING_GEN10_Ys;
> + assert(format_bpb >= 8);
>
> - assert(bs > 0);
> - unsigned width = 1 << (6 + (ffs(bs) / 2) + (2 * is_Ys));
> - unsigned height = 1 << (6 - (ffs(bs) / 2) + (2 * is_Ys));
> + switch (dim) {
> + case ISL_SURF_DIM_1D:
> + /* See the SKL PRM under Memory Views > Common Surface Formats >
> + * Surface Layout and Tiling > 1D Surfaces > 1D Alignment
> + * Requirements.
> + *
> + * The BSpec claims that 1D images cannot be tiled. This is wrong.
> + */
> + logical_el = (struct isl_extent4d) {
> +.w = 1 << (12 - (ffs(format_bpb) - 4) + (4 * is_Ys)),
> +.h = 1,
> +.d = 1,
> +.a = 1,
> + };
> + break;
> +
> + case ISL_SURF_DIM_2D:
> + /* See the BSpec Memory Data Formats » Common Surface Formats »
> + * Surface Layout and Tiling [SKL+] » 2D Surfaces SKL+ » 2D/CUBE
> + * Alignment Requirement [SKL+]
> + *
> + * Or, look in the SKL PRM under Memory Views > Common Surface
> + * Formats > Surface Layout and Tiling > 2D Surfaces > 2D/CUBE
> + * Alignment Requirements.
> + */
> + logical_el = (struct isl_extent4d) {
> +.w = 1 << (6 - ((ffs(format_bpb) - 4) / 2) + (2 * is_Ys)),
> +.h = 1 << (6 - ((ffs(format_bpb) - 3) / 2) + (2 * is_Ys)),
> +.d = 1,
> +.a = 1,
> + };
> +
> + if (samples > 1 && tiling != ISL_TILING_GEN9_Yf) {
> +logical_el.w >>= (ffs(samples) - 0) / 2;
> +logical_el.h >>= (ffs(samples) - 1) / 2;
> +logical_el.a = samples;
> + }
> + break;
> +
> + case ISL_SURF_DIM_3D:
> + /* See the BSpec Memory Data Formats » Common Surface Formats »
> + * Surface Layout and Tiling [SKL+] » 3D Surfaces SKL+ » 3D
> Alignment
> + * Requirements [SKL+]
> + *
> + * Or, look in the SKL PRM under Memory Views > Common Surface
> + * Formats > Surface Layout and Tiling > 3D Surfaces > 3D Alignment
> + * Requirements.
> + */
> + logical_el = (struct isl_extent4d) {
> +.w = 1 << (4 - ((ffs(format_bpb) - 2) / 3) + (2 * is_Ys)),
> +.h = 1 << (4 - ((ffs(format_bpb) - 4) / 3) + (1 * is_Ys)),
> +.d = 1 << (4 - ((ffs(format_bpb) - 3) / 3) + (1 * is_Ys)),
> +.a = 1,
> + };
> + break;
> + }
> +
> + uint32_t tile_size_B = is_Ys ? (1 << 16) : (1 << 12);
>
> - logical_el = isl_extent4d(width / bs, height, 1, 1);
> - phys_B = isl_extent2d(width, height);
> + phys_B.w = logical_el.width * bs;
> + phys_B.h = tile_size_B / phys_B.w;
>break;
> }
>
> diff --git a/src/intel/isl/meson.build b/src/intel/isl/meson.build
> index 62cde190e6e..305a61dc92f 100644
> --- a/src/intel/isl/meson.build
> +++ b/src/intel/isl/meson.build
> @@ -98,4 +98,15 @@ if with_tests
>
Re: [Mesa-dev] [PATCH EGL/MESA] EGL/mesa: Initial writeup for MESA_query_renderer
On Mon, 2018-11-05 at 10:04 +0530, Veluri Mithun wrote: > Signed-off-by: Veluri Mithun Thanks for looking into this! Many of these comments apply equally to the GLX extension I think; if you wanted to write a patch for the equivalent text for that extension too, that'd be awesome. > +EGL 1.4 is required. I'm not sure this is true, from the EGL types you're (currently) using it looks like even an EGL 1.0 implementation could support this. Probably better to say "EGL 1.0 is required; this extension is written against the text of the EGL 1.4 specification." > +EGL_ARB_create_context and EGL_ARB_create_context_profile are required. > + > +This extension interacts with EGL_EXT_create_context_es2_profile and > +EGL_EXT_create_context_es_profile. There are GLX extensions with almost these names, but not EGL: https://www.khronos.org/registry/EGL/ These references should all be deleted. > +New Procedures and Functions EGL functions start with 'egl', lowercase. > +Bool EGLQueryRendererIntegerMESA(EGLDisplay *dpy, int screen, > + int renderer, int attribute, > + unsigned int *value); EGL displays don't have screens, that's an X11-ism. The screen parameter should be deleted. > +const char *EGLQueryRendererStringMESA(EGLDisplay *dpy, int screen, > + int renderer, int attribute); Same comment about 'screen' here. > +New Tokens > + > +Accepted as an in EGLQueryRendererIntegerMESA and > +EGLQueryCurrentRendererIntegerMESA: > + > +EGL_RENDERER_VENDOR_ID_MESA 0x > +EGL_RENDERER_DEVICE_ID_MESA 0x > +EGL_RENDERER_VERSION_MESA0x > +EGL_RENDERER_ACCELERATED_MESA0x > +EGL_RENDERER_VIDEO_MEMORY_MESA 0x > +EGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA0x > +EGL_RENDERER_PREFERRED_PROFILE_MESA 0x > +EGL_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA0x > +EGL_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA0x > +EGL_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA 0x > +EGL_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA 0x > + > +Accepted as an in EGLQueryRendererStringMESA and > +EGLQueryCurrentRendererStringMESA: > + > +EGL_RENDERER_VENDOR_ID_MESA > +EGL_RENDERER_DEVICE_ID_MESA > + > +Accepted as an attribute name in <*attrib_list> in > +EGLCreateContextAttribsARB: > + > +EGL_RENDERER_ID_MESA 0x Normally these are reserved by creating a request against the EGL registry on github. However we happen to have a block of 16 enum values already reserved: > comment="Reserved for John Kåre Alsaker (Public bug 757)"> > > That "public bug 757" is for the abandoned EGL_MESA_image_sRGB extension: https://www.khronos.org/bugzilla/show_bug.cgi?id=757 So I think it's safe to use enums from that range, and we'll still have two free. > +Additions to the EGL 1.4 Specification > + > +[Add the following to Section X.Y.Z of the EGL Specification] Should be Section 3.3 "EGL Versioning". If this were against the EGL 1.5 text it'd be the more-obviously-correct Section 3.3 "EGL Queries". > +To obtain information about the available renderers for a particular > +display and screen, > + > +Bool EGLQueryRendererIntegerMESA(EGLDisplay *dpy, int screen, int > renderer, > + int attribute, unsigned int *value); The corresponding eglQueryCurrentRendererIntegerMESA is not documented. I'm not entirely sure it should even exist, to be honest; I'd prefer if these attributes were instead newly legal values to pass to eglQueryContext. Too late to make that change for GLX I suppose. > +String versions of some attributes may also be queried using > + > +const char *EGLQueryRendererStringMESA(EGLDisplay *dpy, int screen, > + int renderer, int attribute); Likewise eglQueryCurrentRendererStringMESA is not documented. This could not be queried with eglQueryContext since that can only return integers not pointers. > +[Add to section section 3.3.7 "Rendering Contexts"] > + > +The attribute name EGL_RENDERER_ID_MESA specified the index of the render > +against which the context should be created. The default value of > +EGL_RENDERER_ID_MESA is 0. This startled me to read, I didn't think GLX_MESA_query_renderer had this. Turns out it does have this text in the extension spec, but the functionality is not actually implemented. Worse, there's no way to enumerate how many renderers a display (or display/screen in GLX) has. To address this, I would: 1) Remove this text from both GLX and EGL extension specs (Both here and above wher
[Mesa-dev] [PATCH] radv: only expose VK_SUBGROUP_FEATURE_ARITHMETIC_BIT for VI+
Inclusive and exclusives scan are missing because older chips
don't have llvm.amdgcn.update.dpp.
This fixes crashes with dEQP-VK.subgroups.arithmetic.*.
CC: mesa-sta...@lists.freedesktop.org
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index d68111c25b..92254bed2e 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1058,12 +1058,12 @@ void radv_GetPhysicalDeviceProperties2(
* is fixed in LLVM.
*/
properties->supportedOperations =
-
VK_SUBGROUP_FEATURE_ARITHMETIC_BIT |
VK_SUBGROUP_FEATURE_BASIC_BIT |
VK_SUBGROUP_FEATURE_BALLOT_BIT |
VK_SUBGROUP_FEATURE_QUAD_BIT;
if (pdevice->rad_info.chip_class >= VI) {
properties->supportedOperations |=
+
VK_SUBGROUP_FEATURE_ARITHMETIC_BIT |
VK_SUBGROUP_FEATURE_SHUFFLE_BIT |
VK_SUBGROUP_FEATURE_SHUFFLE_RELATIVE_BIT;
}
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] docs: document the staging branch and add reference to it
From: Emil Velikov A while back we agreed that having a live/staging branch is beneficial. Sadly we forgot to document that, so here is my first attempt. Document the caveat that the branch history is not stable. CC: Andres Gomez CC: Dylan Baker CC: Juan A. Suarez Romero Signed-off-by: Emil Velikov --- docs/releasing.html | 20 docs/submittingpatches.html | 3 +++ 2 files changed, 23 insertions(+) diff --git a/docs/releasing.html b/docs/releasing.html index 87590b19301..8ebc2953366 100644 --- a/docs/releasing.html +++ b/docs/releasing.html @@ -21,6 +21,7 @@ Overview Release schedule Cherry-pick and test +Staging branch Making a branchpoint Pre-release announcement Making a new release @@ -212,6 +213,25 @@ system and making some every day's use until the release may be a good idea too. +Staging branch + + +A live branch, which contains the currently merge/rejected patches is available +in the main repository under staging/X.Y. For example: + + + staging/18.1 - WIP branch for the 18.1 series + staging/18.2 - WIP branch for the 18.2 series + + + +Notes: + + +People are encouraged to test the branch and report regressions. +The branch history is not stable and it will be rebased, + + Making a branchpoint diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index b84f01c3b37..3f97c941aa5 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -253,6 +253,9 @@ If you are not the author of the original patch, please Cc: them in your nomination request. + +The current patch status can be observed in the staging branch. + The stable tag -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] docs/releasing.html: polish cherry-picking/testing text
From: Emil Velikov Reword slightly and highlight the important parts of the text. CC: Andres Gomez CC: Dylan Baker CC: Juan A. Suarez Romero Signed-off-by: Emil Velikov --- docs/releasing.html | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/docs/releasing.html b/docs/releasing.html index 52e102207d1..87590b19301 100644 --- a/docs/releasing.html +++ b/docs/releasing.html @@ -111,18 +111,21 @@ the autoconf and scons build. Done continuously up-to the pre-release announcement. -As an exception, patches can be applied up-to the last ~1h before the actual -release. This is made only with explicit permission/request, -and the patch must be very well contained. Thus it cannot -affect more than one driver/subsystem. +Developers can request, as an exception, patches to be applied up-to +the last one hour before the actual release. This is made only +with explicit permission/request, and the patch must be very +well contained. Thus it cannot affect more than one driver/subsystem. - -Currently Ilia Mirkin and AMD devs have requested "permanent" exception. - +Following developers have requested permanent exception + +Ilia Mirkin +AMD team + +The following must pass: -make distcheck, scons and scons check must pass +make distcheck, scons and scons check Testing with different version of system components - LLVM and others is also performed where possible. As a general rule, testing with various combinations of configure @@ -130,9 +133,9 @@ switches, depending on the specific patchset. -Achieved by combination of local ad-hoc scripts, mingw-w64 cross -compilation and AppVeyor plus Travis-CI, the latter as part of their -Github integration. +These are achieved by combination of local testing, +which includes mingw-w64 cross compilation and AppVeyor plus Travis-CI, the +latter two as part of their Github integration. @@ -425,7 +428,7 @@ Ensure the latest code is available - both in your local master and the relevant branch. -Perform basic testing +Perform basic testing Most of the testing should already be done during the -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] docs/submittingpatches.html: correctly handle the tag
From: Emil Velikov As pointed out by the w3c validator. Signed-off-by: Emil Velikov --- docs/submittingpatches.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index e5350bdb2cf..b84f01c3b37 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -156,9 +156,11 @@ As mentioned at the begining, patches should be bisectable. A good way to test this is to make use of the `git rebase` command, to run your tests on each commit. Assuming your branch is based off origin/master, you can run: + $ git rebase --interactive --exec "make check" origin/master + replacing "make check" with whatever other test you want to run. -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/13] mesa/main: fix validation of ARB_query_buffer_object
ctx->Extensions.ARB_query_buffer_object is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_ARB_query_buffer_object(ctx) instead to figure out if the
extension is really supported.
This turns attempts to read queries into buffer objects on ES 3 into
errors, as required by the spec.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/queryobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index d22432930d0..01a5504575d 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -822,7 +822,7 @@ get_query_object(struct gl_context *ctx, const char *func,
if (buf && buf != ctx->Shared->NullBufferObj) {
bool is_64bit = ptype == GL_INT64_ARB ||
ptype == GL_UNSIGNED_INT64_ARB;
- if (!ctx->Extensions.ARB_query_buffer_object) {
+ if (!_mesa_has_ARB_query_buffer_object(ctx)) {
_mesa_error(ctx, GL_INVALID_OPERATION, "%s(not supported)", func);
return;
}
@@ -855,7 +855,7 @@ get_query_object(struct gl_context *ctx, const char *func,
value = q->Result;
break;
case GL_QUERY_RESULT_NO_WAIT:
- if (!ctx->Extensions.ARB_query_buffer_object)
+ if (!_mesa_has_ARB_query_buffer_object(ctx))
goto invalid_enum;
ctx->Driver.CheckQuery(ctx, q);
if (!q->Ready)
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/13] mesa/main: remove overly strict query-validation
The rules encoded in this code also applies to OpenGL ES 3.0 and up,
but the per-enum validation has already been taught about these rules.
So let's get rid of this duplicate, narrow version of the validation.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/queryobj.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 87195d7ae5b..5c455a6db81 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -163,20 +163,6 @@ get_pipe_stats_binding_point(struct gl_context *ctx,
static struct gl_query_object **
get_query_binding_point(struct gl_context *ctx, GLenum target, GLuint index)
{
-
- /* From GL_EXT_occlusion_query_boolean spec:
-*
-*"Accepted by the parameter of BeginQueryEXT, EndQueryEXT,
-*and GetQueryivEXT:
-*
-* ANY_SAMPLES_PASSED_EXT 0x8C2F
-* ANY_SAMPLES_PASSED_CONSERVATIVE_EXT0x8D6A"
-*/
- if ((_mesa_is_gles(ctx) && ctx->Version == 20) &&
- (target != GL_ANY_SAMPLES_PASSED &&
-target != GL_ANY_SAMPLES_PASSED_CONSERVATIVE))
- return NULL;
-
switch (target) {
case GL_SAMPLES_PASSED:
if (_mesa_has_ARB_occlusion_query(ctx))
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/13] mesa/main: fix validation of transform-feedback overflow queries
ctx->Extensions.ARB_transform_feedback_overflow_query is set based on the driver-capabilities, not based on the context type. We need to check against _mesa_has_RB_transform_feedback_overflow_query(ctx) instead to figure out if the extension is really supported. This turns usage of GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW and GL_TRANSFORM_FEEDBACK_OVERFLOW into errors on ES 3, as required by the spec. Signed-off-by: Erik Faye-Lund --- src/mesa/main/queryobj.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c index ce3ae3401b7..d22432930d0 100644 --- a/src/mesa/main/queryobj.c +++ b/src/mesa/main/queryobj.c @@ -211,12 +211,12 @@ get_query_binding_point(struct gl_context *ctx, GLenum target, GLuint index) else return NULL; case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW: - if (ctx->Extensions.ARB_transform_feedback_overflow_query) + if (_mesa_has_ARB_transform_feedback_overflow_query(ctx)) return &ctx->Query.TransformFeedbackOverflow[index]; else return NULL; case GL_TRANSFORM_FEEDBACK_OVERFLOW: - if (ctx->Extensions.ARB_transform_feedback_overflow_query) + if (_mesa_has_ARB_transform_feedback_overflow_query(ctx)) return &ctx->Query.TransformFeedbackOverflowAny; else return NULL; -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/13] mesa/main: fix validation of GL_ANY_SAMPLES_PASSED
ctx->Extensions.ARB_occlusion_query2 is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_ARB_occlusion_query2(ctx) instead to figure out if the extension is really supported. In addition, EXT_occlusion_query_boolean should also allow this behavior. This shouldn't cause any functional change, as all drivers that support ARB_occlusion_query2 should in practice enable either ARB_occlusion_query2 or EXT_occlusion_query_boolean under all APIs that export this symbol. Signed-off-by: Erik Faye-Lund --- src/mesa/main/queryobj.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c index 74977210f2d..f44ed937628 100644 --- a/src/mesa/main/queryobj.c +++ b/src/mesa/main/queryobj.c @@ -184,7 +184,8 @@ get_query_binding_point(struct gl_context *ctx, GLenum target, GLuint index) else return NULL; case GL_ANY_SAMPLES_PASSED: - if (ctx->Extensions.ARB_occlusion_query2) + if (_mesa_has_ARB_occlusion_query2(ctx) || + _mesa_has_EXT_occlusion_query_boolean(ctx)) return &ctx->Query.CurrentOcclusionObject; else return NULL; -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/13] mesa/main: fix validation of GL_ANY_SAMPLES_PASSED_CONSERVATIVE
ctx->Extensions.ARB_ES3_compatibility is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_ARB_ES3_compatibility(ctx) instead to figure out if the extension is really supported. In addition, EXT_occlusion_query_boolean should also allow this behavior. This shouldn't cause any functional change, as all drivers that support ES3_compatibility should in practice enable either ES3_compatibility or EXT_occlusion_query_boolean under all APIs that export this symbol. Signed-off-by: Erik Faye-Lund --- src/mesa/main/queryobj.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c index f44ed937628..2f178bbf483 100644 --- a/src/mesa/main/queryobj.c +++ b/src/mesa/main/queryobj.c @@ -190,8 +190,8 @@ get_query_binding_point(struct gl_context *ctx, GLenum target, GLuint index) else return NULL; case GL_ANY_SAMPLES_PASSED_CONSERVATIVE: - if (ctx->Extensions.ARB_ES3_compatibility - || (ctx->API == API_OPENGLES2 && ctx->Version >= 30)) + if (_mesa_has_ARB_ES3_compatibility(ctx) || + _mesa_has_EXT_occlusion_query_boolean(ctx)) return &ctx->Query.CurrentOcclusionObject; else return NULL; -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/13] mesa/main: fix validation of GL_SAMPLES_PASSED
ctx->Extensions.ARB_occlusion_query is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_ARB_occlusion_query(ctx) instead to figure out if the
extension is really supported.
This turns usage of GL_SAMPLES_PASSED into an error on ES 3, as is
required by the spec.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/queryobj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 96b1c6bb30a..74977210f2d 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -179,7 +179,7 @@ get_query_binding_point(struct gl_context *ctx, GLenum
target, GLuint index)
switch (target) {
case GL_SAMPLES_PASSED:
- if (ctx->Extensions.ARB_occlusion_query)
+ if (_mesa_has_ARB_occlusion_query(ctx))
return &ctx->Query.CurrentOcclusionObject;
else
return NULL;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/13] mesa/main: fix validation of GL_TIMESTAMP
ctx->Extensions.ARB_timer_query is set based on the driver-
capabilities, not based on the context type. We need to check
against _mesa_has_ARB_timer_query(ctx) instead to figure out
if the extension is really supported.
This shouln't have any functional effect, as this entry-point is only
valid on desktop GL in the first place. But if this gets added to a
future version of ES, this should be a step in the right direction.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/queryobj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 01a5504575d..87195d7ae5b 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -676,7 +676,7 @@ _mesa_GetQueryIndexediv(GLenum target, GLuint index, GLenum
pname,
}
if (target == GL_TIMESTAMP) {
- if (!ctx->Extensions.ARB_timer_query) {
+ if (!_mesa_has_ARB_timer_query(ctx)) {
_mesa_error(ctx, GL_INVALID_ENUM, "glGetQueryARB(target)");
return;
}
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/13] mesa/main: fix validation of GL_TIME_ELAPSED
ctx->Extensions.EXT_timer_query is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_EXT_timer_query(ctx) instead to figure out if the extension is really supported. This turns usage of GL_TIME_ELAPSED into an error on ES 3, as is required by the spec. Signed-off-by: Erik Faye-Lund --- src/mesa/main/queryobj.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c index 2f178bbf483..e4185073e3b 100644 --- a/src/mesa/main/queryobj.c +++ b/src/mesa/main/queryobj.c @@ -196,7 +196,7 @@ get_query_binding_point(struct gl_context *ctx, GLenum target, GLuint index) else return NULL; case GL_TIME_ELAPSED: - if (ctx->Extensions.EXT_timer_query) + if (_mesa_has_EXT_timer_query(ctx)) return &ctx->Query.CurrentTimerObject; else return NULL; -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/13] mesa/main: fix validation of transform-feedback queries
ctx->Extensions.EXT_transform_feedback is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_EXT_transform_feedback(ctx) instead to figure out if the extension is really supported. This turns usage of GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN into an error on ES 2, as well as usage of GL_PRIMITIVES_GENERATED on ES 3, both as required by the spec. Signed-off-by: Erik Faye-Lund --- src/mesa/main/queryobj.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c index e4185073e3b..ce3ae3401b7 100644 --- a/src/mesa/main/queryobj.c +++ b/src/mesa/main/queryobj.c @@ -201,12 +201,12 @@ get_query_binding_point(struct gl_context *ctx, GLenum target, GLuint index) else return NULL; case GL_PRIMITIVES_GENERATED: - if (ctx->Extensions.EXT_transform_feedback) + if (_mesa_has_EXT_transform_feedback(ctx)) return &ctx->Query.PrimitivesGenerated[index]; else return NULL; case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN: - if (ctx->Extensions.EXT_transform_feedback) + if (_mesa_has_EXT_transform_feedback(ctx) || _mesa_is_gles3(ctx)) return &ctx->Query.PrimitivesWritten[index]; else return NULL; -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/13] mesa/main: correct requirement for EXT_occlusion_query_boolean
EXT_occlusion_query_boolean require support for GL_ANY_SAMPLES_PASSED, which ARB_occlusion_query doesn't supply. We need ARB_occlusion_query2 for this instead. This is still not 100% accurate, as we also require support for the GL_SAMPLES_PASSED_CONSERVATIVE target, which isn't guaranteed by either ARB_occlusion_query nor ARB_occlusion_query2. But it should be trivial to implement for any driver supporting ARB_occlusion_query2, as it can simply be implemented as GL_ANY_SAMPLES_PASSED. Signed-off-by: Erik Faye-Lund --- src/mesa/main/extensions_table.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h index a516a1b17f8..5d55995856c 100644 --- a/src/mesa/main/extensions_table.h +++ b/src/mesa/main/extensions_table.h @@ -241,7 +241,7 @@ EXT(EXT_map_buffer_range, ARB_map_buffer_range EXT(EXT_memory_object , EXT_memory_object , GLL, GLC, x , ES2, 2017) EXT(EXT_memory_object_fd, EXT_memory_object_fd , GLL, GLC, x , ES2, 2017) EXT(EXT_multi_draw_arrays , dummy_true , GLL, x , ES1, ES2, 1999) -EXT(EXT_occlusion_query_boolean , ARB_occlusion_query , x , x , x , ES2, 2001) +EXT(EXT_occlusion_query_boolean , ARB_occlusion_query2 , x , x , x , ES2, 2001) EXT(EXT_packed_depth_stencil, dummy_true , GLL, GLC, x , x , 2005) EXT(EXT_packed_float, EXT_packed_float , GLL, GLC, x , x , 2004) EXT(EXT_packed_pixels , dummy_true , GLL, x , x , x , 1997) -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/13] mesa/main: use non-prefixed enums for consistency
These enums all have the same values as their non-prefixed versions, and
there's several aliases for some of them. So let's switch to the
non-prefixed versions for simplicity.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/queryobj.c | 66
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index e97a0138e96..2a143191c62 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -146,7 +146,7 @@ static struct gl_query_object **
get_pipe_stats_binding_point(struct gl_context *ctx,
GLenum target)
{
- const int which = target - GL_VERTICES_SUBMITTED_ARB;
+ const int which = target - GL_VERTICES_SUBMITTED;
assert(which < MAX_PIPELINE_STATISTICS);
if (!_mesa_is_desktop_gl(ctx) ||
@@ -179,7 +179,7 @@ get_query_binding_point(struct gl_context *ctx, GLenum
target, GLuint index)
return NULL;
switch (target) {
- case GL_SAMPLES_PASSED_ARB:
+ case GL_SAMPLES_PASSED:
if (ctx->Extensions.ARB_occlusion_query)
return &ctx->Query.CurrentOcclusionObject;
else
@@ -195,7 +195,7 @@ get_query_binding_point(struct gl_context *ctx, GLenum
target, GLuint index)
return &ctx->Query.CurrentOcclusionObject;
else
return NULL;
- case GL_TIME_ELAPSED_EXT:
+ case GL_TIME_ELAPSED:
if (ctx->Extensions.EXT_timer_query)
return &ctx->Query.CurrentTimerObject;
else
@@ -210,43 +210,43 @@ get_query_binding_point(struct gl_context *ctx, GLenum
target, GLuint index)
return &ctx->Query.PrimitivesWritten[index];
else
return NULL;
- case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+ case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW:
if (ctx->Extensions.ARB_transform_feedback_overflow_query)
return &ctx->Query.TransformFeedbackOverflow[index];
else
return NULL;
- case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+ case GL_TRANSFORM_FEEDBACK_OVERFLOW:
if (ctx->Extensions.ARB_transform_feedback_overflow_query)
return &ctx->Query.TransformFeedbackOverflowAny;
else
return NULL;
- case GL_VERTICES_SUBMITTED_ARB:
- case GL_PRIMITIVES_SUBMITTED_ARB:
- case GL_VERTEX_SHADER_INVOCATIONS_ARB:
- case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
- case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
- case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
+ case GL_VERTICES_SUBMITTED:
+ case GL_PRIMITIVES_SUBMITTED:
+ case GL_VERTEX_SHADER_INVOCATIONS:
+ case GL_FRAGMENT_SHADER_INVOCATIONS:
+ case GL_CLIPPING_INPUT_PRIMITIVES:
+ case GL_CLIPPING_OUTPUT_PRIMITIVES:
return get_pipe_stats_binding_point(ctx, target);
case GL_GEOMETRY_SHADER_INVOCATIONS:
/* GL_GEOMETRY_SHADER_INVOCATIONS is defined in a non-sequential order */
- target = GL_VERTICES_SUBMITTED_ARB + MAX_PIPELINE_STATISTICS - 1;
+ target = GL_VERTICES_SUBMITTED + MAX_PIPELINE_STATISTICS - 1;
/* fallthrough */
- case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
+ case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED:
if (_mesa_has_geometry_shaders(ctx))
return get_pipe_stats_binding_point(ctx, target);
else
return NULL;
- case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
- case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
+ case GL_TESS_CONTROL_SHADER_PATCHES:
+ case GL_TESS_EVALUATION_SHADER_INVOCATIONS:
if (_mesa_has_tessellation(ctx))
return get_pipe_stats_binding_point(ctx, target);
else
return NULL;
- case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
+ case GL_COMPUTE_SHADER_INVOCATIONS:
if (_mesa_has_compute_shaders(ctx))
return get_pipe_stats_binding_point(ctx, target);
else
@@ -316,8 +316,8 @@ _mesa_CreateQueries(GLenum target, GLsizei n, GLuint *ids)
case GL_TIMESTAMP:
case GL_PRIMITIVES_GENERATED:
case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
- case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
- case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+ case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW:
+ case GL_TRANSFORM_FEEDBACK_OVERFLOW:
break;
default:
_mesa_error(ctx, GL_INVALID_ENUM, "glCreateQueries(invalid target = %s)",
@@ -393,7 +393,7 @@ query_error_check_index(struct gl_context *ctx, GLenum
target, GLuint index)
switch (target) {
case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
case GL_PRIMITIVES_GENERATED:
- case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+ case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW:
if (index >= ctx->Const.MaxVertexStreams) {
_mesa_error(ctx, GL_INVALID_VALUE,
"glBeginQueryIndexed(index>=MaxVertexStreams)");
@@ -692,7 +692,7 @@ _mesa_GetQueryIndexediv(GLenum target, GLuint index, GLenum
pname,
}
switch (pname) {
- case GL_QUERY_COUNTER_BITS_ARB:
+ case GL_QUERY_COUNTER_BITS:
switch (target) {
case GL_SAMPL
[Mesa-dev] [PATCH 02/13] mesa/main: correct year for EXT_occlusion_query_boolean
According to the extension spec, this was initially released in 2011, so let's set this to the correct value. The value of 2001 could be a copy-paste mistake, as ARB_occlusion_query which this is based on was released then. Signed-off-by: Erik Faye-Lund --- src/mesa/main/extensions_table.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h index 5d55995856c..dd846d7bc5c 100644 --- a/src/mesa/main/extensions_table.h +++ b/src/mesa/main/extensions_table.h @@ -241,7 +241,7 @@ EXT(EXT_map_buffer_range, ARB_map_buffer_range EXT(EXT_memory_object , EXT_memory_object , GLL, GLC, x , ES2, 2017) EXT(EXT_memory_object_fd, EXT_memory_object_fd , GLL, GLC, x , ES2, 2017) EXT(EXT_multi_draw_arrays , dummy_true , GLL, x , ES1, ES2, 1999) -EXT(EXT_occlusion_query_boolean , ARB_occlusion_query2 , x , x , x , ES2, 2001) +EXT(EXT_occlusion_query_boolean , ARB_occlusion_query2 , x , x , x , ES2, 2011) EXT(EXT_packed_depth_stencil, dummy_true , GLL, GLC, x , x , 2005) EXT(EXT_packed_float, EXT_packed_float , GLL, GLC, x , x , 2004) EXT(EXT_packed_pixels , dummy_true , GLL, x , x , x , 1997) -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/13] query validation fixes
Here's a bunch of patches for missing error generation in the query buffer code. The general pattern, is that code that directly checks ctx->Extensions.FOO_bar instead of using _mesa_has_FOO_bar(ctx) will often end up drawing the wrong conclusion on ES, because the flag in ctx->Extensions only tells us that the *driver* supports this, not the target-API. This was noticed when porting the NV_conditional_rendering piglit tests to ES 2, where the observation was that using GL_SAMPLES_PASSED worked in ES 3, but not when run on ES 2. Some other related issues that was noticed while fixing this are also included. Erik Faye-Lund (13): mesa/main: correct requirement for EXT_occlusion_query_boolean mesa/main: correct year for EXT_occlusion_query_boolean mesa/main: use non-prefixed enums for consistency mesa/main: simplify pipeline-statistics query validation mesa/main: fix validation of GL_SAMPLES_PASSED mesa/main: fix validation of GL_ANY_SAMPLES_PASSED mesa/main: fix validation of GL_ANY_SAMPLES_PASSED_CONSERVATIVE mesa/main: fix validation of GL_TIME_ELAPSED mesa/main: fix validation of transform-feedback queries mesa/main: fix validation of transform-feedback overflow queries mesa/main: fix validation of ARB_query_buffer_object mesa/main: fix validation of GL_TIMESTAMP mesa/main: remove overly strict query-validation src/mesa/main/extensions_table.h | 2 +- src/mesa/main/queryobj.c | 108 ++- 2 files changed, 48 insertions(+), 62 deletions(-) -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/13] mesa/main: simplify pipeline-statistics query validation
The _mesa_has_ARB_pipeline_statistics_query(ctx)-helper will already check the GLES-version according to the extension-table, so if this extension would ever be back-ported to ES, we only need to update the table to support this. This shouln't have any functional effect. Signed-off-by: Erik Faye-Lund --- src/mesa/main/queryobj.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c index 2a143191c62..96b1c6bb30a 100644 --- a/src/mesa/main/queryobj.c +++ b/src/mesa/main/queryobj.c @@ -149,8 +149,7 @@ get_pipe_stats_binding_point(struct gl_context *ctx, const int which = target - GL_VERTICES_SUBMITTED; assert(which < MAX_PIPELINE_STATISTICS); - if (!_mesa_is_desktop_gl(ctx) || - !ctx->Extensions.ARB_pipeline_statistics_query) + if (!_mesa_has_ARB_pipeline_statistics_query(ctx)) return NULL; return &ctx->Query.pipeline_stats[which]; -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4] mesa/driconf: rotation of 0-vector
Specification doesn't define behaviour for rotation of 0-vector.
In https://github.com/KhronosGroup/OpenGL-API/issues/41 said that
behaviour is undefined and agreed that it would be fine for
implementation to do something useful for this.
Windows and Nvidia drivers have a workaround for that.
For compatibility proposed optimized version of computations.
Specification defines a formula of rotation (see "OpenGL 4.6
(Compatibility Profile) - May 14, 2018", paragraph "12.1.1 Matrices").
Optimized formula will look so:
R = cos(angle) * I
That is equavalent to logic that magnitude of (0,0,0)-vector is 1.0.
-v2: logic moved to _math_matrix_rotate
-v3: general optimization of computations
-v4: added compatible_0vector_rotation option
CC: Tapani Pälli
CC: Timothy Arceri
CC: Brian Paul
Signed-off-by: Sergii Romantsov
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
Spec: https://github.com/KhronosGroup/OpenGL-API/issues/41
---
src/mesa/drivers/dri/i915/intel_screen.c | 1 +
src/mesa/drivers/dri/i965/brw_context.c | 3 +++
src/mesa/drivers/dri/i965/intel_screen.c | 1 +
src/mesa/main/matrix.c | 3 ++-
src/mesa/main/mtypes.h | 5 +
src/mesa/math/m_matrix.c | 14 +-
src/mesa/math/m_matrix.h | 2 +-
src/util/xmlpool/t_options.h | 5 +
8 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 50934c1..49a1c5f 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -71,6 +71,7 @@ DRI_CONF_BEGIN
DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
+ DRI_CONF_COMPATIBLE_0VECTOR_ROTATION("false")
DRI_CONF_OPT_BEGIN_B(stub_occlusion_query, "false")
DRI_CONF_DESC(en, "Enable stub ARB_occlusion_query support on
915/945.")
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 6ba64e4..ca50364 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -890,6 +890,9 @@ brw_process_driconf_options(struct brw_context *brw)
ctx->Const.AllowGLSLCrossStageInterpolationMismatch =
driQueryOptionb(options,
"allow_glsl_cross_stage_interpolation_mismatch");
+ ctx->Const.Compatible0VectorRotation =
+ driQueryOptionb(options, "compatible_0vector_rotation");
+
ctx->Const.dri_config_options_sha1 = ralloc_array(brw, unsigned char, 20);
driComputeOptionsSha1(&brw->screen->optionCache,
ctx->Const.dri_config_options_sha1);
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index c57fb54..67938b6 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -87,6 +87,7 @@ DRI_CONF_BEGIN
DRI_CONF_ALLOW_GLSL_CROSS_STAGE_INTERPOLATION_MISMATCH("false")
DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION("false")
DRI_CONF_FORCE_GLSL_ABS_SQRT("false")
+ DRI_CONF_COMPATIBLE_0VECTOR_ROTATION("false")
DRI_CONF_OPT_BEGIN_B(shader_precompile, "true")
DRI_CONF_DESC(en, "Perform code generation at shader link time.")
diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index 8065a83..28537a5 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -415,7 +415,8 @@ _mesa_Rotatef( GLfloat angle, GLfloat x, GLfloat y, GLfloat
z )
FLUSH_VERTICES(ctx, 0);
if (angle != 0.0F) {
- _math_matrix_rotate( ctx->CurrentStack->Top, angle, x, y, z);
+ _math_matrix_rotate( ctx->CurrentStack->Top, angle, x, y, z,
+ ctx->Const.Compatible0VectorRotation );
ctx->NewState |= ctx->CurrentStack->DirtyFlag;
}
}
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9ed49b7..e9cbcf1 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3789,6 +3789,11 @@ struct gl_constants
GLboolean AllowLayoutQualifiersOnFunctionParameters;
/**
+* Allow compatible to Windows and Nvidia logic of 0-vector rotation.
+*/
+ GLboolean Compatible0VectorRotation;
+
+ /**
* Force computing the absolute value for sqrt() and inversesqrt() to follow
* D3D9 when apps rely on this behaviour.
*/
diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index 57a4953..8ff7b11 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -794,7 +794,7 @@ static GLboolean matrix_invert( GLmatrix *mat )
*/
void
_math_matrix_rotate( GLmatrix *mat,
-GLfloat angle, GLfloat x, GLfloat y, GLfloat z )
+GLfloat angle, GLfloat x, GLfloat y, GLfloat z, GLboolean
process_zeros )
{
GLfloat xx, yy, zz, xy, yz, zx, xs, ys, zs, one_c, s, c;
GLfloat
[Mesa-dev] [PATCH v3] intel/decoder: tools: Use engine for decoding batch instructions
The engine to which the batch was sent to is now set to the decoder context when
decoding the batch. This is needed so that we can distinguish between
instructions as the render and video pipe share some of the instruction opcodes.
v2: The engine is now in the decoder context and the batch decoder uses a local
function for finding the instruction for an engine.
v3: Spec uses engine_mask now instead of engine, replaced engine class enums
with the definitions from UAPI.
---
src/intel/common/gen_batch_decoder.c | 25 +---
src/intel/common/gen_decoder.c | 7 ++-
src/intel/common/gen_decoder.h | 6 +-
src/intel/tools/aubinator.c | 3 +-
src/intel/tools/aubinator_error_decode.c | 73
5 files changed, 63 insertions(+), 51 deletions(-)
diff --git a/src/intel/common/gen_batch_decoder.c
b/src/intel/common/gen_batch_decoder.c
index 63f04627572..d5482a4d455 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -45,6 +45,7 @@ gen_batch_decode_ctx_init(struct gen_batch_decode_ctx *ctx,
ctx->fp = fp;
ctx->flags = flags;
ctx->max_vbo_decoded_lines = -1; /* No limit! */
+ ctx->engine = I915_ENGINE_CLASS_RENDER;
if (xml_path == NULL)
ctx->spec = gen_spec_load(devinfo);
@@ -192,10 +193,16 @@ ctx_print_buffer(struct gen_batch_decode_ctx *ctx,
fprintf(ctx->fp, "\n");
}
+static struct gen_group *
+gen_ctx_find_instruction(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
+{
+ return gen_spec_find_instruction(ctx->spec, ctx->engine, p);
+}
+
static void
handle_state_base_address(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
{
- struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+ struct gen_group *inst = gen_ctx_find_instruction(ctx, p);
struct gen_field_iterator iter;
gen_field_iterator_init(&iter, inst, p, 0, false);
@@ -309,7 +316,7 @@ static void
handle_media_interface_descriptor_load(struct gen_batch_decode_ctx *ctx,
const uint32_t *p)
{
- struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+ struct gen_group *inst = gen_ctx_find_instruction(ctx, p);
struct gen_group *desc =
gen_spec_find_struct(ctx->spec, "INTERFACE_DESCRIPTOR_DATA");
@@ -373,7 +380,7 @@ static void
handle_3dstate_vertex_buffers(struct gen_batch_decode_ctx *ctx,
const uint32_t *p)
{
- struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+ struct gen_group *inst = gen_ctx_find_instruction(ctx, p);
struct gen_group *vbs = gen_spec_find_struct(ctx->spec,
"VERTEX_BUFFER_STATE");
struct gen_batch_decode_bo vb = {};
@@ -436,7 +443,7 @@ static void
handle_3dstate_index_buffer(struct gen_batch_decode_ctx *ctx,
const uint32_t *p)
{
- struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+ struct gen_group *inst = gen_ctx_find_instruction(ctx, p);
struct gen_batch_decode_bo ib = {};
uint32_t ib_size = 0;
@@ -486,7 +493,7 @@ handle_3dstate_index_buffer(struct gen_batch_decode_ctx
*ctx,
static void
decode_single_ksp(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
{
- struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+ struct gen_group *inst = gen_ctx_find_instruction(ctx, p);
uint64_t ksp = 0;
bool is_simd8 = false; /* vertex shaders on Gen8+ only */
@@ -528,7 +535,7 @@ decode_single_ksp(struct gen_batch_decode_ctx *ctx, const
uint32_t *p)
static void
decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
{
- struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+ struct gen_group *inst = gen_ctx_find_instruction(ctx, p);
uint64_t ksp[3] = {0, 0, 0};
bool enabled[3] = {false, false, false};
@@ -576,7 +583,7 @@ decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const
uint32_t *p)
static void
decode_3dstate_constant(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
{
- struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+ struct gen_group *inst = gen_ctx_find_instruction(ctx, p);
struct gen_group *body =
gen_spec_find_struct(ctx->spec, "3DSTATE_CONSTANT_BODY");
@@ -658,7 +665,7 @@ decode_dynamic_state_pointers(struct gen_batch_decode_ctx
*ctx,
const char *struct_type, const uint32_t *p,
int count)
{
- struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+ struct gen_group *inst = gen_ctx_find_instruction(ctx, p);
uint32_t state_offset = 0;
@@ -802,7 +809,7 @@ gen_print_batch(struct gen_batch_decode_ctx *ctx,
struct gen_group *inst;
for (p = batch; p < end; p += length) {
- inst = gen_spec_find_instruction(ctx->spec, p);
+ inst = gen_ctx_find_instruction(ctx, p);
length = gen_group_get_length(inst, p);
assert(inst == NULL || length > 0);
length
[Mesa-dev] [PATCH v3] intel/decoder: Engine parameter for instructions
Preliminary work for adding handling of different pipes to gen_decoder. Each
instruction needs to have a definition describing which engine it is meant for.
If left undefined, by default, the instruction is defined for all engines.
v2: Changed to use the engine class definitions from UAPI
v3: Changed I915_ENGINE_CLASS_TO_MASK to use BITSET_BIT, change engine to
engine_mask, added check for incorrect engine and added the possibility to
define an instruction to multiple engines using the "|" as a delimiter in the
engine attribute.
---
src/intel/common/gen_decoder.c | 23 +++
src/intel/common/gen_decoder.h | 6 ++
2 files changed, 29 insertions(+)
diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 8148b2f1489..79404660f56 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -165,6 +165,9 @@ create_group(struct parser_context *ctx,
group->fixed_length = fixed_length;
group->dword_length_field = NULL;
group->dw_length = 0;
+ group->engine_mask = I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_RENDER) |
+I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_VIDEO) |
+I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_COPY);
group->bias = 1;
for (int i = 0; atts[i]; i += 2) {
@@ -173,6 +176,26 @@ create_group(struct parser_context *ctx,
group->dw_length = strtoul(atts[i + 1], &p, 0);
} else if (strcmp(atts[i], "bias") == 0) {
group->bias = strtoul(atts[i + 1], &p, 0);
+ } else if (strcmp(atts[i], "engine") == 0) {
+ void *mem_ctx = ralloc_context(NULL);
+ char *tmp = ralloc_strdup(mem_ctx, atts[i + 1]);
+ char *save_ptr;
+ char *tok = strtok_r(tmp, "|", &save_ptr);
+
+ group->engine_mask = 0;
+ while (tok != NULL) {
+if (strcmp(tok, "render") == 0) {
+ group->engine_mask |=
I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_RENDER);
+} else if (strcmp(tok, "video") == 0) {
+ group->engine_mask |=
I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_VIDEO);
+} else if (strcmp(tok, "blitter") == 0) {
+ group->engine_mask |=
I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_COPY);
+} else {
+ fprintf(stderr, "unknown engine class defined for instruction
\"%s\": %s\n", name, atts[i + 1]);
+}
+
+tok = strtok_r(NULL, "|", &save_ptr);
+ }
}
}
diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index 4beed22d729..4311f58b4eb 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -30,6 +30,9 @@
#include "dev/gen_device_info.h"
#include "util/hash_table.h"
+#include "util/bitset.h"
+
+#include "drm-uapi/i915_drm.h"
#ifdef __cplusplus
extern "C" {
@@ -40,6 +43,8 @@ struct gen_group;
struct gen_field;
union gen_field_value;
+#define I915_ENGINE_CLASS_TO_MASK(x) BITSET_BIT(x)
+
static inline uint32_t gen_make_gen(uint32_t major, uint32_t minor)
{
return (major << 8) | minor;
@@ -102,6 +107,7 @@ struct gen_group {
struct gen_field *dword_length_field; /* specific */
uint32_t dw_length;
+ uint32_t engine_mask; /* specific */
uint32_t bias; /* specific */
uint32_t group_offset, group_count;
uint32_t group_size;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control
On Wed, Nov 7, 2018 at 7:45 AM Gert Wollny wrote: > > Am Dienstag, den 06.11.2018, 15:28 -0500 schrieb Ilia Mirkin: > > On Tue, Nov 6, 2018 at 3:15 PM Gert Wollny > > wrote: > > > > > > > > > The extension has the status "not complete" but after reading is it > > > seems to describe what is needed from ARB_framebuffer_sRGB in GLES > > > 3.0, > > Well, after starting to hacking it up and reading the finer details it > turns out that EXT_sRGB is not providing what GLES 3.0 needs: > > EXT_sRGB says > """ > Accepted by the and parameter of TexImage2D, > and TexImage3DOES. These are also accepted by parameter > of TexSubImage2D and TexSubImage3DOES: > > SRGB_EXT 0x8C40 > SRGB_ALPHA_EXT 0x8C42 > > Accepted by the parameter of RenderbufferStorage: > > SRGB8_ALPHA8_EXT 0x8C43 > """ > > whereas GLES 3.0 only knows the internal formats SRGB8 and > SRGB8_ALPHA8 but it doesn't use the unsized SRGB_EXT and SRGB_ALPHA_EXT > at all, and certainaly not as accepted formats. > > Also there is > > """ > 4) What is the expectation for mipmap generation on SRGB textures? > Issue 24 from EXT_texture_sRGB gives two possible ways, will we leave > it similarly undefined, or is this not intended to be supported at all? > > No. This in not likely to be used much so for simplicity let's not > require it. This will generate an INVALID_OPERATION error. > """ > > which is also in conflict with GLES 3.0. > > Which brings me back to what I was talking about yesterday: For > properly calculating GLES 3.0 support a flag is needed that says sRGB > render targets are supported without the need that such a fbo > attachment can switch between linear and sRGB. > > Well, I'll think of something and send an RFC Those are just small API-level differences, not differences in functionality. If you don't feel like actually doing those, you could create the EXT_sRGB enable flag, but not hook it up to an actual extension being enabled. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: use LOAD_CONTEXT_REG when loading fast clear values
This avoids syncing the Micro Engine. This is only supported
for VI+ currently. There is probably a way for using
LOAD_CONTEXT_REG on previous chips but that could be done later.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/sid.h | 1 +
src/amd/vulkan/radv_cmd_buffer.c | 60 +---
src/amd/vulkan/radv_device.c | 4 +++
src/amd/vulkan/radv_private.h| 1 +
4 files changed, 46 insertions(+), 20 deletions(-)
diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index 5c53133147..35782046dd 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -217,6 +217,7 @@
#define PKT3_INCREMENT_CE_COUNTER 0x84
#define PKT3_INCREMENT_DE_COUNTER 0x85
#define PKT3_WAIT_ON_CE_COUNTER0x86
+#define PKT3_LOAD_CONTEXT_REG 0x9F /* new for VI */
#define PKT_TYPE_S(x) (((unsigned)(x) & 0x3) << 30)
#define PKT_TYPE_G(x) (((x) >> 30) & 0x3)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index de67a8a363..4e10470357 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -37,6 +37,8 @@
#include "ac_debug.h"
+#include "addrlib/gfx9/chip/gfx9_enum.h"
+
enum {
RADV_PREFETCH_VBO_DESCRIPTORS = (1 << 0),
RADV_PREFETCH_VS= (1 << 1),
@@ -1313,17 +1315,27 @@ radv_load_ds_clear_metadata(struct radv_cmd_buffer
*cmd_buffer,
if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
++reg_count;
- radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
- radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
- COPY_DATA_DST_SEL(COPY_DATA_REG) |
- (reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
- radeon_emit(cs, va);
- radeon_emit(cs, va >> 32);
- radeon_emit(cs, (R_028028_DB_STENCIL_CLEAR + 4 * reg_offset) >> 2);
- radeon_emit(cs, 0);
+ uint32_t reg = R_028028_DB_STENCIL_CLEAR + 4 * reg_offset;
- radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
- radeon_emit(cs, 0);
+ if (cmd_buffer->device->has_load_context_reg) {
+ radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3, 0));
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+ radeon_emit(cs, reg_count);
+ } else {
+ radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
+ radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
+ COPY_DATA_DST_SEL(COPY_DATA_REG) |
+ (reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, reg >> 2);
+ radeon_emit(cs, 0);
+
+ radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
+ radeon_emit(cs, 0);
+ }
}
/*
@@ -1443,17 +1455,25 @@ radv_load_color_clear_metadata(struct radv_cmd_buffer
*cmd_buffer,
uint32_t reg = R_028C8C_CB_COLOR0_CLEAR_WORD0 + cb_idx * 0x3c;
- radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, cmd_buffer->state.predicating));
- radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
- COPY_DATA_DST_SEL(COPY_DATA_REG) |
- COPY_DATA_COUNT_SEL);
- radeon_emit(cs, va);
- radeon_emit(cs, va >> 32);
- radeon_emit(cs, reg >> 2);
- radeon_emit(cs, 0);
+ if (cmd_buffer->device->has_load_context_reg) {
+ radeon_emit(cs, PKT3(PKT3_LOAD_CONTEXT_REG, 3,
cmd_buffer->state.predicating));
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, (reg >> 2) - CONTEXT_SPACE_START);
+ radeon_emit(cs, 2);
+ } else {
+ radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4,
cmd_buffer->state.predicating));
+ radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
+ COPY_DATA_DST_SEL(COPY_DATA_REG) |
+ COPY_DATA_COUNT_SEL);
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, reg >> 2);
+ radeon_emit(cs, 0);
- radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0,
cmd_buffer->state.predicating));
- radeon_emit(cs, 0);
+ radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0,
cmd_buffer->state.predicating));
+ radeon_emit(cs, 0);
+ }
}
static void
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index d68111c25b..33a1b5bc1b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1680,6 +1680,10 @@ VkResult radv_CreateDevice(
device->physical_device->rad_info.chip_class >= VI &&
device->physical_device->rad_info.max_se >= 2;
+ /* TODO
Re: [Mesa-dev] [PATCH] gm107/ir: fix compile time warning in getTEXSMask
Reviewed-by: Ilia Mirkin Although I'd rather the return go into the "default:" case, after the assert, which is the reason for the warning. On Wed, Nov 7, 2018 at 7:50 AM Karol Herbst wrote: > > In function 'uint8_t nv50_ir::getTEXSMask(uint8_t)': > warning: control reaches end of non-void function [-Wreturn-type] > > Reported-by: Moiman@freenode > Fixes: f821e80213e38e93f96255b3deacb737a600ed40 >"gm107/ir: use scalar tex instructions where possible" > Signed-off-by: Karol Herbst > --- > src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > index 241061ab837..842cf5cb250 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > @@ -2739,6 +2739,7 @@ getTEXSMask(uint8_t mask) > default: >assert(!"invalid mask"); > } > + return 0; > } > > static uint8_t > -- > 2.19.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 2/4] bin/get-pick-list.sh: prefix output with "[stable] "
On Wednesday, 2018-11-07 13:38:26 +, Eric Engestrom wrote:
> On Wednesday, 2018-11-07 12:07:16 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > With later commits we'll fold all the different scripts into one.
> > Add the explicit prefix, so that we know the origin of the nomination
> >
> > Signed-off-by: Emil Velikov
> > ---
> > bin/get-pick-list.sh | 21 -
> > 1 file changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> > index ba741cc4114..33a8a4cba48 100755
> > --- a/bin/get-pick-list.sh
> > +++ b/bin/get-pick-list.sh
> > @@ -7,6 +7,15 @@
> > # $ bin/get-pick-list.sh
> > # $ bin/get-pick-list.sh > picklist
> > # $ bin/get-pick-list.sh | tee picklist
> > +#
> > +# The output is as follows:
> > +# [nominaiton_type] commit_sha commit summary
> > +
> > +is_stable_nomination()
> > +{
> > + stable=`git show --summary $sha | grep -i -o "CC:.*mesa-stable"`
>
> `stable` is unused; you could simply give `-q` to grep to suppress its
> output.
>
> > + return $?
>
> This is already the normal behaviour of a shell function, you can drop
> it.
>
> (both of these also apply to is_typod_nomination() in the next patch)
>
> > +}
> >
> > # Use the last branchpoint as our limit for the search
> > latest_branchpoint=`git merge-base origin/master HEAD`
> > @@ -32,7 +41,17 @@ do
> > continue
> > fi
> >
> > - git --no-pager show --summary --oneline $sha
> > + tag=none
> > + if is_stable_nomination; then
> > + tag=stable
> > + fi
> > +
> > + if test tag = none; then
>
> s/tag/$tag/
>
> > + continue
> > + fi
> > +
> > + printf "[ %8s ] %s\n" \
> > + "$tag" "`git --no-pager show --summary --oneline $sha`"
>
> I'd leave the git invocation out of the printf:
>
> printf "[ %8s ] " "$tag"
> git --no-pager show --summary --oneline $sha
>
> With those fixed, 3 and 4 are:
Sorry, I obviously meant 2 (this patch) and 3 :)
> Reviewed-by: Eric Engestrom
>
> > done
> >
> > rm -f already_picked
> > --
> > 2.19.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 2/4] bin/get-pick-list.sh: prefix output with "[stable] "
On Wednesday, 2018-11-07 12:07:16 +, Emil Velikov wrote:
> From: Emil Velikov
>
> With later commits we'll fold all the different scripts into one.
> Add the explicit prefix, so that we know the origin of the nomination
>
> Signed-off-by: Emil Velikov
> ---
> bin/get-pick-list.sh | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> index ba741cc4114..33a8a4cba48 100755
> --- a/bin/get-pick-list.sh
> +++ b/bin/get-pick-list.sh
> @@ -7,6 +7,15 @@
> # $ bin/get-pick-list.sh
> # $ bin/get-pick-list.sh > picklist
> # $ bin/get-pick-list.sh | tee picklist
> +#
> +# The output is as follows:
> +# [nominaiton_type] commit_sha commit summary
> +
> +is_stable_nomination()
> +{
> + stable=`git show --summary $sha | grep -i -o "CC:.*mesa-stable"`
`stable` is unused; you could simply give `-q` to grep to suppress its
output.
> + return $?
This is already the normal behaviour of a shell function, you can drop
it.
(both of these also apply to is_typod_nomination() in the next patch)
> +}
>
> # Use the last branchpoint as our limit for the search
> latest_branchpoint=`git merge-base origin/master HEAD`
> @@ -32,7 +41,17 @@ do
> continue
> fi
>
> - git --no-pager show --summary --oneline $sha
> + tag=none
> + if is_stable_nomination; then
> + tag=stable
> + fi
> +
> + if test tag = none; then
s/tag/$tag/
> + continue
> + fi
> +
> + printf "[ %8s ] %s\n" \
> + "$tag" "`git --no-pager show --summary --oneline $sha`"
I'd leave the git invocation out of the printf:
printf "[ %8s ] " "$tag"
git --no-pager show --summary --oneline $sha
With those fixed, 3 and 4 are:
Reviewed-by: Eric Engestrom
> done
>
> rm -f already_picked
> --
> 2.19.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 mesa 1/3] mesa: drop unused & deprecated lib
Reviewed-by: Lionel Landwerlin On 07/11/2018 13:20, Eric Engestrom wrote: DeprecationWarning: the imp module is deprecated in favour of importlib Signed-off-by: Eric Engestrom --- src/mesa/main/get_hash_generator.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/get_hash_generator.py b/src/mesa/main/get_hash_generator.py index 37dae45e0b39f06be6a2..f742ebff4b84cd64a9fa 100644 --- a/src/mesa/main/get_hash_generator.py +++ b/src/mesa/main/get_hash_generator.py @@ -30,7 +30,7 @@ from __future__ import print_function -import os, sys, imp, getopt +import os, sys, getopt from collections import defaultdict import get_hash_params ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
