[Mesa-dev] XDC 2019: Schedule published & Workshops CfP reopened!
Hello, The preliminary schedule for XDC 2019 has been published! https://xdc2019.x.org/event/5/timetable/#20191002.detailed XDC 2019 will take place at the Concordia University Conference Centre in Montréal, Canada on October 2-4, 2019. If you haven't already done so, now is the time to book your travel! In addition to publishing the schedule, the CfP for workshops has been reopened. If you ave an idea for a workshop discussion, please sent it in! https://xdc2019.x.org/event/5/abstracts/ 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 v6 4/5] st/dri2: Implement DRI2bufferDamageExtension
On Thu, Aug 1, 2019 at 8:15 PM Boris Brezillon
wrote:
>
> +Marek (looks like I forgot to Cc you on this v6 :-/).
>
> On Mon, 22 Jul 2019 09:49:31 +0200
> Boris Brezillon wrote:
>
> > Hi Qiang,
> >
> > On Sun, 21 Jul 2019 17:02:54 +0800
> > Qiang Yu wrote:
> >
> > > On Mon, Jul 15, 2019 at 8:50 PM Boris Brezillon
> > > wrote:
> > > >
> > > > From: Daniel Stone
> > > >
> > > > Add a pipe_screen->set_damage_region() hook to propagate
> > > > set-damage-region requests to the driver, it's then up to the driver to
> > > > decide what to do with this piece of information.
> > > >
> > > > If the hook is left unassigned, the buffer-damage extension is
> > > > considered unsupported.
> > > >
> > > > Signed-off-by: Daniel Stone
> > > > Signed-off-by: Boris Brezillon
> > > > Reviewed-by: Alyssa Rosenzweig
> > > > ---
> > > > Hello Qiang,
> > > >
> > > > I intentionally dropped your R-b/T-b on this patch since the
> > > > ->set_damage_region() prototype has changed. Feel free to add it back.
> > > >
> > > > Regards,
> > > >
> > > > Boris
> > > >
> > > > Changes in v6:
> > > > * Pass pipe_box objects instead ints
> > > > * Document the set_damage_region() hook
> > > >
> > > > Changes in v5:
> > > > * Add Alyssa's R-b
> > > > ---
> > > > src/gallium/include/pipe/p_screen.h | 17 ++
> > > > src/gallium/state_trackers/dri/dri2.c | 34 +++
> > > > 2 files changed, 51 insertions(+)
> > > >
> > > > diff --git a/src/gallium/include/pipe/p_screen.h
> > > > b/src/gallium/include/pipe/p_screen.h
> > > > index 3f9bad470950..11a6aa939124 100644
> > > > --- a/src/gallium/include/pipe/p_screen.h
> > > > +++ b/src/gallium/include/pipe/p_screen.h
> > > > @@ -464,6 +464,23 @@ struct pipe_screen {
> > > > bool (*is_parallel_shader_compilation_finished)(struct pipe_screen
> > > > *screen,
> > > > void *shader,
> > > > unsigned
> > > > shader_type);
> > > > +
> > > > + /**
> > > > +* Set the damage region (called when KHR_partial_update() is
> > > > invoked).
> > > > +* This function is passed an array of rectangles encoding the
> > > > damage area.
> > > > +* rects are using the bottom-left origin convention.
> > > > +* nrects = 0 means 'reset the damage region'. What 'reset' implies
> > > > is HW
> > > > +* specific. For tile-based renderers, the damage extent is
> > > > typically set
> > > > +* to cover the whole resource with no damage rect (or a 0-size
> > > > damage
> > > > +* rect). This way, the existing resource content is reloaded into
> > > > the
> > > > +* local tile buffer for every tile thus making partial tile update
> > > > +* possible. For HW operating in immediate mode, this reset
> > > > operation is
> > > > +* likely to be a NOOP.
> > > > +*/
> > > > + void (*set_damage_region)(struct pipe_screen *screen,
> > > > + struct pipe_resource *resource,
> > > > + unsigned int nrects,
> > > > + const struct pipe_box *rects);
> > > > };
> > > >
> > > >
> > > > diff --git a/src/gallium/state_trackers/dri/dri2.c
> > > > b/src/gallium/state_trackers/dri/dri2.c
> > > > index 5a7ec878bab0..5273b95cd5fb 100644
> > > > --- a/src/gallium/state_trackers/dri/dri2.c
> > > > +++ b/src/gallium/state_trackers/dri/dri2.c
> > > > @@ -1807,6 +1807,35 @@ static const __DRI2interopExtension
> > > > dri2InteropExtension = {
> > > > .export_object = dri2_interop_export_object
> > > > };
> > > >
> > > > +/**
> > > > + * \brief the DRI2bufferDamageExtension set_damage_region method
> > > > + */
> > > > +static void
> > > > +dri2_set_damage_region(__DRIdrawable *dPriv, unsigned int nrects, int
> > > > *rects)
> > > > +{
> > > > + struct dri_drawable *drawable = dri_drawable(dPriv);
> > > > + struct pipe_resource *resource =
> > > > drawable->textures[ST_ATTACHMENT_BACK_LEFT];
> > > > + struct pipe_screen *screen = resource->screen;
> > > > + struct pipe_box *boxes = NULL;
> > > > +
> > > > + if (nrects) {
> > > > + boxes = CALLOC(nrects, sizeof(*boxes));
> > > > + assert(boxes);
> > >
> > > Where does this boxes array get freed? I can't find in your patch 6
> > > either.
> >
> > Indeed, the FREE() is missing.
> >
> > > In fact I prefer the v5 way which just uses `int *rects` to avoid
> > > unnecessary
> > > conversion.
> >
> > Well, Erik suggested to pass an array of pipe_boxe objects to make
> > things clearer, and I can of agree with him. Moreover, I'd expect the
>
> *kind of
>
> > extra allocation + pipe_box init overhead to be negligible.
>
> Erik, Qiang, Marek,
>
> Any comment on this v5. Should I send a v6 adding the missing FREE()
> call. Anything else you'd like me to change?
>
Hi Boris,
There's no other change from my side. Use v5 way is just my suggestion,
you can get my RB anyway by either add
Re: [Mesa-dev] [PATCH 1/5] util/hash_table: Don't hash the deleted and freed keys
On Mon, 5 Aug 2019 at 19:01, Alyssa Rosenzweig wrote: > > What's the implication of this for Panfrost? (I.e. which patch/es in the > series are pending on this change) Patch 2 needs this, otherwise we SIGSEGV on context destruction if blend shaders are used. And patch 3 depends on patch 5, otherwise the GPU would try to execute a shader in a memory region marked as not executable. Will be sending a v2 with Caio's suggestion. Cheers, Tomeu > On Mon, Aug 05, 2019 at 05:18:32PM +0200, Tomeu Vizoso wrote: > > Some hash functions (eg. key_u64_hash) will attempt to dereference the > > key, causing an invalid access when passed DELETED_KEY_VALUE (0x1) or > > FREED_KEY_VALUE (0x0). > > > > The entry.hash field isn't needed by the delete_function, so just stop > > populating it. > > > > Signed-off-by: Tomeu Vizoso > > Cc: Samuel Pitoiset > > Cc: Nicolai Hähnle > > --- > > src/util/hash_table.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/src/util/hash_table.c b/src/util/hash_table.c > > index f58575de558f..e691f8baa9c1 100644 > > --- a/src/util/hash_table.c > > +++ b/src/util/hash_table.c > > @@ -667,7 +667,6 @@ _mesa_hash_table_u64_clear(struct hash_table_u64 *ht, > > struct hash_entry entry; > > > > /* Create a fake entry for the delete function. */ > > - entry.hash = table->key_hash_function(table->deleted_key); > > entry.key = table->deleted_key; > > entry.data = ht->deleted_key_data; > > > > @@ -682,7 +681,6 @@ _mesa_hash_table_u64_clear(struct hash_table_u64 *ht, > > struct hash_entry entry; > > > > /* Create a fake entry for the delete function. */ > > - entry.hash = table->key_hash_function(uint_key(FREED_KEY_VALUE)); > > entry.key = uint_key(FREED_KEY_VALUE); > > entry.data = ht->freed_key_data; > > > > -- > > 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] [Bug 111302] radv assertion failed on SI cards `reg >= SI_CONTEXT_REG_OFFSET && reg < SI_CONFIG_REG_END'
https://bugs.freedesktop.org/show_bug.cgi?id=111302 Bug ID: 111302 Summary: radv assertion failed on SI cards `reg >= SI_CONTEXT_REG_OFFSET && reg < SI_CONFIG_REG_END' Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: turo.lammi...@alternativegames.net QA Contact: mesa-dev@lists.freedesktop.org Created attachment 144953 --> https://bugs.freedesktop.org/attachment.cgi?id=144953&action=edit Backtrace Running any Vulkan program which creates pipelines (vulkaninfo works, crash info from vkcube) triggers an assertion: ../src/amd/vulkan/radv_cs.h:45: radeon_set_config_reg_seq: Assertion `reg >= SI_CONTEXT_REG_OFFSET && reg < SI_CONFIG_REG_END' failed. Bisected to: 219d6939df8070bdc6e5054e71985a9d6d668da4 is the first bad commit commit 219d6939df8070bdc6e5054e71985a9d6d668da4 Author: Samuel Pitoiset Date: Fri Jul 12 11:12:57 2019 +0200 radv: add more assertions to make sure packets are correctly emitted Signed-off-by: Samuel Pitoiset Reviewed-by: Bas Nieuwenhuizen GPU: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM] Kernel: 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux LLVM: 9.0 SVN revision 366059 from apt.llvm.org No errors in dmesg Commenting out the assert allows it to proceed and seems to work but I doubt it's the right thing. This should probably be a release blocker. -- 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 111303] DoW3 performance is consistently lower than nvidia
https://bugs.freedesktop.org/show_bug.cgi?id=111303 Bug ID: 111303 Summary: DoW3 performance is consistently lower than nvidia Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: b...@basnieuwenhuizen.nl QA Contact: mesa-dev@lists.freedesktop.org especially on low settings. https://www.phoronix.com/scan.php?page=article&item=navi-august-2019&num=1 Looking into things on my desktop (threadripper + vega), it looks like there is 4-5 ms of no GPU work each frame. The sum of submit ioctls take about 2.5 ms. I need to figure out what is causing these chunks of no GPU work. -- 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 111302] radv assertion failed on SI cards `reg >= SI_CONTEXT_REG_OFFSET && reg < SI_CONFIG_REG_END'
https://bugs.freedesktop.org/show_bug.cgi?id=111302 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Bas Nieuwenhuizen --- Looks like one of the assert bounds was wrong, https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1590 should fix this. Please confirm whether it fixes the issue for 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
[Mesa-dev] [Bug 111302] radv assertion failed on SI cards `reg >= SI_CONTEXT_REG_OFFSET && reg < SI_CONFIG_REG_END'
https://bugs.freedesktop.org/show_bug.cgi?id=111302 Turo Lamminen changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #2 from Turo Lamminen --- Confirmed, that fixes it for me. -- 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 2/5] panfrost: Allocate shaders in their own BOs
On Mon, 5 Aug 2019 at 19:01, Alyssa Rosenzweig wrote:
>
> > +for (unsigned c = 0; c < 4; ++c) {
> > +struct panfrost_blend_rt *rt = &blend->rt[c];
> > +_mesa_hash_table_u64_clear(rt->shaders,
> > panfrost_delete_blend_shader);
> > +}
>
> What's the implication of the clear call? Does that recursively free
> the blend CSOs due to ralloc infrastructure?
struct panfrost_blend_shader is allocated here with memdup, so I was
indeed missing a free(). Thanks!
> > +memcpy(final.shader.bo->cpu, shader->bo->cpu,
> > shader->size);
>
> I'm not totally comfortable with reading off CPU-writeable GPU-mapped
> memory. We do it for scoreboarding too (which is probably a bug). But as
> discussed, this may have performance and/or security implications that
> we don't really understand. Maybe we might be better off having a purely
> CPU copy of shaders we'll need to patch?
Hmm, guess would be better to play safe in this case.
> > +entry->flags == flags) {
>
> This is definitely necessary, +1
>
> I'm wondering if we should be optimizing this somehow but we can sail
> that boat when we get there, I guess.
Yep.
> > @@ -2035,6 +2041,7 @@ panfrost_bind_shader_state(
> > enum pipe_shader_type type)
> > {
> > struct panfrost_context *ctx = pan_context(pctx);
> > +struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
> >
> > ctx->shader[type] = hwcso;
> >
> > @@ -2098,6 +2105,8 @@ panfrost_bind_shader_state(
> >
> > shader_state->compiled = true;
> > }
> > +
> > +panfrost_job_add_bo(job, shader_state->bo);
>
> This doesn't strike me as quite right. Conceptually, a shader state
> could be bound on one frame and then just reused for 2000 frames in a
> row, no? I guess that's not something you'll hit in CTS / normal apps,
> but it still strikes me as something we need to pay attention to.
>
> I think we want the add_bo() call to be part of emit_for_draw().
Makes sense.
> > +/* To maximize BO cache usage, don't allocate tiny BOs */
> > +size = MAX2(size, 4096);
>
> FWIW I think we round up to 4k anyway elsewhere?
I think that happens only when going though panfrost_drm_allocate_slab.
> Also, how does this
> interact with shaders -- if you have a bunch of tiny shaders of 128
> bytes each, you'll be wasting 3968 bytes per shader, no? At least the
> old strategy (with the 16MB slab) allowed subdivision with byte
> granularity.
Yeah, there's the wastage you describe, but we are currently wasting
several megs so it's a vast improvement in this regard.
For more fine-grained performance and memory usage improvements, I
think we should track these kind of regressions in CI, or we'll
struggle to consistently improve.
Thanks,
Tomeu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Mark BOs as NOEXEC
On Mon, 5 Aug 2019 at 19:06, Alyssa Rosenzweig wrote:
>
> > +if (screen->kernel_version >= 1) {
>
> Maybe have some #defines for kernel versions instead of magic numbers?
> Also, maybe make it clear that this is a minor version -- what does
> happen if we bump the major version at some point...?
In that case we would need to change Mesa to also take into account
the major field. I cannot see why we would do it, though.
> > panfrost_create_screen(int fd, struct renderonly *ro)
> > {
> > struct panfrost_screen *screen = rzalloc(NULL, struct
> > panfrost_screen);
> > + drmVersionPtr version;
> >
> > pan_debug = debug_get_option_pan_debug();
> >
> > @@ -618,6 +619,17 @@ panfrost_create_screen(int fd, struct renderonly *ro)
> > return NULL;
> > }
> >
> > + version = drmGetVersion(fd);
> > + if (version->version_major != 1) {
> > +debug_printf("panfrost: Unsupported version: %u.%u.%u",
> > + version->version_major,
> > version->version_minor,
> > + version->version_patchlevel);
> > + drmFreeVersion(version);
> > +return NULL;
> > +}
> > +screen->kernel_version = version->version_minor;
> > + drmFreeVersion(version);
> > +
> > util_dynarray_init(&screen->transient_bo, screen);
> >
>
> I don't really care *too* much but spacing is all over the place.
Will check before v2.
Thanks,
Tomeu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] panfrost: Print errors from kernel
On Mon, 5 Aug 2019 at 19:06, Alyssa Rosenzweig wrote:
>
> I didn't know about %m, nifty.
>
> I don't think this is portable, though... which might be a problem
> if/when someone tries to port Android, etc.
Android should be fine, as they use it in their own code.
Cheers,
Tomeu
>
> On Mon, Aug 05, 2019 at 05:18:36PM +0200, Tomeu Vizoso wrote:
> > Signed-off-by: Tomeu Vizoso
> > ---
> > src/gallium/drivers/panfrost/pan_drm.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/gallium/drivers/panfrost/pan_drm.c
> > b/src/gallium/drivers/panfrost/pan_drm.c
> > index 122bc5f3db36..46cceb808919 100644
> > --- a/src/gallium/drivers/panfrost/pan_drm.c
> > +++ b/src/gallium/drivers/panfrost/pan_drm.c
> > @@ -49,14 +49,14 @@ panfrost_drm_mmap_bo(struct panfrost_screen *screen,
> > struct panfrost_bo *bo)
> >
> > ret = drmIoctl(screen->fd, DRM_IOCTL_PANFROST_MMAP_BO, &mmap_bo);
> > if (ret) {
> > -fprintf(stderr, "DRM_IOCTL_PANFROST_MMAP_BO failed: %d\n",
> > ret);
> > +fprintf(stderr, "DRM_IOCTL_PANFROST_MMAP_BO failed: %m\n");
> > assert(0);
> > }
> >
> > bo->cpu = os_mmap(NULL, bo->size, PROT_READ | PROT_WRITE,
> > MAP_SHARED,
> >screen->fd, mmap_bo.offset);
> > if (bo->cpu == MAP_FAILED) {
> > -fprintf(stderr, "mmap failed: %p\n", bo->cpu);
> > +fprintf(stderr, "mmap failed: %p %m\n", bo->cpu);
> > assert(0);
> > }
> >
> > @@ -121,7 +121,7 @@ panfrost_drm_create_bo(struct panfrost_screen *screen,
> > size_t size,
> >
> > ret = drmIoctl(screen->fd, DRM_IOCTL_PANFROST_CREATE_BO,
> > &create_bo);
> > if (ret) {
> > -fprintf(stderr, "DRM_IOCTL_PANFROST_CREATE_BO
> > failed: %d\n", ret);
> > +fprintf(stderr, "DRM_IOCTL_PANFROST_CREATE_BO
> > failed: %m\n");
> > assert(0);
> > }
> >
> > @@ -175,7 +175,7 @@ panfrost_drm_release_bo(struct panfrost_screen *screen,
> > struct panfrost_bo *bo,
> >
> > ret = drmIoctl(screen->fd, DRM_IOCTL_GEM_CLOSE, &gem_close);
> > if (ret) {
> > -fprintf(stderr, "DRM_IOCTL_GEM_CLOSE failed: %d\n", ret);
> > +fprintf(stderr, "DRM_IOCTL_GEM_CLOSE failed: %m\n");
> > assert(0);
> > }
> >
> > @@ -331,7 +331,7 @@ panfrost_fence_create(struct panfrost_context *ctx)
> > */
> > drmSyncobjExportSyncFile(screen->fd, ctx->out_sync, &f->fd);
> > if (f->fd == -1) {
> > -fprintf(stderr, "export failed\n");
> > +fprintf(stderr, "export failed: %m\n");
> > free(f);
> > return NULL;
> > }
> > --
> > 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] [Bug 111027] [radv] recent llvm snapshot is hanging The Witcher 3 (Wine+dxvk)
https://bugs.freedesktop.org/show_bug.cgi?id=111027 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Bas Nieuwenhuizen --- I think this was an issue with the linking for tessellation being changed in LLVM, which was fixed by the following radv MR: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1216 Given the age, I'm closing. Feel free to reopen if still occurring. -- 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] panfrost/ci: Remove two tests from list of failures
These tests have been fixed by:
b514f411837b ("glcpp: use pre-expansion line number for __LINE__")
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/expected-failures.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt
b/src/gallium/drivers/panfrost/ci/expected-failures.txt
index 440231bfb54b..0ecfb02c7cd6 100644
--- a/src/gallium/drivers/panfrost/ci/expected-failures.txt
+++ b/src/gallium/drivers/panfrost/ci/expected-failures.txt
@@ -233,7 +233,5 @@ dEQP-GLES2.functional.fragment_ops.random.99
dEQP-GLES2.functional.polygon_offset.fixed16_render_with_units
dEQP-GLES2.functional.polygon_offset.fixed16_factor_1_slope
dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_w
-dEQP-GLES2.functional.shaders.preprocessor.predefined_macros.line_2_fragment
-dEQP-GLES2.functional.shaders.preprocessor.predefined_macros.line_2_vertex
dEQP-GLES2.functional.shaders.scoping.valid.local_variable_hides_function_parameter_fragment
dEQP-GLES2.functional.shaders.scoping.valid.local_variable_hides_function_parameter_vertex
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111306] gbm creates BO with wrong pitch when dri3_get_modifiers returns modifiers, causing drmModeAddFB2WithModifiers to fail
https://bugs.freedesktop.org/show_bug.cgi?id=111306 Bug ID: 111306 Summary: gbm creates BO with wrong pitch when dri3_get_modifiers returns modifiers, causing drmModeAddFB2WithModifiers to fail Product: Mesa Version: 19.1 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: jwrdego...@fedoraproject.org QA Contact: mesa-dev@lists.freedesktop.org This was first discussed here: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/254 Where I came up with a completely wrong fix. The easiest way to reproduce this is: 1) Take a Skylake iGPU (in my case with 2 1920x1080 monitors attached) 2) Run Xorg master with the modesetting driver (master is necessary because glamor has support for modifiers enabled only in master) 3) Run a recent gnome-shell on top of Xorg 4) Run xrandr --fb x changing the width to be 32 pixels larger then necessary (or any other value not a multiple of 64) 5) Watch Xorg.log filling with errors like these: [ 28843.414] (WW) modeset(0): Page flip failed: Invalid argument [ 28843.414] (EE) modeset(0): present flip failed [ 28843.595] (WW) modeset(0): Page flip failed: Invalid argument [ 28843.595] (EE) modeset(0): present flip failed https://gitlab.freedesktop.org/xorg/xserver/merge_requests/254 has a completely wrong workaround for this by disabling modifier support when a secondary GPU with outputs is present, but that just happen to cause a fb width which was not a multiple of 64. As mentioned above the problem can be reproduced on a single GPU. The problem seems to be that when the xserver's dri3_get_modifiers method returns a non-empty modifier list, gbm creates buffer-objects using these modifiers (fine) without taking the pitch requirements into account. Or at least without taking the pitch requirements for using these modifiers on a BO which is to be used as a framebuffer into account. This causes the Present extension flip done with a pixmap backed by this BO to fail (the xserver will fallback to a bitblt in this case). Fixing this may require new API, since currently when using modifiers it is not possible to indicate that the BO will be used for scanout AFAICT. Another Xserver level workaround is this: --- a/hw/xfree86/modes/xf86RandR12.c +++ b/hw/xfree86/modes/xf86RandR12.c @@ -693,6 +693,12 @@ xf86RandR12ScreenSetSize(ScreenPtr pScreen, if (pRoot && pScrn->vtSema) (*pScrn->EnableDisableFBAccess) (pScrn, FALSE); +/* + * Present flipping with modifiers may fail if our screen width is not + * a multiple of 64. + */ +width = (width + 63) & ~63; + /* Let the driver update virtualX and virtualY */ if (!(*config->funcs->resize) (pScrn, width, height)) goto finish; Which works, but meh. -- 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 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #2 from Denis --- Hi Greg, could you please re-upload apitrace somewhere instead of BZ? Looks like it is too big and can't be opened. (google drive or any other file-sharing system will be ok I think). -- 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 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #3 from Greg --- Ok, here it is https://drive.google.com/file/d/1D3GNUW-DTaxI7hFEZmoEnucRQOrzNBAR/view?usp=sharing That's fresh trace (i've lost old one), way smaller this time. Apitrace leaks doesn't find much, yet by the end of trace there were 115 `/dev/dri/renderD128` regions in process memory. -- 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 2/5] panfrost: Allocate shaders in their own BOs
> Yeah, there's the wastage you describe, but we are currently wasting > several megs so it's a vast improvement in this regard. Ah, touche. > For more fine-grained performance and memory usage improvements, I > think we should track these kind of regressions in CI, or we'll > struggle to consistently improve. I'm not sure how performance/memory CI would work exactly, but it could be interesting. (I don't think a build should 'fail' if perf regressed but functionality improved..) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] panfrost: Print errors from kernel
> Android should be fine, as they use it in their own code. Hmm, still uncomfortable, but tentative R-b I guess :/ I just.. don't like relying on glibc specific behaviour. Even if bionic implements it too, I mean... what happens for the postmarketOS guys? They've been interested in Panfrost for a while, but they use musl. Will this break their build..? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost/ci: Remove two tests from list of failures
R-b but already been pushed.. please use my Collabora email so I see stuff on time! :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #4 from Greg --- Created attachment 144957 --> https://bugs.freedesktop.org/attachment.cgi?id=144957&action=edit terminal output of `apitrace replay mine.trace` Also not sure if it's important, but when replaying this trace I get lots of messages in log (from driver I guess). -- 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 5/5] panfrost: Print errors from kernel
On Tue, 6 Aug 2019 at 16:58, Alyssa Rosenzweig wrote: > > > Android should be fine, as they use it in their own code. > > Hmm, still uncomfortable, but tentative R-b I guess :/ > > I just.. don't like relying on glibc specific behaviour. Even if bionic > implements it too, I mean... what happens for the postmarketOS guys? > They've been interested in Panfrost for a while, but they use musl. Will > this break their build..? Musl seems to support it as well :) https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c#n57 Cheers, Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #5 from Greg --- Mentioned memory regions can also be seen when replaying the trace, accumulating up to 116. -- 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 111308] [Regression, NIR, bisected] Black squares in Unigine Heaven via DXVK
https://bugs.freedesktop.org/show_bug.cgi?id=111308
Bug ID: 111308
Summary: [Regression, NIR, bisected] Black squares in Unigine
Heaven via DXVK
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
Assignee: mesa-dev@lists.freedesktop.org
Reporter: danylo.pilia...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org
Created attachment 144958
--> https://bugs.freedesktop.org/attachment.cgi?id=144958&action=edit
unigine_heaven_artifacts
On latest master there are black squares artifacts when running Unigine Heaven
through DXVK under wine.
It is bisected to:
96fcb3f95bdd53c8c1bdc243c95811acabd3f52c is the first bad commit
commit 96fcb3f95bdd53c8c1bdc243c95811acabd3f52c
Author: Ian Romanick
Date: Thu Oct 11 14:21:42 2018 -0700
nir/algebraic: Use value range analysis to eliminate tautological compares
not used by if-statements
This just eliminates tautological / contradictory compares that are used
for bcsel and other non-if-statement cases. If-statements are not
affected because removing flow control can cause the i965 instrution
scheduler to create some very long live ranges resulting in unncessary
spilling. This causes some shaders to fall of a performance cliff.
Since many small if-statements are already flattened to bcsel, this
optimization covers more than 68% of the possible cases (2417 shaders
helped for instructions on Skylake vs. 3554).
v2: Reorder and add whitespace to make the relationship between the
patterns more obvious. Suggested by Caio.
All Gen7+ platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 16333474 -> 16322028 (-0.07%)
instructions in affected programs: 438559 -> 427113 (-2.61%)
helped: 1765
HURT: 0
helped stats (abs) min: 1 max: 275 x̄: 6.48 x̃: 4
helped stats (rel) min: 0.20% max: 36.36% x̄: 4.07% x̃: 1.82%
95% mean confidence interval for instructions value: -6.87 -6.10
95% mean confidence interval for instructions %-change: -4.30% -3.84%
Instructions are helped.
total cycles in shared programs: 367608554 -> 367511103 (-0.03%)
cycles in affected programs: 8368829 -> 8271378 (-1.16%)
helped: 1541
HURT: 129
helped stats (abs) min: 1 max: 4468 x̄: 66.78 x̃: 39
helped stats (rel) min: 0.01% max: 45.69% x̄: 4.10% x̃: 2.17%
HURT stats (abs) min: 1 max: 973 x̄: 42.25 x̃: 10
HURT stats (rel) min: 0.02% max: 64.39% x̄: 2.15% x̃: 0.60%
95% mean confidence interval for cycles value: -64.90 -51.81
95% mean confidence interval for cycles %-change: -3.89% -3.36%
Cycles are helped.
total spills in shared programs: 8867 -> 8868 (0.01%)
spills in affected programs: 18 -> 19 (5.56%)
helped: 0
HURT: 1
total fills in shared programs: 21900 -> 21903 (0.01%)
fills in affected programs: 78 -> 81 (3.85%)
helped: 0
HURT: 1
All Gen6 and earlier platforms had similar results. (Sandy Bridge shown)
total instructions in shared programs: 10829877 -> 10829247 (<.01%)
instructions in affected programs: 30240 -> 29610 (-2.08%)
helped: 177
HURT: 0
helped stats (abs) min: 1 max: 15 x̄: 3.56 x̃: 3
helped stats (rel) min: 0.37% max: 17.39% x̄: 2.68% x̃: 1.94%
95% mean confidence interval for instructions value: -3.93 -3.18
95% mean confidence interval for instructions %-change: -3.04% -2.32%
Instructions are helped.
total cycles in shared programs: 154036580 -> 154035437 (<.01%)
cycles in affected programs: 352402 -> 351259 (-0.32%)
helped: 96
HURT: 28
helped stats (abs) min: 1 max: 128 x̄: 14.73 x̃: 6
helped stats (rel) min: 0.03% max: 24.00% x̄: 1.51% x̃: 0.46%
HURT stats (abs) min: 1 max: 117 x̄: 9.68 x̃: 4
HURT stats (rel) min: 0.03% max: 2.24% x̄: 0.43% x̃: 0.23%
95% mean confidence interval for cycles value: -13.40 -5.03
95% mean confidence interval for cycles %-change: -1.62% -0.53%
Cycles are helped.
Reviewed-by: Caio Marcelo de Oliveira Filho
:04 04 30117ba78cfcc635e7974f4af6e4eff4f16eadf2
7e5be8503a115d930b1dc2591365e1ea0e1d4d5f M src
The exact optimization which causes it is:
(('flt', 'b(is_not_positive)', 'a(is_gt_zero)'), True),
Which itself looks correct. Maybe there is a bug in range analysis or/and some
wild NaN sneaked in.
--
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] clover: Fix build after clang r367864
Signed-off-by: Jan Vesely
---
src/gallium/state_trackers/clover/llvm/compat.hpp | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 0ecf622a9af..b273abf75af 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -79,11 +79,19 @@ namespace clover {
#endif
}
-#if HAVE_LLVM >= 0x0500
+#if HAVE_LLVM >= 0x1000
+ const clang::InputKind ik_opencl = clang::Language::OpenCL;
+#elif HAVE_LLVM >= 0x0900
+ const clang::InputKind ik_opencl = clang::InputKind::Language::OpenCL;
+#elif HAVE_LLVM >= 0x0500
const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
- const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl10;
#else
const clang::InputKind ik_opencl = clang::IK_OpenCL;
+#endif
+
+#if HAVE_LLVM >= 0x0500
+ const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl10;
+#else
const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl;
#endif
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] clover: Fix build after clang r367864
v2: Drop special case of llvm-9
Signed-off-by: Jan Vesely
---
src/gallium/state_trackers/clover/llvm/compat.hpp | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 0ecf622a9af..b040902fcfe 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -79,11 +79,17 @@ namespace clover {
#endif
}
-#if HAVE_LLVM >= 0x0500
+#if HAVE_LLVM >= 0x1000
+ const clang::InputKind ik_opencl = clang::Language::OpenCL;
+#elif HAVE_LLVM >= 0x0500
const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
- const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl10;
#else
const clang::InputKind ik_opencl = clang::IK_OpenCL;
+#endif
+
+#if HAVE_LLVM >= 0x0500
+ const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl10;
+#else
const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl;
#endif
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111308] [Regression, NIR, bisected] Black squares in Unigine Heaven via DXVK
https://bugs.freedesktop.org/show_bug.cgi?id=111308 Ian Romanick changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Ian Romanick --- Checking out 96fcb3f95bd and commenting out that optimization doesn't affect any of the Unigine Heaven shaders that I have in shader-db (which are all from the native Linux OpenGL version). Do you think you could send me dumps with and without that optimization with the environment variable NIR_PRINT=true? If I can see what changes in the NIR, that should shed some light on things. -- 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 111308] [Regression, NIR, bisected] Black squares in Unigine Heaven via DXVK
https://bugs.freedesktop.org/show_bug.cgi?id=111308 --- Comment #2 from Ian Romanick --- Another thing to try... does changing 'flt' to '~flt' make any difference? -- 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 5/5] panfrost: Print errors from kernel
Alright, you win ;) R-b! On Tue, Aug 06, 2019 at 05:06:32PM +0200, Tomeu Vizoso wrote: > On Tue, 6 Aug 2019 at 16:58, Alyssa Rosenzweig wrote: > > > > > Android should be fine, as they use it in their own code. > > > > Hmm, still uncomfortable, but tentative R-b I guess :/ > > > > I just.. don't like relying on glibc specific behaviour. Even if bionic > > implements it too, I mean... what happens for the postmarketOS guys? > > They've been interested in Panfrost for a while, but they use musl. Will > > this break their build..? > > Musl seems to support it as well :) > > https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c#n57 > > Cheers, > > Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111309] Mesa doesn't build with current Scons version (3.1.0)
https://bugs.freedesktop.org/show_bug.cgi?id=111309
Bug ID: 111309
Summary: Mesa doesn't build with current Scons version (3.1.0)
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: medium
Component: Other
Assignee: mesa-dev@lists.freedesktop.org
Reporter: fdo-b...@engestrom.ch
QA Contact: mesa-dev@lists.freedesktop.org
$ scons
scons: Reading SConscript files ...
scons: warning: EnsureSConsVersion is ignored for development version
File "SConstruct", line 33, in
TypeError: a bytes-like object is required, not 'str':
File "SConstruct", line 47:
ENV = os.environ,
File "/usr/lib/python3.7/site-packages/SCons/Environment.py", line 991:
apply_tools(self, tools, toolpath)
File "/usr/lib/python3.7/site-packages/SCons/Environment.py", line 107:
env.Tool(tool)
File "/usr/lib/python3.7/site-packages/SCons/Environment.py", line 1798:
tool(self)
File "/usr/lib/python3.7/site-packages/SCons/Tool/__init__.py", line 303:
self.generate(env, *args, **kw)
File "scons/gallium.py", line 219:
env['gcc_compat'] = check_cc(env, 'GCC', 'defined(__GNUC__)')
File "scons/gallium.py", line 135:
source.write('#if !(%s)\n#error\n#endif\n' % expr)
File "/usr/lib/python3.7/tempfile.py", line 481:
return func(*args, **kwargs)
>From the error, it sounds like it could be a python2 vs python3 issue?
It works fine if I downgrade back to scons 3.0.4 (which I'll be doing for the
time being)
--
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 111309] Mesa doesn't build with current Scons version (3.1.0)
https://bugs.freedesktop.org/show_bug.cgi?id=111309 Eric Engestrom changed: What|Removed |Added CC||bri...@vmware.com, ||charmai...@vmware.com, ||jfons...@vmware.com -- 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] EXT_shader_image_load_store requires format-less loads?
Hi Pierre-Eric, I see you recently added EXT_shader_image_load_store - nice. It seems like you're relying on the format-less read access feature to make it happen: + extensions->EXT_shader_image_load_store &= + screen->get_param(screen, PIPE_CAP_IMAGE_LOAD_FORMATTED); Can you elaborate why this is necessary? From a quick read of the spec, it seems like the format is required, and maps to a format same way that ARB_image_load_store does (well, *slightly* different, but in the end, we get one of those same enum values out). The LOAD_FORMATTED thing enables you to read from an image with PIPE_FORMAT_NONE (which normally can only be written to). I don't see anything in the spec which requires it, but perhaps I missed something. I'd be a bit surprised though, since this is rather non-trivial on NVIDIA GPUs. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: remove super old TODOs from shaderapi.c
--- src/mesa/main/shaderapi.c | 5 - 1 file changed, 5 deletions(-) diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c index 1351f7fd06f..607d30e2bd4 100644 --- a/src/mesa/main/shaderapi.c +++ b/src/mesa/main/shaderapi.c @@ -29,11 +29,6 @@ * * Implementation of GLSL-related API functions. * The glUniform* functions are in uniforms.c - * - * - * XXX things to do: - * 1. Check that the right error code is generated for all _mesa_error() calls. - * 2. Insert FLUSH_VERTICES calls in various places */ -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] clover: Fix build after clang r367864
Back from vacation try to bring all stuff on par - LLVM 10 (with Clover)
- and boom...
Acked-by: Dieter Nützel
Tested-by: Dieter Nützel
Thank you Jan!
Dieter
Am 06.08.2019 19:59, schrieb Jan Vesely:
v2: Drop special case of llvm-9
Signed-off-by: Jan Vesely
---
src/gallium/state_trackers/clover/llvm/compat.hpp | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 0ecf622a9af..b040902fcfe 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -79,11 +79,17 @@ namespace clover {
#endif
}
-#if HAVE_LLVM >= 0x0500
+#if HAVE_LLVM >= 0x1000
+ const clang::InputKind ik_opencl = clang::Language::OpenCL;
+#elif HAVE_LLVM >= 0x0500
const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
- const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl10;
#else
const clang::InputKind ik_opencl = clang::IK_OpenCL;
+#endif
+
+#if HAVE_LLVM >= 0x0500
+ const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl10;
+#else
const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl;
#endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] clover: Fix build after clang r367864
I had come up with an almost identical patch last night, but hadn't
gotten around to testing it before turning in.
Reviewed-by: Aaron Watry
On Tue, Aug 6, 2019 at 12:59 PM Jan Vesely wrote:
>
> v2: Drop special case of llvm-9
> Signed-off-by: Jan Vesely
> ---
> src/gallium/state_trackers/clover/llvm/compat.hpp | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index 0ecf622a9af..b040902fcfe 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -79,11 +79,17 @@ namespace clover {
> #endif
> }
>
> -#if HAVE_LLVM >= 0x0500
> +#if HAVE_LLVM >= 0x1000
> + const clang::InputKind ik_opencl = clang::Language::OpenCL;
> +#elif HAVE_LLVM >= 0x0500
> const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
> - const clang::LangStandard::Kind lang_opencl10 =
> clang::LangStandard::lang_opencl10;
> #else
> const clang::InputKind ik_opencl = clang::IK_OpenCL;
> +#endif
> +
> +#if HAVE_LLVM >= 0x0500
> + const clang::LangStandard::Kind lang_opencl10 =
> clang::LangStandard::lang_opencl10;
> +#else
> const clang::LangStandard::Kind lang_opencl10 =
> clang::LangStandard::lang_opencl;
> #endif
>
> --
> 2.21.0
>
> ___
> 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] radeonsi: Bump number of allowed global buffers to 48 (again, for clover Blender assertion)
Am 20.06.2019 20:44, schrieb Jan Vesely:
On Sat, 2019-06-15 at 07:38 +0200, Dieter Nützel wrote:
Am 14.06.2019 08:13, schrieb Jan Vesely:
> On Thu, 2019-06-13 at 21:20 +0200, Dieter Nützel wrote:
> > Blender crash as expected ;-)
> >
> > /home/dieter> trying to save userpref at
> > /home/dieter/.config/blender/2.79/config/userpref.blend ok
> > Read blend: /data/Blender/barbershop_interior_gpu.blend
> > scripts disabled for "/data/Blender/barbershop_interior_gpu.blend",
> > skipping 'generate_customprops.py'
> > skipping driver 'var', automatic scripts are disabled
> > skipping driver 'var', automatic scripts are disabled
> > skipping driver 'var', automatic scripts are disabled
> > skipping driver 'var', automatic scripts are disabled
> > skipping driver 'var', automatic scripts are disabled
> > skipping driver 'var', automatic scripts are disabled
> > skipping driver 'var', automatic scripts are disabled
> > skipping driver 'var', automatic scripts are disabled
> > skipping driver 'var', automatic scripts are disabled
> > Device init success
> > Compiling OpenCL program split
> > Kernel compilation of split finished in 8.41s.
> >
> > Compiling OpenCL program base
> > Kernel compilation of base finished in 4.55s.
> >
> > Compiling OpenCL program denoising
> > Kernel compilation of denoising finished in 2.08s.
> >
> > blender: ../src/gallium/drivers/radeonsi/si_compute.c:319:
> > si_set_global_binding: Assertion `first + n <= MAX_GLOBAL_BUFFERS'
> > failed.
> >
> > [1]Abbruch blender (core dumped)
>
> The number of max global buffers was bumped in 06bf56725d to fix
> similar crash in luxmark. I guess it needs another bump.
Hello Jan,
I'm so blind...
...bumping it 48 and 64 (first try) works. 33 not ;-)
We shouldn't waste to much memory.
Feel free to post a patch. I'm not sure at which point Marek wants to
switch to dynamic allocation (or if at all), but there's no limit in
OCL so we might end up bumping this every time a new app pushes
against the limit.
Hello Jan,
comming 'happily' from vacation and think we should've this in 19.2.
Marek,
do we need dynamic allocation, yet?
Sorry, please see attachment.
Would be nice, if someone of you could add these lines during commit:
Fixes assertion failure/crash when running Blender (2.79b) on
clover.
CC: mesa-sta...@lists.freedesktop.org<= ???
Greetings,
DieterFrom 9c3bd0c4c51452a8b1fd278006ef51feed055864 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dieter=20N=C3=BCtzel?=
Date: Wed, 7 Aug 2019 04:33:57 +0200
Subject: [PATCH] radeonsi: Bump number of allowed global buffers to 48
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Dieter Nützel
---
src/gallium/drivers/radeonsi/si_compute.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.h b/src/gallium/drivers/radeonsi/si_compute.h
index 86021178533..5a9be612104 100644
--- a/src/gallium/drivers/radeonsi/si_compute.h
+++ b/src/gallium/drivers/radeonsi/si_compute.h
@@ -29,7 +29,7 @@
#include "si_shader.h"
-#define MAX_GLOBAL_BUFFERS 32
+#define MAX_GLOBAL_BUFFERS 48
struct si_compute {
struct si_shader_selector sel;
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] st/mesa: relax EXT_shader_image_load_store enable
There's no reason to bring format-less load requirement into this
extension. It requires a size to be provided, and a compatible format is
computed from the size + data type. For example
layout(size1x32) uniform iimage1D image;
becomes
DCL IMAGE[0], 1D, PIPE_FORMAT_R32_SINT, WR
whereas PIPE_CAP_IMAGE_LOAD_FORMATTED is designed to allow
PIPE_FORMAT_NONE to be provided as a format and still enable LOAD
operations to be performed.
So the shader has all the information it needs about the format.
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_extensions.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index abc816ed0d4..16bfedcdbc4 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1180,9 +1180,6 @@ void st_init_extensions(struct pipe_screen *screen,
extensions->OES_sample_variables = extensions->ARB_sample_shading &&
extensions->ARB_gpu_shader5;
- extensions->EXT_shader_image_load_store &=
- screen->get_param(screen, PIPE_CAP_IMAGE_LOAD_FORMATTED);
-
/* Maximum sample count. */
{
static const enum pipe_format color_formats[] = {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] gallium: redefine ATOMINC_WRAP to be more hardware-friendly
Both AMD and NVIDIA hardware define it this way. Instead of replicating
the logic everywhere, just fix it up in one place.
Signed-off-by: Ilia Mirkin
---
I'm open to also not doing this. Just seems like it'll make our
collective lives a little easier, since this is what the hw wants (and
presumably other APIs ... PTX definitely defines it this way).
If there's push-back, I can also duplicate the logic in codegen.
src/gallium/docs/source/tgsi.rst | 2 +-
src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 12
src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 11 ++-
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 17ad097e85e..e72b047dbd5 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2846,7 +2846,7 @@ These atomic operations may only be used with 32-bit
integer image formats.
dst_x = resource[offset] + 1
- resource[offset] = dst_x < src_x ? dst_x : 0
+ resource[offset] = dst_x <= src_x ? dst_x : 0
.. opcode:: ATOMDEC_WRAP - Atomic decrement + wrap around
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 4a4ba43780a..f79ed2c57e1 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
@@ -828,18 +828,6 @@ static void atomic_emit(
args.data[num_data++] =
ac_to_integer(&ctx->ac, lp_build_emit_fetch(bld_base, inst, 2,
0));
- if (inst->Instruction.Opcode == TGSI_OPCODE_ATOMINC_WRAP) {
- /* ATOMIC_INC instruction does:
-* value = (value + 1) % (data + 1)
-* but we want:
-* value = (value + 1) % data
-* So replace 'data' by 'data - 1'.
-*/
- args.data[0] = LLVMBuildSub(ctx->ac.builder,
- args.data[0],
- ctx->ac.i32_1, "");
- }
-
args.cache_policy = get_cache_policy(ctx, inst, true, false, false);
if (inst->Src[0].Register.File == TGSI_FILE_BUFFER) {
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index ff2ec0726e8..9b982569490 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -3938,9 +3938,18 @@ glsl_to_tgsi_visitor::visit_image_intrinsic(ir_call *ir)
case ir_intrinsic_image_atomic_comp_swap:
opcode = TGSI_OPCODE_ATOMCAS;
break;
- case ir_intrinsic_image_atomic_inc_wrap:
+ case ir_intrinsic_image_atomic_inc_wrap: {
+ /* There's a bit of disagreement between GLSL and the hardware. The
+ * hardware wants to wrap after the given wrap value, while GLSL
+ * wants to wrap at the value. Subtract 1 to make up the difference.
+ */
+ st_src_reg wrap = get_temp(glsl_type::uint_type);
+ emit_asm(ir, TGSI_OPCODE_ADD, st_dst_reg(wrap),
+ arg1, st_src_reg_for_int(-1));
+ arg1 = wrap;
opcode = TGSI_OPCODE_ATOMINC_WRAP;
break;
+ }
case ir_intrinsic_image_atomic_dec_wrap:
opcode = TGSI_OPCODE_ATOMDEC_WRAP;
break;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] nvc0: add support for ATOMC_WRAP TGSI operations
Signed-off-by: Ilia Mirkin --- .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 10 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index 2dd13e70d0e..c3e3cf2dff5 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -606,6 +606,8 @@ nv50_ir::DataType Instruction::inferSrcType() const case TGSI_OPCODE_ATOMXOR: case TGSI_OPCODE_ATOMUMIN: case TGSI_OPCODE_ATOMUMAX: + case TGSI_OPCODE_ATOMDEC_WRAP: + case TGSI_OPCODE_ATOMINC_WRAP: case TGSI_OPCODE_UBFE: case TGSI_OPCODE_UMSB: case TGSI_OPCODE_UP2H: @@ -969,6 +971,8 @@ static nv50_ir::operation translateOpcode(uint opcode) NV50_IR_OPCODE_CASE(ATOMIMIN, ATOM); NV50_IR_OPCODE_CASE(ATOMIMAX, ATOM); NV50_IR_OPCODE_CASE(ATOMFADD, ATOM); + NV50_IR_OPCODE_CASE(ATOMDEC_WRAP, ATOM); + NV50_IR_OPCODE_CASE(ATOMINC_WRAP, ATOM); NV50_IR_OPCODE_CASE(TEX2, TEX); NV50_IR_OPCODE_CASE(TXB2, TXB); @@ -1012,6 +1016,8 @@ static uint16_t opcodeToSubOp(uint opcode) case TGSI_OPCODE_ATOMUMAX: return NV50_IR_SUBOP_ATOM_MAX; case TGSI_OPCODE_ATOMIMAX: return NV50_IR_SUBOP_ATOM_MAX; case TGSI_OPCODE_ATOMFADD: return NV50_IR_SUBOP_ATOM_ADD; + case TGSI_OPCODE_ATOMDEC_WRAP: return NV50_IR_SUBOP_ATOM_DEC; + case TGSI_OPCODE_ATOMINC_WRAP: return NV50_IR_SUBOP_ATOM_INC; case TGSI_OPCODE_IMUL_HI: case TGSI_OPCODE_UMUL_HI: return NV50_IR_SUBOP_MUL_HIGH; @@ -1628,6 +1634,8 @@ bool Source::scanInstruction(const struct tgsi_full_instruction *inst) case TGSI_OPCODE_ATOMUMAX: case TGSI_OPCODE_ATOMIMAX: case TGSI_OPCODE_ATOMFADD: + case TGSI_OPCODE_ATOMDEC_WRAP: + case TGSI_OPCODE_ATOMINC_WRAP: case TGSI_OPCODE_LOAD: info->io.globalAccess |= (insn.getOpcode() == TGSI_OPCODE_LOAD) ? 0x1 : 0x2; @@ -3779,6 +3787,8 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) case TGSI_OPCODE_ATOMUMAX: case TGSI_OPCODE_ATOMIMAX: case TGSI_OPCODE_ATOMFADD: + case TGSI_OPCODE_ATOMDEC_WRAP: + case TGSI_OPCODE_ATOMINC_WRAP: handleATOM(dst0, dstTy, tgsi::opcodeToSubOp(tgsi.getOpcode())); break; case TGSI_OPCODE_RESQ: diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 8a9d3c4d0bd..b1e12432e14 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -280,6 +280,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_QUERY_SO_OVERFLOW: case PIPE_CAP_DEST_SURFACE_SRGB_CONTROL: case PIPE_CAP_TGSI_DIV: + case PIPE_CAP_TGSI_ATOMINC_WRAP: return 1; case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER: return nouveau_screen(pscreen)->vram_domain & NOUVEAU_BO_VRAM ? 1 : 0; @@ -364,7 +365,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_CS_DERIVED_SYSTEM_VALUES_SUPPORTED: case PIPE_CAP_FBFETCH_COHERENT: case PIPE_CAP_TGSI_SKIP_SHRINK_IO_ARRAYS: - case PIPE_CAP_TGSI_ATOMINC_WRAP: return 0; case PIPE_CAP_VENDOR_ID: -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] nvc0: fix program dumping, use _debug_printf
This debug situation is unforunate. debug_printf only does something
with DEBUG set, but in practice all that needs to be moved to !NDEBUG.
For now, use _debug_printf which always prints. However the whole
function is guarded by !NDEBUG.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index 32487248c7a..2f235805436 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -551,18 +551,18 @@ nvc0_program_dump(struct nvc0_program *prog)
unsigned pos;
if (prog->type != PIPE_SHADER_COMPUTE) {
- debug_printf("dumping HDR for type %i\n", prog->type);
+ _debug_printf("dumping HDR for type %i\n", prog->type);
for (pos = 0; pos < ARRAY_SIZE(prog->hdr); ++pos)
- debug_printf("HDR[%02"PRIxPTR"] = 0x%08x\n",
+ _debug_printf("HDR[%02"PRIxPTR"] = 0x%08x\n",
pos * sizeof(prog->hdr[0]), prog->hdr[pos]);
}
- debug_printf("shader binary code (0x%x bytes):", prog->code_size);
+ _debug_printf("shader binary code (0x%x bytes):", prog->code_size);
for (pos = 0; pos < prog->code_size / 4; ++pos) {
if ((pos % 8) == 0)
- debug_printf("\n");
- debug_printf("%08x ", prog->code[pos]);
+ _debug_printf("\n");
+ _debug_printf("%08x ", prog->code[pos]);
}
- debug_printf("\n");
+ _debug_printf("\n");
}
#endif
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXT_shader_image_load_store requires format-less loads?
It's possible that I misread the spec, because the format qualifier looked imprecise. Feel free to fix this. Marek On Tue, Aug 6, 2019 at 8:10 PM Ilia Mirkin wrote: > Hi Pierre-Eric, > > I see you recently added EXT_shader_image_load_store - nice. It seems > like you're relying on the format-less read access feature to make it > happen: > > + extensions->EXT_shader_image_load_store &= > + screen->get_param(screen, PIPE_CAP_IMAGE_LOAD_FORMATTED); > > Can you elaborate why this is necessary? From a quick read of the > spec, it seems like the format is required, and maps to a format same > way that ARB_image_load_store does (well, *slightly* different, but in > the end, we get one of those same enum values out). The LOAD_FORMATTED > thing enables you to read from an image with PIPE_FORMAT_NONE (which > normally can only be written to). > > I don't see anything in the spec which requires it, but perhaps I > missed something. I'd be a bit surprised though, since this is rather > non-trivial on NVIDIA GPUs. > > Cheers, > > -ilia > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: redefine ATOMINC_WRAP to be more hardware-friendly
For the first two:
Reviewed-by: Marek Olšák
Marek
On Tue, Aug 6, 2019 at 11:06 PM Ilia Mirkin wrote:
> Both AMD and NVIDIA hardware define it this way. Instead of replicating
> the logic everywhere, just fix it up in one place.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> I'm open to also not doing this. Just seems like it'll make our
> collective lives a little easier, since this is what the hw wants (and
> presumably other APIs ... PTX definitely defines it this way).
>
> If there's push-back, I can also duplicate the logic in codegen.
>
> src/gallium/docs/source/tgsi.rst | 2 +-
> src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 12
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 11 ++-
> 3 files changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/docs/source/tgsi.rst
> b/src/gallium/docs/source/tgsi.rst
> index 17ad097e85e..e72b047dbd5 100644
> --- a/src/gallium/docs/source/tgsi.rst
> +++ b/src/gallium/docs/source/tgsi.rst
> @@ -2846,7 +2846,7 @@ These atomic operations may only be used with 32-bit
> integer image formats.
>
>dst_x = resource[offset] + 1
>
> - resource[offset] = dst_x < src_x ? dst_x : 0
> + resource[offset] = dst_x <= src_x ? dst_x : 0
>
>
> .. opcode:: ATOMDEC_WRAP - Atomic decrement + wrap around
> diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> index 4a4ba43780a..f79ed2c57e1 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> @@ -828,18 +828,6 @@ static void atomic_emit(
> args.data[num_data++] =
> ac_to_integer(&ctx->ac, lp_build_emit_fetch(bld_base,
> inst, 2, 0));
>
> - if (inst->Instruction.Opcode == TGSI_OPCODE_ATOMINC_WRAP) {
> - /* ATOMIC_INC instruction does:
> -* value = (value + 1) % (data + 1)
> -* but we want:
> -* value = (value + 1) % data
> -* So replace 'data' by 'data - 1'.
> -*/
> - args.data[0] = LLVMBuildSub(ctx->ac.builder,
> - args.data[0],
> - ctx->ac.i32_1, "");
> - }
> -
> args.cache_policy = get_cache_policy(ctx, inst, true, false,
> false);
>
> if (inst->Src[0].Register.File == TGSI_FILE_BUFFER) {
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index ff2ec0726e8..9b982569490 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -3938,9 +3938,18 @@ glsl_to_tgsi_visitor::visit_image_intrinsic(ir_call
> *ir)
>case ir_intrinsic_image_atomic_comp_swap:
> opcode = TGSI_OPCODE_ATOMCAS;
> break;
> - case ir_intrinsic_image_atomic_inc_wrap:
> + case ir_intrinsic_image_atomic_inc_wrap: {
> + /* There's a bit of disagreement between GLSL and the hardware.
> The
> + * hardware wants to wrap after the given wrap value, while GLSL
> + * wants to wrap at the value. Subtract 1 to make up the
> difference.
> + */
> + st_src_reg wrap = get_temp(glsl_type::uint_type);
> + emit_asm(ir, TGSI_OPCODE_ADD, st_dst_reg(wrap),
> + arg1, st_src_reg_for_int(-1));
> + arg1 = wrap;
> opcode = TGSI_OPCODE_ATOMINC_WRAP;
> break;
> + }
>case ir_intrinsic_image_atomic_dec_wrap:
> opcode = TGSI_OPCODE_ATOMDEC_WRAP;
> break;
> --
> 2.21.0
>
> ___
> 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] radeonsi: Bump number of allowed global buffers to 48 (again, for clover Blender assertion)
Do you know why global buffers are in the compute state and not in the context? Marek On Tue, Aug 6, 2019 at 10:50 PM Dieter Nützel wrote: > Am 20.06.2019 20:44, schrieb Jan Vesely: > > On Sat, 2019-06-15 at 07:38 +0200, Dieter Nützel wrote: > >> Am 14.06.2019 08:13, schrieb Jan Vesely: > >> > On Thu, 2019-06-13 at 21:20 +0200, Dieter Nützel wrote: > > >> > > Blender crash as expected ;-) > >> > > > >> > > /home/dieter> trying to save userpref at > >> > > /home/dieter/.config/blender/2.79/config/userpref.blend ok > >> > > Read blend: /data/Blender/barbershop_interior_gpu.blend > >> > > scripts disabled for "/data/Blender/barbershop_interior_gpu.blend", > >> > > skipping 'generate_customprops.py' > >> > > skipping driver 'var', automatic scripts are disabled > >> > > skipping driver 'var', automatic scripts are disabled > >> > > skipping driver 'var', automatic scripts are disabled > >> > > skipping driver 'var', automatic scripts are disabled > >> > > skipping driver 'var', automatic scripts are disabled > >> > > skipping driver 'var', automatic scripts are disabled > >> > > skipping driver 'var', automatic scripts are disabled > >> > > skipping driver 'var', automatic scripts are disabled > >> > > skipping driver 'var', automatic scripts are disabled > >> > > Device init success > >> > > Compiling OpenCL program split > >> > > Kernel compilation of split finished in 8.41s. > >> > > > >> > > Compiling OpenCL program base > >> > > Kernel compilation of base finished in 4.55s. > >> > > > >> > > Compiling OpenCL program denoising > >> > > Kernel compilation of denoising finished in 2.08s. > >> > > > >> > > blender: ../src/gallium/drivers/radeonsi/si_compute.c:319: > >> > > si_set_global_binding: Assertion `first + n <= MAX_GLOBAL_BUFFERS' > >> > > failed. > >> > > > >> > > [1]Abbruch blender (core dumped) > >> > > >> > The number of max global buffers was bumped in 06bf56725d to fix > >> > similar crash in luxmark. I guess it needs another bump. > >> > >> Hello Jan, > >> > >> I'm so blind... > >> ...bumping it 48 and 64 (first try) works. 33 not ;-) > >> We shouldn't waste to much memory. > > > > Feel free to post a patch. I'm not sure at which point Marek wants to > > switch to dynamic allocation (or if at all), but there's no limit in > > OCL so we might end up bumping this every time a new app pushes > > against the limit. > > Hello Jan, > > comming 'happily' from vacation and think we should've this in 19.2. > > Marek, > > do we need dynamic allocation, yet? > > Sorry, please see attachment. > Would be nice, if someone of you could add these lines during commit: > > Fixes assertion failure/crash when running Blender (2.79b) on > clover. > CC: mesa-sta...@lists.freedesktop.org<= ??? > > Greetings, > Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove super old TODOs from shaderapi.c
Reviewed-by: Marek Olšák Marek On Tue, Aug 6, 2019 at 8:21 PM Timothy Arceri wrote: > --- > src/mesa/main/shaderapi.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c > index 1351f7fd06f..607d30e2bd4 100644 > --- a/src/mesa/main/shaderapi.c > +++ b/src/mesa/main/shaderapi.c > @@ -29,11 +29,6 @@ > * > * Implementation of GLSL-related API functions. > * The glUniform* functions are in uniforms.c > - * > - * > - * XXX things to do: > - * 1. Check that the right error code is generated for all _mesa_error() > calls. > - * 2. Insert FLUSH_VERTICES calls in various places > */ > > > -- > 2.21.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] clover: Fix build after clang r367864
On Tue, 2019-08-06 at 21:39 -0500, Aaron Watry wrote:
> I had come up with an almost identical patch last night, but hadn't
> gotten around to testing it before turning in.
>
> Reviewed-by: Aaron Watry
Thanks both to you and Dieter.
I've pushed the patch.
Jan
>
> On Tue, Aug 6, 2019 at 12:59 PM Jan Vesely wrote:
> > v2: Drop special case of llvm-9
> > Signed-off-by: Jan Vesely
> > ---
> > src/gallium/state_trackers/clover/llvm/compat.hpp | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > index 0ecf622a9af..b040902fcfe 100644
> > --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > @@ -79,11 +79,17 @@ namespace clover {
> > #endif
> > }
> >
> > -#if HAVE_LLVM >= 0x0500
> > +#if HAVE_LLVM >= 0x1000
> > + const clang::InputKind ik_opencl = clang::Language::OpenCL;
> > +#elif HAVE_LLVM >= 0x0500
> > const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
> > - const clang::LangStandard::Kind lang_opencl10 =
> > clang::LangStandard::lang_opencl10;
> > #else
> > const clang::InputKind ik_opencl = clang::IK_OpenCL;
> > +#endif
> > +
> > +#if HAVE_LLVM >= 0x0500
> > + const clang::LangStandard::Kind lang_opencl10 =
> > clang::LangStandard::lang_opencl10;
> > +#else
> > const clang::LangStandard::Kind lang_opencl10 =
> > clang::LangStandard::lang_opencl;
> > #endif
> >
> > --
> > 2.21.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7C009ff6fbb5d940512d2808d71ae09bf8%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C637007424321638812&sdata=BjCsoj8%2Fbz7K0cymyBVVvq6Bgc2yVGdvYATF9yK4ygA%3D&reserved=0
--
Jan Vesely
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
