Re: [Mesa-dev] [RFC PATCH] nir/algebraic: Remove problematic "optimization"
Ran it through shader-db. No changes. Feel free to stuff that in the
commit message somewhere.
Reviewed-by: Jason Ekstrand
On Wed, May 15, 2019 at 12:04 AM Alyssa Rosenzweig
wrote:
> This line is no longer relevant now that booleans are 1-bit, and in fact
> causes issues (infinite progress loop between algebraic optimizations
> and copy prop) with constant vector masks.
>
> Signed-off-by: Alyssa Rosenzweig
> Cc: Jason Ekstrand
> ---
> src/compiler/nir/nir_opt_algebraic.py | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_algebraic.py
> b/src/compiler/nir/nir_opt_algebraic.py
> index 1c7b3597c1f..89d07aa1261 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -621,9 +621,6 @@ optimizations = [
> (('bcsel', True, b, c), b),
> (('bcsel', False, b, c), c),
> (('bcsel', a, ('b2f(is_used_once)', 'b@32'), ('b2f', 'c@32')),
> ('b2f', ('bcsel', a, b, c))),
> - # The result of this should be hit by constant propagation and, in the
> - # next round of opt_algebraic, get picked up by one of the above two.
> - (('bcsel', '#a', b, c), ('bcsel', ('ine', 'a', 0), b, c)),
>
> (('bcsel', a, b, b), b),
> (('fcsel', a, b, b), b),
> --
> 2.20.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] panfrost/midgard: Add load/store opcodes
This commit adds a bunch of new load/store opcodes, largely related to
OpenCL, as well as adjusting the name of existing opcodes to be more
uniform. The immediate effect is compute shaders are substantially
easier to interpret now.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 10 +-
.../drivers/panfrost/midgard/helpers.h| 6 +-
.../drivers/panfrost/midgard/midgard.h| 129 ++
.../panfrost/midgard/midgard_compile.c| 38 +++---
4 files changed, 131 insertions(+), 52 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index c893bc89a6c..a9e443fa67c 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -855,10 +855,10 @@ static bool
is_op_varying(unsigned op)
{
switch (op) {
-case midgard_op_store_vary_16:
-case midgard_op_store_vary_32:
-case midgard_op_load_vary_16:
-case midgard_op_load_vary_32:
+case midgard_op_st_vary_16:
+case midgard_op_st_vary_32:
+case midgard_op_ld_vary_16:
+case midgard_op_ld_vary_32:
return true;
}
@@ -881,7 +881,7 @@ print_load_store_instr(uint64_t data,
int address = word->address;
-if (word->op == midgard_op_load_uniform_32) {
+if (word->op == midgard_op_ld_uniform_32) {
/* Uniforms use their own addressing scheme */
int lo = word->varying_parameters >> 7;
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/drivers/panfrost/midgard/helpers.h
index dc2de15931b..7e7b41b2117 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -23,13 +23,13 @@
*/
#define OP_IS_STORE_VARY(op) (\
- op == midgard_op_store_vary_16 || \
- op == midgard_op_store_vary_32 \
+ op == midgard_op_st_vary_16 || \
+ op == midgard_op_st_vary_32 \
)
#define OP_IS_STORE(op) (\
OP_IS_STORE_VARY(op) || \
-op == midgard_op_store_cubemap_coords \
+op == midgard_op_st_cubemap_coords \
)
#define OP_IS_MOVE(op) ( \
diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h
b/src/gallium/drivers/panfrost/midgard/midgard.h
index 91d1c075f96..4a4ec0e4542 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard.h
@@ -345,20 +345,63 @@ typedef enum {
/* Unclear why this is on the L/S unit, but (with an address of 0,
* appropriate swizzle, magic constant 0x24, and xy mask?) moves fp32
cube
* map coordinates in r27 to its cube map texture coordinate
- * destination (e.g r29). 0x4 magic for loading from fp16 instead */
-
-midgard_op_store_cubemap_coords = 0x0E,
-
-midgard_op_load_attr_16 = 0x95,
-midgard_op_load_attr_32 = 0x94,
-midgard_op_load_vary_16 = 0x99,
-midgard_op_load_vary_32 = 0x98,
-midgard_op_load_color_buffer_16 = 0x9D,
-midgard_op_load_color_buffer_8 = 0xBA,
-midgard_op_load_uniform_16 = 0xAC,
-midgard_op_load_uniform_32 = 0xB0,
-midgard_op_store_vary_16 = 0xD5,
-midgard_op_store_vary_32 = 0xD4
+ * destination (e.g r29). 0x4 magic for lding from fp16 instead */
+
+midgard_op_st_cubemap_coords = 0x0E,
+
+/* Used in OpenCL. Probably can ld other things as well */
+midgard_op_ld_global_id = 0x10,
+
+/* val in r27.y, address embedded, outputs result to argument. Invert
val for sub. Let val = +-1 for inc/dec. */
+midgard_op_atomic_add = 0x40,
+midgard_op_atomic_and = 0x44,
+midgard_op_atomic_or = 0x48,
+midgard_op_atomic_xor = 0x4C,
+
+midgard_op_atomic_imin = 0x50,
+midgard_op_atomic_umin = 0x54,
+midgard_op_atomic_imax = 0x58,
+midgard_op_atomic_umax = 0x5C,
+
+midgard_op_atomic_xchg = 0x60,
+
+/* Used for compute shader's __global arguments, __local variables (or
+ * for register spilling) */
+
+midgard_op_ld_char = 0x81,
+midgard_op_ld_char2 = 0x84,
+midgard_op_ld_short = 0x85,
+midgard_op_ld_char4 = 0x88, /* short2, int, float */
+midgard_op_ld_short4 = 0x8C, /* int2, float2, long */
+midgard_op_ld_int4 = 0x90, /* float4, long2 */
+
+midgard_op_ld_attr_32 = 0x94,
+midgard_op_ld_attr_16 = 0x95,
+midgard_op_ld_attr_32i = 0x97,
+midgard_op_ld_vary_32 = 0x98,
+midgard_op_ld_vary_16 = 0x99,
+midgard_op_ld_vary_32i = 0x9B,
+midgard_op_ld_color_buffer_16 = 0x9D,
+
+midgard_op_ld_uniform_16 = 0xAC,
+
+midgard_op_ld_uniform_32 = 0xB0,
+midgard_op_ld_color_buffer_8 = 0xBA,
+
+
[Mesa-dev] [PATCH] auxiliary/draw: fix crash with zero-stride draw auto
From: Roland Scheidegger transform feedback draws get the number of vertices from the transform feedback object. In draw, we'll figure this out with the number of bytes written divided by the stride. However, it is apparently possible we end up with a stride of 0 there (not entirely sure it could happen with GL). Probably when nothing was actually ever written (so we don't actually have a stride set). Just avoid the division by zero by setting the count to 0. --- src/gallium/auxiliary/draw/draw_pt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/draw/draw_pt.c b/src/gallium/auxiliary/draw/draw_pt.c index 50286149cd4..eeebca30ce7 100644 --- a/src/gallium/auxiliary/draw/draw_pt.c +++ b/src/gallium/auxiliary/draw/draw_pt.c @@ -440,7 +440,8 @@ resolve_draw_info(const struct pipe_draw_info *raw_info, struct draw_so_target *target = (struct draw_so_target *)info->count_from_stream_output; assert(vertex_buffer != NULL); - info->count = target->internal_offset / vertex_buffer->stride; + info->count = vertex_buffer->stride == 0 ? 0 : + target->internal_offset / vertex_buffer->stride; /* Stream output draw can not be indexed */ debug_assert(!info->index_size); -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs/features: don't list EXT extensions in a list for KHR/ARB/OES extensions
That sounds OK, but then the number of EXT extensions is pretty high. Marek On Wed, May 15, 2019 at 10:39 AM Gert Wollny wrote: > How about moving these extensions to another (new) section? I think it > is nice to have a one-stop place to find out what is supported. > > Best, > Gert > > On Di, 2019-05-14 at 16:07 -0400, Marek Olšák wrote: > > From: Marek Olšák > > > > --- > > docs/features.txt | 10 -- > > 1 file changed, 10 deletions(-) > > > > diff --git a/docs/features.txt b/docs/features.txt > > index 38d6186dbe1..b1799550a0c 100644 > > --- a/docs/features.txt > > +++ b/docs/features.txt > > @@ -309,30 +309,20 @@ Khronos, ARB, and OES extensions that are not > > part of any OpenGL or OpenGL ES ve > >GL_ARB_seamless_cubemap_per_texture DONE > > (freedreno, i965, nvc0, radeonsi, r600, softpipe, swr, virgl) > >GL_ARB_shader_ballot DONE > > (i965/gen8+, nvc0, radeonsi) > >GL_ARB_shader_clock DONE > > (i965/gen7+, nv50, nvc0, r600, radeonsi, virgl) > >GL_ARB_shader_stencil_export DONE > > (i965/gen9+, r600, radeonsi, softpipe, llvmpipe, swr, virgl) > >GL_ARB_shader_viewport_layer_arrayDONE > > (i965/gen6+, nvc0, radeonsi) > >GL_ARB_sparse_buffer DONE > > (radeonsi/CIK+) > >GL_ARB_sparse_texture not started > >GL_ARB_sparse_texture2not started > >GL_ARB_sparse_texture_clamp not started > >GL_ARB_texture_filter_minmax not started > > - GL_EXT_memory_object DONE > > (radeonsi) > > - GL_EXT_memory_object_fd DONE > > (radeonsi) > > - GL_EXT_memory_object_win32not started > > - GL_EXT_render_snorm DONE (i965, > > radeonsi) > > - GL_EXT_semaphore DONE > > (radeonsi) > > - GL_EXT_semaphore_fd DONE > > (radeonsi) > > - GL_EXT_semaphore_win32not started > > - GL_EXT_sRGB_write_control DONE (all > > drivers that support GLES 3.0+) > > - GL_EXT_texture_norm16 DONE > > (freedreno, i965, r600, radeonsi, nvc0) > > - GL_EXT_texture_sRGB_R8DONE (all > > drivers that support GLES 3.0+) > >GL_KHR_blend_equation_advanced_coherent DONE > > (i965/gen9+) > >GL_KHR_texture_compression_astc_hdr DONE > > (i965/bxt) > >GL_KHR_texture_compression_astc_sliced_3d DONE > > (i965/gen9+, radeonsi) > >GL_OES_depth_texture_cube_map DONE (all > > drivers that support GLSL 1.30+) > >GL_OES_EGL_image DONE (all > > drivers) > >GL_OES_EGL_image_external DONE (all > > drivers) > >GL_OES_EGL_image_external_essl3 DONE (all > > drivers) > >GL_OES_required_internalformatDONE (all > > drivers) > >GL_OES_surfaceless_contextDONE (all > > drivers) > >GL_OES_texture_compression_astc DONE (core > > only) > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ac: treat Mullins as Kabini, remove the enum
From: Marek Olšák
it's the same design
---
include/pci_ids/radeonsi_pci_ids.h| 32 +--
src/amd/common/ac_gpu_info.c | 2 --
src/amd/common/ac_llvm_util.c | 2 --
src/amd/common/ac_surface.c | 4 ---
src/amd/common/amd_family.h | 1 -
src/amd/vulkan/radv_device.c | 1 -
src/amd/vulkan/radv_pipeline.c| 3 +-
src/gallium/drivers/radeonsi/cik_sdma.c | 6 ++--
src/gallium/drivers/radeonsi/si_shader.c | 3 +-
.../winsys/radeon/drm/radeon_drm_winsys.c | 3 --
10 files changed, 20 insertions(+), 37 deletions(-)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index 75ac7761bb4..65ae163f231 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -98,36 +98,36 @@ CHIPSET(0x9836, KABINI)
CHIPSET(0x9837, KABINI)
CHIPSET(0x9838, KABINI)
CHIPSET(0x9839, KABINI)
CHIPSET(0x983A, KABINI)
CHIPSET(0x983B, KABINI)
CHIPSET(0x983C, KABINI)
CHIPSET(0x983D, KABINI)
CHIPSET(0x983E, KABINI)
CHIPSET(0x983F, KABINI)
-CHIPSET(0x9850, MULLINS)
-CHIPSET(0x9851, MULLINS)
-CHIPSET(0x9852, MULLINS)
-CHIPSET(0x9853, MULLINS)
-CHIPSET(0x9854, MULLINS)
-CHIPSET(0x9855, MULLINS)
-CHIPSET(0x9856, MULLINS)
-CHIPSET(0x9857, MULLINS)
-CHIPSET(0x9858, MULLINS)
-CHIPSET(0x9859, MULLINS)
-CHIPSET(0x985A, MULLINS)
-CHIPSET(0x985B, MULLINS)
-CHIPSET(0x985C, MULLINS)
-CHIPSET(0x985D, MULLINS)
-CHIPSET(0x985E, MULLINS)
-CHIPSET(0x985F, MULLINS)
+CHIPSET(0x9850, KABINI)
+CHIPSET(0x9851, KABINI)
+CHIPSET(0x9852, KABINI)
+CHIPSET(0x9853, KABINI)
+CHIPSET(0x9854, KABINI)
+CHIPSET(0x9855, KABINI)
+CHIPSET(0x9856, KABINI)
+CHIPSET(0x9857, KABINI)
+CHIPSET(0x9858, KABINI)
+CHIPSET(0x9859, KABINI)
+CHIPSET(0x985A, KABINI)
+CHIPSET(0x985B, KABINI)
+CHIPSET(0x985C, KABINI)
+CHIPSET(0x985D, KABINI)
+CHIPSET(0x985E, KABINI)
+CHIPSET(0x985F, KABINI)
CHIPSET(0x1304, KAVERI)
CHIPSET(0x1305, KAVERI)
CHIPSET(0x1306, KAVERI)
CHIPSET(0x1307, KAVERI)
CHIPSET(0x1309, KAVERI)
CHIPSET(0x130A, KAVERI)
CHIPSET(0x130B, KAVERI)
CHIPSET(0x130C, KAVERI)
CHIPSET(0x130D, KAVERI)
diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 171560d6f04..fc3dfc951e3 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -640,21 +640,20 @@ int
ac_get_gs_table_depth(enum chip_class chip_class, enum radeon_family family)
{
if (chip_class >= GFX9)
return -1;
switch (family) {
case CHIP_OLAND:
case CHIP_HAINAN:
case CHIP_KAVERI:
case CHIP_KABINI:
- case CHIP_MULLINS:
case CHIP_ICELAND:
case CHIP_CARRIZO:
case CHIP_STONEY:
return 16;
case CHIP_TAHITI:
case CHIP_PITCAIRN:
case CHIP_VERDE:
case CHIP_BONAIRE:
case CHIP_HAWAII:
case CHIP_TONGA:
@@ -674,21 +673,20 @@ ac_get_raster_config(struct radeon_info *info,
uint32_t *raster_config_p,
uint32_t *raster_config_1_p,
uint32_t *se_tile_repeat_p)
{
unsigned raster_config, raster_config_1, se_tile_repeat;
switch (info->family) {
/* 1 SE / 1 RB */
case CHIP_HAINAN:
case CHIP_KABINI:
- case CHIP_MULLINS:
case CHIP_STONEY:
raster_config = 0x;
raster_config_1 = 0x;
break;
/* 1 SE / 4 RBs */
case CHIP_VERDE:
raster_config = 0x124a;
raster_config_1 = 0x;
break;
/* 1 SE / 2 RBs (Oland is special) */
diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 69446863b95..a4e5ccb41da 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -100,22 +100,20 @@ const char *ac_get_llvm_processor_name(enum radeon_family
family)
case CHIP_HAINAN:
return "hainan";
case CHIP_BONAIRE:
return "bonaire";
case CHIP_KABINI:
return "kabini";
case CHIP_KAVERI:
return "kaveri";
case CHIP_HAWAII:
return "hawaii";
- case CHIP_MULLINS:
- return "mullins";
case CHIP_TONGA:
return "tonga";
case CHIP_ICELAND:
return "iceland";
case CHIP_CARRIZO:
return "carrizo";
case CHIP_FIJI:
return "fiji";
case CHIP_STONEY:
return "stoney";
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index a9433b9696c..28256352cb7 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -88,24 +88,20 @@ static void addrlib_family_rev_id(enum radeon_family family,
*addrlib_revid = get_first(AMDGPU_SPECTRE_RANGE);
Re: [Mesa-dev] [PATCH 2/2] ac: rename SI-CIK-VI to GFX6-GFX7-GFX8
We already use GFX9 and I don't want us to have confusing naming in the driver. GFXn naming is better from the driver perspective, because it's the real version of the gfx portion of the hw. Also, CIK means Bonaire-Kaveri-Kabini, it doesn't mean CI. It shouldn't confuse our SDMA, UVD, VCE etc. code much. Those have nothing to do with GFXn and they have their own version numbers. Marek On Wed, May 15, 2019 at 3:26 AM Dave Airlie wrote: > > From: Marek Olšák > > It would be nice to have a reasoning why, I assume that is what they > are called internally and in the kernel, but it would be good to > mention something to justify it in the commit msg. > > Acked-by: Dave Airlie > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107391] feature request: enforceable vsync and anisotropic filtering via environment variables
https://bugs.freedesktop.org/show_bug.cgi?id=107391 --- Comment #9 from tempel.jul...@gmail.com --- It seems forcing vsync off doesn't work in Rage 2. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs/features: don't list EXT extensions in a list for KHR/ARB/OES extensions
How about moving these extensions to another (new) section? I think it is nice to have a one-stop place to find out what is supported. Best, Gert On Di, 2019-05-14 at 16:07 -0400, Marek Olšák wrote: > From: Marek Olšák > > --- > docs/features.txt | 10 -- > 1 file changed, 10 deletions(-) > > diff --git a/docs/features.txt b/docs/features.txt > index 38d6186dbe1..b1799550a0c 100644 > --- a/docs/features.txt > +++ b/docs/features.txt > @@ -309,30 +309,20 @@ Khronos, ARB, and OES extensions that are not > part of any OpenGL or OpenGL ES ve >GL_ARB_seamless_cubemap_per_texture DONE > (freedreno, i965, nvc0, radeonsi, r600, softpipe, swr, virgl) >GL_ARB_shader_ballot DONE > (i965/gen8+, nvc0, radeonsi) >GL_ARB_shader_clock DONE > (i965/gen7+, nv50, nvc0, r600, radeonsi, virgl) >GL_ARB_shader_stencil_export DONE > (i965/gen9+, r600, radeonsi, softpipe, llvmpipe, swr, virgl) >GL_ARB_shader_viewport_layer_arrayDONE > (i965/gen6+, nvc0, radeonsi) >GL_ARB_sparse_buffer DONE > (radeonsi/CIK+) >GL_ARB_sparse_texture not started >GL_ARB_sparse_texture2not started >GL_ARB_sparse_texture_clamp not started >GL_ARB_texture_filter_minmax not started > - GL_EXT_memory_object DONE > (radeonsi) > - GL_EXT_memory_object_fd DONE > (radeonsi) > - GL_EXT_memory_object_win32not started > - GL_EXT_render_snorm DONE (i965, > radeonsi) > - GL_EXT_semaphore DONE > (radeonsi) > - GL_EXT_semaphore_fd DONE > (radeonsi) > - GL_EXT_semaphore_win32not started > - GL_EXT_sRGB_write_control DONE (all > drivers that support GLES 3.0+) > - GL_EXT_texture_norm16 DONE > (freedreno, i965, r600, radeonsi, nvc0) > - GL_EXT_texture_sRGB_R8DONE (all > drivers that support GLES 3.0+) >GL_KHR_blend_equation_advanced_coherent DONE > (i965/gen9+) >GL_KHR_texture_compression_astc_hdr DONE > (i965/bxt) >GL_KHR_texture_compression_astc_sliced_3d DONE > (i965/gen9+, radeonsi) >GL_OES_depth_texture_cube_map DONE (all > drivers that support GLSL 1.30+) >GL_OES_EGL_image DONE (all > drivers) >GL_OES_EGL_image_external DONE (all > drivers) >GL_OES_EGL_image_external_essl3 DONE (all > drivers) >GL_OES_required_internalformatDONE (all > drivers) >GL_OES_surfaceless_contextDONE (all > drivers) >GL_OES_texture_compression_astc DONE (core > only) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] ac: add comments to chip enums
On Tue, May 14, 2019 at 10:17 PM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> src/amd/common/amd_family.h | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/amd/common/amd_family.h b/src/amd/common/amd_family.h
> index 185ba029763..eed6553d44b 100644
> --- a/src/amd/common/amd_family.h
> +++ b/src/amd/common/amd_family.h
> @@ -50,5 +50,5 @@ enum radeon_family {
> CHIP_RV560,
> CHIP_RV570,
> -CHIP_R600,
> +CHIP_R600, /* R6xx */
Could also make this /* GFX3 (R6xx) */
> CHIP_RV610,
> CHIP_RV630,
> @@ -58,9 +58,9 @@ enum radeon_family {
> CHIP_RS780,
> CHIP_RS880,
> -CHIP_RV770,
> +CHIP_RV770,/* R7xx */
Could also make this /* GFX3 (R7xx) */
> CHIP_RV730,
> CHIP_RV710,
> CHIP_RV740,
> -CHIP_CEDAR,
> +CHIP_CEDAR,/* Evergreen */
Could also make this /* GFX4 (Evergreen) */
> CHIP_REDWOOD,
> CHIP_JUNIPER,
> @@ -73,17 +73,17 @@ enum radeon_family {
> CHIP_TURKS,
> CHIP_CAICOS,
> -CHIP_CAYMAN,
> +CHIP_CAYMAN, /* Northern Islands */
Could also make this /* GFX5 (Northern Islands) */
Either way:
Reviewed-by: Alex Deucher
> CHIP_ARUBA,
> -CHIP_TAHITI,
> +CHIP_TAHITI, /* GFX6 (Southern Islands) */
> CHIP_PITCAIRN,
> CHIP_VERDE,
> CHIP_OLAND,
> CHIP_HAINAN,
> -CHIP_BONAIRE,
> +CHIP_BONAIRE, /* GFX7 (Sea Islands) */
> CHIP_KAVERI,
> CHIP_KABINI,
> CHIP_HAWAII,
> CHIP_MULLINS,
> -CHIP_TONGA,
> +CHIP_TONGA,/* GFX8 (Volcanic Islands & Polaris) */
> CHIP_ICELAND,
> CHIP_CARRIZO,
> @@ -94,5 +94,5 @@ enum radeon_family {
> CHIP_POLARIS12,
> CHIP_VEGAM,
> -CHIP_VEGA10,
> +CHIP_VEGA10, /* GFX9 (Vega) */
> CHIP_VEGA12,
> CHIP_VEGA20,
> --
> 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] [RFC 0/2] Alternate default config mechanism
Hi all, On Tue, 14 May 2019 at 08:18, Tapani Pälli wrote: > > > On 5/13/19 6:52 PM, Haehnle, Nicolai wrote: > > This approach seems entirely incompatible with si_debug_options.h, and > > will be an absolute maintenance nightmare going forward for adding / > > removing options, because you're introducing a second location where > > options are defined. > > > > Quite frankly, this seems like a terrible idea as-is. > > > > If you really can't use XML for whatever reason, then please find some > > way of deriving both the tables here and the XML from the same single > > source of truth. > > I was looking at this yesterday and came up with same conclusion. We > should have the options in one place. Currently libexpat is statically > linked with Android >=O, maybe for such restricted environments we could > just inline the xml as is at compile time and parse that later or > alternatively (maybe cleaner) parse and generate default option cache > already during compilation? > I realise that jumping the "me too" train does not help much, so here are some alternative ideas. How about we first distil the reasons why this is a problem and what kind. Then explore independent solution for each one - as-is this seems like a one-size-fits-all approach. Some examples: - XML file may be inaccessible - the in-driver defaults should work(tm) Yes there are some app specific ones, yet neither(?) of these apps is present on Android - libexpat is not available, but libFOO is - investigate into a compat wrapper - cannot use external libraries (libexpat or equivalent) - static link -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLU and GLUT issues migrated to gitlab
Hi, On 14.5.2019 20.06, Adam Jackson wrote: On Mon, 2019-05-13 at 12:14 -0400, Adam Jackson wrote: Not, I hope, that anyone is likely to notice, but I've moved the open GLU and GLUT bugs from bugzilla to gitlab and closed the components in bugzilla. I say "moved" but really glut only had one open bug and it was fixed ages ago. Anyway, use gitlab now please. mesa/demos has been migrated now as well. Looking at the results for a patch inlined to a comment in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=97043 Migration tooling will need some improvements to avoid messed formatting. - Eero ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Prevent classic swrast crash on a surfaceless context.
On Wed, 15 May 2019 at 08:26, wrote: > > From: Mathias Fröhlich > > Hi all, > > One small fix below. > > Please review! > > best > > Mathias > > > > > > Running swrast with the new device egl extensions piglit test > brings up this failure. Fix that by adding some NULL pointer > checks. > From a very quick look this seems to be off. The driver does not set the buffers as incomplete, thus in MakeCurrent (and handle_first_current in particular) things go south. For context grep for _mesa_get_incomplete_framebuffer and see how i9[16]5 use the function when both read/draw priv. are NULL. The gallium drivers st/mesa (really) also do that, yet classic swrast (alongside r100, r200, nouveau_vieux) don't do that. Which is understandable since those drivers receive far less testing than the rest. Can I suggest fleshing out some helper and fixing the drivers instead? Note !intel classic drivers may also struggle with (draw xor read) surfaces. It could be handled in the upper layers (dri/common or DRI loaders - GLX/EGL/GBM) but haven't checked. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] ac: rename SI-CIK-VI to GFX6-GFX7-GFX8
On 5/15/19 9:26 AM, Dave Airlie wrote: From: Marek Olšák It would be nice to have a reasoning why, I assume that is what they are called internally and in the kernel, but it would be good to mention something to justify it in the commit msg. Probably because Navi will be GFX10? :-) Acked-by: Dave Airlie ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] ac: rename SI-CIK-VI to GFX6-GFX7-GFX8
> From: Marek Olšák It would be nice to have a reasoning why, I assume that is what they are called internally and in the kernel, but it would be good to mention something to justify it in the commit msg. Acked-by: Dave Airlie ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Prevent classic swrast crash on a surfaceless context.
From: Mathias Fröhlich
Hi all,
One small fix below.
Please review!
best
Mathias
Running swrast with the new device egl extensions piglit test
brings up this failure. Fix that by adding some NULL pointer
checks.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/fbobject.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 09143d30af5..225a7e8e9bd 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1850,10 +1850,10 @@ _mesa_DeleteRenderbuffers(GLsizei n, const GLuint
*renderbuffers)
* non-bound framebuffers is the responsibility of the
* application.
*/
-if (_mesa_is_user_fbo(ctx->DrawBuffer)) {
+if (ctx->DrawBuffer && _mesa_is_user_fbo(ctx->DrawBuffer)) {
_mesa_detach_renderbuffer(ctx, ctx->DrawBuffer, rb);
}
-if (_mesa_is_user_fbo(ctx->ReadBuffer)
+if (ctx->ReadBuffer && _mesa_is_user_fbo(ctx->ReadBuffer)
&& ctx->ReadBuffer != ctx->DrawBuffer) {
_mesa_detach_renderbuffer(ctx, ctx->ReadBuffer, rb);
}
@@ -2881,7 +2881,6 @@ _mesa_bind_framebuffers(struct gl_context *ctx,
const bool bindDrawBuf = oldDrawFb != newDrawFb;
const bool bindReadBuf = oldReadFb != newReadFb;
- assert(newDrawFb);
assert(newDrawFb != );
/*
@@ -2900,7 +2899,8 @@ _mesa_bind_framebuffers(struct gl_context *ctx,
FLUSH_VERTICES(ctx, _NEW_BUFFERS);
/* check if old readbuffer was render-to-texture */
- check_end_texture_render(ctx, oldReadFb);
+ if (oldDrawFb)
+ check_end_texture_render(ctx, oldReadFb);
_mesa_reference_framebuffer(>ReadBuffer, newReadFb);
}
@@ -2914,7 +2914,8 @@ _mesa_bind_framebuffers(struct gl_context *ctx,
check_end_texture_render(ctx, oldDrawFb);
/* check if newly bound framebuffer has any texture attachments */
- check_begin_texture_render(ctx, newDrawFb);
+ if (newDrawFb)
+ check_begin_texture_render(ctx, newDrawFb);
_mesa_reference_framebuffer(>DrawBuffer, newDrawFb);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
