[Mesa-dev] [Bug 110699] Shader-based MJPEG decoding
https://bugs.freedesktop.org/show_bug.cgi?id=110699 --- Comment #1 from Andrew Randrianasulu --- There also were OpenCL patches for libjpeg-turbo, but they remain unintegrated. https://sourceforge.net/p/libjpeg-turbo/patches/40/ Patches so big because they include CL headers! -- 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 110697] glXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely
https://bugs.freedesktop.org/show_bug.cgi?id=110697 acc12345...@gmail.com changed: What|Removed |Added Component|Drivers/DRI/i965|Drivers/X11 Assignee|intel-3d-bugs@lists.freedes |mesa-dev@lists.freedesktop. |ktop.org|org QA Contact|intel-3d-bugs@lists.freedes |mesa-dev@lists.freedesktop. |ktop.org|org --- Comment #3 from acc12345...@gmail.com --- EDIT: I just tested on my AMD GPU under Mesa 19.0 and it freezes as well... (and has even higher chance of freezing) -- 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 110673] amdgpu hevc encoding problems: segment fault and contents of garbage
https://bugs.freedesktop.org/show_bug.cgi?id=110673 --- Comment #1 from Boyuan Zhang --- Hi Zhoulei, Thanks for pointing out these 2 issues. I reproduced issue#1, and have a fix submitted for code review: https://lists.freedesktop.org/archives/mesa-dev/2019-May/219392.html Please give a try. And I will investigate issue#2. -- 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] radeon/uvd: fix max poc for hevc encode
From: Boyuan Zhang
Fix max poc value with hardcoded value until new feature requires
to change this in the future.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_uvd_enc.c | 4 +++-
src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 1 -
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc.c
b/src/gallium/drivers/radeon/radeon_uvd_enc.c
index 3164dbb2c20..2bfb5215be1 100644
--- a/src/gallium/drivers/radeon/radeon_uvd_enc.c
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc.c
@@ -73,7 +73,9 @@ radeon_uvd_enc_get_param(struct radeon_uvd_encoder *enc,
enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
- enc->enc_pic.max_poc = pic->seq.intra_period;
+ enc->enc_pic.layer_ctrl.max_num_temporal_layers = 1;
+ enc->enc_pic.max_poc =
+ (enc->enc_pic.layer_ctrl.max_num_temporal_layers == 4) ? 32 : 16;
enc->enc_pic.log2_max_poc = 0;
for (int i = enc->enc_pic.max_poc; i != 0; enc->enc_pic.log2_max_poc++)
i = (i >> 1);
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
index 1f41b09472f..87d3d269cb1 100644
--- a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
@@ -262,7 +262,6 @@ radeon_uvd_enc_session_init_hevc(struct radeon_uvd_encoder
*enc)
static void
radeon_uvd_enc_layer_control(struct radeon_uvd_encoder *enc)
{
- enc->enc_pic.layer_ctrl.max_num_temporal_layers = 1;
enc->enc_pic.layer_ctrl.num_temporal_layers = 1;
RADEON_ENC_BEGIN(RENC_UVD_IB_PARAM_LAYER_CONTROL);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon/vcn: fix max poc for hevc encode
From: Boyuan Zhang
Fix max poc value with hardcoded value until new feature requires
to change this in the future.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vcn_enc.c | 4 +++-
src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 1 -
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index 7d64a28a405..b8c73227929 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -72,7 +72,9 @@ static void radeon_vcn_enc_get_param(struct radeon_encoder
*enc, struct pipe_pic
enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
- enc->enc_pic.max_poc = pic->seq.intra_period;
+ enc->enc_pic.layer_ctrl.max_num_temporal_layers = 1;
+ enc->enc_pic.max_poc =
+ (enc->enc_pic.layer_ctrl.max_num_temporal_layers == 4) ? 32 : 16;
enc->enc_pic.log2_max_poc = 0;
for (int i = enc->enc_pic.max_poc; i != 0; enc->enc_pic.log2_max_poc++)
i = (i >> 1);
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
index 7f5b1909344..c489de39a89 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
@@ -253,7 +253,6 @@ static void radeon_enc_session_init_hevc(struct
radeon_encoder *enc)
static void radeon_enc_layer_control(struct radeon_encoder *enc)
{
- enc->enc_pic.layer_ctrl.max_num_temporal_layers = 1;
enc->enc_pic.layer_ctrl.num_temporal_layers = 1;
RADEON_ENC_BEGIN(RENCODE_IB_PARAM_LAYER_CONTROL);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110116] Neverball particles are broken (GL_POINT_SPRITE)
https://bugs.freedesktop.org/show_bug.cgi?id=110116 QwertyChouskie changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |NOTOURBUG --- Comment #10 from QwertyChouskie --- Turns out the the Debian package somehow doesn't install all the assets. Not a Mesa issue, closing. https://github.com/Neverball/neverball/issues/170#issuecomment-493550779 -- 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] docs/features: don't list EXT extensions in a list for KHR/ARB/OES extensions
Out-of-tree TODO lists would be more convenient for tracking non-core
features.
Marek
On Fri, May 17, 2019 at 1:45 PM Ian Romanick wrote:
> On 5/17/19 6:24 AM, Eric Engestrom wrote:
> > On 2019-05-16 at 18:34, Ian Romanick wrote:
> >> On 5/15/19 7: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.
> >>
> >> Given the existence of mesamatrix.net, is that useful?
> >
> > mesamatrix.net is nothing more than a pretty parser for this file. If
> you remove
> > the information from this file, it won't be on the website anymore
> either ;-)
> >
> >> When we started
> >> this file, the purpose was to track work that people were doing to avoid
> >> collisions and track progress towards closing the functionality gap with
> >> the rest of the industry. There's not a lot of new functionality work
> >> being done, and there's not much of a functionality gap with the rest of
> >> the industry.
> >>
> >> Given that it's unlikely there will ever be another GL version, ARB
> >> extension, KHR extension, or OES extension, I'm honestly not sure how
> >> much value this file has at all.
> >
> > This file has contained other things as well for a while, which is why
> it was eventually renamed from gl3.txt to features.txt a few years ago.
>
> When I made commit f926cf5bd0a ("docs: Rename GL3.txt to features.txt")
> in 2016, it was because we finished OpenGL 3.x, and had been using the
> file to track progress on OpenGL 4.x and OpenGL ES 3.x features for some
> time.
>
> > I don't have a stake in this steak, but to me this issue with this patch
> is that I don't see what's gained by removing this information?
>
> I think Marek's point is that there are zero other EXT / vendor
> extensions in features.txt that are not also part of some OpenGL or
> OpenGL ES version. I think if reviewers had been paying attention to
> features.txt, none of these would have landed in the first place.
> Looking at the logs, it seems that many of these changes were either
> unreviewed or were reviewed by Marek. There's some irony there. :)
>
> I also believe that leaving these odd ball extensions invites more
> clutter in this file.
>
> >>> 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)
>
Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation
Thanks. It looks good.
Marek
On Fri, May 17, 2019 at 3:56 AM Juan A. Suarez Romero
wrote:
> On Fri, 2019-05-10 at 01:19 -0400, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108824
> >
> > Cc: 19.1
>
> Hi, Marek,
>
> This patch didn't apply cleanly on 19.1 branch, so I've fixed the
> conflicts.
>
> You can find the solved patch in
>
> https://gitlab.freedesktop.org/mesa/mesa/commit/21620c889e3fc78be13f096fa273cfd27a3d
>
>
> Thanks!
>
>
> J.A.
>
> > ---
> > src/gallium/drivers/radeonsi/si_descriptors.c | 94 ---
> > src/gallium/drivers/radeonsi/si_pipe.h| 2 +
> > src/gallium/drivers/radeonsi/si_state_draw.c | 9 +-
> > 3 files changed, 72 insertions(+), 33 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> > index 744fc9a15d7..6a4dcacc0f3 100644
> > --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> > +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> > @@ -1580,242 +1580,272 @@ void
> si_update_needs_color_decompress_masks(struct si_context *sctx)
> >
> si_samplers_update_needs_color_decompress_mask(>samplers[i]);
> >
> si_images_update_needs_color_decompress_mask(>images[i]);
> > si_update_shader_needs_decompress_mask(sctx, i);
> > }
> >
> > si_resident_handles_update_needs_color_decompress(sctx);
> > }
> >
> > /* BUFFER DISCARD/INVALIDATION */
> >
> > -/** Reset descriptors of buffer resources after \p buf has been
> invalidated. */
> > +/* Reset descriptors of buffer resources after \p buf has been
> invalidated.
> > + * If buf == NULL, reset all descriptors.
> > + */
> > static void si_reset_buffer_resources(struct si_context *sctx,
> > struct si_buffer_resources *buffers,
> > unsigned descriptors_idx,
> > unsigned slot_mask,
> > struct pipe_resource *buf,
> > enum radeon_bo_priority priority)
> > {
> > struct si_descriptors *descs = >descriptors[descriptors_idx];
> > unsigned mask = buffers->enabled_mask & slot_mask;
> >
> > while (mask) {
> > unsigned i = u_bit_scan();
> > - if (buffers->buffers[i] == buf) {
> > - si_set_buf_desc_address(si_resource(buf),
> buffers->offsets[i],
> > + struct pipe_resource *buffer = buffers->buffers[i];
> > +
> > + if (buffer && (!buf || buffer == buf)) {
> > + si_set_buf_desc_address(si_resource(buffer),
> buffers->offsets[i],
> > descs->list + i*4);
> > sctx->descriptors_dirty |= 1u << descriptors_idx;
> >
> > radeon_add_to_gfx_buffer_list_check_mem(sctx,
> > -
> si_resource(buf),
> > +
> si_resource(buffer),
> >
> buffers->writable_mask & (1u << i) ?
> >
> RADEON_USAGE_READWRITE :
> >
> RADEON_USAGE_READ,
> > priority,
> true);
> > }
> > }
> > }
> >
> > -/* Update all resource bindings where the buffer is bound, including
> > +/* Update all buffer bindings where the buffer is bound, including
> > * all resource descriptors. This is invalidate_buffer without
> > - * the invalidation. */
> > + * the invalidation.
> > + *
> > + * If buf == NULL, update all buffer bindings.
> > + */
> > void si_rebind_buffer(struct si_context *sctx, struct pipe_resource
> *buf)
> > {
> > struct si_resource *buffer = si_resource(buf);
> > unsigned i, shader;
> > unsigned num_elems = sctx->vertex_elements ?
> > sctx->vertex_elements->count : 0;
> >
> > /* We changed the buffer, now we need to bind it where the old one
> >* was bound. This consists of 2 things:
> >* 1) Updating the resource descriptor and dirtying it.
> >* 2) Adding a relocation to the CS, so that it's usable.
> >*/
> >
> > /* Vertex buffers. */
> > - if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
> > + if (!buffer) {
> > + if (num_elems)
> > + sctx->vertex_buffers_dirty = true;
> > + } else if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
> > for (i = 0; i < num_elems; i++) {
> > int vb =
> sctx->vertex_elements->vertex_buffer_index[i];
> >
> > if (vb >= ARRAY_SIZE(sctx->vertex_buffer))
> > continue;
> > if (!sctx->vertex_buffer[vb].buffer.resource)
> > continue;
> >
> > if (sctx->vertex_buffer[vb].buffer.resource ==
> buf) {
> > sctx->vertex_buffers_dirty = true;
> >
[Mesa-dev] [PATCH] radeonsi: clean up winsys creation
From: Marek Olšák
- unify the code
- choose radeon or amdgpu based on the DRM version, not based on which one
succeeds first
---
.../auxiliary/target-helpers/drm_helper.h | 13 ++---
src/gallium/drivers/radeonsi/si_pipe.c| 27 +--
src/gallium/drivers/radeonsi/si_public.h | 5 +---
.../targets/pipe-loader/pipe_radeonsi.c | 13 ++---
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 8 --
5 files changed, 30 insertions(+), 36 deletions(-)
diff --git a/src/gallium/auxiliary/target-helpers/drm_helper.h
b/src/gallium/auxiliary/target-helpers/drm_helper.h
index ac891d1d307..6bdd1a008db 100644
--- a/src/gallium/auxiliary/target-helpers/drm_helper.h
+++ b/src/gallium/auxiliary/target-helpers/drm_helper.h
@@ -154,37 +154,28 @@ pipe_r600_create_screen(int fd, const struct
pipe_screen_config *config)
struct pipe_screen *
pipe_r600_create_screen(int fd, const struct pipe_screen_config *config)
{
fprintf(stderr, "r600: driver missing\n");
return NULL;
}
#endif
#ifdef GALLIUM_RADEONSI
-#include "radeon/radeon_winsys.h"
-#include "radeon/drm/radeon_drm_public.h"
-#include "amdgpu/drm/amdgpu_public.h"
#include "radeonsi/si_public.h"
struct pipe_screen *
pipe_radeonsi_create_screen(int fd, const struct pipe_screen_config *config)
{
- struct radeon_winsys *rw;
-
- /* First, try amdgpu. */
- rw = amdgpu_winsys_create(fd, config, radeonsi_screen_create);
+ struct pipe_screen *screen = radeonsi_screen_create(fd, config);
- if (!rw)
- rw = radeon_drm_winsys_create(fd, config, radeonsi_screen_create);
-
- return rw ? debug_screen_wrap(rw->screen) : NULL;
+ return screen ? debug_screen_wrap(screen) : NULL;
}
const char *radeonsi_driconf_xml =
#include "radeonsi/si_driinfo.h"
;
#else
struct pipe_screen *
pipe_radeonsi_create_screen(int fd, const struct pipe_screen_config *config)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 9ddf7802746..c19a2cd97d3 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -35,20 +35,24 @@
#include "util/disk_cache.h"
#include "util/u_log.h"
#include "util/u_memory.h"
#include "util/u_suballoc.h"
#include "util/u_tests.h"
#include "util/u_upload_mgr.h"
#include "util/xmlconfig.h"
#include "vl/vl_decoder.h"
#include "driver_ddebug/dd_util.h"
+#include "gallium/winsys/radeon/drm/radeon_drm_public.h"
+#include "gallium/winsys/amdgpu/drm/amdgpu_public.h"
+#include
+
static const struct debug_named_value debug_options[] = {
/* Shader logging options: */
{ "vs", DBG(VS), "Print vertex shaders" },
{ "ps", DBG(PS), "Print pixel shaders" },
{ "gs", DBG(GS), "Print geometry shaders" },
{ "tcs", DBG(TCS), "Print tessellation control shaders" },
{ "tes", DBG(TES), "Print tessellation evaluation shaders" },
{ "cs", DBG(CS), "Print compute shaders" },
{ "noir", DBG(NO_IR), "Don't print the LLVM IR"},
{ "notgsi", DBG(NO_TGSI), "Don't print the TGSI"},
@@ -872,22 +876,23 @@ static bool
si_is_parallel_shader_compilation_finished(struct pipe_screen *scree
if (shader_type == PIPE_SHADER_COMPUTE) {
struct si_compute *cs = (struct si_compute*)shader;
return util_queue_fence_is_signalled(>ready);
}
struct si_shader_selector *sel = (struct si_shader_selector *)shader;
return util_queue_fence_is_signalled(>ready);
}
-struct pipe_screen *radeonsi_screen_create(struct radeon_winsys *ws,
- const struct pipe_screen_config
*config)
+static struct pipe_screen *
+radeonsi_screen_create_impl(struct radeon_winsys *ws,
+ const struct pipe_screen_config *config)
{
struct si_screen *sscreen = CALLOC_STRUCT(si_screen);
unsigned hw_threads, num_comp_hi_threads, num_comp_lo_threads, i;
if (!sscreen) {
return NULL;
}
sscreen->ws = ws;
ws->query_info(ws, >info);
@@ -1218,10 +1223,28 @@ struct pipe_screen *radeonsi_screen_create(struct
radeon_winsys *ws,
si_test_gds_memory_management((struct
si_context*)sscreen->aux_context,
32 * 1024, 4, RADEON_DOMAIN_GDS);
}
if (sscreen->debug_flags & DBG(TEST_GDS_OA_MM)) {
si_test_gds_memory_management((struct
si_context*)sscreen->aux_context,
4, 1, RADEON_DOMAIN_OA);
}
return >b;
}
+
+struct pipe_screen *radeonsi_screen_create(int fd, const struct
pipe_screen_config *config)
+{
+ drmVersionPtr version = drmGetVersion(fd);
+ struct radeon_winsys *rw = NULL;
+
+ switch (version->version_major) {
+ case 2:
+ rw = radeon_drm_winsys_create(fd, config,
radeonsi_screen_create_impl);
+
Re: [Mesa-dev] undefined behaviour in spirv_to_nir.c
well, the code was required for the old style load_const as we unioned the arrays. But now that the load_const data is just one 64 bit value and we 0 out untouched bits I am quite sure we don't have to adjust the bit size of the shift anymore? Although I would feel better if we would have some explicit handling about it, even if the compiler just optimizes it away. On Fri, May 17, 2019 at 8:55 PM Jason Ekstrand wrote: > > I'm not convinced that code is correct. In particular, the bit_size value is > for the destination and not necessarily that one source. As Karol points > out, it probably is safe to just delete. However, I'd feel slightly better > about it if we figured out the right bit size and just called > nir_eval_const_opcode to do a u2u32 on the value. > > --Jason > > On Fri, May 17, 2019 at 1:24 AM Karol Herbst wrote: >> >> ohhh, yeah.. I think we can actually just remove that code, as it >> shouldn't have any affect on the constants value. >> >> On Fri, May 17, 2019 at 4:07 AM Jason Ekstrand wrote: >> > >> > I think it's fine but I'm not at my computer right now. >> > >> > --Jason >> > >> > On May 16, 2019 20:58:03 Dave Airlie wrote: >> > >> > > Coverity gave me this: >> > > >> > > mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987: >> > > overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32", >> > > which have overlapping memory locations and different types. >> > > >> > > and the following lines, I think it's actually undefined behaviour wrt >> > > the C spec. >> > > >> > > Dave. >> > >> > >> > >> > ___ >> > 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 109183] GPU Hangs randomly with GTA V
https://bugs.freedesktop.org/show_bug.cgi?id=109183 --- Comment #10 from Alexander Vereeken --- ehm... could this releated to the old gnome version 3.24? Since my distro upgraded gnome to 3.3.0, i never got this freeze again. -- 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] undefined behaviour in spirv_to_nir.c
I'm not convinced that code is correct. In particular, the bit_size value is for the destination and not necessarily that one source. As Karol points out, it probably is safe to just delete. However, I'd feel slightly better about it if we figured out the right bit size and just called nir_eval_const_opcode to do a u2u32 on the value. --Jason On Fri, May 17, 2019 at 1:24 AM Karol Herbst wrote: > ohhh, yeah.. I think we can actually just remove that code, as it > shouldn't have any affect on the constants value. > > On Fri, May 17, 2019 at 4:07 AM Jason Ekstrand > wrote: > > > > I think it's fine but I'm not at my computer right now. > > > > --Jason > > > > On May 16, 2019 20:58:03 Dave Airlie wrote: > > > > > Coverity gave me this: > > > > > > mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987: > > > overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32", > > > which have overlapping memory locations and different types. > > > > > > and the following lines, I think it's actually undefined behaviour wrt > > > the C spec. > > > > > > Dave. > > > > > > > > ___ > > 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 109659] Missing OpenGL symbols in OSMesa Gallium when building with meson
https://bugs.freedesktop.org/show_bug.cgi?id=109659 --- Comment #3 from Chuck Atkins --- I spoke a little too soon but I think this patch is still okay. llvmpipe and softpipe work fine but swr is mysteriously broken. What I don't know is if swr is broken with osmesa because of this or something else. So given that, I'm okay with aserting that the fix addresses the specific issues of missing gl symbols in OSMesa and having swr being broken in OSMesa as a different problem to be addresses separately. -- 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] XDC 2019: Registration & Call for Proposals now open!
Hello! Registration & Call for Proposals are now open for XDC 2019, which will take place at the Concordia University Conference Centre in Montréal, Canada on October 2-4, 2019. Thanks to LWN.net, this year we have a brand new website using the Indico platform, a fully open source event management tool! https://xdc2019.x.org If you plan on attending, please make sure to register as early as possible as space is limited! As usual, the conference is free of charge and open to the general public. Please note, as we are now based on Indico, we will no longer use the wiki for registration. You will therefore need to register via the XDC website. However, as XDC is sharing the same Indico infrastructure as LPC, if you previously registered on the LPC website (linuxplumbersconference.org), then you already have an active account and can use the same username & password to login! https://xdc2019.x.org/event/5/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2019. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://xdc2019.x.org/event/5/abstracts/ The deadline for submissions Sunday, 7 July 2019. We are looking forward to seeing you (and sharing a poutine!) in beautiful Montréal! If you have any questions, please send me an email to mark.fil...@collabora.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/xdc2019 Best, Mark ___ 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
On 5/17/19 6:24 AM, Eric Engestrom wrote:
> On 2019-05-16 at 18:34, Ian Romanick wrote:
>> On 5/15/19 7: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.
>>
>> Given the existence of mesamatrix.net, is that useful?
>
> mesamatrix.net is nothing more than a pretty parser for this file. If you
> remove
> the information from this file, it won't be on the website anymore either ;-)
>
>> When we started
>> this file, the purpose was to track work that people were doing to avoid
>> collisions and track progress towards closing the functionality gap with
>> the rest of the industry. There's not a lot of new functionality work
>> being done, and there's not much of a functionality gap with the rest of
>> the industry.
>>
>> Given that it's unlikely there will ever be another GL version, ARB
>> extension, KHR extension, or OES extension, I'm honestly not sure how
>> much value this file has at all.
>
> This file has contained other things as well for a while, which is why it was
> eventually renamed from gl3.txt to features.txt a few years ago.
When I made commit f926cf5bd0a ("docs: Rename GL3.txt to features.txt")
in 2016, it was because we finished OpenGL 3.x, and had been using the
file to track progress on OpenGL 4.x and OpenGL ES 3.x features for some
time.
> I don't have a stake in this steak, but to me this issue with this patch is
> that I don't see what's gained by removing this information?
I think Marek's point is that there are zero other EXT / vendor
extensions in features.txt that are not also part of some OpenGL or
OpenGL ES version. I think if reviewers had been paying attention to
features.txt, none of these would have landed in the first place.
Looking at the logs, it seems that many of these changes were either
unreviewed or were reviewed by Marek. There's some irony there. :)
I also believe that leaving these odd ball extensions invites more
clutter in this file.
>>> 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
[Mesa-dev] [Bug 109560] Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=109560 --- Comment #7 from Michel Dänzer --- (In reply to Michel Dänzer from comment #6) > Not sure yet if this Mesa's fault (maybe it missed the event while the context > wasn't current), or maybe the X server failed to send an event when it should > (e.g. because the window was unmapped). So far I'm not seeing how either of that could be the case. > Most likely not an XCB issue though. I'm not sure about this anymore, since thread 6 (from Qt) is stuck in xcb_wait_for_event. Maybe there's some kind of bad interaction between that and xcb_wait_for_special_event. Anyway, I won't be able to investigate more for a couple of weeks at least. -- 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] radeonsi: Fix editorconfig
At least on vim, indenting doesn't work without this. Copied from
src/amd/vulkan.
---
src/gallium/drivers/radeonsi/.editorconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeonsi/.editorconfig
b/src/gallium/drivers/radeonsi/.editorconfig
index cc8e11ffd65..21a3c7d1274 100644
--- a/src/gallium/drivers/radeonsi/.editorconfig
+++ b/src/gallium/drivers/radeonsi/.editorconfig
@@ -1,2 +1,3 @@
[*.{c,h}]
indent_style = tab
+indent_size = tab
--
2.17.2
___
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
On 2019-05-16 at 18:34, Ian Romanick wrote: > On 5/15/19 7: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. > > Given the existence of mesamatrix.net, is that useful? mesamatrix.net is nothing more than a pretty parser for this file. If you remove the information from this file, it won't be on the website anymore either ;-) > When we started > this file, the purpose was to track work that people were doing to avoid > collisions and track progress towards closing the functionality gap with > the rest of the industry. There's not a lot of new functionality work > being done, and there's not much of a functionality gap with the rest of > the industry. > > Given that it's unlikely there will ever be another GL version, ARB > extension, KHR extension, or OES extension, I'm honestly not sure how > much value this file has at all. This file has contained other things as well for a while, which is why it was eventually renamed from gl3.txt to features.txt a few years ago. I don't have a stake in this steak, but to me this issue with this patch is that I don't see what's gained by removing this information? > > > 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 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 109659] Missing OpenGL symbols in OSMesa Gallium when building with meson
https://bugs.freedesktop.org/show_bug.cgi?id=109659 --- Comment #2 from Chuck Atkins --- I can confirm that the proposed patch, https://lists.freedesktop.org/archives/mesa-dev/2019-May/218700.html, fixes the bug. Please add Tested-by: Chuck Atkins . This should also go to all stable branches and is really should be a blocker for 19.1 since OSMesa is unusable without it. I'd reply on the mailing list but in doing some cleanup I wiped out everything older than week :-( -- 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 3/4] imgui: fix undefined behaviour bitshift.
Reviewed-by: Lionel Landwerlin And reported upstream : https://github.com/ocornut/imgui/pull/2561 On 17/05/2019 03:22, Dave Airlie wrote: From: Dave Airlie imgui_draw.cpp:1781: error[shiftTooManyBitsSigned]: Shifting signed 32-bit value by 31 bits is undefined behaviour Reported by coverity --- src/imgui/imgui_draw.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/imgui/imgui_draw.cpp b/src/imgui/imgui_draw.cpp index 1d4e1d51692..c69c01ee801 100644 --- a/src/imgui/imgui_draw.cpp +++ b/src/imgui/imgui_draw.cpp @@ -1778,7 +1778,7 @@ static void UnpackBoolVectorToFlatIndexList(const ImBoolVector* in, ImVectorpush_back((int)((it - it_begin) << 5) + bit_n); } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation
On Fri, 2019-05-10 at 01:19 -0400, Marek Olšák wrote:
> From: Marek Olšák
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108824
>
> Cc: 19.1
Hi, Marek,
This patch didn't apply cleanly on 19.1 branch, so I've fixed the conflicts.
You can find the solved patch in
https://gitlab.freedesktop.org/mesa/mesa/commit/21620c889e3fc78be13f096fa273cfd27a3d
Thanks!
J.A.
> ---
> src/gallium/drivers/radeonsi/si_descriptors.c | 94 ---
> src/gallium/drivers/radeonsi/si_pipe.h| 2 +
> src/gallium/drivers/radeonsi/si_state_draw.c | 9 +-
> 3 files changed, 72 insertions(+), 33 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> index 744fc9a15d7..6a4dcacc0f3 100644
> --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> @@ -1580,242 +1580,272 @@ void si_update_needs_color_decompress_masks(struct
> si_context *sctx)
>
> si_samplers_update_needs_color_decompress_mask(>samplers[i]);
> si_images_update_needs_color_decompress_mask(>images[i]);
> si_update_shader_needs_decompress_mask(sctx, i);
> }
>
> si_resident_handles_update_needs_color_decompress(sctx);
> }
>
> /* BUFFER DISCARD/INVALIDATION */
>
> -/** Reset descriptors of buffer resources after \p buf has been invalidated.
> */
> +/* Reset descriptors of buffer resources after \p buf has been invalidated.
> + * If buf == NULL, reset all descriptors.
> + */
> static void si_reset_buffer_resources(struct si_context *sctx,
> struct si_buffer_resources *buffers,
> unsigned descriptors_idx,
> unsigned slot_mask,
> struct pipe_resource *buf,
> enum radeon_bo_priority priority)
> {
> struct si_descriptors *descs = >descriptors[descriptors_idx];
> unsigned mask = buffers->enabled_mask & slot_mask;
>
> while (mask) {
> unsigned i = u_bit_scan();
> - if (buffers->buffers[i] == buf) {
> - si_set_buf_desc_address(si_resource(buf),
> buffers->offsets[i],
> + struct pipe_resource *buffer = buffers->buffers[i];
> +
> + if (buffer && (!buf || buffer == buf)) {
> + si_set_buf_desc_address(si_resource(buffer),
> buffers->offsets[i],
> descs->list + i*4);
> sctx->descriptors_dirty |= 1u << descriptors_idx;
>
> radeon_add_to_gfx_buffer_list_check_mem(sctx,
> -
> si_resource(buf),
> +
> si_resource(buffer),
>
> buffers->writable_mask & (1u << i) ?
>
> RADEON_USAGE_READWRITE :
>
> RADEON_USAGE_READ,
> priority, true);
> }
> }
> }
>
> -/* Update all resource bindings where the buffer is bound, including
> +/* Update all buffer bindings where the buffer is bound, including
> * all resource descriptors. This is invalidate_buffer without
> - * the invalidation. */
> + * the invalidation.
> + *
> + * If buf == NULL, update all buffer bindings.
> + */
> void si_rebind_buffer(struct si_context *sctx, struct pipe_resource *buf)
> {
> struct si_resource *buffer = si_resource(buf);
> unsigned i, shader;
> unsigned num_elems = sctx->vertex_elements ?
> sctx->vertex_elements->count : 0;
>
> /* We changed the buffer, now we need to bind it where the old one
>* was bound. This consists of 2 things:
>* 1) Updating the resource descriptor and dirtying it.
>* 2) Adding a relocation to the CS, so that it's usable.
>*/
>
> /* Vertex buffers. */
> - if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
> + if (!buffer) {
> + if (num_elems)
> + sctx->vertex_buffers_dirty = true;
> + } else if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
> for (i = 0; i < num_elems; i++) {
> int vb = sctx->vertex_elements->vertex_buffer_index[i];
>
> if (vb >= ARRAY_SIZE(sctx->vertex_buffer))
> continue;
> if (!sctx->vertex_buffer[vb].buffer.resource)
> continue;
>
> if (sctx->vertex_buffer[vb].buffer.resource == buf) {
>
Re: [Mesa-dev] undefined behaviour in spirv_to_nir.c
ohhh, yeah.. I think we can actually just remove that code, as it shouldn't have any affect on the constants value. On Fri, May 17, 2019 at 4:07 AM Jason Ekstrand wrote: > > I think it's fine but I'm not at my computer right now. > > --Jason > > On May 16, 2019 20:58:03 Dave Airlie wrote: > > > Coverity gave me this: > > > > mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987: > > overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32", > > which have overlapping memory locations and different types. > > > > and the following lines, I think it's actually undefined behaviour wrt > > the C spec. > > > > Dave. > > > > ___ > 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] util: add missing include to build_id.h
Reviewed-by: Tapani Pälli On 5/17/19 8:23 AM, Timothy Arceri wrote: Required to use uint8_t --- src/util/build_id.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/util/build_id.h b/src/util/build_id.h index 86d611d8db7..1872ca5c7e5 100644 --- a/src/util/build_id.h +++ b/src/util/build_id.h @@ -26,6 +26,8 @@ #ifdef HAVE_DL_ITERATE_PHDR +#include + struct build_id_note; const struct build_id_note * ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110345] Unrecoverable GPU crash with DiRT 4
https://bugs.freedesktop.org/show_bug.cgi?id=110345 --- Comment #35 from ant...@gmx.de --- I do experience the same hang in Far Cry New Dawn. It occurs very randomly. Using latest LLVM9 git and mesa 19,2 git with kernel 5.0.13 -- 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
