[Mesa-dev] [Bug 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #4 from ilia --- Created attachment 141403 --> https://bugs.freedesktop.org/attachment.cgi?id=141403=edit Windowed Tried to click on menu items - I even heard it, but no > err:d3dadapter:PRESENTPixmap FATAL ERROR: Trying to Present a pixmap not > released or any similar in console. Attached 2 logs above: with nine enabled and disabled, hope you will see some difference in it. -- 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 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #3 from ilia --- Created attachment 141402 --> https://bugs.freedesktop.org/attachment.cgi?id=141402=edit NINE ON log env NINE_DEBUG=all GALLIUM_HUD="fps,requested-VRAM" LIBGL_DEBUG=verbose GALLIUM_PRINT_OPTIONS=1 ST_DEBUG=constants EGL_LOG_LEVEL=debug MESA_DEBUG=1 WINEDEBUG="d3d,d3dadapter,d3d9nine" WINEPREFIX="/tmp/empty" WINE=/opt/wine-d3d9-staging/bin/wine /opt/wine-d3d9-staging/bin/wine vampire.exe -window > /tmp/vampnine_off.log 2>&1 Nine enabled -- 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 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #2 from ilia --- Created attachment 141401 --> https://bugs.freedesktop.org/attachment.cgi?id=141401=edit NINE OFF log Output of env NINE_DEBUG=all GALLIUM_HUD="fps,requested-VRAM" LIBGL_DEBUG=verbose GALLIUM_PRINT_OPTIONS=1 ST_DEBUG=constants EGL_LOG_LEVEL=debug MESA_DEBUG=1 WINEDEBUG="d3d,d3dadapter,d3d9nine" WINEPREFIX="/tmp/empty" WINE=/opt/wine-d3d9-staging/bin/wine /opt/wine-d3d9-staging/bin/wine vampire.exe -window > /tmp/vampnine_off.log 2>&1 -- 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 2/3] radeonsi/nir: Set vs_inputs_dual_locations and let NIR do the remap
We were going out of our way to disable dual-location re-mapping in NIR
only to then do the remapping in st_glsl_to_nir.cpp. Presumably, this
was so that double_inputs would be correct for the core state tracker.
However, now that we've it to gl_program::DualSlotInputs which is
unaffected by NIR lowering, we can let NIR lower things for us. The one
tricky bit here is that we have to remap the inputs_read bitfield back
to the single-slot convention for the gallium state tracker to use.
Since radeonsi is the only NIR-capable gallium driver that also supports
GL_ARB_vertex_attrib_64bit, we only have to worry about radeonsi when
making core gallium state tracker changes.
---
.../nir/nir_lower_io_arrays_to_elements.c | 5 +--
src/gallium/drivers/radeonsi/si_get.c | 1 +
src/mesa/state_tracker/st_glsl_to_nir.cpp | 45 +--
3 files changed, 22 insertions(+), 29 deletions(-)
diff --git a/src/compiler/nir/nir_lower_io_arrays_to_elements.c
b/src/compiler/nir/nir_lower_io_arrays_to_elements.c
index 16f6233f614..af33d153ea5 100644
--- a/src/compiler/nir/nir_lower_io_arrays_to_elements.c
+++ b/src/compiler/nir/nir_lower_io_arrays_to_elements.c
@@ -36,9 +36,6 @@ static unsigned
get_io_offset(nir_builder *b, nir_deref_instr *deref, nir_variable *var,
unsigned *element_index, nir_ssa_def **vertex_index)
{
- bool vs_in = (b->shader->info.stage == MESA_SHADER_VERTEX) &&
-(var->data.mode == nir_var_shader_in);
-
nir_deref_path path;
nir_deref_path_init(, deref, NULL);
@@ -60,7 +57,7 @@ get_io_offset(nir_builder *b, nir_deref_instr *deref,
nir_variable *var,
assert(c); /* must not be indirect dereference */
- unsigned size = glsl_count_attribute_slots((*p)->type, vs_in);
+ unsigned size = glsl_count_attribute_slots((*p)->type, false);
offset += size * c->u32[0];
unsigned num_elements = glsl_type_is_array((*p)->type) ?
diff --git a/src/gallium/drivers/radeonsi/si_get.c
b/src/gallium/drivers/radeonsi/si_get.c
index 90f62edf470..bc3d559861f 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -497,6 +497,7 @@ static const struct nir_shader_compiler_options nir_options
= {
.lower_extract_word = true,
.max_unroll_iterations = 32,
.native_integers = true,
+ .vs_inputs_dual_locations = true,
};
static const void *
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 0ee9bd9fef1..d0ec410ec69 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -32,6 +32,7 @@
#include "program/prog_parameter.h"
#include "program/ir_to_mesa.h"
#include "main/mtypes.h"
+#include "main/imports.h"
#include "main/errors.h"
#include "main/shaderapi.h"
#include "main/uniforms.h"
@@ -83,33 +84,18 @@ st_nir_fixup_varying_slots(struct st_context *st, struct
exec_list *var_list)
static void
st_nir_assign_vs_in_locations(struct gl_program *prog, nir_shader *nir)
{
- unsigned attr, num_inputs = 0;
- unsigned input_to_index[VERT_ATTRIB_MAX] = {0};
-
- /* TODO de-duplicate w/ similar code in st_translate_vertex_program()? */
- for (attr = 0; attr < VERT_ATTRIB_MAX; attr++) {
- if ((prog->info.inputs_read & BITFIELD64_BIT(attr)) != 0) {
- input_to_index[attr] = num_inputs;
- num_inputs++;
- if ((prog->DualSlotInputs & BITFIELD64_BIT(attr)) != 0) {
-/* add placeholder for second part of a double attribute */
-num_inputs++;
- }
- } else {
- input_to_index[attr] = ~0;
- }
- }
-
- /* bit of a hack, mirroring st_translate_vertex_program */
- input_to_index[VERT_ATTRIB_EDGEFLAG] = num_inputs;
-
nir->num_inputs = 0;
nir_foreach_variable_safe(var, >inputs) {
- attr = var->data.location;
- assert(attr < ARRAY_SIZE(input_to_index));
-
- if (input_to_index[attr] != ~0u) {
- var->data.driver_location = input_to_index[attr];
+ /* NIR already assigns dual-slot inputs to two locations so all we have
+ * to do is compact everything down.
+ */
+ if (var->data.location == VERT_ATTRIB_EDGEFLAG) {
+ /* bit of a hack, mirroring st_translate_vertex_program */
+ var->data.driver_location = _mesa_bitcount_64(nir->info.inputs_read);
+ } else if (nir->info.inputs_read & BITFIELD64_BIT(var->data.location)) {
+ var->data.driver_location =
+_mesa_bitcount_64(nir->info.inputs_read &
+ BITFIELD64_MASK(var->data.location));
nir->num_inputs++;
} else {
/* Move unused input variables to the globals list (with no
@@ -743,6 +729,15 @@ st_link_nir(struct gl_context *ctx,
nir_shader_gather_info(nir, nir_shader_get_entrypoint(nir));
shader->Program->info = nir->info;
+ if (i == MESA_SHADER_VERTEX) {
+ /*
[Mesa-dev] [PATCH 3/3] nir: Drop the vs_inputs_dual_locations option
It was very inconsistently handled; the only things that made use of it
were glsl_to_nir, glspirv, and nir_gather_info. In particular,
nir_lower_io completely ignored it so anyone using nir_lower_io on
64-bit vertex attributes was going to be in for a shock. Also, as of
the previous commit, it's set by every driver that supports 64-bit
vertex attributes. There's no longer any reason to have it be an option
so let's just delete it.
---
src/amd/vulkan/radv_shader.c | 1 -
src/compiler/glsl/glsl_to_nir.cpp | 7 ++
src/compiler/nir/nir.c| 32 +--
src/compiler/nir/nir.h| 9 +---
src/compiler/nir/nir_gather_info.c| 20 +++--
src/gallium/drivers/radeonsi/si_get.c | 1 -
src/intel/compiler/brw_compiler.c | 3 ---
src/mesa/main/glspirv.c | 8 ++-
8 files changed, 23 insertions(+), 58 deletions(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 207e5b050eb..e05961339ca 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -71,7 +71,6 @@ static const struct nir_shader_compiler_options nir_options =
{
.lower_extract_word = true,
.lower_ffma = true,
.lower_fpow = true,
- .vs_inputs_dual_locations = true,
.max_unroll_iterations = 32
};
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index d22f4a58dd4..dc6ffa3599d 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -149,11 +149,8 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
* two locations. For instance, if we have in the IR code a dvec3 attr0 in
* location 0 and vec4 attr1 in location 1, in NIR attr0 will use
* locations/slots 0 and 1, and attr1 will use location/slot 2 */
- if (shader->info.stage == MESA_SHADER_VERTEX) {
- sh->Program->DualSlotInputs = nir_get_dual_slot_attributes(shader);
- if (options->vs_inputs_dual_locations)
- nir_remap_dual_slot_attributes(shader, sh->Program->DualSlotInputs);
- }
+ if (shader->info.stage == MESA_SHADER_VERTEX)
+ nir_remap_dual_slot_attributes(shader, >Program->DualSlotInputs);
shader->info.name = ralloc_asprintf(shader, "GLSL%d", shader_prog->Name);
if (shader_prog->Label)
diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 0d8a554bd20..a6240c11f2d 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -1854,34 +1854,32 @@ nir_system_value_from_intrinsic(nir_intrinsic_op intrin)
}
}
-uint64_t
-nir_get_dual_slot_attributes(nir_shader *shader)
+/* OpenGL utility method that remaps the location attributes if they are
+ * doubles. Not needed for vulkan due the differences on the input location
+ * count for doubles on vulkan vs OpenGL
+ *
+ * The bitfield returned in dual_slot is one bit for each double input slot in
+ * the original OpenGL single-slot input numbering. The mapping from old
+ * locations to new locations is as follows:
+ *
+ *new_loc = loc + _mesa_bitcount(dual_slot & BITFIELD64_MASK(loc))
+ */
+void
+nir_remap_dual_slot_attributes(nir_shader *shader, uint64_t *dual_slot)
{
assert(shader->info.stage == MESA_SHADER_VERTEX);
- uint64_t dual_slot = 0;
+ *dual_slot = 0;
nir_foreach_variable(var, >inputs) {
if (glsl_type_is_dual_slot(glsl_without_array(var->type))) {
unsigned slots = glsl_count_attribute_slots(var->type, true);
- dual_slot |= BITFIELD64_MASK(slots) << var->data.location;
+ *dual_slot |= BITFIELD64_MASK(slots) << var->data.location;
}
}
- return dual_slot;
-}
-
-/* OpenGL utility method that remaps the location attributes if they are
- * doubles. Not needed for vulkan due the differences on the input location
- * count for doubles on vulkan vs OpenGL
- */
-void
-nir_remap_dual_slot_attributes(nir_shader *shader, uint64_t dual_slot)
-{
- assert(shader->info.stage == MESA_SHADER_VERTEX);
-
nir_foreach_variable(var, >inputs) {
var->data.location +=
- _mesa_bitcount_64(dual_slot & BITFIELD64_MASK(var->data.location));
+ _mesa_bitcount_64(*dual_slot & BITFIELD64_MASK(var->data.location));
}
}
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index b9393702097..bf4bd916d27 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2119,12 +2119,6 @@ typedef struct nir_shader_compiler_options {
*/
bool use_interpolated_input_intrinsics;
- /**
-* Do vertex shader double inputs use two locations? The Vulkan spec
-* requires two locations to be used, OpenGL allows a single location.
-*/
- bool vs_inputs_dual_locations;
-
unsigned max_unroll_iterations;
} nir_shader_compiler_options;
@@ -3039,9 +3033,8 @@ bool nir_opt_conditional_discard(nir_shader *shader);
void nir_sweep(nir_shader *shader);
-uint64_t nir_get_dual_slot_attributes(nir_shader *shader);
void
[Mesa-dev] [PATCH 0/3] nir: Rework 64-bit attribute handling
NIR handling of 64-bit vertex attributes is inconsistent at best. When it comes vertex attributes which are 196 or 256 bits (dvec3 or dvec4), some passes assume they consume two slots, some passes assume they consume one, and some passes are configurable. When you combine that with the limited number of tests and apps which use attrib_64bit, it's an utter minefield. Since both gallium and i965 want 196-bit and 256-bit attributes to map to two slots eventually, you have the challenge of mapping back and forth between the two in all the right places. This series attempts to fix the problem and make all of NIR consistently have the dual-slot behavior. Cc: Timothy Arceri Jason Ekstrand (3): compiler: Move double_inputs to gl_program::DualSlotInputs radeonsi/nir: Set vs_inputs_dual_locations and let NIR do the remap nir: Drop the vs_inputs_dual_locations option src/amd/vulkan/radv_shader.c | 1 - src/compiler/glsl/glsl_to_nir.cpp | 11 + src/compiler/glsl/ir_set_program_inouts.cpp | 2 +- src/compiler/glsl/serialize.cpp | 2 + src/compiler/nir/nir.c| 45 ++- src/compiler/nir/nir.h| 11 ++--- src/compiler/nir/nir_gather_info.c| 26 ++- .../nir/nir_lower_io_arrays_to_elements.c | 5 +-- src/compiler/shader_info.h| 3 -- src/intel/compiler/brw_compiler.c | 3 -- src/mesa/drivers/dri/i965/brw_draw_upload.c | 21 - src/mesa/drivers/dri/i965/genX_state_upload.c | 1 + src/mesa/main/glspirv.c | 20 + src/mesa/main/mtypes.h| 15 +++ src/mesa/state_tracker/st_glsl_to_nir.cpp | 45 +-- src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 2 +- src/mesa/state_tracker/st_program.c | 3 +- 17 files changed, 96 insertions(+), 120 deletions(-) -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] compiler: Move double_inputs to gl_program::DualSlotInputs
Previously, we had two field in shader_info: double_inputs_read and
double_inputs. Presumably, the one was for all double inputs that are
read and the other is all that exist. However, because nir_gather_info
regenerates these two values, there is a possibility, if a variable gets
deleted, that the value of double_inputs could change over time. This
is a problem because double_inputs is used to remap the input locations
to a two-slot-per-dvec3/4 scheme for i965. If that mapping were to
change between glsl_to_nir and back-end state setup, we would fall over
when trying to map the NIR outputs back onto the GL location space.
This commit changes the way slot re-mapping works. Instead of the
double_inputs field in shader_info, it adds a DualSlotInputs bitfield to
gl_program. By having it in gl_program, we more easily guarantee that
NIR passes won't touch it after it's been set. It also makes more sense
to put it in a GL data structure since it's really a mapping from GL
slots to back-end and/or NIR slots and not really a NIR shader thing.
---
src/compiler/glsl/glsl_to_nir.cpp | 16 ++
src/compiler/glsl/ir_set_program_inouts.cpp | 2 +-
src/compiler/glsl/serialize.cpp | 2 +
src/compiler/nir/nir.c| 49 ++-
src/compiler/nir/nir.h| 6 ++-
src/compiler/nir/nir_gather_info.c| 6 ---
src/compiler/shader_info.h| 3 --
src/mesa/drivers/dri/i965/brw_draw_upload.c | 21
src/mesa/drivers/dri/i965/genX_state_upload.c | 1 +
src/mesa/main/glspirv.c | 20 ++--
src/mesa/main/mtypes.h| 15 ++
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 2 +-
src/mesa/state_tracker/st_program.c | 3 +-
14 files changed, 83 insertions(+), 65 deletions(-)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index f38d280d406..d22f4a58dd4 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -149,8 +149,11 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
* two locations. For instance, if we have in the IR code a dvec3 attr0 in
* location 0 and vec4 attr1 in location 1, in NIR attr0 will use
* locations/slots 0 and 1, and attr1 will use location/slot 2 */
- if (shader->info.stage == MESA_SHADER_VERTEX)
- nir_remap_attributes(shader, options);
+ if (shader->info.stage == MESA_SHADER_VERTEX) {
+ sh->Program->DualSlotInputs = nir_get_dual_slot_attributes(shader);
+ if (options->vs_inputs_dual_locations)
+ nir_remap_dual_slot_attributes(shader, sh->Program->DualSlotInputs);
+ }
shader->info.name = ralloc_asprintf(shader, "GLSL%d", shader_prog->Name);
if (shader_prog->Label)
@@ -344,15 +347,6 @@ nir_visitor::visit(ir_variable *ir)
var->data.compact = ir->type->without_array()->is_scalar();
}
}
-
- /* Mark all the locations that require two slots */
- if (shader->info.stage == MESA_SHADER_VERTEX &&
- glsl_type_is_dual_slot(glsl_without_array(var->type))) {
- for (unsigned i = 0; i < glsl_count_attribute_slots(var->type, true);
i++) {
-uint64_t bitfield = BITFIELD64_BIT(var->data.location + i);
-shader->info.vs.double_inputs |= bitfield;
- }
- }
break;
case ir_var_shader_out:
diff --git a/src/compiler/glsl/ir_set_program_inouts.cpp
b/src/compiler/glsl/ir_set_program_inouts.cpp
index ba1e44167c3..a3cb19479b8 100644
--- a/src/compiler/glsl/ir_set_program_inouts.cpp
+++ b/src/compiler/glsl/ir_set_program_inouts.cpp
@@ -118,7 +118,7 @@ mark(struct gl_program *prog, ir_variable *var, int offset,
int len,
/* double inputs read is only for vertex inputs */
if (stage == MESA_SHADER_VERTEX &&
var->type->without_array()->is_dual_slot())
-prog->info.vs.double_inputs_read |= bitfield;
+prog->DualSlotInputs |= bitfield;
if (stage == MESA_SHADER_FRAGMENT) {
prog->info.fs.uses_sample_qualifier |= var->data.sample;
diff --git a/src/compiler/glsl/serialize.cpp b/src/compiler/glsl/serialize.cpp
index 889038fb5e2..267700e7e78 100644
--- a/src/compiler/glsl/serialize.cpp
+++ b/src/compiler/glsl/serialize.cpp
@@ -1035,6 +1035,7 @@ write_shader_metadata(struct blob *metadata,
gl_linked_shader *shader)
struct gl_program *glprog = shader->Program;
unsigned i;
+ blob_write_uint64(metadata, glprog->DualSlotInputs);
blob_write_bytes(metadata, glprog->TexturesUsed,
sizeof(glprog->TexturesUsed));
blob_write_uint64(metadata, glprog->SamplersUsed);
@@ -1088,6 +1089,7 @@ read_shader_metadata(struct blob_reader *metadata,
{
unsigned i;
+ glprog->DualSlotInputs = blob_read_uint64(metadata);
blob_copy_bytes(metadata, (uint8_t *)
[Mesa-dev] [Bug 107778] 3d renders does not work at all in game, only 2d (like menus) shows up.
https://bugs.freedesktop.org/show_bug.cgi?id=107778 Bug ID: 107778 Summary: 3d renders does not work at all in game, only 2d (like menus) shows up. Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: jonathanil...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org I think this is a bug with mesa. When playing No Mans Sky with the new Proton Engine (custom version of Wine) with steam no 3d rendering shows up, just the menus and any hud markers (which are 2d). I would have guessed this is a bug with Proton but it also happens on a random Windows laptop of mine. My guess is it has some thing to do with No Man's Skies strick support of only OpenGL 4.5. But as far as I can find you do support OpenGL 4.5. -- 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 1/2] gallium: add PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET
From: Marek Olšák --- src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 4 src/gallium/drivers/radeonsi/si_get.c| 4 src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/v3d/v3d_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/virgl/virgl_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + 18 files changed, 26 insertions(+) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 485248261df..b1846dd2343 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -451,20 +451,23 @@ PIPE_CONSERVATIVE_RASTER_PRE_SNAP mode is supported for points and lines. works with conservative rasterization. * ``PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS``: The maximum subpixel precision bias in bits during conservative rasterization. * ``PIPE_CAP_PROGRAMMABLE_SAMPLE_LOCATIONS``: True is the driver supports programmable sample location through ```get_sample_pixel_grid``` and ```set_sample_locations```. * ``PIPE_CAP_MAX_GS_INVOCATIONS``: Maximum supported value of TGSI_PROPERTY_GS_INVOCATIONS. * ``PIPE_CAP_MAX_SHADER_BUFFER_SIZE``: Maximum supported size for binding with set_shader_buffers. +* ``PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET: Maximum recommend memory size + for all active texture uploads combined. This is a performance hint. + 0 means no limit. .. _pipe_capf: PIPE_CAPF_* The floating-point capabilities are: * ``PIPE_CAPF_MAX_LINE_WIDTH``: The maximum width of a regular line. * ``PIPE_CAPF_MAX_LINE_WIDTH_AA``: The maximum width of a smoothed line. diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c b/src/gallium/drivers/etnaviv/etnaviv_screen.c index 9669bd2f601..497bc37ad0e 100644 --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c @@ -277,20 +277,21 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_FENCE_SIGNAL: case PIPE_CAP_CONSTBUF0_FLAGS: case PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_TRIANGLES: case PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_POINTS_LINES: case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_TRIANGLES: case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES: case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE: case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS: case PIPE_CAP_PACKED_UNIFORMS: case PIPE_CAP_PROGRAMMABLE_SAMPLE_LOCATIONS: + case PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET: return 0; case PIPE_CAP_MAX_GS_INVOCATIONS: return 32; case PIPE_CAP_MAX_SHADER_BUFFER_SIZE: return 1 << 27; /* Stream output. */ case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index 489986703cd..c91f7094025 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -208,20 +208,21 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_COMPUTE: return has_compute(screen); case PIPE_CAP_SHADER_STENCIL_EXPORT: case PIPE_CAP_TGSI_TEXCOORD: case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER: case PIPE_CAP_TEXTURE_MIRROR_CLAMP: case PIPE_CAP_TEXTURE_MIRROR_CLAMP_TO_EDGE: case PIPE_CAP_QUERY_MEMORY_INFO: + case PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET: case PIPE_CAP_PCI_GROUP: case PIPE_CAP_PCI_BUS: case PIPE_CAP_PCI_DEVICE: case PIPE_CAP_PCI_FUNCTION: return 0; case PIPE_CAP_SM3: case PIPE_CAP_PRIMITIVE_RESTART: case PIPE_CAP_TGSI_INSTANCEID: case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR: diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 103725ca5c8..7a8bd91a43c 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -283,20 +283,21 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: case PIPE_CAP_TGSI_ARRAY_COMPONENTS: case
[Mesa-dev] [PATCH 2/2] st/mesa: throttle texture uploads if their memory usage goes beyond a limit
From: Marek Olšák
This prevents radeonsi from running out of memory. It also increases
texture upload performance by being nice to the kernel memory manager.
---
src/gallium/auxiliary/util/u_helpers.c | 120 +
src/gallium/auxiliary/util/u_helpers.h | 17
src/mesa/state_tracker/st_cb_texture.c | 16
src/mesa/state_tracker/st_context.c| 5 ++
src/mesa/state_tracker/st_context.h| 7 ++
5 files changed, 165 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_helpers.c
b/src/gallium/auxiliary/util/u_helpers.c
index 365238631a2..25d8fbce6f7 100644
--- a/src/gallium/auxiliary/util/u_helpers.c
+++ b/src/gallium/auxiliary/util/u_helpers.c
@@ -172,10 +172,130 @@ util_end_pipestat_query(struct pipe_context *ctx, struct
pipe_query *q,
/* This is a helper for hardware bring-up. Don't remove. */
void
util_wait_for_idle(struct pipe_context *ctx)
{
struct pipe_fence_handle *fence = NULL;
ctx->flush(ctx, , 0);
ctx->screen->fence_finish(ctx->screen, NULL, fence, PIPE_TIMEOUT_INFINITE);
}
+
+void
+util_throttle_init(struct util_throttle *t, uint64_t max_mem_usage)
+{
+ t->max_mem_usage = max_mem_usage;
+}
+
+void
+util_throttle_deinit(struct pipe_screen *screen, struct util_throttle *t)
+{
+ for (unsigned i = 0; i < ARRAY_SIZE(t->ring); i++)
+ screen->fence_reference(screen, >ring[i].fence, NULL);
+}
+
+static uint64_t
+util_get_throttle_total_memory_usage(struct util_throttle *t)
+{
+ uint64_t total_usage = 0;
+
+ for (unsigned i = 0; i < ARRAY_SIZE(t->ring); i++)
+ total_usage += t->ring[i].mem_usage;
+ return total_usage;
+}
+
+static void util_dump_throttle_ring(struct util_throttle *t)
+{
+ printf("Throttle:\n");
+ for (unsigned i = 0; i < ARRAY_SIZE(t->ring); i++) {
+ printf(" ring[%u]: fence = %s, mem_usage = %"PRIu64"%s%s\n",
+ i, t->ring[i].fence ? "yes" : " no",
+ t->ring[i].mem_usage,
+ t->flush_index == i ? " [flush]" : "",
+ t->wait_index == i ? " [wait]" : "");
+ }
+}
+
+/**
+ * Notify util_throttle that the next operation allocates memory.
+ * util_throttle tracks memory usage and waits for fences until its tracked
+ * memory usage decreases.
+ *
+ * Example:
+ * util_throttle_memory_usage(..., w*h*d*Bpp);
+ * TexSubImage(..., w, h, d, ...);
+ *
+ * This means that TexSubImage can't allocate more memory its maximum limit
+ * set during initialization.
+ */
+void
+util_throttle_memory_usage(struct pipe_context *pipe,
+ struct util_throttle *t, uint64_t memory_size)
+{
+ (void)util_dump_throttle_ring; /* silence warning */
+
+ if (!t->max_mem_usage)
+ return;
+
+ struct pipe_screen *screen = pipe->screen;
+ struct pipe_fence_handle **fence = NULL;
+ unsigned ring_size = ARRAY_SIZE(t->ring);
+ uint64_t total = util_get_throttle_total_memory_usage(t);
+
+ /* If there is not enough memory, walk the list of fences and find
+* the latest one that we need to wait for.
+*/
+ while (t->wait_index != t->flush_index &&
+ total && total + memory_size > t->max_mem_usage) {
+ assert(t->ring[t->wait_index].fence);
+
+ /* Release an older fence if we need to wait for a newer one. */
+ if (fence)
+ screen->fence_reference(screen, fence, NULL);
+
+ fence = >ring[t->wait_index].fence;
+ t->ring[t->wait_index].mem_usage = 0;
+ t->wait_index = (t->wait_index + 1) % ring_size;
+
+ total = util_get_throttle_total_memory_usage(t);
+ }
+
+ /* Wait for the fence to decrease memory usage. */
+ if (fence) {
+ screen->fence_finish(screen, pipe, *fence, PIPE_TIMEOUT_INFINITE);
+ screen->fence_reference(screen, fence, NULL);
+ }
+
+ /* Flush and get a fence if we've exhausted memory usage for the current
+* slot.
+*/
+ if (t->ring[t->flush_index].mem_usage &&
+ t->ring[t->flush_index].mem_usage + memory_size >
+ t->max_mem_usage / (ring_size / 2)) {
+ struct pipe_fence_handle **fence =
+ >ring[t->flush_index].fence;
+
+ /* Expect that the current flush slot doesn't have a fence yet. */
+ assert(!*fence);
+
+ pipe->flush(pipe, fence, PIPE_FLUSH_ASYNC);
+ t->flush_index = (t->flush_index + 1) % ring_size;
+
+ /* Vacate the next slot if it's occupied. This should be rare. */
+ if (t->flush_index == t->wait_index) {
+ struct pipe_fence_handle **fence =
+>ring[t->wait_index].fence;
+
+ t->ring[t->wait_index].mem_usage = 0;
+ t->wait_index = (t->wait_index + 1) % ring_size;
+
+ assert(*fence);
+ screen->fence_finish(screen, pipe, *fence, PIPE_TIMEOUT_INFINITE);
+ screen->fence_reference(screen, fence, NULL);
+ }
+
+ assert(!t->ring[t->flush_index].mem_usage);
+ assert(!t->ring[t->flush_index].fence);
+ }
+
+ t->ring[t->flush_index].mem_usage += memory_size;
+}
diff --git a/src/gallium/auxiliary/util/u_helpers.h
[Mesa-dev] [PATCH] docs: add the beginning of the 18.3 cycle
Cc: Dylan Baker Cc: Juan A. Suarez Cc: Emil Velikov Signed-off-by: Andres Gomez --- docs/release-calendar.html | 25 + 1 file changed, 25 insertions(+) This is just a proposal for the beginning of the 18.3 releasing process. 18.2 has gotten exceptionally long to be released but that's not a reason for delaying 18.3 as we have agreed to get one release every 3 months. 18.2 will just be shorter if 18.3 gets released by the planned scheduled date. Juan has transmitted me his wish to skip this cycle as he sees himself very busy during those weeks. He may also have to back me up in some of the 18.2 releases, in any case. Emil also commented his wish to rest for a bit from release duties. Therefore, I'm proposing Dylan to manage 18.3. diff --git a/docs/release-calendar.html b/docs/release-calendar.html index 2e3bb8a..669d692ecc4 100644 --- a/docs/release-calendar.html +++ b/docs/release-calendar.html @@ -58,6 +58,31 @@ if you'd like to nominate a patch in the next stable release. Andres Gomez Last planned RC/Final release + +18.3 +2018-10-10 +18.3.0-rc1 +Dylan Baker + + + +2018-10-17 +18.3.0-rc2 +Dylan Baker + + + +2018-10-24 +18.3.0-rc3 +Dylan Baker + + + +2018-10-31 +18.3.0-rc4 +Dylan Baker +Last planned RC/Final release + -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl/wayland: do not leak wl_buffer when it is locked
Juan, should we also include this in the stable queues ?
On Thu, 2018-08-30 at 13:59 +0200, Juan A. Suarez Romero wrote:
> If color buffer is locked, do not set its wayland buffer to NULL;
> otherwise it can not be freed later.
>
> Rather, flag it in order to destroy it later on the release event.
>
> v2: instruct release event to unlock only or free wl_buffer too (Daniel)
>
> This also fixes dEQP-EGL.functional.swap_buffers_with_damage.* tests.
>
> CC: Daniel Stone
> ---
> src/egl/drivers/dri2/egl_dri2.h | 1 +
> src/egl/drivers/dri2/platform_wayland.c | 22 +++---
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index d1e4e8dcf22..349f66a3506 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -297,6 +297,7 @@ struct dri2_egl_surface
> struct {
> #ifdef HAVE_WAYLAND_PLATFORM
>struct wl_buffer *wl_buffer;
> + boolwl_release;
>__DRIimage *dri_image;
>/* for is_different_gpu case. NULL else */
>__DRIimage *linear_copy;
> diff --git a/src/egl/drivers/dri2/platform_wayland.c
> b/src/egl/drivers/dri2/platform_wayland.c
> index 11c57de0f89..03a3e0993b0 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -182,9 +182,12 @@ wl_buffer_release(void *data, struct wl_buffer *buffer)
>if (dri2_surf->color_buffers[i].wl_buffer == buffer)
> break;
>
> - if (i == ARRAY_SIZE(dri2_surf->color_buffers)) {
> + assert (i < ARRAY_SIZE(dri2_surf->color_buffers));
> +
> + if (dri2_surf->color_buffers[i].wl_release) {
>wl_buffer_destroy(buffer);
> - return;
> + dri2_surf->color_buffers[i].wl_release = false;
> + dri2_surf->color_buffers[i].wl_buffer = NULL;
> }
>
> dri2_surf->color_buffers[i].locked = false;
> @@ -425,9 +428,14 @@ dri2_wl_release_buffers(struct dri2_egl_surface
> *dri2_surf)
>dri2_egl_display(dri2_surf->base.Resource.Display);
>
> for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> - if (dri2_surf->color_buffers[i].wl_buffer &&
> - !dri2_surf->color_buffers[i].locked)
> - wl_buffer_destroy(dri2_surf->color_buffers[i].wl_buffer);
> + if (dri2_surf->color_buffers[i].wl_buffer) {
> + if (dri2_surf->color_buffers[i].locked) {
> +dri2_surf->color_buffers[i].wl_release = true;
> + } else {
> +wl_buffer_destroy(dri2_surf->color_buffers[i].wl_buffer);
> +dri2_surf->color_buffers[i].wl_buffer = NULL;
> + }
> + }
>if (dri2_surf->color_buffers[i].dri_image)
>
> dri2_dpy->image->destroyImage(dri2_surf->color_buffers[i].dri_image);
>if (dri2_surf->color_buffers[i].linear_copy)
> @@ -436,11 +444,9 @@ dri2_wl_release_buffers(struct dri2_egl_surface
> *dri2_surf)
> munmap(dri2_surf->color_buffers[i].data,
> dri2_surf->color_buffers[i].data_size);
>
> - dri2_surf->color_buffers[i].wl_buffer = NULL;
>dri2_surf->color_buffers[i].dri_image = NULL;
>dri2_surf->color_buffers[i].linear_copy = NULL;
>dri2_surf->color_buffers[i].data = NULL;
> - dri2_surf->color_buffers[i].locked = false;
> }
>
> if (dri2_dpy->dri2)
> @@ -968,6 +974,8 @@ dri2_wl_swap_buffers_with_damage(_EGLDriver *drv,
>dri2_surf->current->wl_buffer =
> create_wl_buffer(dri2_dpy, dri2_surf, image);
>
> + dri2_surf->current->wl_release = false;
> +
>wl_buffer_add_listener(dri2_surf->current->wl_buffer,
> _buffer_listener, dri2_surf);
> }
--
Br,
Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] anv/blorp: Do more flushing around HiZ clears
On Fri, Aug 31, 2018 at 5:38 PM Nanley Chery wrote:
> On Fri, Aug 31, 2018 at 05:15:53PM -0500, Jason Ekstrand wrote:
> > We make the flush after a HiZ clear unconditional and add a flush/stall
> > before the clear as well.
> >
> > Cc: mesa-sta...@lists.freedesktop.org
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107760
> > ---
> > src/intel/vulkan/anv_blorp.c | 44 +++-
> > 1 file changed, 33 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index 35b304f92b3..04bca4d261f 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -1604,6 +1604,24 @@ anv_image_hiz_clear(struct anv_cmd_buffer
> *cmd_buffer,
> > ISL_AUX_USAGE_NONE, );
> > }
> >
> > + /* From the Sky Lake PRM Volume 7, "Depth Buffer Clear":
> > +*
> > +*"The following is required when performing a depth buffer
> clear with
> > +*using the WM_STATE or 3DSTATE_WM:
> > +*
> > +* * If other rendering operations have preceded this clear, a
> > +* PIPE_CONTROL with depth cache flush enabled, Depth Stall
> bit
> > +* enabled must be issued before the rectangle primitive
> used for
> > +* the depth buffer clear operation.
> > +* * [...]"
> > +*
> > +* Even though the PRM only says that this is required if using
> 3DSTATE_WM
> > +* and a 3DPRIMITIVE, it appears to also sometimes hang when doing a
> clear
> > +* with WM_HZ_OP.
>^
> This part was a little hard to parse because the PRM hasn't mentioned
> the hardware hanging and the subject's changed from the pipecontrol to
> the GPU. Maybe replace it with something like the following?
>
>the GPU appears to also need this to avoid
>occasional hangs when doing a clear with
>WM_HZ_OP.
>
Works for me.
> We could discuss it more on IRC if you prefer.
>
> With that changed, this patch is
> Reviewed-by: Nanley Chery
>
Thanks!
> > +*/
> > + cmd_buffer->state.pending_pipe_bits |=
> > + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
> > +
> > blorp_hiz_clear_depth_stencil(, , ,
> > level, base_layer, layer_count,
> > area.offset.x, area.offset.y,
> > @@ -1618,18 +1636,22 @@ anv_image_hiz_clear(struct anv_cmd_buffer
> *cmd_buffer,
> >
> > /* From the SKL PRM, Depth Buffer Clear:
> > *
> > -* Depth Buffer Clear Workaround
> > -* Depth buffer clear pass using any of the methods (WM_STATE,
> 3DSTATE_WM
> > -* or 3DSTATE_WM_HZ_OP) must be followed by a PIPE_CONTROL command
> with
> > -* DEPTH_STALL bit and Depth FLUSH bits “set” before starting to
> render.
> > -* DepthStall and DepthFlush are not needed between consecutive
> depth clear
> > -* passes nor is it required if the depth-clear pass was done with
> > -* “full_surf_clear” bit set in the 3DSTATE_WM_HZ_OP.
> > +*"Depth Buffer Clear Workaround
> > +*
> > +*Depth buffer clear pass using any of the methods (WM_STATE,
> > +*3DSTATE_WM or 3DSTATE_WM_HZ_OP) must be followed by a
> PIPE_CONTROL
> > +*command with DEPTH_STALL bit and Depth FLUSH bits “set” before
> > +*starting to render. DepthStall and DepthFlush are not needed
> between
> > +*consecutive depth clear passes nor is it required if the
> depth-clear
> > +*pass was done with “full_surf_clear” bit set in the
> > +*3DSTATE_WM_HZ_OP."
> > +*
> > +* Even though the PRM provides a bunch of conditions under which
> this is
> > +* supposedly unnecessary, we choose to perform the flush
> unconditionally
> > +* just to be safe.
> > */
> > - if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
> > - cmd_buffer->state.pending_pipe_bits |=
> > - ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
> > - }
> > + cmd_buffer->state.pending_pipe_bits |=
> > + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
> > }
> >
> > void
> > --
> > 2.17.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).
https://bugs.freedesktop.org/show_bug.cgi?id=107670 --- Comment #9 from i...@yahoo.com --- (In reply to Timothy Arceri from comment #8) > Using SSE2 memcpy seems to avoid this problem" > > Glib should select the SSE2 (or better) version of memcpy. If Slackware > doesn't ship and SSE2 support for glibc I don't see how this is Mesas fault. > > If I'm misunderstanding somthing please clarify. Otherwise I'm inclined to > close this as won't fix. Please, I'm not done investigating this bug. I also intent on writing some patches for it. 1. The glibc memcpy() is optimized for system->system memory transfer. While it might be faster than the problematic one, it still may not be the optimal one. Also, nothing guarantees that glibc memcpy() will continue to work properly in future. That's why it is good idea for Mesa to have its own implementation that is known to always do the right thing, when going sys->vid mem transfer. I can write the x86(_64), MMX/AVX assembly, I've written SIMD before. Finding the all functions that have to use it, might be more tricky and need help by experts. (The memcpy I've reported is mostly used by Nine, but I'm getting the same problem with other memcpy()s when using OpenGL.) --- 2. Another issue that has to be checked is related to Write Combine caching. In the past the XFree86 DDX driver was setting video memory region caching through MTRR registers. That was removed in favor of using PAT (Page Attribute Table, aka setting caching per memory page). I have asked developers where is the PAT handling code. Is it in the kernel kms, libdrm or Mesa3D itself? Where exactly? How do I check the caching status? So far nobody was brave enough to answer. And if nobody has checked that code recently, it might have silently stopped working some time ago. (One reason why SSE2 code might be working better is that it usually employs MOVNTQ. That instruction forces WC to avoid cache pollution.) I want Mesa3D to always be fast. So help me help you. -- 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 v2] anv/blorp: Do more flushing around HiZ clears
On Fri, Aug 31, 2018 at 05:15:53PM -0500, Jason Ekstrand wrote:
> We make the flush after a HiZ clear unconditional and add a flush/stall
> before the clear as well.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107760
> ---
> src/intel/vulkan/anv_blorp.c | 44 +++-
> 1 file changed, 33 insertions(+), 11 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 35b304f92b3..04bca4d261f 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1604,6 +1604,24 @@ anv_image_hiz_clear(struct anv_cmd_buffer *cmd_buffer,
> ISL_AUX_USAGE_NONE, );
> }
>
> + /* From the Sky Lake PRM Volume 7, "Depth Buffer Clear":
> +*
> +*"The following is required when performing a depth buffer clear with
> +*using the WM_STATE or 3DSTATE_WM:
> +*
> +* * If other rendering operations have preceded this clear, a
> +* PIPE_CONTROL with depth cache flush enabled, Depth Stall bit
> +* enabled must be issued before the rectangle primitive used for
> +* the depth buffer clear operation.
> +* * [...]"
> +*
> +* Even though the PRM only says that this is required if using 3DSTATE_WM
> +* and a 3DPRIMITIVE, it appears to also sometimes hang when doing a clear
> +* with WM_HZ_OP.
^
This part was a little hard to parse because the PRM hasn't mentioned
the hardware hanging and the subject's changed from the pipecontrol to
the GPU. Maybe replace it with something like the following?
the GPU appears to also need this to avoid
occasional hangs when doing a clear with
WM_HZ_OP.
We could discuss it more on IRC if you prefer.
With that changed, this patch is
Reviewed-by: Nanley Chery
> +*/
> + cmd_buffer->state.pending_pipe_bits |=
> + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
> +
> blorp_hiz_clear_depth_stencil(, , ,
> level, base_layer, layer_count,
> area.offset.x, area.offset.y,
> @@ -1618,18 +1636,22 @@ anv_image_hiz_clear(struct anv_cmd_buffer *cmd_buffer,
>
> /* From the SKL PRM, Depth Buffer Clear:
> *
> -* Depth Buffer Clear Workaround
> -* Depth buffer clear pass using any of the methods (WM_STATE, 3DSTATE_WM
> -* or 3DSTATE_WM_HZ_OP) must be followed by a PIPE_CONTROL command with
> -* DEPTH_STALL bit and Depth FLUSH bits “set” before starting to render.
> -* DepthStall and DepthFlush are not needed between consecutive depth
> clear
> -* passes nor is it required if the depth-clear pass was done with
> -* “full_surf_clear” bit set in the 3DSTATE_WM_HZ_OP.
> +*"Depth Buffer Clear Workaround
> +*
> +*Depth buffer clear pass using any of the methods (WM_STATE,
> +*3DSTATE_WM or 3DSTATE_WM_HZ_OP) must be followed by a PIPE_CONTROL
> +*command with DEPTH_STALL bit and Depth FLUSH bits “set” before
> +*starting to render. DepthStall and DepthFlush are not needed
> between
> +*consecutive depth clear passes nor is it required if the depth-clear
> +*pass was done with “full_surf_clear” bit set in the
> +*3DSTATE_WM_HZ_OP."
> +*
> +* Even though the PRM provides a bunch of conditions under which this is
> +* supposedly unnecessary, we choose to perform the flush unconditionally
> +* just to be safe.
> */
> - if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
> - cmd_buffer->state.pending_pipe_bits |=
> - ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
> - }
> + cmd_buffer->state.pending_pipe_bits |=
> + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
> }
>
> void
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] anv/blorp: Do more flushing around HiZ clears
We make the flush after a HiZ clear unconditional and add a flush/stall
before the clear as well.
Cc: mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107760
---
src/intel/vulkan/anv_blorp.c | 44 +++-
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 35b304f92b3..04bca4d261f 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1604,6 +1604,24 @@ anv_image_hiz_clear(struct anv_cmd_buffer *cmd_buffer,
ISL_AUX_USAGE_NONE, );
}
+ /* From the Sky Lake PRM Volume 7, "Depth Buffer Clear":
+*
+*"The following is required when performing a depth buffer clear with
+*using the WM_STATE or 3DSTATE_WM:
+*
+* * If other rendering operations have preceded this clear, a
+* PIPE_CONTROL with depth cache flush enabled, Depth Stall bit
+* enabled must be issued before the rectangle primitive used for
+* the depth buffer clear operation.
+* * [...]"
+*
+* Even though the PRM only says that this is required if using 3DSTATE_WM
+* and a 3DPRIMITIVE, it appears to also sometimes hang when doing a clear
+* with WM_HZ_OP.
+*/
+ cmd_buffer->state.pending_pipe_bits |=
+ ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
+
blorp_hiz_clear_depth_stencil(, , ,
level, base_layer, layer_count,
area.offset.x, area.offset.y,
@@ -1618,18 +1636,22 @@ anv_image_hiz_clear(struct anv_cmd_buffer *cmd_buffer,
/* From the SKL PRM, Depth Buffer Clear:
*
-* Depth Buffer Clear Workaround
-* Depth buffer clear pass using any of the methods (WM_STATE, 3DSTATE_WM
-* or 3DSTATE_WM_HZ_OP) must be followed by a PIPE_CONTROL command with
-* DEPTH_STALL bit and Depth FLUSH bits “set” before starting to render.
-* DepthStall and DepthFlush are not needed between consecutive depth clear
-* passes nor is it required if the depth-clear pass was done with
-* “full_surf_clear” bit set in the 3DSTATE_WM_HZ_OP.
+*"Depth Buffer Clear Workaround
+*
+*Depth buffer clear pass using any of the methods (WM_STATE,
+*3DSTATE_WM or 3DSTATE_WM_HZ_OP) must be followed by a PIPE_CONTROL
+*command with DEPTH_STALL bit and Depth FLUSH bits “set” before
+*starting to render. DepthStall and DepthFlush are not needed between
+*consecutive depth clear passes nor is it required if the depth-clear
+*pass was done with “full_surf_clear” bit set in the
+*3DSTATE_WM_HZ_OP."
+*
+* Even though the PRM provides a bunch of conditions under which this is
+* supposedly unnecessary, we choose to perform the flush unconditionally
+* just to be safe.
*/
- if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
- cmd_buffer->state.pending_pipe_bits |=
- ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
- }
+ cmd_buffer->state.pending_pipe_bits |=
+ ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT;
}
void
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/blorp: Emit depth flush and stall prior to HiZ clears
On Fri 31 Aug 2018, Jason Ekstrand wrote: > On Fri, Aug 31, 2018 at 4:35 PM Nanley Chery <[1]nanleych...@gmail.com> wrote: > > If that doesn't fix it, I think it'd be good to comment that we've > observed this pipecontrol be necessary for 3DSTATE_WM_HZ_OP. > > > I'm happy to add some comments. We just need to decide how big of a hammer > to > use. Like I said above, in GL we pull out a pretty big one. Speaking from prior experience, I support big flush hammers for hiz. When a gpu hang happens, it can be incredibly difficult to diagnose it as a hiz hang. It's better to prevent most of them with a large hammer rather than diagnose them individually and try to prevent them with several, single-focus tiny hammers. Considering the impact of a gpu hang on Chrome (the entire OS may use a single GL ctx, and for Vulkan it may do the same, using a small number of VkDevices), we should err on the side of avoiding the gpu hang rather than err on the side of "too many flushes are bad". ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/blorp: Emit depth flush and stall prior to HiZ clears
On Fri 31 Aug 2018, Jason Ekstrand wrote: > We had the flush/stall after the clear but missed the one that needs to > go before the clear. > > Cc: mesa-sta...@lists.freedesktop.org > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107760 > --- > src/intel/vulkan/anv_blorp.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c > index 3dfc8087630..532e8185c0e 100644 > --- a/src/intel/vulkan/anv_blorp.c > +++ b/src/intel/vulkan/anv_blorp.c > @@ -1605,6 +1605,16 @@ anv_image_hiz_clear(struct anv_cmd_buffer *cmd_buffer, > ISL_AUX_USAGE_NONE, ); > } > > + /* From the Sky Lake PRM Volume 7, "Depth Buffer Clear": > +* > +*"If other rendering operations have preceded this clear, a The hw spec is vague, in my opinion. Does this WA apply to only preceding "rendering operations" to *this* depth buffer? To *any* depth buffer? To *any* render target at all? And, does the hiz clear op reset the WA condition? That is, if two sucessive 3DPRIMITIVEs perform a hiz clear op, does the hw require the WA before the second one? After all, no true "rendering operations" occurred between the two. Ahh! Why does the specification fail to specify??? Anyway, I convinced myself that genX(blorp_exec) emits the requested bits before the problematic 3DPRIMITIVE. Reviewed-by: Chad Versace > +*PIPE_CONTROL with depth cache flush enabled, Depth Stall bit enabled > +*must be issued before the rectangle primitive used for the depth > +*buffer clear operation." > +*/ > + cmd_buffer->state.pending_pipe_bits |= > + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT; > + > blorp_hiz_clear_depth_stencil(, , , > level, base_layer, layer_count, > area.offset.x, area.offset.y, > -- > 2.17.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/blorp: Emit depth flush and stall prior to HiZ clears
On Fri, Aug 31, 2018 at 4:35 PM Nanley Chery wrote: > On Fri, Aug 31, 2018 at 04:04:22PM -0500, Jason Ekstrand wrote: > > We had the flush/stall after the clear but missed the one that needs to > > go before the clear. > > > > Does this fix the GPU Hang in DiRT 3? > It appears to mostly fix it, yes. The remaining hanging seems like it's maybe a kernel hang? > > Cc: mesa-sta...@lists.freedesktop.org > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107760 > > --- > > src/intel/vulkan/anv_blorp.c | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c > > index 3dfc8087630..532e8185c0e 100644 > > --- a/src/intel/vulkan/anv_blorp.c > > +++ b/src/intel/vulkan/anv_blorp.c > > @@ -1605,6 +1605,16 @@ anv_image_hiz_clear(struct anv_cmd_buffer > *cmd_buffer, > > ISL_AUX_USAGE_NONE, ); > > } > > > > + /* From the Sky Lake PRM Volume 7, "Depth Buffer Clear": > > +* > > +*"If other rendering operations have preceded this clear, a > > +*PIPE_CONTROL with depth cache flush enabled, Depth Stall bit > enabled > > +*must be issued before the rectangle primitive used for the > depth > > +*buffer clear operation." > > +*/ > > + cmd_buffer->state.pending_pipe_bits |= > > + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT; > > + > > The PRMs say this pipecontrol is needed only if you're doing a clear > with WM_STATE or 3DSTATE_WM. > It does seem to imply that, yes. In GL, we just pull out the big hammer and surrournd every HZ op with that pipe control on both ends regardless of what kind of HiZ op it is. I know I found cases in GL where these sorts of flushes are needed around ambiguates as well. > I wonder if we should be doing the pipecontrol that comes after > blorp_hiz_clear_depth_stencil() in the case of stencil-only HIZ clears > as well? > Probably? But I don't think that's related. The hang I observed was with a depth resolve immediately followed by a fast clear. > If that doesn't fix it, I think it'd be good to comment that we've > observed this pipecontrol be necessary for 3DSTATE_WM_HZ_OP. > I'm happy to add some comments. We just need to decide how big of a hammer to use. Like I said above, in GL we pull out a pretty big one. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/blorp: Emit depth flush and stall prior to HiZ clears
On Fri, Aug 31, 2018 at 04:04:22PM -0500, Jason Ekstrand wrote: > We had the flush/stall after the clear but missed the one that needs to > go before the clear. > Does this fix the GPU Hang in DiRT 3? > Cc: mesa-sta...@lists.freedesktop.org > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107760 > --- > src/intel/vulkan/anv_blorp.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c > index 3dfc8087630..532e8185c0e 100644 > --- a/src/intel/vulkan/anv_blorp.c > +++ b/src/intel/vulkan/anv_blorp.c > @@ -1605,6 +1605,16 @@ anv_image_hiz_clear(struct anv_cmd_buffer *cmd_buffer, > ISL_AUX_USAGE_NONE, ); > } > > + /* From the Sky Lake PRM Volume 7, "Depth Buffer Clear": > +* > +*"If other rendering operations have preceded this clear, a > +*PIPE_CONTROL with depth cache flush enabled, Depth Stall bit enabled > +*must be issued before the rectangle primitive used for the depth > +*buffer clear operation." > +*/ > + cmd_buffer->state.pending_pipe_bits |= > + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT; > + The PRMs say this pipecontrol is needed only if you're doing a clear with WM_STATE or 3DSTATE_WM. I wonder if we should be doing the pipecontrol that comes after blorp_hiz_clear_depth_stencil() in the case of stencil-only HIZ clears as well? If that doesn't fix it, I think it'd be good to comment that we've observed this pipecontrol be necessary for 3DSTATE_WM_HZ_OP. > blorp_hiz_clear_depth_stencil(, , , > level, base_layer, layer_count, > area.offset.x, area.offset.y, > -- > 2.17.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv/blorp: Emit depth flush and stall prior to HiZ clears
We had the flush/stall after the clear but missed the one that needs to go before the clear. Cc: mesa-sta...@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107760 --- src/intel/vulkan/anv_blorp.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c index 3dfc8087630..532e8185c0e 100644 --- a/src/intel/vulkan/anv_blorp.c +++ b/src/intel/vulkan/anv_blorp.c @@ -1605,6 +1605,16 @@ anv_image_hiz_clear(struct anv_cmd_buffer *cmd_buffer, ISL_AUX_USAGE_NONE, ); } + /* From the Sky Lake PRM Volume 7, "Depth Buffer Clear": +* +*"If other rendering operations have preceded this clear, a +*PIPE_CONTROL with depth cache flush enabled, Depth Stall bit enabled +*must be issued before the rectangle primitive used for the depth +*buffer clear operation." +*/ + cmd_buffer->state.pending_pipe_bits |= + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT; + blorp_hiz_clear_depth_stencil(, , , level, base_layer, layer_count, area.offset.x, area.offset.y, -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled
https://bugs.freedesktop.org/show_bug.cgi?id=10 Axel Davy changed: What|Removed |Added CC||s...@das-labor.org -- 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
Re: [Mesa-dev] [PATCH 3/3] intel: Introducing Whiskey Lake platform
On Fri, Aug 31, 2018 at 11:05:13AM +0100, Lionel Landwerlin wrote:
> On 30/08/2018 22:41, Rodrigo Vivi wrote:
> > Whiskey Lake uses the same gen graphics as Coffe Lake, including some
> > ids that were previously marked as reserved on Coffe Lake, but that
> > now are moved to WHL page.
> >
> > This follows the ids and approach used on kernel's commit
> > b9be78531d27 ("drm/i915/whl: Introducing Whiskey Lake platform")
> >
> > Cc: José Roberto de Souza
> > Cc: Anuj Phogat
> > Signed-off-by: Rodrigo Vivi
> > ---
> > include/pci_ids/i965_pci_ids.h | 10 +-
> > src/intel/compiler/test_eu_validate.cpp | 1 +
> > src/intel/dev/gen_device_info.c | 1 +
> > src/intel/tools/aubinator.c | 2 +-
> > 4 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> > index 4efac638e9..d151b3dd0e 100644
> > --- a/include/pci_ids/i965_pci_ids.h
> > +++ b/include/pci_ids/i965_pci_ids.h
> > @@ -170,8 +170,6 @@ CHIPSET(0x3185, glk_2x6, "Intel(R) UHD Graphics 600
> > (Geminilake 2x6)")
> > CHIPSET(0x3E90, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
> > CHIPSET(0x3E93, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
> > CHIPSET(0x3E99, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
> > -CHIPSET(0x3EA1, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
> > -CHIPSET(0x3EA4, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
> > CHIPSET(0x3E91, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
> > CHIPSET(0x3E92, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
> > CHIPSET(0x3E96, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
> > @@ -179,14 +177,16 @@ CHIPSET(0x3E98, cfl_gt2, "Intel(R) HD Graphics
> > (Coffeelake 3x8 GT2)")
> > CHIPSET(0x3E9A, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
> > CHIPSET(0x3E9B, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
> > CHIPSET(0x3E94, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
> > -CHIPSET(0x3EA0, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
> > -CHIPSET(0x3EA3, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
> > CHIPSET(0x3EA9, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
> > -CHIPSET(0x3EA2, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
> > CHIPSET(0x3EA5, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
> > CHIPSET(0x3EA6, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
> > CHIPSET(0x3EA7, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
> > CHIPSET(0x3EA8, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
> > +CHIPSET(0x3EA1, cfl_gt1, "Intel(R) HD Graphics (Whiskey Lake 2x6 GT1)")
> > +CHIPSET(0x3EA0, cfl_gt2, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT2)")
> > +CHIPSET(0x3EA2, cfl_gt3, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT3)")
> > +CHIPSET(0x3EA3, cfl_gt3, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT3)")
> > +CHIPSET(0x3EA4, cfl_gt3, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT3)")
>
>
> Documentation says 0x3EA3 has only 12 EUs. Doesn't sound like GT3.
Yeap, it seems a spec bug that got propagated to kernel and luckly you caught
here:
U42 24 3EA0
U41f12 3EA1
U43 48 3EA2
U43 24 3EA3
U43 12 3EA4
I will file an issue there and update this one later...
But I will push the first 2 patches because on second one there is a missed id.
Thanks for reviewing it.
>
>
> > CHIPSET(0x5A49, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)")
> > CHIPSET(0x5A4A, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)")
> > CHIPSET(0x5A41, cnl_3x8, "Intel(R) HD Graphics (Cannonlake 3x8 GT1)")
> > diff --git a/src/intel/compiler/test_eu_validate.cpp
> > b/src/intel/compiler/test_eu_validate.cpp
> > index 744ae5806d..73300b2312 100644
> > --- a/src/intel/compiler/test_eu_validate.cpp
> > +++ b/src/intel/compiler/test_eu_validate.cpp
> > @@ -43,6 +43,7 @@ static const struct gen_info {
> > { "aml", },
> > { "glk", },
> > { "cfl", },
> > + { "whl", },
> > { "cnl", },
> > { "icl", },
> > };
> > diff --git a/src/intel/dev/gen_device_info.c
> > b/src/intel/dev/gen_device_info.c
> > index 3cece52a04..0f12d17a84 100644
> > --- a/src/intel/dev/gen_device_info.c
> > +++ b/src/intel/dev/gen_device_info.c
> > @@ -60,6 +60,7 @@ gen_device_name_to_pci_device_id(const char *name)
> > { "aml", 0x591C },
> > { "glk", 0x3185 },
> > { "cfl", 0x3E9B },
> > + { "whl", 0x3EA1 },
> > { "cnl", 0x5a52 },
> > { "icl", 0x8a52 },
> > };
> > diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> > index 55672fa073..7de20f3d7a 100644
> > --- a/src/intel/tools/aubinator.c
> > +++ b/src/intel/tools/aubinator.c
> > @@ -282,7 +282,7 @@ int main(int argc, char *argv[])
> >if (id < 0) {
> > fprintf(stderr, "can't parse gen: '%s', expected brw, g4x,
> >
[Mesa-dev] [Bug 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #1 from Axel Davy --- Thank you for this bug report, A similar issue for this game was reported long ago here: https://github.com/iXit/Mesa-3D/issues/101 I had hoped it had been fixed since, but apparently not. If you click something of the invisible menu, do you have this error shown in the console: err:d3dadapter:PRESENTPixmap FATAL ERROR: Trying to Present a pixmap not released If you parameter the game to launch windowed, do you have the same issues ? -- 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] [ANNOUNCE] mesa 18.2.0-rc5
Hi Andres, The final blockers have been resolved. You should be able to make an RC that passes all Intel validation, if you pick up: 904c2a617d8 * i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on some gen9 d9cf4308cee * i965/screen: Allow modifiers on sRGB formats Looking forward to the release, -Mark Andres Gomez writes: > Hello list, > > The fifth release candidate for the Mesa 18.2.0 is now available. > > As per the issue tracker [1] we still have a number of outstanding bugs > blocking the release. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=107457 > > Currently we have: > - 23 queued > - 11 nominated (outstanding) > - and 0 rejected patches > > > We have in the queue: > > In Mesa Core we have included a correction to actually expose the > GL_EXT_robustness extension for GLES. > > The GLSL compiler has received a fix preventing an incorrect linking > error when having allowed unused in blocks with not corresponding out > blocks in the previous stage. Also, its tests have been made sure that > they should be executed from the build system check target or, at the > very least, with an explicitly versioned python executable. > > AMD's drivers have received multiple fixes, including one to correct > some rendering with radv for Super Mario Sunshine with the Dolphin > emulator and another one detected due to a segmentation fault in Rise > of the Tomb Raider. > > Intel's drivers have also received multiple fixes, including one to > correct a GPU hang in DOOM 2016 running under wine. > > The documentation has also gotten a couple of fixes, to note 0.8.0 as > the minimum required mako version, and to add 3 more features into the > 18.2's release notes. > > Finally, from build and integration point of view, we have multiple > fixes for meson, correcting EGL's compilation, making the GLSL tests to > explicitly run with python, and to actually load translation files. > > > Take a look at section "Mesa stable queue" for more information. > > > Testing reports/general approval > > > Any testing reports (or general approval of the state of the branch) > will be greatly appreciated. > > The plan is to have the sixth release candidate for 18.2.0 next > Wednesday (2018/09/05), around or shortly after 18:00 EEST. > > If you have any questions or suggestions - be that about the current > patch queue or otherwise, please go ahead. > > > Trivial merge conflicts > --- > > commit f958837964784315c1dc633f41f1ef5d2a17aea9 > Author: Dylan Baker > > meson: Actually load translation files > > (cherry picked from commit 7c00db9527245d80cb748ec3442163585a5463a6) > > commit f6dccf66865c31b13f48b50891a9f5a0d9949b1c > Author: Emil Velikov > > glsl: remove execute bit and shebang from python tests > > (cherry picked from commit 48820ed8da0ad50d51a58f26e156d82b685492e2) > > > Br, > Andres > > > Mesa stable queue > - > > Nominated (11) > == > > Andrii Simiklit (1): > 1b0df8a4602 i965/gen6/xfb: handle case where transform feedback is not > active > > Bas Nieuwenhuizen (1): > 4738b6ac814 radv: Add missing checks in > radv_get_image_format_properties. > > Jason Ekstrand (6): > 4ffb575da59 vulkan/alloc: Add a vk_strdup helper > 8c048af5890 anv: Copy the appliation info into the instance > c92a463d234 anv: Claim to support depthBounds for ID games > cdea5d996ed anv: Free the app and engine name > 116b47fe3c0 nir/algebraic: Be more careful converting ushr to > extract_u8/16 > 7cdf8f93390 nir/format_convert: Fix a bitmask in unpack_11f11f10f > > Lionel Landwerlin (1): > 5a1c23d1502 anv: blorp: support multiple aspect blits > > Marek Olšák (1): > 1e40f694831 ac/surface: fix CMASK fast clear for NPOT textures with > mipmapping on SI/CI/VI > > Tapani Pälli (1): > a72dbc461bd mesa: allow GL_UNSIGNED_BYTE type for SNORM reads > > > Queued (23) > === > > Andres Gomez (1): > Update version to 18.2.0-rc5 > > Dylan Baker (1): > meson: Actually load translation files > > Emil Velikov (2): > docs: update required mako version > glsl: remove execute bit and shebang from python tests > > Grazvydas Ignotas (1): > radv: place pointer length into cache uuid > > Gurchetan Singh (2): > meson: fix egl build for surfaceless > meson: fix egl build for android > > Jason Ekstrand (4): > anv: Fill holes in the VF VUE to zero > intel/decoder: Clean up field iteration and fix sub-dword fields > intel/batch_decoder: Fix dynamic state printing > intel/batch_decoder: Print blend states properly > > Lionel Landwerlin (2): > intel: decoder: unify MI_BB_START field naming > intel: decoder: handle 0 sized structs > > Marek Olšák (2): > ac: completely remove +auto-waitcnt-before-barrier > glapi: actually implement GL_EXT_robustness for GLES >
[Mesa-dev] [Bug 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled
https://bugs.freedesktop.org/show_bug.cgi?id=10 Bug ID: 10 Summary: No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled Product: Mesa Version: 18.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Gallium/StateTracker/galliumnine Assignee: mesa-dev@lists.freedesktop.org Reporter: infer...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 141398 --> https://bugs.freedesktop.org/attachment.cgi?id=141398=edit Resolution issue. Also no HUD displayed. Using wine from https://launchpad.net/~commendsarnex/+archive/ubuntu/winedri3 on empty profile. With gallium nine off game (GOG version) runs just fine. But there is at least 2 faults when nine enabled: 1. After opening videos shown there it no any menus - just black screen keeping last frame of the last video. 2. Running in fullscreen mode, but resolution don't changed - all videos showed in top-left corner of main screen (see attachment). no any special errors in wine output. Tried with mesa 18.05 and 18.2-rc5 Tried some debug: env GALLIUM_HUD="fps,requested-VRAM" LIBGL_DEBUG=verbose GALLIUM_PRINT_OPTIONS=1 ST_DEBUG=constants EGL_LOG_LEVEL=debug MESA_DEBUG=1 WINEDEBUG="-all" WINEPREFIX="/tmp/empty" WINE=/opt/wine-d3d9-staging/bin/wine /opt/wine-d3d9-staging/bin/wine vampire.exe Got: /usr/share/libdrm/amdgpu.ids version: 1.0.0 libGL: pci id for fd 78: 1002:67ff, driver radeonsi libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/tls/radeonsi_dri.so libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so mesa: for the -simplifycfg-sink-common option: may only occur zero or one times! mesa: for the -global-isel-abort option: may only occur zero or one times! libGL: Using DRI3 for screen 0 and screenshot in attachment. Also filed bug here https://bugs.winehq.org/show_bug.cgi?id=45745 -- 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] shader cache backward compatibility
On Fri, Aug 31, 2018 at 4:05 PM Emil Velikov wrote:
>
> On 31 August 2018 at 14:36, Timothy Arceri wrote:
> > On 31/08/18 21:07, Emil Velikov wrote:
> >>
> >> On 31 August 2018 at 11:37, Timothy Arceri wrote:
> >>>
> >>> On 31/08/18 20:10, Emil Velikov wrote:
>
>
> Hi Timothy,
>
> On 31 August 2018 at 10:57, Timothy Arceri
> wrote:
> >
> >
> > On 31/08/18 19:40, Bas Nieuwenhuizen wrote:
> >>
> >>
> >>
> >> +TImothy
> >>
> >> On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson
> >> wrote:
> >>>
> >>>
> >>>
> >>>
> >>> Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've
> >>> recently run into some issues with the mesa shader cache. Flatpak has
> >>> a app/runtime split where the runtime is shared between app and
> >>> provides /usr. The runtime contains a version of mesa, but this can
> >>> be
> >>> overridden by runtime extensions to add other OpenGL drivers.
> >>>
> >>> Each app has a separate $XDG_CACHE_HOME, pointing into the per-app
> >>> writable storage. For example, gedit has
> >>> XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This
> >>> causes mesa to store the shader cache per-app in
> >>> $XDG_CACHE_HOME/mesa_shader_cache.
> >>>
> >>> In the regular case this works fine, but sometimes the version of
> >>> mesa
> >>> is changed, with the shader cache being left in place. For example,
> >>> sometimes we update the mesa version in the runtime, and sometimes
> >>> the
> >>> app switches to a new runtime which has a different mesa version.
> >>>
> >>> Such updates have caused a lot of issues for us, ranging from direct
> >>> crashes at startup as in
> >>> https://github.com/flatpak/flatpak/issues/2052 and sometimes just
> >>> super-slow performance. In all cases, blowing away the shader cache
> >>> directory fixed all issues.
> >>>
> >>> The steam flatpak has a bunch of workaround for the cache:
> >>>
> >>>
> >>>
> >>> https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35
> >>> But we can't expect every app to do this.
> >>>
> >>> So, my question is, is the cache supposed to be backward compatible,
> >>> or at least versioned? Are we missing something in our mesa builds to
> >>> make that work? Is this fixed somewhere with a patch i can backport?
> >>> And if not, do we need to add some magic to flatpak to automatically
> >>> clean up the shader cache after an update?
> >>
> >>
> >>
> >>
> >> It is supposed to be versioned automatically by mesa.
> >>
> >
> > Hi Alexander,
> >
> > We depend on build timestamps of the mesa/llvm binaries when generating
> > the
> > sha for cache items. So if flatpak results in two versions of mesa
> > having
> > the same timestamp then there is likely going to be issues.
> >
> > static inline bool
> > disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
> > {
> > Dl_info info;
> > struct stat st;
> > if (!dladdr(ptr, ) || !info.dli_fname) {
> > return false;
> > }
> > if (stat(info.dli_fname, )) {
> > return false;
> > }
> > *timestamp = st.st_mtime;
> > return true;
> > }
> >
> Have you tried using the build-id from src/util/build_id.c?
>
> >>>
> >>> Hi Emil,
> >>>
> >>> Honestly I've got no idea what that code does. Maybe someone who does
> >>> could
> >>> write patches to switch to it along with an explanation of why its
> >>> better.
> >>> Even just adding some comments in that file would be helpful.
> >>>
> >>> I don't want to be the one responsible for it (and any new issues with
> >>> the
> >>> cache) when I'm not aware of how it works :(
> >>>
> >> In a few words - retrieves the unique, in our case sha1, for the
> >> binary. Any change in Mesa source will lead to a different build-id.
> >> The SO thread has longer/better explanation [1]. You can skim through
> >> git log for details and poke contributors with specific questions.
> >
> >
> > Hmm, I think part of the reason we never did this is that we need and id for
> > llvm also.
> >
> Valid point - I forgot about that.
Did we actually check that it typically does not in typical situations?
One reason we use this in radv was because I did not about build-id
then and we had this before Intel implemented the build-id solution.
I suppose I can use the build-id and fallback to time if not available.
>
> A couple of ideas come to mind:
> - static link LLVM (Flatpak already does it)
> No LLVM changes needed.
>
> - shared link LLVM
> LLVM add -Wl,--build-id=sha1
>
> In both cases Mesa will need something like
> s/disk_cache_get_function_timestamp/build_id_find_nhdr_for_addr/
>
> HTH
> Emil
Re: [Mesa-dev] [PATCH 5/7] gallium: add PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER{S, _BUFFERS}
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
>
> This moves the evergreen-specific max-sizes out as a driver-cap, so
> other drivers with less strict requirements also can use hw-atomics.
>
> Remove ssbo_atomic as it's no longer needed.
>
> We should now be able to use hw-atomics for some stages and not for
> other, if needed.
>
> Signed-off-by: Erik Faye-Lund
> ---
> src/gallium/drivers/etnaviv/etnaviv_screen.c | 5 +
> .../drivers/freedreno/freedreno_screen.c | 5 +
> .../drivers/nouveau/nv30/nv30_screen.c| 2 ++
> .../drivers/nouveau/nv50/nv50_screen.c| 2 ++
> .../drivers/nouveau/nvc0/nvc0_screen.c| 2 ++
> src/gallium/drivers/r300/r300_screen.c| 2 ++
> src/gallium/drivers/r600/r600_pipe.c | 9 +
> src/gallium/drivers/radeonsi/si_get.c | 2 ++
> src/gallium/drivers/svga/svga_screen.c| 2 ++
> src/gallium/drivers/v3d/v3d_screen.c | 2 ++
> src/gallium/drivers/vc4/vc4_screen.c | 2 ++
> src/gallium/drivers/virgl/virgl_screen.c | 2 ++
> src/gallium/include/pipe/p_defines.h | 2 ++
> src/mesa/state_tracker/st_extensions.c| 20 +--
> 14 files changed, 49 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index 108b97d35c..95166a2db1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -372,6 +372,11 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
>return 0;
> case PIPE_CAP_UMA:
>return 1;
> +
> + /* hw atomic counters */
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
> + return 0;
> }
>
> debug_printf("unknown param %d", param);
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index af44ab698e..e6dfc2e48e 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -491,6 +491,11 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
> return 1;
> case PIPE_CAP_NATIVE_FENCE_FD:
> return fd_device_version(screen->dev) >= FD_VERSION_FENCE_FD;
> +
> + /* hw atomic counters */
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
> + return 0;
> }
> debug_printf("unknown param %d\n", param);
> return 0;
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> index d52d8f3988..3fdbadb6c6 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -239,6 +239,8 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
> case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE:
> case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS:
> case PIPE_CAP_PROGRAMMABLE_SAMPLE_LOCATIONS:
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
>
> case PIPE_CAP_MAX_GS_INVOCATIONS:
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> index cd36795e56..a6dda5dfa0 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
> @@ -293,6 +293,8 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
> case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE:
> case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS:
> case PIPE_CAP_PROGRAMMABLE_SAMPLE_LOCATIONS:
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
>
> case PIPE_CAP_MAX_GS_INVOCATIONS:
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> index 446e30dcc8..b628b24d76 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> @@ -322,6 +322,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
> case PIPE_CAP_CONSTBUF0_FLAGS:
> case PIPE_CAP_PACKED_UNIFORMS:
> case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES:
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
> + case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
>
> case PIPE_CAP_VENDOR_ID:
> diff --git a/src/gallium/drivers/r300/r300_screen.c
> b/src/gallium/drivers/r300/r300_screen.c
> index d27c2b8f1d..f29d5244ff 100644
> --- a/src/gallium/drivers/r300/r300_screen.c
> +++
Re: [Mesa-dev] [PATCH 7/7] virgl: use hw-atomics instead of in-ssbo ones
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
>
> From: Tomeu Vizoso
>
> Emulating atomics on top of ssbos can lead to too small max SSBO count,
> so let's use the hw-atomics mechanism to expose atomic buffers instead.
>
> Signed-off-by: Erik Faye-Lund
> ---
> src/gallium/drivers/virgl/virgl_context.c | 37 ++
> src/gallium/drivers/virgl/virgl_context.h | 2 ++
> src/gallium/drivers/virgl/virgl_encode.c | 23 ++
> src/gallium/drivers/virgl/virgl_encode.h | 3 ++
> src/gallium/drivers/virgl/virgl_hw.h | 5 +++
> src/gallium/drivers/virgl/virgl_protocol.h | 9 ++
> src/gallium/drivers/virgl/virgl_screen.c | 14 +---
> 7 files changed, 88 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.c
> b/src/gallium/drivers/virgl/virgl_context.c
> index edc03f5dcf..30cd0e4331 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -196,6 +196,19 @@ static void virgl_attach_res_shader_images(struct
> virgl_context *vctx,
> }
> }
>
> +static void virgl_attach_res_atomic_buffers(struct virgl_context *vctx)
> +{
> + struct virgl_winsys *vws = virgl_screen(vctx->base.screen)->vws;
> + struct virgl_resource *res;
> + unsigned i;
> + for (i = 0; i < PIPE_MAX_SHADER_BUFFERS; i++) {
Why not PIPE_MAX_HW_ATOMIC_BUFFERS?
> + res = virgl_resource(vctx->atomic_buffers[i]);
> + if (res) {
> + vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
> + }
> + }
> +}
> +
> /*
> * after flushing, the hw context still has a bunch of
> * resources bound, so we need to rebind those here.
> @@ -214,6 +227,7 @@ static void virgl_reemit_res(struct virgl_context *vctx)
>virgl_attach_res_shader_buffers(vctx, shader_type);
>virgl_attach_res_shader_images(vctx, shader_type);
> }
> + virgl_attach_res_atomic_buffers(vctx);
> virgl_attach_res_vertex_buffers(vctx);
> virgl_attach_res_so_targets(vctx);
> }
> @@ -952,6 +966,28 @@ static void virgl_blit(struct pipe_context *ctx,
> blit);
> }
>
> +static void virgl_set_hw_atomic_buffers(struct pipe_context *ctx,
> + unsigned start_slot,
> + unsigned count,
> + const struct pipe_shader_buffer
> *buffers)
nit: mixing tabs and spaces
> +{
> + struct virgl_context *vctx = virgl_context(ctx);
> +
> + for (unsigned i = 0; i < count; i++) {
> + unsigned idx = start_slot + i;
> +
> + if (buffers) {
> + if (buffers[i].buffer) {
> +pipe_resource_reference(>atomic_buffers[idx],
> +buffers[i].buffer);
> +continue;
> + }
> + }
> + pipe_resource_reference(>atomic_buffers[idx], NULL);
> + }
> + virgl_encode_set_hw_atomic_buffers(vctx, start_slot, count, buffers);
> +}
> +
> static void virgl_set_shader_buffers(struct pipe_context *ctx,
> enum pipe_shader_type shader,
> unsigned start_slot, unsigned count,
> @@ -1209,6 +1245,7 @@ struct pipe_context *virgl_context_create(struct
> pipe_screen *pscreen,
> vctx->base.blit = virgl_blit;
>
> vctx->base.set_shader_buffers = virgl_set_shader_buffers;
> + vctx->base.set_hw_atomic_buffers = virgl_set_hw_atomic_buffers;
> vctx->base.set_shader_images = virgl_set_shader_images;
> vctx->base.memory_barrier = virgl_memory_barrier;
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.h
> b/src/gallium/drivers/virgl/virgl_context.h
> index 38d1f450e1..20988baa3c 100644
> --- a/src/gallium/drivers/virgl/virgl_context.h
> +++ b/src/gallium/drivers/virgl/virgl_context.h
> @@ -75,6 +75,8 @@ struct virgl_context {
> int num_draws;
> struct list_head to_flush_bufs;
>
> + struct pipe_resource *atomic_buffers[PIPE_MAX_HW_ATOMIC_BUFFERS];
> +
> struct primconvert_context *primconvert;
> uint32_t hw_sub_ctx_id;
> };
> diff --git a/src/gallium/drivers/virgl/virgl_encode.c
> b/src/gallium/drivers/virgl/virgl_encode.c
> index bcb14d8939..c9cc099061 100644
> --- a/src/gallium/drivers/virgl/virgl_encode.c
> +++ b/src/gallium/drivers/virgl/virgl_encode.c
> @@ -958,6 +958,29 @@ int virgl_encode_set_shader_buffers(struct virgl_context
> *ctx,
> return 0;
> }
>
> +int virgl_encode_set_hw_atomic_buffers(struct virgl_context *ctx,
> + unsigned start_slot, unsigned count,
> + const struct pipe_shader_buffer
> *buffers)
> +{
> + int i;
> + virgl_encoder_write_cmd_dword(ctx,
> VIRGL_CMD0(VIRGL_CCMD_SET_ATOMIC_BUFFERS, 0,
> VIRGL_SET_ATOMIC_BUFFER_SIZE(count)));
> +
> + virgl_encoder_write_dword(ctx->cbuf, start_slot);
> + for (i = 0; i < count; i++) {
> + if (buffers) {
> +struct virgl_resource *res =
[Mesa-dev] [PATCH v2] egl/android: rework device probing
From: Emil Velikov
Unlike the other platforms, here we aim do guess if the device that we
somewhat arbitrarily picked, is supported or not.
In particular: when a vendor is _not_ requested we loop through all
devices, picking the first one which can create a DRI screen.
When a vendor is requested - we use that and do _not_ fall-back to any
other device.
The former seems a bit fiddly, but considering EGL_EXT_explicit_device and
EGL_MESA_query_renderer are MIA, this is the best we can do for the
moment.
With those (proposed) extensions userspace will be able to create a
separate EGL display for each device, query device details and make the
conscious decision which one to use.
v2:
- update droid_open_device_drm_gralloc()
- set the dri2_dpy->fd before using it
- return a EGLBoolean for droid_{probe,open}_device*
- do not warn on droid_load_driver failure (Tomasz)
- plug mem leak on dri2_create_screen failure (Tomasz)
- fixup function name typo (Tomasz, Rob)
Cc: Robert Foss
Cc: Tomasz Figa
Cc: Mauro Rossi
Signed-off-by: Emil Velikov
---
Rob, I choose not to keep your r-b since the patch has changed quite a
bit.
Mauro, please check that this version doesn't break the drm_gralloc case.
Thanks
Emil
---
src/egl/drivers/dri2/platform_android.c | 116 +++-
1 file changed, 73 insertions(+), 43 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index 1f9fe27ab85..0586633a6db 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1203,9 +1203,10 @@ droid_add_configs_for_visuals(_EGLDriver *drv,
_EGLDisplay *dpy)
}
#ifdef HAVE_DRM_GRALLOC
-static int
-droid_open_device_drm_gralloc(struct dri2_egl_display *dri2_dpy)
+static EGLBoolean
+droid_open_device_drm_gralloc(_EGLDisplay *disp)
{
+ struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
int fd = -1, err = -EINVAL;
if (dri2_dpy->gralloc->perform)
@@ -1214,10 +1215,13 @@ droid_open_device_drm_gralloc(struct dri2_egl_display
*dri2_dpy)
);
if (err || fd < 0) {
_eglLog(_EGL_WARNING, "fail to get drm fd");
- fd = -1;
+ return EGL_FALSE;
}
- return (fd >= 0) ? fcntl(fd, F_DUPFD_CLOEXEC, 3) : -1;
+ if (dri2_dpy->fd = fcntl(fd, F_DUPFD_CLOEXEC, 3) < 0)
+ return EGL_FALSE;
+
+ return droid_probe_device(disp);
}
#endif /* HAVE_DRM_GRALLOC */
@@ -1365,7 +1369,7 @@ static const __DRIextension
*droid_image_loader_extensions[] = {
EGLBoolean
droid_load_driver(_EGLDisplay *disp)
{
- struct dri2_egl_display *dri2_dpy = disp->DriverData;
+ struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
const char *err;
dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
@@ -1404,6 +1408,17 @@ error:
return false;
}
+static void
+droid_unload_driver(_EGLDisplay *disp)
+{
+ struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+
+ dlclose(dri2_dpy->driver);
+ dri2_dpy->driver = NULL;
+ free(dri2_dpy->driver_name);
+ dri2_dpy->driver_name = NULL;
+}
+
static int
droid_filter_device(_EGLDisplay *disp, int fd, const char *vendor)
{
@@ -1420,13 +1435,31 @@ droid_filter_device(_EGLDisplay *disp, int fd, const
char *vendor)
return 0;
}
-static int
+static EGLBoolean
+droid_probe_device(_EGLDisplay *disp)
+{
+ /* Check that the device is supported, by attempting to:
+ * - load the dri module
+ * - and, create a screen
+ */
+ if (!droid_load_driver(disp))
+ return EGL_FALSE;
+
+ if (!dri2_create_screen(disp)) {
+ _eglLog(_EGL_WARNING, "DRI2: failed to create screen");
+ droid_unload_driver(disp);
+ return EGL_FALSE;
+ }
+ return EGL_TRUE;
+}
+
+static EGLBoolean
droid_open_device(_EGLDisplay *disp)
{
#define MAX_DRM_DEVICES 32
+ struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
int prop_set, num_devices;
- int fd = -1, fallback_fd = -1;
char *vendor_name = NULL;
char vendor_buf[PROPERTY_VALUE_MAX];
@@ -1436,7 +1469,7 @@ droid_open_device(_EGLDisplay *disp)
num_devices = drmGetDevices2(0, devices, ARRAY_SIZE(devices));
if (num_devices < 0)
- return num_devices;
+ return EGL_FALSE;
for (int i = 0; i < num_devices; i++) {
device = devices[i];
@@ -1444,41 +1477,49 @@ droid_open_device(_EGLDisplay *disp)
if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
continue;
- fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
- if (fd < 0) {
+ dri2_dpy->fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
+ if (dri2_dpy->fd < 0) {
_eglLog(_EGL_WARNING, "%s() Failed to open DRM device %s",
__func__, device->nodes[DRM_NODE_RENDER]);
continue;
}
- if (vendor_name && droid_filter_device(disp, fd, vendor_name)) {
- /* Match
Re: [Mesa-dev] [PATCH] st/dri: Don't expose sRGB formats to clients
This is basically what we do in i965 only we support two SRGB formats.
Acked-by: Jason Ekstrand
On Fri, Aug 31, 2018 at 11:37 AM Daniel Stone wrote:
> Though the SARGB format is used internally through its FourCC value,
> it is not a real format as defined by drm_fourcc.h; it cannot be used
> with KMS or other interfaces expecting drm_fourcc.h format codes.
>
> Ensure we don't advertise it through the dmabuf format/modifier query
> interfaces, preventing us from tripping over an assert.
>
> Signed-off-by: Daniel Stone
> Reported-by: Michel Dänzer
> Fixes: 8c1b9882b2e0 ("egl/dri2: Guard against invalid fourcc formats")
> Cc: Jason Ekstrand
> ---
> src/gallium/state_trackers/dri/dri2.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c
> b/src/gallium/state_trackers/dri/dri2.c
> index 2ac32205d9a..c8a484e3926 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -1485,6 +1485,12 @@ dri2_query_dma_buf_formats(__DRIscreen *_screen,
> int max, int *formats,
>
> for (i = 0, j = 0; (i < ARRAY_SIZE(fourcc_formats)) &&
> (j < max || max == 0); i++) {
> + /* The sRGB format is not a real FourCC as defined by drm_fourcc.h,
> so we
> + * must not leak it out to clients.
> + */
> + if (fourcc_formats[i] == __DRI_IMAGE_FOURCC_SARGB)
> + continue;
> +
>if (pscreen->is_format_supported(pscreen,
> fourcc_to_pipe_format(
>fourcc_formats[i]),
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/dri: Don't expose sRGB formats to clients
Though the SARGB format is used internally through its FourCC value,
it is not a real format as defined by drm_fourcc.h; it cannot be used
with KMS or other interfaces expecting drm_fourcc.h format codes.
Ensure we don't advertise it through the dmabuf format/modifier query
interfaces, preventing us from tripping over an assert.
Signed-off-by: Daniel Stone
Reported-by: Michel Dänzer
Fixes: 8c1b9882b2e0 ("egl/dri2: Guard against invalid fourcc formats")
Cc: Jason Ekstrand
---
src/gallium/state_trackers/dri/dri2.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index 2ac32205d9a..c8a484e3926 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1485,6 +1485,12 @@ dri2_query_dma_buf_formats(__DRIscreen *_screen, int
max, int *formats,
for (i = 0, j = 0; (i < ARRAY_SIZE(fourcc_formats)) &&
(j < max || max == 0); i++) {
+ /* The sRGB format is not a real FourCC as defined by drm_fourcc.h, so we
+ * must not leak it out to clients.
+ */
+ if (fourcc_formats[i] == __DRI_IMAGE_FOURCC_SARGB)
+ continue;
+
if (pscreen->is_format_supported(pscreen,
fourcc_to_pipe_format(
fourcc_formats[i]),
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Bounding box avx2 intrinsic algorithm for openGL/GLES
Hi, On 31.08.2018 08:25, kedar.j.kara...@intel.com wrote: From: "J Karanje, Kedar" The feature is enabled by default during make however we need to add the following to drirc to enable the feature at runtime. vbo: Main algorithm & code to check for MVP & vertex position location Build Files: Flags to enable BBOX Code and check AVX version compiler: Code to recognize simple shader (gl_position is a simple function of mvp and vertex) i965 & util: dri query to check if feature is enabled vbo: Implements a bounding box algorithm for mesa,we hook into the default drawelements and drawrangelements and the MVP & vertex positions location and the corresponding program is got,we re-create the frustum planes using this data and also create a box around the object and use the 8 vertices (box vertices) and check if the box is within the frustum or not, we drop the draw calls that are completely outside the view frustum and go for sub-boxes for objects that are intersecting with the frustum planes. The current patch has been verified on KBL+Ubuntu 16.04, we noticed 8~10% improvements in GFxBench TREX offscreen and ~2% for Manhattan offscreen, Platforms where avx2 is not supported shall still see ~6-8% improvement, the other KPIs were not impacted. I've tried this with Egypt and T-Rex on KBL GT3e, and I'm not seeing a performance difference. What I'm missing / what exactly I should do to get it enabled, see that it's enabled, and to see the perf difference? Based on empirical data we have set minimum vertex count as 999 and the sub-box size as 198, this provides the best results, we have also implemented some level of caching for the box co-od and frustum plane co-od. we have also optimized some algorithms to use avx2 when a target supports it. Shader classification code is currently in hir and we have got review comments to move the same to NIR. Signed-off-by: Aravindan Muthukumar Signed-off-by: Yogesh Marathe --- Android.common.mk| 19 + configure.ac | 34 +- src/compiler/glsl/ast_to_hir.cpp | 168 +++- src/compiler/glsl/glsl_parser_extras.cpp | 10 + src/compiler/glsl/glsl_parser_extras.h |7 + src/compiler/glsl/linker.cpp | 18 + src/intel/common/gen_debug.c |7 + src/mesa/Makefile.sources| 11 + src/mesa/drivers/dri/i965/brw_context.c | 17 + src/mesa/drivers/dri/i965/intel_screen.c |4 + src/mesa/main/bufferobj.c| 19 + src/mesa/main/mtypes.h | 51 + src/mesa/program/Android.mk |1 + src/mesa/program/program.c |3 + src/mesa/vbo/vbo_bbox.c | 1538 ++ src/mesa/vbo/vbo_bbox.h | 383 src/mesa/vbo/vbo_bbox_cache.c| 195 src/mesa/vbo/vbo_context.c | 11 +- src/mesa/vbo/vbo_exec_array.c| 37 +- src/util/00-mesa-defaults.conf |4 + src/util/xmlpool/t_options.h |5 + 21 files changed, 2535 insertions(+), 7 deletions(-) mode change 100644 => 100755 src/compiler/glsl/ast_to_hir.cpp create mode 100644 src/mesa/vbo/vbo_bbox.c create mode 100644 src/mesa/vbo/vbo_bbox.h create mode 100644 src/mesa/vbo/vbo_bbox_cache.c diff --git a/Android.common.mk b/Android.common.mk index aa1b266..efd6792 100644 --- a/Android.common.mk +++ b/Android.common.mk @@ -21,6 +21,8 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER # DEALINGS IN THE SOFTWARE. +MESA_BBOX_ENABLE=true + ifeq ($(LOCAL_IS_HOST_MODULE),true) LOCAL_CFLAGS += -D_GNU_SOURCE endif @@ -80,6 +82,10 @@ LOCAL_CFLAGS += \ -fno-trapping-math \ -Wno-sign-compare +ifeq ($(MESA_BBOX_ENABLE),true) +LOCAL_CFLAGS += -DMESA_BBOX_OPT +endif + LOCAL_CPPFLAGS += \ -D__STDC_CONSTANT_MACROS \ -D__STDC_FORMAT_MACROS \ @@ -87,6 +93,10 @@ LOCAL_CPPFLAGS += \ -Wno-error=non-virtual-dtor \ -Wno-non-virtual-dtor +ifeq ($(MESA_BBOX_ENABLE),true) +LOCAL_CPPFLAGS += -DMESA_BBOX_OPT +endif + # mesa requires at least c99 compiler LOCAL_CONLYFLAGS += \ -std=c99 @@ -98,6 +108,15 @@ ifeq ($(filter 5 6 7 8 9, $(MESA_ANDROID_MAJOR_VERSION)),) LOCAL_CFLAGS += -DHAVE_TIMESPEC_GET endif +ifeq ($(MESA_BBOX_ENABLE),true) +#if defined(CONFIG_AS_AVX) +LOCAL_CONLYFLAGS += -mavx +#elif +LOCAL_CONLYFLAGS += -msse4.1 +#endif +endif + + ifeq ($(strip $(MESA_ENABLE_ASM)),true) ifeq ($(TARGET_ARCH),x86) LOCAL_CFLAGS += \ diff --git a/configure.ac b/configure.ac index 4d9d9e5..dcdbcf3 100644 --- a/configure.ac +++ b/configure.ac @@ -278,7 +278,8 @@ _SAVE_LDFLAGS="$LDFLAGS" _SAVE_CPPFLAGS="$CPPFLAGS" dnl Compiler macros -DEFINES="-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS" +DEFINES="-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
[Mesa-dev] [Bug 107772] Mesa preprocessor matches if(def)s & endifs incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=107772 Mark Janes changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |t_arc...@yahoo.com.au |org | Status|NEEDINFO|ASSIGNED Keywords||bisected -- 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 107772] Mesa preprocessor matches if(def)s & endifs incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=107772
Ian Romanick changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #3 from Ian Romanick ---
(In reply to Ian Romanick from comment #1)
> I'll add a piglit test for this. I cut-and-paste that code into a shader
> (and did 's/[[]ERROR]: [0-9]*: //'), and I get:
>
> Failed to compile vertex shader bad.vert: 0:30(1): error: syntax error,
> unexpected $end
Which I now realized is due to the shader being empty after preprocessing.
With the test case below, I cannot reproduce this issue. I tried a couple
similar things. Eero: Can you provide a small case that reproduces this?
#version 400 core
#define SV_301
#define highp
#define mediump
#define lowp
#define TYPE_vertex
#define DO_EMISSIVE_AND_AMBIENT 0
#define NUM_COLORS 64
#define NUM_LIGHTS 16
#ifdef TYPE_fragment
#if !DO_EMISSIVE_AND_AMBIENT
#define DO_LOOP_ITERATION(i)
#define DO_2_LOOP_ITERATIONS(i)
#define DO_4_LOOP_ITERATIONS(i)
#define DO_6_LOOP_ITERATIONS(i)
#define DO_8_LOOP_ITERATIONS(i)
#define DO_16_LOOP_ITERATIONS(i)
#endif
#if !DO_EMISSIVE_AND_AMBIENT
#endif
#if DO_EMISSIVE_AND_AMBIENT
#else
#endif
#endif
#ifdef TYPE_vertex
#if !DO_EMISSIVE_AND_AMBIENT
#endif
#if !DO_EMISSIVE_AND_AMBIENT
#endif
#endif
void main()
{
}
--
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 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error
https://bugs.freedesktop.org/show_bug.cgi?id=107477 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error
https://bugs.freedesktop.org/show_bug.cgi?id=107477 --- Comment #19 from Samuel Pitoiset --- Fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=6f47df312943b05653efc0494551ebf8c3903d43 Feel free to open a new bug report if you think the reflection issue is on the driver side. Thanks a lot for reporting this! -- 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 107772] Mesa preprocessor matches if(def)s & endifs incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=107772 --- Comment #2 from Ian Romanick --- (In reply to Ian Romanick from comment #1) > I'll add a piglit test for this. I cut-and-paste that code into a shader > (and did 's/[[]ERROR]: [0-9]*: //'), and I get: And 's/ \\$//' > Failed to compile vertex shader bad.vert: 0:30(1): error: syntax error, > unexpected $end -- 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 107772] Mesa preprocessor matches if(def)s & endifs incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=107772 Ian Romanick changed: What|Removed |Added CC||i...@freedesktop.org, ||t_arc...@yahoo.com.au --- Comment #1 from Ian Romanick --- I'll add a piglit test for this. I cut-and-paste that code into a shader (and did 's/[[]ERROR]: [0-9]*: //'), and I get: Failed to compile vertex shader bad.vert: 0:30(1): error: syntax error, unexpected $end -- 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
Re: [Mesa-dev] [PATCH] Bounding box avx2 intrinsic algorithm for openGL/GLES
This needs to be split into more than one patch before anyone is going to look at it. Each commit should do one, self-contained thing. "Implement a giant feature" in +2535 lines of code is not one, self-contained thing. Doing "simple shader" detection at the GLSL AST level (not even HIR yet, in spite of the commit message) is also not acceptable. The soonest this detection should happen is after linking. Even that neglects "assembly" vertex shaders and fixed-function. There are tons of whitespace, formatting, and style errors. The very first hunk in src/compiler/glsl/ast_to_hir.cpp is a spurious whitespace change. Don't remove -Wall from pre-SSE4.1 builds. There is a driver called SWR, so those are not good names for configure.ac variables. Many people, including all Intel developers, have switch to meson for building, so this won't even build for the people who might review your code. And many, many more... On 08/30/2018 10:25 PM, kedar.j.kara...@intel.com wrote: > From: "J Karanje, Kedar" > > The feature is enabled by default during make however we need to > add the following to drirc to enable the feature at runtime. > > > vbo: Main algorithm & code to check for MVP & vertex position location > Build Files: Flags to enable BBOX Code and check AVX version > compiler: Code to recognize simple shader > (gl_position is a simple function of mvp and vertex) > i965 & util: dri query to check if feature is enabled > > vbo: Implements a bounding box algorithm for mesa,we hook into the default > drawelements and drawrangelements and the MVP & vertex positions location > and the corresponding program is got,we re-create the frustum planes > using this data and also create a box around the object and use the 8 > vertices (box vertices) and check if the box is within the frustum or not, > we drop the draw calls that are completely outside the view frustum and > go for sub-boxes for objects that are intersecting with the frustum > planes. > > The current patch has been verified on KBL+Ubuntu 16.04, we noticed > 8~10% improvements in GFxBench TREX offscreen and ~2% for Manhattan offscreen, > Platforms where avx2 is not supported shall still see ~6-8% improvement, the > other KPIs were not impacted. > > Based on empirical data we have set minimum vertex count as 999 and the > sub-box size as 198, this provides the best results, we have also implemented > some level of caching for the box co-od and frustum plane co-od. > we have also optimized some algorithms to use avx2 when a target supports it. > > Shader classification code is currently in hir and we have got review comments > to move the same to NIR. > > Signed-off-by: Aravindan Muthukumar > Signed-off-by: Yogesh Marathe > --- > Android.common.mk| 19 + > configure.ac | 34 +- > src/compiler/glsl/ast_to_hir.cpp | 168 +++- > src/compiler/glsl/glsl_parser_extras.cpp | 10 + > src/compiler/glsl/glsl_parser_extras.h |7 + > src/compiler/glsl/linker.cpp | 18 + > src/intel/common/gen_debug.c |7 + > src/mesa/Makefile.sources| 11 + > src/mesa/drivers/dri/i965/brw_context.c | 17 + > src/mesa/drivers/dri/i965/intel_screen.c |4 + > src/mesa/main/bufferobj.c| 19 + > src/mesa/main/mtypes.h | 51 + > src/mesa/program/Android.mk |1 + > src/mesa/program/program.c |3 + > src/mesa/vbo/vbo_bbox.c | 1538 > ++ > src/mesa/vbo/vbo_bbox.h | 383 > src/mesa/vbo/vbo_bbox_cache.c| 195 > src/mesa/vbo/vbo_context.c | 11 +- > src/mesa/vbo/vbo_exec_array.c| 37 +- > src/util/00-mesa-defaults.conf |4 + > src/util/xmlpool/t_options.h |5 + > 21 files changed, 2535 insertions(+), 7 deletions(-) > mode change 100644 => 100755 src/compiler/glsl/ast_to_hir.cpp > create mode 100644 src/mesa/vbo/vbo_bbox.c > create mode 100644 src/mesa/vbo/vbo_bbox.h > create mode 100644 src/mesa/vbo/vbo_bbox_cache.c > > diff --git a/Android.common.mk b/Android.common.mk > index aa1b266..efd6792 100644 > --- a/Android.common.mk > +++ b/Android.common.mk > @@ -21,6 +21,8 @@ > # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > # DEALINGS IN THE SOFTWARE. > > +MESA_BBOX_ENABLE=true > + > ifeq ($(LOCAL_IS_HOST_MODULE),true) > LOCAL_CFLAGS += -D_GNU_SOURCE > endif > @@ -80,6 +82,10 @@ LOCAL_CFLAGS += \ > -fno-trapping-math \ > -Wno-sign-compare > > +ifeq ($(MESA_BBOX_ENABLE),true) > +LOCAL_CFLAGS += -DMESA_BBOX_OPT > +endif > + > LOCAL_CPPFLAGS += \ > -D__STDC_CONSTANT_MACROS \ > -D__STDC_FORMAT_MACROS \ > @@ -87,6 +93,10 @@ LOCAL_CPPFLAGS += \ > -Wno-error=non-virtual-dtor \ > -Wno-non-virtual-dtor > > +ifeq ($(MESA_BBOX_ENABLE),true)
Re: [Mesa-dev] [PATCH] gallivm/radeonsi: allow to pass two swizzles into fetches.
On 2018-08-31 2:14 a.m., Dave Airlie wrote: > On Fri., 31 Aug. 2018, 01:22 Michel Dänzer, wrote: >> >> On 2018-08-27 11:16 p.m., Dave Airlie wrote: >>> From: Dave Airlie >>> >>> This hijacks the top 16-bits of swizzle, to pass in the swizzle >>> for the second channel. >>> >>> This fixes handling .yx swizzles of 64-bit values. >>> >>> This should fixup radeonsi and llvmpipe. >>> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107524 >> >> This change broke a bunch of piglit tests for me with radeonsi on >> Bonair >> > > Wierd I did piglit runs locally, but I must have screwed them up somehow. Shit happens. :) > I've sent two patches to fix up the regressions, thanks for finding > and reporting them! Thank you for fixing them up so promptly! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107772] Mesa preprocessor matches if(def)s & endifs incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=107772 Bug ID: 107772 Summary: Mesa preprocessor matches if(def)s & endifs incorrectly Product: Mesa Version: git Hardware: Other OS: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: glsl-compiler Assignee: mesa-dev@lists.freedesktop.org Reporter: eero.t.tammi...@intel.com QA Contact: intel-3d-b...@lists.freedesktop.org Mesa started to give bogus error: 0:10(1): preprocessor error: Unterminated #if for GfxBench ALU2 test shader between these commits: 2018-08-29 17:51:11 8fb966688b: st/mesa: Disable blending for integer formats 2018-08-30 16:41:50 d9cf4308ce: i965/screen: Allow modifiers on sRGB formats Test-case: * bin/testfw_app --gfx glfw --gl_api desktop_core --width 1920 --height 1080 --test_id gl_alu2 GfxBench is proprietary, so I can't provide whole shader, but these are the pre-processor directive lines from the failing shader: --- [ERROR]: 1: #version 400 core [ERROR]: 2: #define SV_301 [ERROR]: 3: #define highp [ERROR]: 4: #define mediump [ERROR]: 5: #define lowp [ERROR]: 6: #define TYPE_vertex [ERROR]: 7: #define DO_EMISSIVE_AND_AMBIENT 0 [ERROR]: 8: #define NUM_COLORS 64 [ERROR]: 9: #define NUM_LIGHTS 16 [ERROR]: 10: #ifdef TYPE_fragment [ERROR]: 20: #if !DO_EMISSIVE_AND_AMBIENT [ERROR]: 25: #define DO_LOOP_ITERATION(i) \ [ERROR]: 46: #define DO_2_LOOP_ITERATIONS(i) \ [ERROR]: 50: #define DO_4_LOOP_ITERATIONS(i) \ [ERROR]: 54: #define DO_6_LOOP_ITERATIONS(i) \ [ERROR]: 58: #define DO_8_LOOP_ITERATIONS(i) \ [ERROR]: 62: #define DO_16_LOOP_ITERATIONS(i) \ [ERROR]: 66: #endif [ERROR]: 69: #if !DO_EMISSIVE_AND_AMBIENT [ERROR]: 71: #endif [ERROR]: 76: #if DO_EMISSIVE_AND_AMBIENT [ERROR]: 85: #else [ERROR]: 104: #endif [ERROR]: 106: #endif [ERROR]: 108: #ifdef TYPE_vertex [ERROR]: 112: #if !DO_EMISSIVE_AND_AMBIENT [ERROR]: 115: #endif [ERROR]: 120: #if !DO_EMISSIVE_AND_AMBIENT [ERROR]: 122: #endif [ERROR]: 125: #endif --- One should also be able to reproduce this with the GUI-only free version of GfxBench v4 from gfxbench.com, but I haven't tested that. (No other tests we run were affected.) I haven't bisected this, but the most likely candidate looks this: 28a3731e3f: glsl: skip stringification in preprocessor if in unreachable branch -- 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] i965/glsl: don't add unused aoa elements to the program resource list
From: Andrii Simiklit
It fixes a bit incorrectly implemented ARB_program_interface_query.
If input aoa element is unused in shader program
the 'glGetProgramResourceIndex' function shouldn't
return a valid resource index for it according to:
ARB_program_interface_query spec:
" For an active variable declared as an array of an aggregate data type
(structures or arrays), a separate entry will be generated for each
active array element"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92822
Signed-off-by: Andrii Simiklit
---
src/compiler/Makefile.sources | 4 +-
.../glsl/ir_collect_active_aoa_elements.cpp| 148 +
src/compiler/glsl/ir_collect_active_aoa_elements.h | 49 +++
src/compiler/glsl/linker.cpp | 75 +--
src/compiler/glsl/meson.build | 2 +
5 files changed, 265 insertions(+), 13 deletions(-)
create mode 100644 src/compiler/glsl/ir_collect_active_aoa_elements.cpp
create mode 100644 src/compiler/glsl/ir_collect_active_aoa_elements.h
diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index d3b0656..a2ba3e3 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -154,7 +154,9 @@ LIBGLSL_FILES = \
glsl/serialize.cpp \
glsl/serialize.h \
glsl/string_to_uint_map.cpp \
- glsl/string_to_uint_map.h
+ glsl/string_to_uint_map.h \
+ glsl/ir_collect_active_aoa_elements.cpp \
+ glsl/ir_collect_active_aoa_elements.h
LIBGLSL_SHADER_CACHE_FILES = \
glsl/shader_cache.cpp \
diff --git a/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
b/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
new file mode 100644
index 000..50042c7
--- /dev/null
+++ b/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
@@ -0,0 +1,148 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "ir_collect_active_aoa_elements.h"
+#include "program.h"
+#include "linker_util.h"
+#include "util/set.h"
+#include "util/u_dynarray.h"
+
+namespace
+{
+/***
+ * Helps to collect the names of used aoa elements
+ * to the accessed_elements set
+ ***/
+struct elem_inserter
+{
+elem_inserter(struct set *accessed_elements_)
+: accessed_elements(accessed_elements_)
+{}
+void operator ()(const char *name)
+{
+if (NULL == _mesa_set_search(accessed_elements, name)) {
+_mesa_set_add(accessed_elements, name);
+}
+}
+struct set *accessed_elements;
+};
+
+bool
+ir_is_array_deref(ir_rvalue *const ir)
+{
+return (ir_type_dereference_array == ir->ir_type);
+}
+
+ir_variable *
+base_ir_dereference_var(ir_dereference_array *const ir)
+{
+ir_dereference_array const *base_ir = ir;
+while (ir_type_dereference_array == base_ir->array->ir_type) {
+base_ir = base_ir->array->as_dereference_array();
+assert(NULL != base_ir);
+}
+
+ir_dereference_variable *const d =
+base_ir->array->as_dereference_variable();
+return (NULL == d) ? NULL : d->var;
+}
+}
+/**
+ * Helps to produce all combinations of used aoa elements
+ * for cases with constant and variable index.
+ **/
+template
+inline void enumiramte_active_elements(void *memctx,
+ir_dereference_array **first,
+ir_dereference_array **item,
+const char *accessed_elem_name,
+FunctorType functor)
+{
+if(item == (first - 1)) {
+functor(accessed_elem_name);
+return;
+}
+
+ir_dereference_array *const deref = (*item);
+ir_constant const *const
Re: [Mesa-dev] shader cache backward compatibility
On 31 August 2018 at 14:36, Timothy Arceri wrote:
> On 31/08/18 21:07, Emil Velikov wrote:
>>
>> On 31 August 2018 at 11:37, Timothy Arceri wrote:
>>>
>>> On 31/08/18 20:10, Emil Velikov wrote:
Hi Timothy,
On 31 August 2018 at 10:57, Timothy Arceri
wrote:
>
>
> On 31/08/18 19:40, Bas Nieuwenhuizen wrote:
>>
>>
>>
>> +TImothy
>>
>> On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson
>> wrote:
>>>
>>>
>>>
>>>
>>> Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've
>>> recently run into some issues with the mesa shader cache. Flatpak has
>>> a app/runtime split where the runtime is shared between app and
>>> provides /usr. The runtime contains a version of mesa, but this can
>>> be
>>> overridden by runtime extensions to add other OpenGL drivers.
>>>
>>> Each app has a separate $XDG_CACHE_HOME, pointing into the per-app
>>> writable storage. For example, gedit has
>>> XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This
>>> causes mesa to store the shader cache per-app in
>>> $XDG_CACHE_HOME/mesa_shader_cache.
>>>
>>> In the regular case this works fine, but sometimes the version of
>>> mesa
>>> is changed, with the shader cache being left in place. For example,
>>> sometimes we update the mesa version in the runtime, and sometimes
>>> the
>>> app switches to a new runtime which has a different mesa version.
>>>
>>> Such updates have caused a lot of issues for us, ranging from direct
>>> crashes at startup as in
>>> https://github.com/flatpak/flatpak/issues/2052 and sometimes just
>>> super-slow performance. In all cases, blowing away the shader cache
>>> directory fixed all issues.
>>>
>>> The steam flatpak has a bunch of workaround for the cache:
>>>
>>>
>>>
>>> https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35
>>> But we can't expect every app to do this.
>>>
>>> So, my question is, is the cache supposed to be backward compatible,
>>> or at least versioned? Are we missing something in our mesa builds to
>>> make that work? Is this fixed somewhere with a patch i can backport?
>>> And if not, do we need to add some magic to flatpak to automatically
>>> clean up the shader cache after an update?
>>
>>
>>
>>
>> It is supposed to be versioned automatically by mesa.
>>
>
> Hi Alexander,
>
> We depend on build timestamps of the mesa/llvm binaries when generating
> the
> sha for cache items. So if flatpak results in two versions of mesa
> having
> the same timestamp then there is likely going to be issues.
>
> static inline bool
> disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
> {
> Dl_info info;
> struct stat st;
> if (!dladdr(ptr, ) || !info.dli_fname) {
> return false;
> }
> if (stat(info.dli_fname, )) {
> return false;
> }
> *timestamp = st.st_mtime;
> return true;
> }
>
Have you tried using the build-id from src/util/build_id.c?
>>>
>>> Hi Emil,
>>>
>>> Honestly I've got no idea what that code does. Maybe someone who does
>>> could
>>> write patches to switch to it along with an explanation of why its
>>> better.
>>> Even just adding some comments in that file would be helpful.
>>>
>>> I don't want to be the one responsible for it (and any new issues with
>>> the
>>> cache) when I'm not aware of how it works :(
>>>
>> In a few words - retrieves the unique, in our case sha1, for the
>> binary. Any change in Mesa source will lead to a different build-id.
>> The SO thread has longer/better explanation [1]. You can skim through
>> git log for details and poke contributors with specific questions.
>
>
> Hmm, I think part of the reason we never did this is that we need and id for
> llvm also.
>
Valid point - I forgot about that.
A couple of ideas come to mind:
- static link LLVM (Flatpak already does it)
No LLVM changes needed.
- shared link LLVM
LLVM add -Wl,--build-id=sha1
In both cases Mesa will need something like
s/disk_cache_get_function_timestamp/build_id_find_nhdr_for_addr/
HTH
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Etnaviv on mesa master vs. Array._DrawVAO
> I'm looking into forward porting laanwj's patches for GC7000 support to > current mesa master. Luckily most of it already got merged last November > with mostly only the texture descriptor support missing( > https://github.com/laanwj/mesa/commit/b71802207432543745dff471c68fbc40495b4858) > > Putting this on current master leads to this assertion in mesa when running > kmscube like: > > kmscube: ../src/gallium/drivers/etnaviv/etnaviv_state.c:536: > etna_vertex_elements_state_create: Assertion `element_size != 0 && end_offset > <= 256' failed. > > Printing the value there gives: > > etna_vertex_elements_state_create:535: size: 12, offset: 0, end_offset: 12 > etna_vertex_elements_state_create:535: size: 12, offset: 576, end_offset: > 588 > > I've traced this back to this commit: > > 19a91841c347107d877bc750371c5fa4e9b4de19 is the first bad commit > commit 19a91841c347107d877bc750371c5fa4e9b4de19 > Author: Mathias Fröhlich > Date: Sun Apr 1 20:18:36 2018 +0200 > > st/mesa: Use Array._DrawVAO in st_atom_array.c. > > Finally make use of the binding information in the VAO when > setting up arrays for draw. > > v2: Emit less relocations also for interleaved userspace arrays. > > Reviewed-by: Brian Paul > Signed-off-by: Mathias Fröhlich > > And indeed commits prior to that one work as expected. Any hints what > would be the right fix to not trigger the assert? Hmm strange, So on etnaviv devices, as far as I know, the maximum 'stride' between vertices is 256. This means that a starting offset of 576 is not possible. (even more, it says size=12, so I'm really confused why it is requesting an index of 576 into that, it looks invalid) Regards, Wladimir ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
Am Dienstag, den 13.03.2018, 14:24 +1000 schrieb Dave Airlie: > This is the main code for the soft fp64 work. It's mostly Elie's > code with a bunch of changes by me. > With all the changes that landed lately for r600 I wanted to check how things are doing, but unfortunately the series doesn't apply anymore, specifically the file compiler/glsl/lower_64bit.cpp was renamed to compiler/glsl/lower_64int.cpp and changed in a way that requires to make nontrivial changes to the patch. Could you respin? many thanks, Gert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader cache backward compatibility
On 31/08/18 21:07, Emil Velikov wrote:
On 31 August 2018 at 11:37, Timothy Arceri wrote:
On 31/08/18 20:10, Emil Velikov wrote:
Hi Timothy,
On 31 August 2018 at 10:57, Timothy Arceri wrote:
On 31/08/18 19:40, Bas Nieuwenhuizen wrote:
+TImothy
On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson
wrote:
Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've
recently run into some issues with the mesa shader cache. Flatpak has
a app/runtime split where the runtime is shared between app and
provides /usr. The runtime contains a version of mesa, but this can be
overridden by runtime extensions to add other OpenGL drivers.
Each app has a separate $XDG_CACHE_HOME, pointing into the per-app
writable storage. For example, gedit has
XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This
causes mesa to store the shader cache per-app in
$XDG_CACHE_HOME/mesa_shader_cache.
In the regular case this works fine, but sometimes the version of mesa
is changed, with the shader cache being left in place. For example,
sometimes we update the mesa version in the runtime, and sometimes the
app switches to a new runtime which has a different mesa version.
Such updates have caused a lot of issues for us, ranging from direct
crashes at startup as in
https://github.com/flatpak/flatpak/issues/2052 and sometimes just
super-slow performance. In all cases, blowing away the shader cache
directory fixed all issues.
The steam flatpak has a bunch of workaround for the cache:
https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35
But we can't expect every app to do this.
So, my question is, is the cache supposed to be backward compatible,
or at least versioned? Are we missing something in our mesa builds to
make that work? Is this fixed somewhere with a patch i can backport?
And if not, do we need to add some magic to flatpak to automatically
clean up the shader cache after an update?
It is supposed to be versioned automatically by mesa.
Hi Alexander,
We depend on build timestamps of the mesa/llvm binaries when generating
the
sha for cache items. So if flatpak results in two versions of mesa having
the same timestamp then there is likely going to be issues.
static inline bool
disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
{
Dl_info info;
struct stat st;
if (!dladdr(ptr, ) || !info.dli_fname) {
return false;
}
if (stat(info.dli_fname, )) {
return false;
}
*timestamp = st.st_mtime;
return true;
}
Have you tried using the build-id from src/util/build_id.c?
Hi Emil,
Honestly I've got no idea what that code does. Maybe someone who does could
write patches to switch to it along with an explanation of why its better.
Even just adding some comments in that file would be helpful.
I don't want to be the one responsible for it (and any new issues with the
cache) when I'm not aware of how it works :(
In a few words - retrieves the unique, in our case sha1, for the
binary. Any change in Mesa source will lead to a different build-id.
The SO thread has longer/better explanation [1]. You can skim through
git log for details and poke contributors with specific questions.
Hmm, I think part of the reason we never did this is that we need and id
for llvm also.
HTH
Emil
[1]
https://stackoverflow.com/questions/29856780/what-is-nt-gnu-build-id-used-for
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader cache backward compatibility
On Fri, Aug 31, 2018 at 11:57 AM Timothy Arceri wrote:
>
> On 31/08/18 19:40, Bas Nieuwenhuizen wrote:
> We depend on build timestamps of the mesa/llvm binaries when generating
> the sha for cache items. So if flatpak results in two versions of mesa
> having the same timestamp then there is likely going to be issues.
>
> static inline bool
> disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
> {
> Dl_info info;
> struct stat st;
> if (!dladdr(ptr, ) || !info.dli_fname) {
>return false;
> }
> if (stat(info.dli_fname, )) {
>return false;
> }
> *timestamp = st.st_mtime;
> return true;
> }
Then i understand the problem. Flatpak stores all binaries in ostree,
and for technical reasons[1] all files stored in ostree have a mtime
of 0. This means the versioining will not work at all inside the
flatpak (nor will it when ostree stores the host OS in e.g. fedora
atomic). Is there no other unique id you can use?
[1] In ostree, all files are stored content-addressed. I.e. the
content + the some of the file metadata are checksummed. In order to
ensure files are shared more, the mtime is *not* part of the content
that is checksummed, so the ostree object has no mtime, which is
handled by using 0 for mtime in the repo.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Deny persistent mappings of incoherent GTT mmaps
On 31/08/2018 12:43, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-08-31 12:32:23) On 31/08/2018 12:22, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-08-31 12:16:19) We would need a fairly recent kernel (drm-tip?) to test this in CI. Unpatched mesa, assumes all is fine. Post-patch mesa, assumes all is broken. So we can quickly see if anything actually fails if a persistent GGTT mmap is rejected. Which is the important part for determining if such exclusion will harm anyone. The problem is then is the risk of corruption worth keeping it around. I can't see any issue with this because we always have the meta path as a fallback for tiled buffers. I'm worried if the mmap actually leaks through to glMapBufferRange with say GL_MAP_PERSISTENT_BIT. Hmm, maybe that's all ok so long at the client flushes are explicit. As far as I can tell, buffers are linear, so brw_bo_map() wouldn't even try to map in gtt at first. Then brw_bo_map_wc() would assert if it failed. So we're fine? :) I like that plan. Not having to rely on GGTT will save a lot of headaches. -Chris Maybe brw_bo_map() needs to be updated a bit to make that clear. Ken: does this look okay with you? - Lionel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: update calendar to extended the 18.1 cycle by one more release
Yes, please. Acked-by: Emil Velikov -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Deny persistent mappings of incoherent GTT mmaps
Quoting Lionel Landwerlin (2018-08-31 12:32:23) > On 31/08/2018 12:22, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2018-08-31 12:16:19) > >> We would need a fairly recent kernel (drm-tip?) to test this in CI. > > Unpatched mesa, assumes all is fine. > > Post-patch mesa, assumes all is broken. > > > > So we can quickly see if anything actually fails if a persistent GGTT > > mmap is rejected. Which is the important part for determining if such > > exclusion will harm anyone. The problem is then is the risk of > > corruption worth keeping it around. > > > >> I can't see any issue with this because we always have the meta path as > >> a fallback for tiled buffers. > > I'm worried if the mmap actually leaks through to glMapBufferRange with > > say GL_MAP_PERSISTENT_BIT. Hmm, maybe that's all ok so long at the > > client flushes are explicit. > > > As far as I can tell, buffers are linear, so brw_bo_map() wouldn't even > try to map in gtt at first. > > Then brw_bo_map_wc() would assert if it failed. > > So we're fine? :) I like that plan. Not having to rely on GGTT will save a lot of headaches. -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Deny persistent mappings of incoherent GTT mmaps
On 31/08/2018 12:22, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-08-31 12:16:19) We would need a fairly recent kernel (drm-tip?) to test this in CI. Unpatched mesa, assumes all is fine. Post-patch mesa, assumes all is broken. So we can quickly see if anything actually fails if a persistent GGTT mmap is rejected. Which is the important part for determining if such exclusion will harm anyone. The problem is then is the risk of corruption worth keeping it around. I can't see any issue with this because we always have the meta path as a fallback for tiled buffers. I'm worried if the mmap actually leaks through to glMapBufferRange with say GL_MAP_PERSISTENT_BIT. Hmm, maybe that's all ok so long at the client flushes are explicit. As far as I can tell, buffers are linear, so brw_bo_map() wouldn't even try to map in gtt at first. Then brw_bo_map_wc() would assert if it failed. So we're fine? :) -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Deny persistent mappings of incoherent GTT mmaps
Quoting Lionel Landwerlin (2018-08-31 12:16:19) > We would need a fairly recent kernel (drm-tip?) to test this in CI. Unpatched mesa, assumes all is fine. Post-patch mesa, assumes all is broken. So we can quickly see if anything actually fails if a persistent GGTT mmap is rejected. Which is the important part for determining if such exclusion will harm anyone. The problem is then is the risk of corruption worth keeping it around. > I can't see any issue with this because we always have the meta path as > a fallback for tiled buffers. I'm worried if the mmap actually leaks through to glMapBufferRange with say GL_MAP_PERSISTENT_BIT. Hmm, maybe that's all ok so long at the client flushes are explicit. -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Deny persistent mappings of incoherent GTT mmaps
We would need a fairly recent kernel (drm-tip?) to test this in CI.
I can't see any issue with this because we always have the meta path as
a fallback for tiled buffers.
Reviewed-by: Lionel Landwerlin
On 30/08/2018 16:22, Chris Wilson wrote:
On more recent HW, the indirect writes via the GGTT are internally
buffered presenting a nuisance to trying to use them for persistent
client maps. (We cannot guarantee that any write by the client will
then be visible to either the GPU or third parties in a timely manner,
leading to corruption.) Fortunately, we try very hard not to even use
the GGTT for anything and even less so for persistent mmaps, so their
loss is unlikely to be noticed.
No piglits harmed.
Cc: Kenneth Graunke
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
---
include/drm-uapi/i915_drm.h | 22 +++
src/mesa/drivers/dri/i965/brw_bufmgr.c | 36
src/mesa/drivers/dri/i965/intel_screen.c | 3 ++
src/mesa/drivers/dri/i965/intel_screen.h | 1 +
4 files changed, 62 insertions(+)
diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index 16e452aa12d..268b585f8a4 100644
--- a/include/drm-uapi/i915_drm.h
+++ b/include/drm-uapi/i915_drm.h
@@ -529,6 +529,28 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_CS_TIMESTAMP_FREQUENCY 51
+/*
+ * Once upon a time we supposed that writes through the GGTT would be
+ * immediately in physical memory (once flushed out of the CPU path). However,
+ * on a few different processors and chipsets, this is not necessarily the case
+ * as the writes appear to be buffered internally. Thus a read of the backing
+ * storage (physical memory) via a different path (with different physical tags
+ * to the indirect write via the GGTT) will see stale values from before
+ * the GGTT write. Inside the kernel, we can for the most part keep track of
+ * the different read/write domains in use (e.g. set-domain), but the
assumption
+ * of coherency is baked into the ABI, hence reporting its true state in this
+ * parameter.
+ *
+ * Reports true when writes via mmap_gtt are immediately visible following an
+ * lfence to flush the WCB.
+ *
+ * Reports false when writes via mmap_gtt are indeterminately delayed in an in
+ * internal buffer and are _not_ immediately visible to third parties accessing
+ * directly via mmap_cpu/mmap_wc. Use of mmap_gtt as part of an IPC
+ * communications channel when reporting false is strongly disadvised.
+ */
+#define I915_PARAM_MMAP_GTT_COHERENT 52
+
typedef struct drm_i915_getparam {
__s32 param;
/*
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index f1675b191c1..6955c5c890c 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -1068,6 +1068,19 @@ brw_bo_map_wc(struct brw_context *brw, struct brw_bo
*bo, unsigned flags)
return bo->map_wc;
}
+static void
+bo_set_domain(struct brw_bo *bo, unsigned int read, unsigned int write)
+{
+ struct brw_bufmgr *bufmgr = bo->bufmgr;
+
+ struct drm_i915_gem_set_domain arg = {
+ .handle = bo->gem_handle,
+ .read_domains = read,
+ .write_domain = write,
+ };
+ drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, );
+}
+
/**
* Perform an uncached mapping via the GTT.
*
@@ -1095,6 +1108,25 @@ brw_bo_map_gtt(struct brw_context *brw, struct brw_bo
*bo, unsigned flags)
{
struct brw_bufmgr *bufmgr = bo->bufmgr;
+ /* Once upon a time we believed that there was no internal buffering of
+* the indirect writes via the Global GTT; that is once flushed from
+* the processor the write would be immediately visible to any one
+* else reading that memory location be they the GPU, kernel or another
+* client. As it turns out, on modern hardware there is an internal buffer
+* that cannot be directly flushed (e.g. using the sfence one would normally
+* use to flush the WCB) and so far the w/a requires us to do an uncached
+* mmio read, quite expensive and requires user cooperation. That is we
+* cannot simply support persistent user access to the GTT mmap buffers
+* as we have no means of flushing their writes in a timely manner.
+*/
+ if (flags & MAP_PERSISTENT &&
+ flags & MAP_COHERENT &&
+ flags & MAP_WRITE &&
+ !(brw->screen->kernel_features & KERNEL_ALLOWS_COHERENT_MMAP_GTT)) {
+ DBG("bo_map_gtt: rejected attempt to make a coherent, persistent and writable GGTT
mmap, %d (%s)\n", bo->gem_handle, bo->name);
+ return NULL;
+ }
+
/* Get a mapping of the buffer if we haven't before. */
if (bo->map_gtt == NULL) {
DBG("bo_map_gtt: mmap %d (%s)\n", bo->gem_handle, bo->name);
@@ -1138,6 +1170,10 @@ brw_bo_map_gtt(struct brw_context *brw, struct brw_bo
*bo, unsigned flags)
if (!(flags & MAP_ASYNC)) {
bo_wait_with_stall_warning(brw, bo, "GTT mapping");
}
+ if (flags &
Re: [Mesa-dev] shader cache backward compatibility
On 31 August 2018 at 11:37, Timothy Arceri wrote:
> On 31/08/18 20:10, Emil Velikov wrote:
>>
>> Hi Timothy,
>>
>> On 31 August 2018 at 10:57, Timothy Arceri wrote:
>>>
>>> On 31/08/18 19:40, Bas Nieuwenhuizen wrote:
+TImothy
On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson
wrote:
>
>
>
> Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've
> recently run into some issues with the mesa shader cache. Flatpak has
> a app/runtime split where the runtime is shared between app and
> provides /usr. The runtime contains a version of mesa, but this can be
> overridden by runtime extensions to add other OpenGL drivers.
>
> Each app has a separate $XDG_CACHE_HOME, pointing into the per-app
> writable storage. For example, gedit has
> XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This
> causes mesa to store the shader cache per-app in
> $XDG_CACHE_HOME/mesa_shader_cache.
>
> In the regular case this works fine, but sometimes the version of mesa
> is changed, with the shader cache being left in place. For example,
> sometimes we update the mesa version in the runtime, and sometimes the
> app switches to a new runtime which has a different mesa version.
>
> Such updates have caused a lot of issues for us, ranging from direct
> crashes at startup as in
> https://github.com/flatpak/flatpak/issues/2052 and sometimes just
> super-slow performance. In all cases, blowing away the shader cache
> directory fixed all issues.
>
> The steam flatpak has a bunch of workaround for the cache:
>
>
> https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35
> But we can't expect every app to do this.
>
> So, my question is, is the cache supposed to be backward compatible,
> or at least versioned? Are we missing something in our mesa builds to
> make that work? Is this fixed somewhere with a patch i can backport?
> And if not, do we need to add some magic to flatpak to automatically
> clean up the shader cache after an update?
It is supposed to be versioned automatically by mesa.
>>>
>>> Hi Alexander,
>>>
>>> We depend on build timestamps of the mesa/llvm binaries when generating
>>> the
>>> sha for cache items. So if flatpak results in two versions of mesa having
>>> the same timestamp then there is likely going to be issues.
>>>
>>> static inline bool
>>> disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
>>> {
>>> Dl_info info;
>>> struct stat st;
>>> if (!dladdr(ptr, ) || !info.dli_fname) {
>>>return false;
>>> }
>>> if (stat(info.dli_fname, )) {
>>>return false;
>>> }
>>> *timestamp = st.st_mtime;
>>> return true;
>>> }
>>>
>> Have you tried using the build-id from src/util/build_id.c?
>>
>
> Hi Emil,
>
> Honestly I've got no idea what that code does. Maybe someone who does could
> write patches to switch to it along with an explanation of why its better.
> Even just adding some comments in that file would be helpful.
>
> I don't want to be the one responsible for it (and any new issues with the
> cache) when I'm not aware of how it works :(
>
In a few words - retrieves the unique, in our case sha1, for the
binary. Any change in Mesa source will lead to a different build-id.
The SO thread has longer/better explanation [1]. You can skim through
git log for details and poke contributors with specific questions.
HTH
Emil
[1]
https://stackoverflow.com/questions/29856780/what-is-nt-gnu-build-id-used-for
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl/wayland: do not leak wl_buffer when it is locked
On Thu, 30 Aug 2018 at 12:59, Juan A. Suarez Romero wrote: > If color buffer is locked, do not set its wayland buffer to NULL; > otherwise it can not be freed later. > > Rather, flag it in order to destroy it later on the release event. > > v2: instruct release event to unlock only or free wl_buffer too (Daniel) > > This also fixes dEQP-EGL.functional.swap_buffers_with_damage.* tests. Thanks Juan! Reviewed-by: Daniel Stone ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] compiler: Move double_inputs to gl_program::DualSlotInputs
As right now piglit only have one ARB_gl_spirv test with double inputs,
and Im not really sure if intel CI already runs piglit with spirv-tools
available, I tested this patch with my local piglit, that includes all
the va64 tests converted to SPIR-V (that as some already know/complained
about, that means ~20k tests). No regressions. So, on the ARB_gl_spirv part:
Tested-by: Alejandro Piñeiro
On 31/08/18 01:48, Jason Ekstrand wrote:
> Previously, we had two field in shader_info: double_inputs_read and
> double_inputs. Presumably, the one was for all double inputs that are
> read and the other is all that exist. However, because nir_gather_info
> regenerates these two values, there is a possibility, if a variable gets
> deleted, that the value of double_inputs could change over time. This
> is a problem because double_inputs is used to remap the input locations
> to a two-slot-per-dvec3/4 scheme for i965. If that mapping were to
> change between glsl_to_nir and back-end state setup, we would fall over
> when trying to map the NIR outputs back onto the GL location space.
>
> This commit changes the way slot re-mapping works. Instead of the
> double_inputs field in shader_info, it adds a DualSlotInputs bitfield to
> gl_program. By having it in gl_program, we more easily guarantee that
> NIR passes won't touch it after it's been set. It also makes more sense
> to put it in a GL data structure since it's really a mapping from GL
> slots to back-end and/or NIR slots and not really a NIR shader thing.
>
> This shouldn't affect gallium drivers or radv but I have yet to actually
> test it on any of them.
>
> Cc: Kenneth Graunke
> Cc: Timothy Arceri
>
> ---
> src/compiler/glsl/glsl_to_nir.cpp | 16 +++--
> src/compiler/glsl/ir_set_program_inouts.cpp | 2 +-
> src/compiler/glsl/serialize.cpp | 2 ++
> src/compiler/nir/nir.c| 36 ---
> src/compiler/nir/nir.h| 5 +--
> src/compiler/nir/nir_gather_info.c| 6
> src/compiler/shader_info.h| 3 --
> src/mesa/drivers/dri/i965/brw_draw_upload.c | 19 +-
> src/mesa/drivers/dri/i965/genX_state_upload.c | 1 +
> src/mesa/main/glspirv.c | 20 +++
> src/mesa/main/mtypes.h| 15
> src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 2 +-
> src/mesa/state_tracker/st_program.c | 3 +-
> 14 files changed, 66 insertions(+), 66 deletions(-)
>
> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
> b/src/compiler/glsl/glsl_to_nir.cpp
> index f38d280d406..d22f4a58dd4 100644
> --- a/src/compiler/glsl/glsl_to_nir.cpp
> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> @@ -149,8 +149,11 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
> * two locations. For instance, if we have in the IR code a dvec3 attr0 in
> * location 0 and vec4 attr1 in location 1, in NIR attr0 will use
> * locations/slots 0 and 1, and attr1 will use location/slot 2 */
> - if (shader->info.stage == MESA_SHADER_VERTEX)
> - nir_remap_attributes(shader, options);
> + if (shader->info.stage == MESA_SHADER_VERTEX) {
> + sh->Program->DualSlotInputs = nir_get_dual_slot_attributes(shader);
> + if (options->vs_inputs_dual_locations)
> + nir_remap_dual_slot_attributes(shader, sh->Program->DualSlotInputs);
> + }
>
> shader->info.name = ralloc_asprintf(shader, "GLSL%d", shader_prog->Name);
> if (shader_prog->Label)
> @@ -344,15 +347,6 @@ nir_visitor::visit(ir_variable *ir)
> var->data.compact = ir->type->without_array()->is_scalar();
> }
>}
> -
> - /* Mark all the locations that require two slots */
> - if (shader->info.stage == MESA_SHADER_VERTEX &&
> - glsl_type_is_dual_slot(glsl_without_array(var->type))) {
> - for (unsigned i = 0; i < glsl_count_attribute_slots(var->type,
> true); i++) {
> -uint64_t bitfield = BITFIELD64_BIT(var->data.location + i);
> -shader->info.vs.double_inputs |= bitfield;
> - }
> - }
>break;
>
> case ir_var_shader_out:
> diff --git a/src/compiler/glsl/ir_set_program_inouts.cpp
> b/src/compiler/glsl/ir_set_program_inouts.cpp
> index ba1e44167c3..a3cb19479b8 100644
> --- a/src/compiler/glsl/ir_set_program_inouts.cpp
> +++ b/src/compiler/glsl/ir_set_program_inouts.cpp
> @@ -118,7 +118,7 @@ mark(struct gl_program *prog, ir_variable *var, int
> offset, int len,
> /* double inputs read is only for vertex inputs */
> if (stage == MESA_SHADER_VERTEX &&
> var->type->without_array()->is_dual_slot())
> -prog->info.vs.double_inputs_read |= bitfield;
> +prog->DualSlotInputs |= bitfield;
>
> if (stage == MESA_SHADER_FRAGMENT) {
> prog->info.fs.uses_sample_qualifier |= var->data.sample;
> diff
[Mesa-dev] Etnaviv on mesa master vs. Array._DrawVAO
Hi, I'm looking into forward porting laanwj's patches for GC7000 support to current mesa master. Luckily most of it already got merged last November with mostly only the texture descriptor support missing( https://github.com/laanwj/mesa/commit/b71802207432543745dff471c68fbc40495b4858) Putting this on current master leads to this assertion in mesa when running kmscube like: kmscube: ../src/gallium/drivers/etnaviv/etnaviv_state.c:536: etna_vertex_elements_state_create: Assertion `element_size != 0 && end_offset <= 256' failed. Printing the value there gives: etna_vertex_elements_state_create:535: size: 12, offset: 0, end_offset: 12 etna_vertex_elements_state_create:535: size: 12, offset: 576, end_offset: 588 And the bt is: Stack trace of thread 2158: #0 0xa93427c0 raise (libc.so.6) #1 0xa934274c raise (libc.so.6) #2 0xa9343bac abort (libc.so.6) #3 0xa933bd2c n/a (libc.so.6) #4 0xa933bdac __assert_fail (libc.so.6) #5 0xa8de468c etna_vertex_elements_state_create (imx-drm_dri.so) #6 0xa8757178 u_vbuf_set_vertex_elements_internal (imx-drm_dri.so) #7 0xa875726c u_vbuf_set_vertex_elements (imx-drm_dri.so) #8 0xa8711bcc cso_set_vertex_elements (imx-drm_dri.so) #9 0xa8b28760 set_vertex_attribs (imx-drm_dri.so) #10 0xa8b28c9c st_update_array (imx-drm_dri.so) #11 0xa8ad4e44 st_validate_state (imx-drm_dri.so) #12 0xa8a1e410 prepare_draw (imx-drm_dri.so) #13 0xa8a1e488 st_draw_vbo (imx-drm_dri.so) #14 0xa8a0ea9c vbo_draw_arrays (imx-drm_dri.so) #15 0xa8a0f408 vbo_exec_DrawArrays (imx-drm_dri.so) #16 0xa953f7e0 glDrawArrays (libGLESv2.so.2) #17 0xd7e62ea0 draw_cube_smooth (kmscube) #18 0xd7e64160 atomic_run (kmscube) #19 0xa93306e0 __libc_start_main (libc.so.6) #20 0xd7e621fc $x (kmscube) #21 0xd7e621fc $x (kmscube) I've traced this back to this commit: 19a91841c347107d877bc750371c5fa4e9b4de19 is the first bad commit commit 19a91841c347107d877bc750371c5fa4e9b4de19 Author: Mathias Fröhlich Date: Sun Apr 1 20:18:36 2018 +0200 st/mesa: Use Array._DrawVAO in st_atom_array.c. Finally make use of the binding information in the VAO when setting up arrays for draw. v2: Emit less relocations also for interleaved userspace arrays. Reviewed-by: Brian Paul Signed-off-by: Mathias Fröhlich And indeed commits prior to that one work as expected. Any hints what would be the right fix to not trigger the assert? Cheers, -- Guido ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] i965/screen: Allow modifiers on sRGB formats
On Wed, 29 Aug 2018 at 16:43, Eric Engestrom wrote:
> On Tuesday, 2018-08-28 21:44:54 -0500, Jason Ekstrand wrote:
> > On Tue, Aug 28, 2018 at 5:22 PM Jason Ekstrand wrote:
> > > This effectively reverts a26693493570a9d0f0fba1be617e01ee7bfff4db which
> > > was a misguided attempt at protecting intel_query_dma_buf_modifiers from
> > > invalid formats. Unfortunately, in some internal EGL cases, we can get
> > > an SRGB format validly in this function. Rejecting such formats caused
> > > us to not allow CCS in some cases where we should have been allowing it.
> > >
> > > There's some question of whether or not we really should be using SRGB
> > > "fourcc" formats that aren't actually in drm_foucc.h but there's not
> > > much harm in allowing them through here.
> > >
> > > [...]
> > >
> > > @@ -1302,6 +1302,14 @@ intel_query_dma_buf_formats(__DRIscreen *_screen,
> > > int max,
> > > int num_formats = 0, i;
> > >
> > > for (i = 0; i < ARRAY_SIZE(intel_image_formats); i++) {
> > > + /* These two formats are valid DRI formats but do not exist in
> > > + * drm_fourcc.h in the Linux kernel. We don't want to accidentally
> > > + * advertise them through the EGL layer.
> > > + */
> > > + if (intel_image_formats[i].fourcc == __DRI_IMAGE_FOURCC_SARGB
> > > ||
> > > + intel_image_formats[i].fourcc == __DRI_IMAGE_FOURCC_SABGR)
> > > + return false;
> > >
> >
> > This should be a continue. Fixed locally.
>
> With that, the series is
> Reviewed-by: Eric Engestrom
... and also:
Reviewed-by: Daniel Stone
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/genxml: add FAULT_REG for Gen10/11
Signed-off-by: Lionel Landwerlin --- src/intel/genxml/gen10.xml | 33 + src/intel/genxml/gen11.xml | 33 + 2 files changed, 66 insertions(+) diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml index 541e4405716..819a807691a 100644 --- a/src/intel/genxml/gen10.xml +++ b/src/intel/genxml/gen10.xml @@ -3627,6 +3627,39 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml index 1b3befbbfc9..c10477fda6b 100644 --- a/src/intel/genxml/gen11.xml +++ b/src/intel/genxml/gen11.xml @@ -3625,6 +3625,39 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader cache backward compatibility
On 31/08/18 20:10, Emil Velikov wrote:
Hi Timothy,
On 31 August 2018 at 10:57, Timothy Arceri wrote:
On 31/08/18 19:40, Bas Nieuwenhuizen wrote:
+TImothy
On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson
wrote:
Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've
recently run into some issues with the mesa shader cache. Flatpak has
a app/runtime split where the runtime is shared between app and
provides /usr. The runtime contains a version of mesa, but this can be
overridden by runtime extensions to add other OpenGL drivers.
Each app has a separate $XDG_CACHE_HOME, pointing into the per-app
writable storage. For example, gedit has
XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This
causes mesa to store the shader cache per-app in
$XDG_CACHE_HOME/mesa_shader_cache.
In the regular case this works fine, but sometimes the version of mesa
is changed, with the shader cache being left in place. For example,
sometimes we update the mesa version in the runtime, and sometimes the
app switches to a new runtime which has a different mesa version.
Such updates have caused a lot of issues for us, ranging from direct
crashes at startup as in
https://github.com/flatpak/flatpak/issues/2052 and sometimes just
super-slow performance. In all cases, blowing away the shader cache
directory fixed all issues.
The steam flatpak has a bunch of workaround for the cache:
https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35
But we can't expect every app to do this.
So, my question is, is the cache supposed to be backward compatible,
or at least versioned? Are we missing something in our mesa builds to
make that work? Is this fixed somewhere with a patch i can backport?
And if not, do we need to add some magic to flatpak to automatically
clean up the shader cache after an update?
It is supposed to be versioned automatically by mesa.
Hi Alexander,
We depend on build timestamps of the mesa/llvm binaries when generating the
sha for cache items. So if flatpak results in two versions of mesa having
the same timestamp then there is likely going to be issues.
static inline bool
disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
{
Dl_info info;
struct stat st;
if (!dladdr(ptr, ) || !info.dli_fname) {
return false;
}
if (stat(info.dli_fname, )) {
return false;
}
*timestamp = st.st_mtime;
return true;
}
Have you tried using the build-id from src/util/build_id.c?
Hi Emil,
Honestly I've got no idea what that code does. Maybe someone who does
could write patches to switch to it along with an explanation of why its
better. Even just adding some comments in that file would be helpful.
I don't want to be the one responsible for it (and any new issues with
the cache) when I'm not aware of how it works :(
Tim
The reproducible builds' date/time override feature, is something
people could easily misusing.
Effectively having the same timestamp across multiple, completely
different, builds.
HTH
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader cache backward compatibility
Hi Timothy,
On 31 August 2018 at 10:57, Timothy Arceri wrote:
> On 31/08/18 19:40, Bas Nieuwenhuizen wrote:
>>
>> +TImothy
>>
>> On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson
>> wrote:
>>>
>>>
>>> Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've
>>> recently run into some issues with the mesa shader cache. Flatpak has
>>> a app/runtime split where the runtime is shared between app and
>>> provides /usr. The runtime contains a version of mesa, but this can be
>>> overridden by runtime extensions to add other OpenGL drivers.
>>>
>>> Each app has a separate $XDG_CACHE_HOME, pointing into the per-app
>>> writable storage. For example, gedit has
>>> XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This
>>> causes mesa to store the shader cache per-app in
>>> $XDG_CACHE_HOME/mesa_shader_cache.
>>>
>>> In the regular case this works fine, but sometimes the version of mesa
>>> is changed, with the shader cache being left in place. For example,
>>> sometimes we update the mesa version in the runtime, and sometimes the
>>> app switches to a new runtime which has a different mesa version.
>>>
>>> Such updates have caused a lot of issues for us, ranging from direct
>>> crashes at startup as in
>>> https://github.com/flatpak/flatpak/issues/2052 and sometimes just
>>> super-slow performance. In all cases, blowing away the shader cache
>>> directory fixed all issues.
>>>
>>> The steam flatpak has a bunch of workaround for the cache:
>>>
>>> https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35
>>> But we can't expect every app to do this.
>>>
>>> So, my question is, is the cache supposed to be backward compatible,
>>> or at least versioned? Are we missing something in our mesa builds to
>>> make that work? Is this fixed somewhere with a patch i can backport?
>>> And if not, do we need to add some magic to flatpak to automatically
>>> clean up the shader cache after an update?
>>
>>
>> It is supposed to be versioned automatically by mesa.
>>
>
> Hi Alexander,
>
> We depend on build timestamps of the mesa/llvm binaries when generating the
> sha for cache items. So if flatpak results in two versions of mesa having
> the same timestamp then there is likely going to be issues.
>
> static inline bool
> disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
> {
>Dl_info info;
>struct stat st;
>if (!dladdr(ptr, ) || !info.dli_fname) {
> return false;
>}
>if (stat(info.dli_fname, )) {
> return false;
>}
>*timestamp = st.st_mtime;
>return true;
> }
>
Have you tried using the build-id from src/util/build_id.c?
The reproducible builds' date/time override feature, is something
people could easily misusing.
Effectively having the same timestamp across multiple, completely
different, builds.
HTH
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] intel: aubinator: Adding missed platforms to the error message.
On 30/08/2018 22:41, Rodrigo Vivi wrote:
Many new platforms got added to gen_device_name_to_pci_device_id()
but the error message inside aubinator didn't reflected those
changes. So syncing on the same order to be sure that we are not
missing any now.
Cc: Anuj Phogat
Cc: Matt Turner
Cc: Jordan Justen
Signed-off-by: Rodrigo Vivi
Reviewed-by: Lionel Landwerlin
---
src/intel/tools/aubinator.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index c22d191f14..edd11fe0f5 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -280,8 +280,9 @@ int main(int argc, char *argv[])
case 'g': {
const int id = gen_device_name_to_pci_device_id(optarg);
if (id < 0) {
-fprintf(stderr, "can't parse gen: '%s', expected ivb, byt, hsw, "
- "bdw, chv, skl, kbl or bxt\n", optarg);
+fprintf(stderr, "can't parse gen: '%s', expected brw, g4x, ilk, "
+"snb, ivb, hsw, byt, bdw, chv, skl, bxt, kbl, "
+"glk, cfl, cnl, icl", optarg);
exit(EXIT_FAILURE);
} else {
pci_id = id;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] intel: Introducing Amber Lake platform
On 30/08/2018 22:41, Rodrigo Vivi wrote:
Amber Lake uses the same gen graphics as Kaby Lake, including a id
that were previously marked as reserved on Kaby Lake, but that
now is moved to AML page.
This follows the ids and approach used on kernel's commit
e364672477a1 ("drm/i915/aml: Introducing Amber Lake platform")
Reported-by: Timo Aaltonen
Cc: José Roberto de Souza
Cc: Anuj Phogat
Signed-off-by: Rodrigo Vivi
Reviewed-by: Lionel Landwerlin
---
include/pci_ids/i965_pci_ids.h | 3 ++-
src/intel/compiler/test_eu_validate.cpp | 1 +
src/intel/dev/gen_device_info.c | 1 +
src/intel/tools/aubinator.c | 2 +-
4 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index bced44e288..4efac638e9 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -156,7 +156,6 @@ CHIPSET(0x5912, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby Lake
GT2)")
CHIPSET(0x5916, kbl_gt2, "Intel(R) HD Graphics 620 (Kaby Lake GT2)")
CHIPSET(0x591A, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
CHIPSET(0x591B, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby Lake GT2)")
-CHIPSET(0x591C, kbl_gt2, "Intel(R) Kaby Lake GT2")
CHIPSET(0x591D, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
CHIPSET(0x591E, kbl_gt2, "Intel(R) HD Graphics 615 (Kaby Lake GT2)")
CHIPSET(0x5921, kbl_gt2, "Intel(R) Kabylake GT2F")
@@ -164,6 +163,8 @@ CHIPSET(0x5923, kbl_gt3, "Intel(R) Kabylake GT3")
CHIPSET(0x5926, kbl_gt3, "Intel(R) Iris Plus Graphics 640 (Kaby Lake GT3e)")
CHIPSET(0x5927, kbl_gt3, "Intel(R) Iris Plus Graphics 650 (Kaby Lake GT3e)")
CHIPSET(0x593B, kbl_gt4, "Intel(R) Kabylake GT4")
+CHIPSET(0x591C, kbl_gt2, "Intel(R) Amber Lake GT2")
+CHIPSET(0x87C0, kbl_gt2, "Intel(R) Amber Lake GT2")
CHIPSET(0x3184, glk, "Intel(R) UHD Graphics 605 (Geminilake)")
CHIPSET(0x3185, glk_2x6, "Intel(R) UHD Graphics 600 (Geminilake 2x6)")
CHIPSET(0x3E90, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
diff --git a/src/intel/compiler/test_eu_validate.cpp
b/src/intel/compiler/test_eu_validate.cpp
index b132b87a1a..744ae5806d 100644
--- a/src/intel/compiler/test_eu_validate.cpp
+++ b/src/intel/compiler/test_eu_validate.cpp
@@ -40,6 +40,7 @@ static const struct gen_info {
{ "skl", },
{ "bxt", },
{ "kbl", },
+ { "aml", },
{ "glk", },
{ "cfl", },
{ "cnl", },
diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index b0ae4d1803..3cece52a04 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -57,6 +57,7 @@ gen_device_name_to_pci_device_id(const char *name)
{ "skl", 0x1912 },
{ "bxt", 0x5A85 },
{ "kbl", 0x5912 },
+ { "aml", 0x591C },
{ "glk", 0x3185 },
{ "cfl", 0x3E9B },
{ "cnl", 0x5a52 },
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index edd11fe0f5..55672fa073 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -282,7 +282,7 @@ int main(int argc, char *argv[])
if (id < 0) {
fprintf(stderr, "can't parse gen: '%s', expected brw, g4x, ilk, "
"snb, ivb, hsw, byt, bdw, chv, skl, bxt, kbl, "
-"glk, cfl, cnl, icl", optarg);
+"aml, glk, cfl, cnl, icl", optarg);
exit(EXIT_FAILURE);
} else {
pci_id = id;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] intel: Introducing Whiskey Lake platform
On 30/08/2018 22:41, Rodrigo Vivi wrote:
Whiskey Lake uses the same gen graphics as Coffe Lake, including some
ids that were previously marked as reserved on Coffe Lake, but that
now are moved to WHL page.
This follows the ids and approach used on kernel's commit
b9be78531d27 ("drm/i915/whl: Introducing Whiskey Lake platform")
Cc: José Roberto de Souza
Cc: Anuj Phogat
Signed-off-by: Rodrigo Vivi
---
include/pci_ids/i965_pci_ids.h | 10 +-
src/intel/compiler/test_eu_validate.cpp | 1 +
src/intel/dev/gen_device_info.c | 1 +
src/intel/tools/aubinator.c | 2 +-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 4efac638e9..d151b3dd0e 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -170,8 +170,6 @@ CHIPSET(0x3185, glk_2x6, "Intel(R) UHD Graphics 600 (Geminilake
2x6)")
CHIPSET(0x3E90, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
CHIPSET(0x3E93, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
CHIPSET(0x3E99, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
-CHIPSET(0x3EA1, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
-CHIPSET(0x3EA4, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
CHIPSET(0x3E91, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
CHIPSET(0x3E92, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
CHIPSET(0x3E96, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
@@ -179,14 +177,16 @@ CHIPSET(0x3E98, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8
GT2)")
CHIPSET(0x3E9A, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
CHIPSET(0x3E9B, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
CHIPSET(0x3E94, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
-CHIPSET(0x3EA0, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
-CHIPSET(0x3EA3, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
CHIPSET(0x3EA9, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
-CHIPSET(0x3EA2, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
CHIPSET(0x3EA5, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
CHIPSET(0x3EA6, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
CHIPSET(0x3EA7, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
CHIPSET(0x3EA8, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
+CHIPSET(0x3EA1, cfl_gt1, "Intel(R) HD Graphics (Whiskey Lake 2x6 GT1)")
+CHIPSET(0x3EA0, cfl_gt2, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT2)")
+CHIPSET(0x3EA2, cfl_gt3, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT3)")
+CHIPSET(0x3EA3, cfl_gt3, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT3)")
+CHIPSET(0x3EA4, cfl_gt3, "Intel(R) HD Graphics (Whiskey Lake 3x8 GT3)")
Documentation says 0x3EA3 has only 12 EUs. Doesn't sound like GT3.
CHIPSET(0x5A49, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)")
CHIPSET(0x5A4A, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)")
CHIPSET(0x5A41, cnl_3x8, "Intel(R) HD Graphics (Cannonlake 3x8 GT1)")
diff --git a/src/intel/compiler/test_eu_validate.cpp
b/src/intel/compiler/test_eu_validate.cpp
index 744ae5806d..73300b2312 100644
--- a/src/intel/compiler/test_eu_validate.cpp
+++ b/src/intel/compiler/test_eu_validate.cpp
@@ -43,6 +43,7 @@ static const struct gen_info {
{ "aml", },
{ "glk", },
{ "cfl", },
+ { "whl", },
{ "cnl", },
{ "icl", },
};
diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 3cece52a04..0f12d17a84 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -60,6 +60,7 @@ gen_device_name_to_pci_device_id(const char *name)
{ "aml", 0x591C },
{ "glk", 0x3185 },
{ "cfl", 0x3E9B },
+ { "whl", 0x3EA1 },
{ "cnl", 0x5a52 },
{ "icl", 0x8a52 },
};
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 55672fa073..7de20f3d7a 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -282,7 +282,7 @@ int main(int argc, char *argv[])
if (id < 0) {
fprintf(stderr, "can't parse gen: '%s', expected brw, g4x, ilk, "
"snb, ivb, hsw, byt, bdw, chv, skl, bxt, kbl, "
-"aml, glk, cfl, cnl, icl", optarg);
+"aml, glk, cfl, whl, cnl, icl", optarg);
exit(EXIT_FAILURE);
} else {
pci_id = id;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader cache backward compatibility
On 31/08/18 19:40, Bas Nieuwenhuizen wrote:
+TImothy
On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson wrote:
Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've
recently run into some issues with the mesa shader cache. Flatpak has
a app/runtime split where the runtime is shared between app and
provides /usr. The runtime contains a version of mesa, but this can be
overridden by runtime extensions to add other OpenGL drivers.
Each app has a separate $XDG_CACHE_HOME, pointing into the per-app
writable storage. For example, gedit has
XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This
causes mesa to store the shader cache per-app in
$XDG_CACHE_HOME/mesa_shader_cache.
In the regular case this works fine, but sometimes the version of mesa
is changed, with the shader cache being left in place. For example,
sometimes we update the mesa version in the runtime, and sometimes the
app switches to a new runtime which has a different mesa version.
Such updates have caused a lot of issues for us, ranging from direct
crashes at startup as in
https://github.com/flatpak/flatpak/issues/2052 and sometimes just
super-slow performance. In all cases, blowing away the shader cache
directory fixed all issues.
The steam flatpak has a bunch of workaround for the cache:
https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35
But we can't expect every app to do this.
So, my question is, is the cache supposed to be backward compatible,
or at least versioned? Are we missing something in our mesa builds to
make that work? Is this fixed somewhere with a patch i can backport?
And if not, do we need to add some magic to flatpak to automatically
clean up the shader cache after an update?
It is supposed to be versioned automatically by mesa.
Hi Alexander,
We depend on build timestamps of the mesa/llvm binaries when generating
the sha for cache items. So if flatpak results in two versions of mesa
having the same timestamp then there is likely going to be issues.
static inline bool
disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
{
Dl_info info;
struct stat st;
if (!dladdr(ptr, ) || !info.dli_fname) {
return false;
}
if (stat(info.dli_fname, )) {
return false;
}
*timestamp = st.st_mtime;
return true;
}
Tim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.com alexander.lars...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107767] Segfault with standalone compiler and --dump-builder
https://bugs.freedesktop.org/show_bug.cgi?id=107767 --- Comment #1 from Sergii Romantsov --- Patch series: https://patchwork.freedesktop.org/series/48998/ -- 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 v1 1/2] glsl/standalone: segfault with --dump-builder for ir_texture
Shader that contains builtin functions texture* causes segfault for
standalone compiler with parameter --dump-builder.
Added handling of ir_texture as rhs of assignment.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107767
Signed-off-by: Sergii Romantsov
---
src/compiler/glsl/ir_builder_print_visitor.cpp | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/compiler/glsl/ir_builder_print_visitor.cpp
b/src/compiler/glsl/ir_builder_print_visitor.cpp
index da04868..eb98f41 100644
--- a/src/compiler/glsl/ir_builder_print_visitor.cpp
+++ b/src/compiler/glsl/ir_builder_print_visitor.cpp
@@ -60,6 +60,8 @@ public:
virtual ir_visitor_status visit_leave(class ir_swizzle *);
virtual ir_visitor_status visit_leave(class ir_return *);
+ virtual ir_visitor_status visit_enter(ir_texture *ir);
+
private:
void print_with_indent(const char *fmt, ...);
void print_without_indent(const char *fmt, ...);
@@ -446,6 +448,7 @@ ir_builder_print_visitor::print_without_declaration(const
ir_swizzle *ir)
print_without_declaration(ir->val);
print_without_indent(")");
} else {
+ assert(he);
print_without_indent("swizzle_%c(r%04X)",
swiz[ir->mask.x],
(unsigned)(uintptr_t) he->data);
@@ -453,6 +456,7 @@ ir_builder_print_visitor::print_without_declaration(const
ir_swizzle *ir)
} else {
static const char swiz[4] = { 'X', 'Y', 'Z', 'W' };
+ assert(he);
print_without_indent("swizzle(r%04X, MAKE_SWIZZLE4(SWIZZLE_%c,
SWIZZLE_%c, SWIZZLE_%c, SWIZZLE_%c), %u)",
(unsigned)(uintptr_t) he->data,
swiz[ir->mask.x],
@@ -527,6 +531,7 @@ ir_builder_print_visitor::visit_leave(ir_assignment *ir)
_mesa_hash_table_search(index_map, ir->rhs);
assert(ir->condition == NULL);
+ assert(ir->lhs && ir->rhs);
print_with_indent("body.emit(assign(r%04X, r%04X, 0x%02x));\n\n",
(unsigned)(uintptr_t) he_lhs->data,
@@ -684,6 +689,20 @@ ir_builder_print_visitor::visit_leave(ir_return *ir)
}
ir_visitor_status
+ir_builder_print_visitor::visit_enter(ir_texture *ir)
+{
+ const struct hash_entry *const he =
+ _mesa_hash_table_search(index_map, ir);
+ if (!he)
+ {
+ const unsigned my_index = next_ir_index++;
+ _mesa_hash_table_insert(index_map, ir, (void *)(uintptr_t) my_index);
+ }
+
+ return visit_continue;
+}
+
+ir_visitor_status
ir_builder_print_visitor::visit_leave(ir_call *ir)
{
const unsigned my_index = next_ir_index++;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v1 2/2] glsl/standalone: --dump-builder: dump of ir_texture
For standalone compilation with parameter --dump-builder in dump
absent description of texture invocation.
Added the simplest handling.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107767
Signed-off-by: Sergii Romantsov
---
src/compiler/glsl/ir_builder_print_visitor.cpp | 51 ++
1 file changed, 51 insertions(+)
diff --git a/src/compiler/glsl/ir_builder_print_visitor.cpp
b/src/compiler/glsl/ir_builder_print_visitor.cpp
index eb98f41..679d1b8 100644
--- a/src/compiler/glsl/ir_builder_print_visitor.cpp
+++ b/src/compiler/glsl/ir_builder_print_visitor.cpp
@@ -61,6 +61,7 @@ public:
virtual ir_visitor_status visit_leave(class ir_return *);
virtual ir_visitor_status visit_enter(ir_texture *ir);
+ virtual ir_visitor_status visit_leave(ir_texture *ir);
private:
void print_with_indent(const char *fmt, ...);
@@ -703,6 +704,56 @@ ir_builder_print_visitor::visit_enter(ir_texture *ir)
}
ir_visitor_status
+ir_builder_print_visitor::visit_leave(ir_texture *ir)
+{
+ const struct hash_entry *const he_lhs =
+ _mesa_hash_table_search(index_map, ir);
+ const struct hash_entry *const he_rhs_sampler =
+ _mesa_hash_table_search(index_map, ir->sampler);
+ const struct hash_entry *const he_rhs_coord =
+ _mesa_hash_table_search(index_map, ir->coordinate);
+ const struct hash_entry *const he_rhs_proj =
+ _mesa_hash_table_search(index_map, ir->projector);
+ const struct hash_entry *const he_rhs_comp =
+ _mesa_hash_table_search(index_map, ir->shadow_comparator);
+ const struct hash_entry *const he_rhs_offset =
+ _mesa_hash_table_search(index_map, ir->offset);
+ const struct hash_entry *const he_rhs_lodinfo = ir->op != ir_txd
+ ? _mesa_hash_table_search(index_map, ir->lod_info.lod) //use any member
due to union
+ : NULL;
+ const struct hash_entry *const he_rhs_lodinfo_pdx = ir->op == ir_txd
+ ? _mesa_hash_table_search(index_map, ir->lod_info.grad.dPdx)
+ : NULL;
+ const struct hash_entry *const he_rhs_lodinfo_pdy = ir->op == ir_txd
+ ? _mesa_hash_table_search(index_map, ir->lod_info.grad.dPdy)
+ : NULL;
+
+ print_with_indent("ir_texture *const r%04X = new(mem_ctx) ir_texture(%s,
r%04X",
+ he_lhs->data,
+ ir->opcode_string(),
+ he_rhs_sampler->data);
+ if (he_rhs_coord)
+ print_without_indent(", r%04X", he_rhs_coord->data);
+ if (he_rhs_proj)
+ print_without_indent(", r%04X", he_rhs_proj->data);
+ if (he_rhs_comp)
+ print_without_indent(", r%04X", he_rhs_comp->data);
+ if (he_rhs_offset)
+ print_without_indent(", r%04X", he_rhs_offset->data);
+ if (he_rhs_lodinfo)
+ print_without_indent(", r%04X", he_rhs_lodinfo->data);
+ if (he_rhs_lodinfo_pdx)
+ print_without_indent(", r%04X", he_rhs_lodinfo_pdx->data);
+ if (he_rhs_lodinfo_pdy)
+ print_without_indent(", r%04X", he_rhs_lodinfo_pdy->data);
+ print_without_indent(");\n");
+
+ print_with_indent("body.emit(r%04X);\n", he_lhs->data);
+
+ return visit_continue;
+}
+
+ir_visitor_status
ir_builder_print_visitor::visit_leave(ir_call *ir)
{
const unsigned my_index = next_ir_index++;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107767] Segfault with standalone compiler and --dump-builder
https://bugs.freedesktop.org/show_bug.cgi?id=107767 Bug ID: 107767 Summary: Segfault with standalone compiler and --dump-builder Product: Mesa Version: git Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: glsl-compiler Assignee: mesa-dev@lists.freedesktop.org Reporter: sergii.romant...@globallogic.com QA Contact: intel-3d-b...@lists.freedesktop.org Created attachment 141392 --> https://bugs.freedesktop.org/attachment.cgi?id=141392=edit shader_big.frag - shader causes segfault Usage of command mesa/src/compiler/glsl_compiler --version 450 --dump-builder ./shader_big.frag gives segfault with git-master 3e04c67950fe3edcabedc72516de63c5c20510e2 -- 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
Re: [Mesa-dev] shader cache backward compatibility
+TImothy On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson wrote: > > Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've > recently run into some issues with the mesa shader cache. Flatpak has > a app/runtime split where the runtime is shared between app and > provides /usr. The runtime contains a version of mesa, but this can be > overridden by runtime extensions to add other OpenGL drivers. > > Each app has a separate $XDG_CACHE_HOME, pointing into the per-app > writable storage. For example, gedit has > XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This > causes mesa to store the shader cache per-app in > $XDG_CACHE_HOME/mesa_shader_cache. > > In the regular case this works fine, but sometimes the version of mesa > is changed, with the shader cache being left in place. For example, > sometimes we update the mesa version in the runtime, and sometimes the > app switches to a new runtime which has a different mesa version. > > Such updates have caused a lot of issues for us, ranging from direct > crashes at startup as in > https://github.com/flatpak/flatpak/issues/2052 and sometimes just > super-slow performance. In all cases, blowing away the shader cache > directory fixed all issues. > > The steam flatpak has a bunch of workaround for the cache: > > https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35 > But we can't expect every app to do this. > > So, my question is, is the cache supposed to be backward compatible, > or at least versioned? Are we missing something in our mesa builds to > make that work? Is this fixed somewhere with a patch i can backport? > And if not, do we need to add some magic to flatpak to automatically > clean up the shader cache after an update? It is supposed to be versioned automatically by mesa. > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander LarssonRed Hat, Inc >al...@redhat.com alexander.lars...@gmail.com > ___ > 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] swr/rast: Rename createInstructionSimplifierPass with llvm-7.0.
Tested-by: Juan A. Suarez
J.A.
On Sat, 2018-06-30 at 15:10 +, Vinson Lee wrote:
> Fix build error after llvm-7.0svn r336028 ("[instsimplify] Move the
> instsimplify pass to use more obvious file names and diretory.").
>
> rasterizer/jitter/blend_jit.cpp:873:20: error: use of undeclared identifier
> 'createInstructionSimplifierPass'
> passes.add(createInstructionSimplifierPass());
>^
>
> Signed-off-by: Vinson Lee
> ---
> src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp | 4
> src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp | 4
> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 1 +
> src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp | 4
> 4 files changed, 13 insertions(+)
>
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp
> b/src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp
> index f89c502db7d7..1d6fb405dd6b 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp
> @@ -870,7 +870,11 @@ struct BlendJit : public Builder
> passes.add(createCFGSimplificationPass());
> passes.add(createEarlyCSEPass());
> passes.add(createInstructionCombiningPass());
> +#if LLVM_VERSION_MAJOR >= 7
> +passes.add(createInstSimplifyLegacyPass());
> +#else
> passes.add(createInstructionSimplifierPass());
> +#endif
> passes.add(createConstantPropagationPass());
> passes.add(createSCCPPass());
> passes.add(createAggressiveDCEPass());
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
> b/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
> index b4d326ebdcc2..26972cddc251 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
> @@ -294,7 +294,11 @@ Function* FetchJit::Create(const FETCH_COMPILE_STATE&
> fetchState)
> optPasses.add(createCFGSimplificationPass());
> optPasses.add(createEarlyCSEPass());
> optPasses.add(createInstructionCombiningPass());
> +#if LLVM_VERSION_MAJOR >= 7
> +optPasses.add(createInstSimplifyLegacyPass());
> +#else
> optPasses.add(createInstructionSimplifierPass());
> +#endif
> optPasses.add(createConstantPropagationPass());
> optPasses.add(createSCCPPass());
> optPasses.add(createAggressiveDCEPass());
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> index 47f717bfc2a1..760d1dab80ee 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> @@ -70,6 +70,7 @@ using PassManager = llvm::legacy::PassManager;
> #if LLVM_VERSION_MAJOR >= 7
> #include "llvm/Transforms/Utils.h"
> #include "llvm/Transforms/InstCombine/InstCombine.h"
> +#include "llvm/Transforms/Scalar/InstSimplifyPass.h"
> #endif
> #include "llvm/Support/Host.h"
> #include "llvm/Support/DynamicLibrary.h"
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp
> b/src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp
> index 8f86af2a4b41..5c1555280fce 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp
> @@ -306,7 +306,11 @@ struct StreamOutJit : public Builder
> passes.add(createCFGSimplificationPass());
> passes.add(createEarlyCSEPass());
> passes.add(createInstructionCombiningPass());
> +#if LLVM_VERSION_MAJOR >= 7
> +passes.add(createInstSimplifyLegacyPass());
> +#else
> passes.add(createInstructionSimplifierPass());
> +#endif
> passes.add(createConstantPropagationPass());
> passes.add(createSCCPPass());
> passes.add(createAggressiveDCEPass());
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false
https://bugs.freedesktop.org/show_bug.cgi?id=105333 Timothy Arceri changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/galliu ||mnine -- 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] shader cache backward compatibility
Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've recently run into some issues with the mesa shader cache. Flatpak has a app/runtime split where the runtime is shared between app and provides /usr. The runtime contains a version of mesa, but this can be overridden by runtime extensions to add other OpenGL drivers. Each app has a separate $XDG_CACHE_HOME, pointing into the per-app writable storage. For example, gedit has XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This causes mesa to store the shader cache per-app in $XDG_CACHE_HOME/mesa_shader_cache. In the regular case this works fine, but sometimes the version of mesa is changed, with the shader cache being left in place. For example, sometimes we update the mesa version in the runtime, and sometimes the app switches to a new runtime which has a different mesa version. Such updates have caused a lot of issues for us, ranging from direct crashes at startup as in https://github.com/flatpak/flatpak/issues/2052 and sometimes just super-slow performance. In all cases, blowing away the shader cache directory fixed all issues. The steam flatpak has a bunch of workaround for the cache: https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35 But we can't expect every app to do this. So, my question is, is the cache supposed to be backward compatible, or at least versioned? Are we missing something in our mesa builds to make that work? Is this fixed somewhere with a patch i can backport? And if not, do we need to add some magic to flatpak to automatically clean up the shader cache after an update? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.com alexander.lars...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: don't expose linear depth surfaces on SI/CIK/VI either.
Reviewed-by: Bas Nieuwenhuizen
On Fri, Aug 31, 2018 at 7:56 AM Dave Airlie wrote:
>
> From: Dave Airlie
>
> ac_surface.c: gfx6_compute_surface says
> /* DB doesn't support linear layouts. */
>
> Now if we expose linear depth and create a linear depth image
> and use CmdCopyImage to copy into it, we can't map the underlying
> memory and read it linearly which I think should work.
> ---
> src/amd/vulkan/radv_formats.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
> index 6253c27b95d..e1b4b5e830f 100644
> --- a/src/amd/vulkan/radv_formats.c
> +++ b/src/amd/vulkan/radv_formats.c
> @@ -645,9 +645,8 @@ radv_physical_device_get_format_properties(struct
> radv_physical_device *physical
> if (radv_is_filter_minmax_format_supported(format))
> tiled |=
> VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT;
>
> - /* GFX9 doesn't support linear depth surfaces */
> - if (physical_device->rad_info.chip_class >= GFX9)
> - linear = 0;
> + /* Don't support linear depth surfaces */
> + linear = 0;
> }
> } else {
> bool linear_sampling;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: update calendar to extended the 18.1 cycle by one more release
On Thu, 2018-08-30 at 18:03 +0300, Andres Gomez wrote: > Due to having 2 additional RCs for 18.2. > > Cc: Dylan Baker > Cc: Juan A. Suarez > Cc: Emil Velikov > Signed-off-by: Andres Gomez Acked-by: Juan A. Suarez > --- > docs/release-calendar.html | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/docs/release-calendar.html b/docs/release-calendar.html > index d4c9ab86967..2e3bb8a 100644 > --- a/docs/release-calendar.html > +++ b/docs/release-calendar.html > @@ -39,14 +39,20 @@ if you'd like to nominate a patch in the next stable > release. > Notes > > > -18.1 > +18.1 > 2018-09-07 > 18.1.8 > Dylan Baker > + > + > + > +2018-09-21 > +18.1.9 > +Dylan Baker > Last planned 18.1.x release > > > -18.2 > +18.2 > 2018-09-05 > 18.2.0-rc6 > Andres Gomez ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: ignore VAO IDs equal to 0 in glDeleteVertexArrays
On 08/30/2018 07:42 PM, Marek Olšák wrote:
> Sadly, there are no tests for this.
Ok... I just sent one to the piglit list. It should be easy enough to
create a few more for other glDeleteFoo functions. I'll save that for
during boring meetings. ;)
> Marek
>
> On Thu, Aug 30, 2018 at 6:24 PM, Ian Romanick wrote:
>> This patch is
>>
>> Reviewed-by: Ian Romanick
>>
>> Is there a piglit test? I wonder how many other glDeleteFoo functions
>> mishandle the id=0 case. :(
>>
>> On 08/30/2018 12:16 PM, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> This fixes a firefox crash.
>>>
>>> Fixes: 781a78914c798dc64005b37c6ca1224ce06803fc
>>> ---
>>> src/mesa/main/arrayobj.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
>>> index a23031fe182..6e0665c0e5d 100644
>>> --- a/src/mesa/main/arrayobj.c
>>> +++ b/src/mesa/main/arrayobj.c
>>> @@ -1007,20 +1007,24 @@ _mesa_BindVertexArray(GLuint id)
>>> *
>>> * \param n Number of array objects to delete.
>>> * \param idsArray of \c n array object IDs.
>>> */
>>> static void
>>> delete_vertex_arrays(struct gl_context *ctx, GLsizei n, const GLuint *ids)
>>> {
>>> GLsizei i;
>>>
>>> for (i = 0; i < n; i++) {
>>> + /* IDs equal to 0 should be silently ignored. */
>>> + if (!ids[i])
>>> + continue;
>>> +
>>>struct gl_vertex_array_object *obj = _mesa_lookup_vao(ctx, ids[i]);
>>>
>>>if (obj) {
>>> assert(obj->Name == ids[i]);
>>>
>>> /* If the array object is currently bound, the spec says "the
>>> binding
>>>* for that object reverts to zero and the default vertex array
>>>* becomes current."
>>>*/
>>> if (obj == ctx->Array.VAO)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: update calendar to extended the 18.1 cycle by one more release
Quoting Andres Gomez (2018-08-30 08:03:04) > Due to having 2 additional RCs for 18.2. > > Cc: Dylan Baker > Cc: Juan A. Suarez > Cc: Emil Velikov > Signed-off-by: Andres Gomez > --- > docs/release-calendar.html | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/docs/release-calendar.html b/docs/release-calendar.html > index d4c9ab86967..2e3bb8a 100644 > --- a/docs/release-calendar.html > +++ b/docs/release-calendar.html > @@ -39,14 +39,20 @@ if you'd like to nominate a patch in the next stable > release. > Notes > > > -18.1 > +18.1 > 2018-09-07 > 18.1.8 > Dylan Baker > + > + > + > +2018-09-21 > +18.1.9 > +Dylan Baker > Last planned 18.1.x release > > > -18.2 > +18.2 > 2018-09-05 > 18.2.0-rc6 > Andres Gomez > -- > 2.18.0 > I was going to suggest this as well, Acked-by: Dylan Baker signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 97003] [d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders
https://bugs.freedesktop.org/show_bug.cgi?id=97003 Timothy Arceri changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/galliu ||mnine -- 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] Bounding box avx2 intrinsic algorithm for openGL/GLES
From: "J Karanje, Kedar" The feature is enabled by default during make however we need to add the following to drirc to enable the feature at runtime. vbo: Main algorithm & code to check for MVP & vertex position location Build Files: Flags to enable BBOX Code and check AVX version compiler: Code to recognize simple shader (gl_position is a simple function of mvp and vertex) i965 & util: dri query to check if feature is enabled vbo: Implements a bounding box algorithm for mesa,we hook into the default drawelements and drawrangelements and the MVP & vertex positions location and the corresponding program is got,we re-create the frustum planes using this data and also create a box around the object and use the 8 vertices (box vertices) and check if the box is within the frustum or not, we drop the draw calls that are completely outside the view frustum and go for sub-boxes for objects that are intersecting with the frustum planes. The current patch has been verified on KBL+Ubuntu 16.04, we noticed 8~10% improvements in GFxBench TREX offscreen and ~2% for Manhattan offscreen, Platforms where avx2 is not supported shall still see ~6-8% improvement, the other KPIs were not impacted. Based on empirical data we have set minimum vertex count as 999 and the sub-box size as 198, this provides the best results, we have also implemented some level of caching for the box co-od and frustum plane co-od. we have also optimized some algorithms to use avx2 when a target supports it. Shader classification code is currently in hir and we have got review comments to move the same to NIR. Signed-off-by: Aravindan Muthukumar Signed-off-by: Yogesh Marathe --- Android.common.mk| 19 + configure.ac | 34 +- src/compiler/glsl/ast_to_hir.cpp | 168 +++- src/compiler/glsl/glsl_parser_extras.cpp | 10 + src/compiler/glsl/glsl_parser_extras.h |7 + src/compiler/glsl/linker.cpp | 18 + src/intel/common/gen_debug.c |7 + src/mesa/Makefile.sources| 11 + src/mesa/drivers/dri/i965/brw_context.c | 17 + src/mesa/drivers/dri/i965/intel_screen.c |4 + src/mesa/main/bufferobj.c| 19 + src/mesa/main/mtypes.h | 51 + src/mesa/program/Android.mk |1 + src/mesa/program/program.c |3 + src/mesa/vbo/vbo_bbox.c | 1538 ++ src/mesa/vbo/vbo_bbox.h | 383 src/mesa/vbo/vbo_bbox_cache.c| 195 src/mesa/vbo/vbo_context.c | 11 +- src/mesa/vbo/vbo_exec_array.c| 37 +- src/util/00-mesa-defaults.conf |4 + src/util/xmlpool/t_options.h |5 + 21 files changed, 2535 insertions(+), 7 deletions(-) mode change 100644 => 100755 src/compiler/glsl/ast_to_hir.cpp create mode 100644 src/mesa/vbo/vbo_bbox.c create mode 100644 src/mesa/vbo/vbo_bbox.h create mode 100644 src/mesa/vbo/vbo_bbox_cache.c diff --git a/Android.common.mk b/Android.common.mk index aa1b266..efd6792 100644 --- a/Android.common.mk +++ b/Android.common.mk @@ -21,6 +21,8 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER # DEALINGS IN THE SOFTWARE. +MESA_BBOX_ENABLE=true + ifeq ($(LOCAL_IS_HOST_MODULE),true) LOCAL_CFLAGS += -D_GNU_SOURCE endif @@ -80,6 +82,10 @@ LOCAL_CFLAGS += \ -fno-trapping-math \ -Wno-sign-compare +ifeq ($(MESA_BBOX_ENABLE),true) +LOCAL_CFLAGS += -DMESA_BBOX_OPT +endif + LOCAL_CPPFLAGS += \ -D__STDC_CONSTANT_MACROS \ -D__STDC_FORMAT_MACROS \ @@ -87,6 +93,10 @@ LOCAL_CPPFLAGS += \ -Wno-error=non-virtual-dtor \ -Wno-non-virtual-dtor +ifeq ($(MESA_BBOX_ENABLE),true) +LOCAL_CPPFLAGS += -DMESA_BBOX_OPT +endif + # mesa requires at least c99 compiler LOCAL_CONLYFLAGS += \ -std=c99 @@ -98,6 +108,15 @@ ifeq ($(filter 5 6 7 8 9, $(MESA_ANDROID_MAJOR_VERSION)),) LOCAL_CFLAGS += -DHAVE_TIMESPEC_GET endif +ifeq ($(MESA_BBOX_ENABLE),true) +#if defined(CONFIG_AS_AVX) +LOCAL_CONLYFLAGS += -mavx +#elif +LOCAL_CONLYFLAGS += -msse4.1 +#endif +endif + + ifeq ($(strip $(MESA_ENABLE_ASM)),true) ifeq ($(TARGET_ARCH),x86) LOCAL_CFLAGS += \ diff --git a/configure.ac b/configure.ac index 4d9d9e5..dcdbcf3 100644 --- a/configure.ac +++ b/configure.ac @@ -278,7 +278,8 @@ _SAVE_LDFLAGS="$LDFLAGS" _SAVE_CPPFLAGS="$CPPFLAGS" dnl Compiler macros -DEFINES="-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS" +DEFINES="-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DMESA_BBOX_OPT" +dnl DEFINES="-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS" AC_SUBST([DEFINES]) android=no case "$host_os" in @@ -295,10 +296,38 @@ esac AM_CONDITIONAL(HAVE_ANDROID, test "x$android" = xyes) + +dnl Conditional parameters for enabling BBOX file compilation in Makefile
Re: [Mesa-dev] [PATCH] radv: don't expose linear depth surfaces on SI/CIK/VI either.
On Fri, Aug 31, 2018 at 1:57 AM Dave Airlie wrote:
>
> From: Dave Airlie
>
> ac_surface.c: gfx6_compute_surface says
> /* DB doesn't support linear layouts. */
I think r100 was the last chip to support linear depth surfaces.
Alex
>
> Now if we expose linear depth and create a linear depth image
> and use CmdCopyImage to copy into it, we can't map the underlying
> memory and read it linearly which I think should work.
> ---
> src/amd/vulkan/radv_formats.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
> index 6253c27b95d..e1b4b5e830f 100644
> --- a/src/amd/vulkan/radv_formats.c
> +++ b/src/amd/vulkan/radv_formats.c
> @@ -645,9 +645,8 @@ radv_physical_device_get_format_properties(struct
> radv_physical_device *physical
> if (radv_is_filter_minmax_format_supported(format))
> tiled |=
> VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT;
>
> - /* GFX9 doesn't support linear depth surfaces */
> - if (physical_device->rad_info.chip_class >= GFX9)
> - linear = 0;
> + /* Don't support linear depth surfaces */
> + linear = 0;
> }
> } else {
> bool linear_sampling;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
