Re: [Mesa-dev] [PATCH 7/9] egl: keep the software device at the end of the list
Hi Emil,
The patches 1-7 are as well:
Reviewed-by: Mathias Fröhlich
plenty thanks and best
Mathias
On Monday, 6 May 2019 17:01:30 CEST Emil Velikov wrote:
> From: Emil Velikov
>
> By default, the user is likely to pick the first device so it should
> not be the least performant (aka software) one.
>
> Suggested-by: Marek Olšák
> Signed-off-by: Emil Velikov
> ---
> src/egl/main/egldevice.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/egl/main/egldevice.c b/src/egl/main/egldevice.c
> index c5c9a21273a..328d9ea08c5 100644
> --- a/src/egl/main/egldevice.c
> +++ b/src/egl/main/egldevice.c
> @@ -293,13 +293,26 @@ _eglQueryDevicesEXT(EGLint max_devices,
>goto out;
> }
>
> + /* Push the first device (the software one) to the end of the list.
> +* Sending it to the user only if they've requested the full list.
> +*
> +* By default, the user is likely to pick the first device so having the
> +* software (aka least performant) one is not a good idea.
> +*/
> *num_devices = MIN2(num_devs, max_devices);
>
> - for (i = 0, dev = devs; i < *num_devices; i++) {
> + for (i = 0, dev = devs->Next; dev && i < max_devices; i++) {
>devices[i] = dev;
>dev = dev->Next;
> }
>
> + /* User requested the full device list, add the sofware device. */
> + if (max_devices >= num_devs) {
> + /* The first device is always software */
> + assert(_eglDeviceSupports(devs, _EGL_DEVICE_SOFTWARE));
> + devices[num_devs - 1] = devs;
> + }
> +
> out:
> mtx_unlock(_eglGlobal.Mutex);
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/fs/ra: Stop adding RA interference to too many SENDS nodes
On Wed, May 8, 2019 at 1:29 PM Matt Turner wrote: > Whoops/Nice! > > Are there any shader-db changes as a result? > total instructions in shared programs: 15311103 -> 15311100 (<.01%) instructions in affected programs: 1554 -> 1551 (-0.19%) helped: 3 HURT: 0 total cycles in shared programs: 355468062 -> 355543197 (0.02%) cycles in affected programs: 2531922 -> 2607057 (2.97%) helped: 20 HURT: 20 No spill/fill change. At first I thought there were none because I'd run my over-all spilling branch but I guess I hadn't gotten this patch in it yet. > Reviewed-by: Matt Turner > Thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78700] Debug warnings should be generated when BindAttribLocation isn't followed by a re-link
https://bugs.freedesktop.org/show_bug.cgi?id=78700 --- Comment #3 from Kenneth Graunke --- Also the "unreleased game" was Witcher 2, but I think they reworked their shader compilation considerably since the build I was using, so I doubt this affects it still. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78700] Debug warnings should be generated when BindAttribLocation isn't followed by a re-link
https://bugs.freedesktop.org/show_bug.cgi?id=78700 Kenneth Graunke changed: What|Removed |Added Assignee|kenn...@whitecape.org |mesa-dev@lists.freedesktop. ||org Status|ASSIGNED|NEW --- Comment #2 from Kenneth Graunke --- I sent these patches in May 2014 but apparently never landed them. Brian even reviewed them, but had suggested predicating work on the context being a debug context. I assume they've bitrotten pretty badly by now. https://gitlab.freedesktop.org/kwg/mesa/tree/relink-v3 https://lists.freedesktop.org/archives/mesa-dev/2014-May/059533.html Someone should feel free to pick this up, I'm not likely to have time... -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33797] memcpy segfault in st_cb_texture.c:171
https://bugs.freedesktop.org/show_bug.cgi?id=33797 Timothy Arceri changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/llvmpipe -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move adriconf to mesa repositories
Hi Emil, >This is the tricky part - wish I could find my notes they have better >brain-dump. >It's OK to have the library as both front (config tool) and backend >(used by mesa) although: > - special care on splitting and annotating the API is needed > - handling this "extra" dependency would be fiddly for slower moving distros > I'm not sure I get the whole picture of what you are suggesting, so I put some ideas on how I think such API would work [here][1]. >> What about the current configuration files? Do you think there is a better >> way to handle them? >> They are for in a xml format, which is far from optimal. >> >What seems to be the problem with XML? The files are meant to be >read/written to $app. > I dislike XML because it is too ugly. Something more natural and easy to read/write would be more interesting. Like a YML format. Ideally I would like to use JSON, but then it becomes a lot harder for people to write this by hand in case the GUI tools don't offer the options they want/need. Of course this is just my point of view, and not necessarily a real issue. Kind Regards, Jean Hertel [1]: https://github.com/jlHertel/libdriconfig/blob/master/USAGE.md ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/fs/ra: Stop adding RA interference to too many SENDS nodes
Whoops/Nice! Are there any shader-db changes as a result? Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/fs/ra: Stop adding RA interference to too many SENDS nodes
We only have one node per VGRF so this was adding way too much
interference. No idea how we didn't catch this before.
Fixes: 014edff0d20d "intel/fs: Add interference between SENDS sources"
---
src/intel/compiler/brw_fs_reg_allocate.cpp | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/src/intel/compiler/brw_fs_reg_allocate.cpp
b/src/intel/compiler/brw_fs_reg_allocate.cpp
index 17a9dc8e9c4..96819630faa 100644
--- a/src/intel/compiler/brw_fs_reg_allocate.cpp
+++ b/src/intel/compiler/brw_fs_reg_allocate.cpp
@@ -710,14 +710,9 @@ fs_visitor::assign_regs(bool allow_spilling, bool
spill_all)
if (inst->opcode == SHADER_OPCODE_SEND && inst->ex_mlen > 0 &&
inst->src[2].file == VGRF &&
inst->src[3].file == VGRF &&
- inst->src[2].nr != inst->src[3].nr) {
-for (unsigned i = 0; i < inst->mlen; i++) {
- for (unsigned j = 0; j < inst->ex_mlen; j++) {
- ra_add_node_interference(g, inst->src[2].nr + i,
- inst->src[3].nr + j);
- }
-}
- }
+ inst->src[2].nr != inst->src[3].nr)
+ra_add_node_interference(g, inst->src[2].nr,
+ inst->src[3].nr);
}
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix uninitialized lower_flrp_progress variable
I sent an MR for this and the other cases earlier this morning.
On May 8, 2019 9:20:16 AM Brian Paul wrote:
The 'progress' variable is initialized to false in other locations.
This fixes a new Coverity warning.
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 0a67d45..5706425 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -338,7 +338,7 @@ st_nir_opts(nir_shader *nir, bool scalar)
NIR_PASS(progress, nir, nir_opt_constant_folding);
if (lower_flrp != 0) {
- bool lower_flrp_progress;
+ bool lower_flrp_progress = false;
NIR_PASS(lower_flrp_progress, nir, nir_lower_flrp,
lower_flrp,
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix uninitialized lower_flrp_progress variable
The 'progress' variable is initialized to false in other locations.
This fixes a new Coverity warning.
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 0a67d45..5706425 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -338,7 +338,7 @@ st_nir_opts(nir_shader *nir, bool scalar)
NIR_PASS(progress, nir, nir_opt_constant_folding);
if (lower_flrp != 0) {
- bool lower_flrp_progress;
+ bool lower_flrp_progress = false;
NIR_PASS(lower_flrp_progress, nir, nir_lower_flrp,
lower_flrp,
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] 2019 Xorg Election Results
Total membership 84; total votes 65; which makes for a 77.4% voter turnout. Here are the results: Board Members: Name 1 2 3 4 5 6 Score Daniel Vetter 27 10 14 6 2 6 296 Samuel Iglesias Gonsálvez 11 10 13 15 10 6 239 Lyude Paul10 12 13 12 12 6 238 Manasi Navare 8 13 7 16 18 3 228 Trevor Woerner 4 14 10 10 8 19 199 Arkadiusz Hiler5 6 8 6 15 25 165 So that means our new board members are: Daniel Vetter Samuel Iglesias Gonsálvez Lyude Paul Manasi Navare Please welcome our new members to the board! In the interest of transparency I should mention that one person accidentally signed up twice and voted twice. Luckily this doesn't change the results of the election since there is more than a 6-point gap between 4th and 5th place. We'll take this as a reminder to have a better look at membership sign-ups. It should also be noted that even though our election process as outlined at https://www.x.org/wiki/BoardOfDirectors/Elections/ allows denying candidates any points our website didn't take this into account and forced voters to rank every candidate. Due to the lack of controversy about the candidates we don't expect this to have had any impact on the final results. Thanks, Harry Wentland, On behalf of the Xorg Elections Committee ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 99781] Some Unity games fail assertion on startup in glXCreateContextAttribsARB
https://bugs.freedesktop.org/show_bug.cgi?id=99781 --- Comment #20 from Uli Schlachter --- Random guess for where the regression comes from: X11DRV_expect_error() is used to say "I expect that the next request might fail": https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a63fa13/dlls/winex11.drv/x11drv_main.c#L228-L241 ...which is then used by the error handler to check if the error is expected and should be ignored: https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a63fa13/dlls/winex11.drv/x11drv_main.c#L262-L271 So... apparently Wine wants to catch errors for "the next X11 request" while mesa tries to invent errors that do not come from any X11 request. Another random idea for a fix would be: Add a call to XSync(dpy, False) to the "invent an error"-functions. That should guarantee that dpy->request == dpy->last_request_read and so it does not matter any more which of the two sequence numbers mesa uses. (Well, actually XSync() does a XGetInputFocus() internally, so mesa would then use the sequence number of this GetInputFocus request for its claim that something failed that never happened.) -- 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #28 from tempel.jul...@gmail.com --- Would it be possible to ship this with one of the 19.1-rcs? -- 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 110636] [radv] DOOM 2016 particle artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=110636 --- Comment #6 from Samuel Pitoiset --- a12681683a5de5b433ad99212e860c13a3478ebf is the first bad commit commit a12681683a5de5b433ad99212e860c13a3478ebf Author: Alexander Timofeev Date: Fri Sep 21 10:31:22 2018 + [AMDGPU] Divergence driven instruction selection. Part 1. Summary: This change is the first part of the AMDGPU target description change. The aim of it is the effective splitting the vector and scalar flows at the selection stage. Selection uses predicate functions based on the framework implemented earlier - https://reviews.llvm.org/D35267 Differential revision: https://reviews.llvm.org/D52019 Reviewers: rampitec git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@342719 91177308-0d34-0410-b5e6-96231b3b80d8 :04 04 202bb2e2ff19d86b67d7f891b81fb3c4fc016ef6 6c959ec368ad7a539823ad33c11ea5fdbac73381 M lib :04 04 97eb807e54bb01456e23744ec6b29c1bc1215266 f7af4dc9e4b78429c4b4190ff2d985a89fec0e4c M test -- 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] 2019 Xorg Election Results
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote: > > Due to the lack of > controversy about the candidates [...] Such a statement, when talking about election results, very much sounds like "the election committees favourite candidates won anyway, so..." p. Luc Verhaegen. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 2019 Xorg Election Results
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote: > > It should also be noted that even though our election process as > outlined at https://www.x.org/wiki/BoardOfDirectors/Elections/ allows > denying candidates any points our website didn't take this into account > and forced voters to rank every candidate. Due to the lack of > controversy about the candidates we don't expect this to have had any > impact on the final results. Does this change not massively skew results? Lack of controversy has absolutely nothing to do with it. Luc Verhaegen. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 2019 Xorg Election Results
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote: > > In the interest of transparency I should mention that one person > accidentally signed up twice and voted twice. Luckily this doesn't > change the results of the election since there is more than a 6-point > gap between 4th and 5th place. We'll take this as a reminder to have a > better look at membership sign-ups. From private conversation with Stefan, i learned that the second membership application was approved between the first round of voting and the second round of voting. How many members were added between the two rounds? Is the vote on the fd.o merger counted against the first set of members, or against the second set of members. Does that not raise questions about the validity of the fd.o bylaws change? Imho, these are 3 significant irregularities with these elections and the subsequent results. Luc Verhaegen. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group
Reviewed-by: Bas Nieuwenhuizen for then, because the Mesa code indeed prevents AMDGPU_CHUNK_ID_FENCE in submissions. On Wed, May 8, 2019 at 3:24 PM Christian König wrote: > > Am 08.05.19 um 15:23 schrieb Liu, Leo: > > On 5/8/19 9:19 AM, Koenig, Christian wrote: > >> Am 08.05.19 um 15:14 schrieb Liu, Leo: > >>> On 5/8/19 9:02 AM, Christian König wrote: > [CAUTION: External Email] > > Am 08.05.19 um 14:56 schrieb Liu, Leo: > > There is no user fence for JPEG, the bug triggering > > kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT) > Oh, we are probably going to need to check for this in the kernel as > well. > > Currently we only check for UVD and VCE there, > >>> Are you talking about the checking for JPEG engine? if that, and then > >>> yes the check of " WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)" is there, > >>> that's why current JPEG is triggering that. > >> Yeah, but this check comes way to late. > >> > >> We usually already reject command submissions when they have user fences > >> for UVD & VCE, see amdgpu_cs_ib_fill(): > >>> /* UVD & VCE fw doesn't support user fences */ > >>> ring = to_amdgpu_ring(parser->entity->rq->sched); > >>> if (parser->job->uf_addr && ( > >>> ring->funcs->type == AMDGPU_RING_TYPE_UVD || > >>> ring->funcs->type == AMDGPU_RING_TYPE_VCE)) > >>> return -EINVAL; > >> We should probably make that a ring flag or something like that and > >> generalize he code here. > >> > >> Then the WARN_ON in the JPEG fence code can be removed. > > Yep. I will take a look at this on the kernel side, in the meantime, can > > I have a RB on the Mesa side? > > Well Acked-by: Christian König , cause I don't > know the Mesa code well enough. > > Christian. > > > > > Thanks, > > Leo > > > > > >> Christian. > >> > >>> Regards, > >>> > >>> Leo > >>> > >>> > do you want to take a > look Leo or should I do this? > > Christian. > > > Signed-off-by: Leo Liu > > Cc: mesa-sta...@lists.freedesktop.org > > --- > > src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c > > b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c > > index 4a2377f7e09..972030eaaa8 100644 > > --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c > > +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c > > @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct > > amdgpu_cs_context *cs) > >cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE && > >cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC && > >cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC && > > - cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC; > > + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC && > > + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG; > > } > > > > static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs) > > ___ > > 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
Re: [Mesa-dev] 2019 Xorg Election Results
On Wed, May 8, 2019 at 10:06 AM Harry Wentland wrote: >Trevor Woerner 4 14 10 10 8 19 199 > I'd like to truly thank the other 3 people who chose me as their 1st pick, and the 14 (:-O !!) who chose me as their first 2nd-place pick! Considering I'm not an active contributor of code to this project, I think this is an amazing result! Thank you :-D Although I didn't make it on the board, I remain committed to running GSoC and EVoC. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Fix two uninitialized accesses in compiler
Oh, I have a hunch what could be happening. I'll take a look before merging :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110645] Blender EEVEE World Volumetric flickering
https://bugs.freedesktop.org/show_bug.cgi?id=110645 Michel Dänzer changed: What|Removed |Added QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Mesa core |Drivers/Gallium/radeonsi -- 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 110645] Blender EEVEE World Volumetric flickering
https://bugs.freedesktop.org/show_bug.cgi?id=110645 Bug ID: 110645 Summary: Blender EEVEE World Volumetric flickering Product: Mesa Version: 19.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: shylonnat...@yahoo.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 144198 --> https://bugs.freedesktop.org/attachment.cgi?id=144198=edit example file Hello seems Mesa 19.0.3 Has bug regarding Blender EEVEE viewport render with Volumetric, it seems appear only on AMD hawaii GPUs please see this bug report https://developer.blender.org/T64305 Operating system: Linux-4.19.36-1-MANJARO-x86_64-with-arch-Manjaro-Linux 64 Bits Graphics card: AMD HAWAII (DRM 2.50.0, 4.19.36-1-MANJARO, LLVM 8.0.0) X.Org 4.5 (Core Profile) Mesa 19.0.3 Thanks -- 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] winsys/amdgpu: add VCN JPEG to no user fence group
Am 08.05.19 um 15:23 schrieb Liu, Leo: On 5/8/19 9:19 AM, Koenig, Christian wrote: Am 08.05.19 um 15:14 schrieb Liu, Leo: On 5/8/19 9:02 AM, Christian König wrote: [CAUTION: External Email] Am 08.05.19 um 14:56 schrieb Liu, Leo: There is no user fence for JPEG, the bug triggering kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT) Oh, we are probably going to need to check for this in the kernel as well. Currently we only check for UVD and VCE there, Are you talking about the checking for JPEG engine? if that, and then yes the check of " WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)" is there, that's why current JPEG is triggering that. Yeah, but this check comes way to late. We usually already reject command submissions when they have user fences for UVD & VCE, see amdgpu_cs_ib_fill(): /* UVD & VCE fw doesn't support user fences */ ring = to_amdgpu_ring(parser->entity->rq->sched); if (parser->job->uf_addr && ( ring->funcs->type == AMDGPU_RING_TYPE_UVD || ring->funcs->type == AMDGPU_RING_TYPE_VCE)) return -EINVAL; We should probably make that a ring flag or something like that and generalize he code here. Then the WARN_ON in the JPEG fence code can be removed. Yep. I will take a look at this on the kernel side, in the meantime, can I have a RB on the Mesa side? Well Acked-by: Christian König , cause I don't know the Mesa code well enough. Christian. Thanks, Leo Christian. Regards, Leo do you want to take a look Leo or should I do this? Christian. Signed-off-by: Leo Liu Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c index 4a2377f7e09..972030eaaa8 100644 --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct amdgpu_cs_context *cs) cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE && cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC && cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC && - cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC; + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC && + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG; } static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs) ___ 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] winsys/amdgpu: add VCN JPEG to no user fence group
On 5/8/19 9:19 AM, Koenig, Christian wrote: > Am 08.05.19 um 15:14 schrieb Liu, Leo: >> On 5/8/19 9:02 AM, Christian König wrote: >>> [CAUTION: External Email] >>> >>> Am 08.05.19 um 14:56 schrieb Liu, Leo: There is no user fence for JPEG, the bug triggering kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT) >>> Oh, we are probably going to need to check for this in the kernel as >>> well. >>> >>> Currently we only check for UVD and VCE there, >> Are you talking about the checking for JPEG engine? if that, and then >> yes the check of " WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)" is there, >> that's why current JPEG is triggering that. > Yeah, but this check comes way to late. > > We usually already reject command submissions when they have user fences > for UVD & VCE, see amdgpu_cs_ib_fill(): >> /* UVD & VCE fw doesn't support user fences */ >> ring = to_amdgpu_ring(parser->entity->rq->sched); >> if (parser->job->uf_addr && ( >> ring->funcs->type == AMDGPU_RING_TYPE_UVD || >> ring->funcs->type == AMDGPU_RING_TYPE_VCE)) >> return -EINVAL; > We should probably make that a ring flag or something like that and > generalize he code here. > > Then the WARN_ON in the JPEG fence code can be removed. Yep. I will take a look at this on the kernel side, in the meantime, can I have a RB on the Mesa side? Thanks, Leo > > Christian. > >> >> Regards, >> >> Leo >> >> >>> do you want to take a >>> look Leo or should I do this? >>> >>> Christian. >>> Signed-off-by: Leo Liu Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c index 4a2377f7e09..972030eaaa8 100644 --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct amdgpu_cs_context *cs) cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE && cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC && cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC && - cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC; + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC && + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG; } static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group
Am 08.05.19 um 15:14 schrieb Liu, Leo: > On 5/8/19 9:02 AM, Christian König wrote: >> [CAUTION: External Email] >> >> Am 08.05.19 um 14:56 schrieb Liu, Leo: >>> There is no user fence for JPEG, the bug triggering >>> kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT) >> Oh, we are probably going to need to check for this in the kernel as >> well. >> >> Currently we only check for UVD and VCE there, > Are you talking about the checking for JPEG engine? if that, and then > yes the check of " WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)" is there, > that's why current JPEG is triggering that. Yeah, but this check comes way to late. We usually already reject command submissions when they have user fences for UVD & VCE, see amdgpu_cs_ib_fill(): > /* UVD & VCE fw doesn't support user fences */ > ring = to_amdgpu_ring(parser->entity->rq->sched); > if (parser->job->uf_addr && ( > ring->funcs->type == AMDGPU_RING_TYPE_UVD || > ring->funcs->type == AMDGPU_RING_TYPE_VCE)) > return -EINVAL; We should probably make that a ring flag or something like that and generalize he code here. Then the WARN_ON in the JPEG fence code can be removed. Christian. > > > Regards, > > Leo > > >> do you want to take a >> look Leo or should I do this? >> >> Christian. >> >>> Signed-off-by: Leo Liu >>> Cc: mesa-sta...@lists.freedesktop.org >>> --- >>> src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c >>> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c >>> index 4a2377f7e09..972030eaaa8 100644 >>> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c >>> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c >>> @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct >>> amdgpu_cs_context *cs) >>> cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE && >>> cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC && >>> cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC && >>> - cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC; >>> + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC && >>> + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG; >>> } >>> >>> static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group
On 5/8/19 9:02 AM, Christian König wrote: > [CAUTION: External Email] > > Am 08.05.19 um 14:56 schrieb Liu, Leo: >> There is no user fence for JPEG, the bug triggering >> kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT) > > Oh, we are probably going to need to check for this in the kernel as > well. > > Currently we only check for UVD and VCE there, Are you talking about the checking for JPEG engine? if that, and then yes the check of " WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT)" is there, that's why current JPEG is triggering that. Regards, Leo > do you want to take a > look Leo or should I do this? > > Christian. > >> >> Signed-off-by: Leo Liu >> Cc: mesa-sta...@lists.freedesktop.org >> --- >> src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c >> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c >> index 4a2377f7e09..972030eaaa8 100644 >> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c >> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c >> @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct >> amdgpu_cs_context *cs) >> cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE && >> cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC && >> cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC && >> - cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC; >> + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC && >> + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG; >> } >> >> static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs) > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group
Am 08.05.19 um 14:56 schrieb Liu, Leo: There is no user fence for JPEG, the bug triggering kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT) Oh, we are probably going to need to check for this in the kernel as well. Currently we only check for UVD and VCE there, do you want to take a look Leo or should I do this? Christian. Signed-off-by: Leo Liu Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c index 4a2377f7e09..972030eaaa8 100644 --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct amdgpu_cs_context *cs) cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE && cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC && cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC && - cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC; + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC && + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG; } static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/amdgpu: add VCN JPEG to no user fence group
There is no user fence for JPEG, the bug triggering kernel WARN_ON(flags & AMDGPU_FENCE_FLAG_64BIT) Signed-off-by: Leo Liu Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c index 4a2377f7e09..972030eaaa8 100644 --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c @@ -378,7 +378,8 @@ static bool amdgpu_cs_has_user_fence(struct amdgpu_cs_context *cs) cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE && cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC && cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC && - cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC; + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC && + cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_JPEG; } static bool amdgpu_cs_has_chaining(struct amdgpu_cs *cs) -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110636] [radv] DOOM 2016 particle artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=110636 --- Comment #4 from Samuel Pitoiset --- This looks like a LLVM 8 regression to me. -- 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 110636] [radv] DOOM 2016 particle artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=110636 --- Comment #3 from Samuel Pitoiset --- Can you try with LLVM 7 please? -- 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 backport] radv: apply the indexing workaround for atomic buffer operations on GFX9
Because the new raw/struct intrinsics are buggy with LLVM 8
(they weren't marked as source of divergence), we fallback to the
old instrinsics for atomic buffer operations only. This means we need
to apply the indexing workaround for GFX9. The load/store
operations still use the new LLVM 8 intrinsics.
The fact that we need another workaround is painful but we should
be able to clean up that a bit once LLVM 7 support will be dropped.
This fixes a GPU hang with AC Odyssey and some rendering problems
with Nioh.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110573
Fixes: 31164cf5f70 ("ac/nir: only use the new raw/struct image atomic
intrinsics with LLVM 9+")
Signed-off-by: Samuel Pitoiset
Reviewed-by: Bas Nieuwenhuizen
---
src/amd/common/ac_nir_to_llvm.c | 12 +++-
src/amd/common/ac_shader_abi.h| 1 +
src/amd/vulkan/radv_nir_to_llvm.c | 6 ++
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b96dc7f5420..a0815995b12 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2359,10 +2359,12 @@ static void get_image_coords(struct ac_nir_context *ctx,
}
static LLVMValueRef get_image_buffer_descriptor(struct ac_nir_context *ctx,
-const nir_intrinsic_instr
*instr, bool write)
+const nir_intrinsic_instr
*instr,
+ bool write, bool atomic)
{
LLVMValueRef rsrc = get_image_descriptor(ctx, instr, AC_DESC_BUFFER,
write);
- if (ctx->abi->gfx9_stride_size_workaround) {
+ if (ctx->abi->gfx9_stride_size_workaround ||
+ (ctx->abi->gfx9_stride_size_workaround_for_atomic && atomic)) {
LLVMValueRef elem_count =
LLVMBuildExtractElement(ctx->ac.builder, rsrc, LLVMConstInt(ctx->ac.i32, 2, 0),
"");
LLVMValueRef stride = LLVMBuildExtractElement(ctx->ac.builder,
rsrc, LLVMConstInt(ctx->ac.i32, 1, 0), "");
stride = LLVMBuildLShr(ctx->ac.builder, stride,
LLVMConstInt(ctx->ac.i32, 16, 0), "");
@@ -2395,7 +2397,7 @@ static LLVMValueRef visit_image_load(struct
ac_nir_context *ctx,
unsigned num_channels = util_last_bit(mask);
LLVMValueRef rsrc, vindex;
- rsrc = get_image_buffer_descriptor(ctx, instr, false);
+ rsrc = get_image_buffer_descriptor(ctx, instr, false, false);
vindex = LLVMBuildExtractElement(ctx->ac.builder, get_src(ctx,
instr->src[1]),
ctx->ac.i32_0, "");
@@ -2439,7 +2441,7 @@ static void visit_image_store(struct ac_nir_context *ctx,
if (dim == GLSL_SAMPLER_DIM_BUF) {
char name[48];
const char *types[] = { "f32", "v2f32", "v4f32" };
- LLVMValueRef rsrc = get_image_buffer_descriptor(ctx, instr,
true);
+ LLVMValueRef rsrc = get_image_buffer_descriptor(ctx, instr,
true, false);
LLVMValueRef src = ac_to_float(>ac, get_src(ctx,
instr->src[3]));
unsigned src_channels = ac_get_llvm_num_components(src);
@@ -2535,7 +2537,7 @@ static LLVMValueRef visit_image_atomic(struct
ac_nir_context *ctx,
params[param_count++] = get_src(ctx, instr->src[3]);
if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
- params[param_count++] = get_image_buffer_descriptor(ctx, instr,
true);
+ params[param_count++] = get_image_buffer_descriptor(ctx, instr,
true, true);
params[param_count++] =
LLVMBuildExtractElement(ctx->ac.builder, get_src(ctx, instr->src[1]),
ctx->ac.i32_0,
""); /* vindex */
params[param_count++] = ctx->ac.i32_0; /* voffset */
diff --git a/src/amd/common/ac_shader_abi.h b/src/amd/common/ac_shader_abi.h
index ee18e6c1923..9eb4d37257e 100644
--- a/src/amd/common/ac_shader_abi.h
+++ b/src/amd/common/ac_shader_abi.h
@@ -195,6 +195,7 @@ struct ac_shader_abi {
/* Whether to workaround GFX9 ignoring the stride for the buffer size
if IDXEN=0
* and LLVM optimizes an indexed load with constant index to IDXEN=0. */
bool gfx9_stride_size_workaround;
+ bool gfx9_stride_size_workaround_for_atomic;
};
#endif /* AC_SHADER_ABI_H */
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index b1eeb2cc1f7..3b5381f5353 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -3497,6 +3497,12 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
ac_llvm_compiler *ac_llvm,
ctx.abi.clamp_shadow_reference = false;
ctx.abi.gfx9_stride_size_workaround = ctx.ac.chip_class == GFX9 &&
HAVE_LLVM < 0x800;
+ /* Because the new raw/struct atomic intrinsics are buggy with LLVM 8,
+* we fallback to
Re: [Mesa-dev] [PATCH] radv: apply the indexing workaround for atomic buffer operations on GFX9
Err no, my mistake.
I will write a backport.
On 5/8/19 10:54 AM, Samuel Pitoiset wrote:
You mean 19.1?
On 5/7/19 8:29 PM, Dylan Baker wrote:
Hi Samuel,
This doesn't apply cleanly on 19.0, and I'm not sure how to resolve
the diff.
Could you provide a packport please?
Thanks,
Dylan
Quoting Samuel Pitoiset (2019-05-03 02:45:34)
Because the new raw/struct intrinsics are buggy with LLVM 8
(they weren't marked as source of divergence), we fallback to the
old instrinsics for atomic buffer operations. This means we need
to apply the indexing workaround for GFX9.
The fact that we need another workaround is painful but we should
be able to clean up that a bit once LLVM 7 support will be dropped.
This fixes a GPU hang with AC Odyssey and some rendering problems
with Nioh.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110573
Fixes: 31164cf5f70 ("ac/nir: only use the new raw/struct image
atomic intrinsics with LLVM 9+")
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 12 +++-
src/amd/common/ac_shader_abi.h | 1 +
src/amd/vulkan/radv_nir_to_llvm.c | 6 ++
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c
b/src/amd/common/ac_nir_to_llvm.c
index c92eaaca31d..151e0d0f961 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2417,10 +2417,12 @@ static void get_image_coords(struct
ac_nir_context *ctx,
}
static LLVMValueRef get_image_buffer_descriptor(struct
ac_nir_context *ctx,
- const
nir_intrinsic_instr *instr, bool write)
+ const
nir_intrinsic_instr *instr,
+ bool write, bool
atomic)
{
LLVMValueRef rsrc = get_image_descriptor(ctx, instr,
AC_DESC_BUFFER, write);
- if (ctx->abi->gfx9_stride_size_workaround) {
+ if (ctx->abi->gfx9_stride_size_workaround ||
+ (ctx->abi->gfx9_stride_size_workaround_for_atomic && atomic)) {
LLVMValueRef elem_count =
LLVMBuildExtractElement(ctx->ac.builder, rsrc,
LLVMConstInt(ctx->ac.i32, 2, 0), "");
LLVMValueRef stride =
LLVMBuildExtractElement(ctx->ac.builder, rsrc,
LLVMConstInt(ctx->ac.i32, 1, 0), "");
stride = LLVMBuildLShr(ctx->ac.builder, stride,
LLVMConstInt(ctx->ac.i32, 16, 0), "");
@@ -2466,7 +2468,7 @@ static LLVMValueRef visit_image_load(struct
ac_nir_context *ctx,
unsigned num_channels = util_last_bit(mask);
LLVMValueRef rsrc, vindex;
- rsrc = get_image_buffer_descriptor(ctx, instr,
false);
+ rsrc = get_image_buffer_descriptor(ctx, instr,
false, false);
vindex = LLVMBuildExtractElement(ctx->ac.builder,
get_src(ctx, instr->src[1]),
ctx->ac.i32_0, "");
@@ -2520,7 +2522,7 @@ static void visit_image_store(struct
ac_nir_context *ctx,
args.cache_policy = get_cache_policy(ctx, access, true,
writeonly_memory);
if (dim == GLSL_SAMPLER_DIM_BUF) {
- LLVMValueRef rsrc = get_image_buffer_descriptor(ctx,
instr, true);
+ LLVMValueRef rsrc = get_image_buffer_descriptor(ctx,
instr, true, false);
LLVMValueRef src = ac_to_float(>ac,
get_src(ctx, instr->src[3]));
unsigned src_channels =
ac_get_llvm_num_components(src);
LLVMValueRef vindex;
@@ -2632,7 +2634,7 @@ static LLVMValueRef visit_image_atomic(struct
ac_nir_context *ctx,
params[param_count++] = get_src(ctx, instr->src[3]);
if (dim == GLSL_SAMPLER_DIM_BUF) {
- params[param_count++] =
get_image_buffer_descriptor(ctx, instr, true);
+ params[param_count++] =
get_image_buffer_descriptor(ctx, instr, true, true);
params[param_count++] =
LLVMBuildExtractElement(ctx->ac.builder, get_src(ctx, instr->src[1]),
ctx->ac.i32_0, ""); /* vindex */
params[param_count++] = ctx->ac.i32_0; /* voffset */
diff --git a/src/amd/common/ac_shader_abi.h
b/src/amd/common/ac_shader_abi.h
index 108fe58ce57..8debb1ff986 100644
--- a/src/amd/common/ac_shader_abi.h
+++ b/src/amd/common/ac_shader_abi.h
@@ -203,6 +203,7 @@ struct ac_shader_abi {
/* Whether to workaround GFX9 ignoring the stride for the
buffer size if IDXEN=0
* and LLVM optimizes an indexed load with constant index to
IDXEN=0. */
bool gfx9_stride_size_workaround;
+ bool gfx9_stride_size_workaround_for_atomic;
};
#endif /* AC_SHADER_ABI_H */
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 796d78e34f4..d83f0bd547f 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -3687,6 +3687,12 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
ac_llvm_compiler *ac_llvm,
ctx.abi.clamp_shadow_reference = false;
Re: [Mesa-dev] [PATCH] radv: apply the indexing workaround for atomic buffer operations on GFX9
You mean 19.1?
On 5/7/19 8:29 PM, Dylan Baker wrote:
Hi Samuel,
This doesn't apply cleanly on 19.0, and I'm not sure how to resolve the diff.
Could you provide a packport please?
Thanks,
Dylan
Quoting Samuel Pitoiset (2019-05-03 02:45:34)
Because the new raw/struct intrinsics are buggy with LLVM 8
(they weren't marked as source of divergence), we fallback to the
old instrinsics for atomic buffer operations. This means we need
to apply the indexing workaround for GFX9.
The fact that we need another workaround is painful but we should
be able to clean up that a bit once LLVM 7 support will be dropped.
This fixes a GPU hang with AC Odyssey and some rendering problems
with Nioh.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110573
Fixes: 31164cf5f70 ("ac/nir: only use the new raw/struct image atomic intrinsics
with LLVM 9+")
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 12 +++-
src/amd/common/ac_shader_abi.h| 1 +
src/amd/vulkan/radv_nir_to_llvm.c | 6 ++
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index c92eaaca31d..151e0d0f961 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2417,10 +2417,12 @@ static void get_image_coords(struct ac_nir_context *ctx,
}
static LLVMValueRef get_image_buffer_descriptor(struct ac_nir_context *ctx,
-const nir_intrinsic_instr
*instr, bool write)
+const nir_intrinsic_instr
*instr,
+ bool write, bool atomic)
{
LLVMValueRef rsrc = get_image_descriptor(ctx, instr, AC_DESC_BUFFER,
write);
- if (ctx->abi->gfx9_stride_size_workaround) {
+ if (ctx->abi->gfx9_stride_size_workaround ||
+ (ctx->abi->gfx9_stride_size_workaround_for_atomic && atomic)) {
LLVMValueRef elem_count = LLVMBuildExtractElement(ctx->ac.builder, rsrc,
LLVMConstInt(ctx->ac.i32, 2, 0), "");
LLVMValueRef stride = LLVMBuildExtractElement(ctx->ac.builder, rsrc,
LLVMConstInt(ctx->ac.i32, 1, 0), "");
stride = LLVMBuildLShr(ctx->ac.builder, stride,
LLVMConstInt(ctx->ac.i32, 16, 0), "");
@@ -2466,7 +2468,7 @@ static LLVMValueRef visit_image_load(struct
ac_nir_context *ctx,
unsigned num_channels = util_last_bit(mask);
LLVMValueRef rsrc, vindex;
- rsrc = get_image_buffer_descriptor(ctx, instr, false);
+ rsrc = get_image_buffer_descriptor(ctx, instr, false, false);
vindex = LLVMBuildExtractElement(ctx->ac.builder, get_src(ctx,
instr->src[1]),
ctx->ac.i32_0, "");
@@ -2520,7 +2522,7 @@ static void visit_image_store(struct ac_nir_context *ctx,
args.cache_policy = get_cache_policy(ctx, access, true,
writeonly_memory);
if (dim == GLSL_SAMPLER_DIM_BUF) {
- LLVMValueRef rsrc = get_image_buffer_descriptor(ctx, instr,
true);
+ LLVMValueRef rsrc = get_image_buffer_descriptor(ctx, instr,
true, false);
LLVMValueRef src = ac_to_float(>ac, get_src(ctx,
instr->src[3]));
unsigned src_channels = ac_get_llvm_num_components(src);
LLVMValueRef vindex;
@@ -2632,7 +2634,7 @@ static LLVMValueRef visit_image_atomic(struct
ac_nir_context *ctx,
params[param_count++] = get_src(ctx, instr->src[3]);
if (dim == GLSL_SAMPLER_DIM_BUF) {
- params[param_count++] = get_image_buffer_descriptor(ctx, instr,
true);
+ params[param_count++] = get_image_buffer_descriptor(ctx, instr,
true, true);
params[param_count++] = LLVMBuildExtractElement(ctx->ac.builder,
get_src(ctx, instr->src[1]),
ctx->ac.i32_0,
""); /* vindex */
params[param_count++] = ctx->ac.i32_0; /* voffset */
diff --git a/src/amd/common/ac_shader_abi.h b/src/amd/common/ac_shader_abi.h
index 108fe58ce57..8debb1ff986 100644
--- a/src/amd/common/ac_shader_abi.h
+++ b/src/amd/common/ac_shader_abi.h
@@ -203,6 +203,7 @@ struct ac_shader_abi {
/* Whether to workaround GFX9 ignoring the stride for the buffer size
if IDXEN=0
* and LLVM optimizes an indexed load with constant index to IDXEN=0. */
bool gfx9_stride_size_workaround;
+ bool gfx9_stride_size_workaround_for_atomic;
};
#endif /* AC_SHADER_ABI_H */
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 796d78e34f4..d83f0bd547f 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -3687,6 +3687,12 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
ac_llvm_compiler *ac_llvm,
ctx.abi.clamp_shadow_reference = false;
Re: [Mesa-dev] [PATCH] radv: call constant folding before opt algebraic
LGTM.
Thanks for double checking Tim!
On 5/8/19 1:27 AM, Timothy Arceri wrote:
On 8/5/19 1:51 am, Samuel Pitoiset wrote:
What games are affected btw?
PERCENTAGE DELTAS Shaders SGPRs VGPRs SpillSGPR CodeSize
MaxWaves
batman-arkham-city 2581 . . . . .
dawn-of-war-3 244 . . . . .
f1-2017 5627 . . . . .
fallout4-vr 196 . . . . .
nier 1905 . . . . .
no-mans-sky 4054 . . . . .
prey 2182 . . . . .
rot-tomb-raider 8391 . . . . .
skyrim-vr 494 . . . . .
sot-tomb-raider 613 . . . 0.01 % .
the_witcher_3-medium 803 . . . . .
the_wither_3-ultra 1040 0.05 % -0.03 % . . 0.02 %
valve-vr-pref-trace 323 . . . . .
wolfenstein-2 1056 . . -0.20 % -0.02 % .
--
All affected 69 0.50 % -0.22 % -7.69 % -0.28 %0.57 %
--
Total 29509 . . -0.03 % . .
Can you please double check before pushing because of the flrp
changes that landed around?
No change.
On 5/7/19 7:14 AM, Timothy Arceri wrote:
ping!
On 2/5/19 1:38 pm, Timothy Arceri wrote:
The pattern of calling opt algebraic first seems to have originated
in i965. The order in OpenGL drivers generally doesn't matter
because the GLSL IR optimisations do constant folding before
opt algebraic.
However in Vulkan drivers calling opt algebraic first can result
in missed constant folding opportunities.
vkpipeline-db results (VEGA64):
Totals from affected shaders:
SGPRS: 3160 -> 3176 (0.51 %)
VGPRS: 3588 -> 3580 (-0.22 %)
Spilled SGPRs: 52 -> 44 (-15.38 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 12 -> 12 (0.00 %) dwords per thread
Code Size: 261812 -> 261036 (-0.30 %) bytes
LDS: 7 -> 7 (0.00 %) blocks
Max Waves: 346 -> 348 (0.58 %)
Wait states: 0 -> 0 (0.00 %)
---
src/amd/vulkan/radv_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_shader.c
b/src/amd/vulkan/radv_shader.c
index cd5a9f2afb4..ad7b2439735 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -162,8 +162,8 @@ radv_optimize_nir(struct nir_shader *shader,
bool optimize_conservatively,
NIR_PASS(progress, shader, nir_opt_dead_cf);
NIR_PASS(progress, shader, nir_opt_cse);
NIR_PASS(progress, shader,
nir_opt_peephole_select, 8, true, true);
- NIR_PASS(progress, shader, nir_opt_algebraic);
NIR_PASS(progress, shader,
nir_opt_constant_folding);
+ NIR_PASS(progress, shader, nir_opt_algebraic);
NIR_PASS(progress, shader, nir_opt_undef);
NIR_PASS(progress, shader,
nir_opt_conditional_discard);
if (shader->options->max_unroll_iterations) {
___
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 110636] [radv] DOOM 2016 particle artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=110636 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Timothy Arceri --- It's not clear to me what the issue is. Can you get a before and after screenshot? I've run "kagindir sanctum" on both 19.0 and 18.3 and I didn't really notice any difference. It also seemed pretty much the same as: https://www.youtube.com/watch?v=D0KV9s6Chjs -- 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 110636] [radv] DOOM 2016 particle artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=110636 Samuel Pitoiset changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- 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 107511] KHR/khrplatform.h not always installed when needed
https://bugs.freedesktop.org/show_bug.cgi?id=107511 Eric Engestrom changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Engestrom --- (In reply to Madhurkiran from comment #2) > Hi all, > > I see that certain GL headers like "glcorearb.h" needs "KHRplatform.h" > header files. This works seamlessly when the GL and EGL providers are MESA. > In scenarios where the GL provider is MESA and EGL provider is some GPU > vendor say ARM, in that scenario, the khrplatform header comes from two > different providers and that results in conflict. In scenarios like this, > who should provide the KHRplatform.h header. Some users, may want use > exclusively EGL/GLES2 binaries, and they dont need GL support. How can we > resolve this conflict? > > Thanks > Mads Hi! Please open a new issue when you encounter a new issue, it helps keep things clearer ;) As for your issue, I'm afraid if a user chooses to pull two khrplatform.h from two different providers, the user is the one who has to choose which one to keep, or how to merge/combine them. Neither provider can decide "I'm more important than any other provider, keep me!" Hopefully though, this should be easy enough for the user to choose: keep the most recent one (see the date at the top of the file), and if the other one was modified from what Khronos provides then copy those modifications :) -- 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] kmsro: add _dri.so to two of the kmsro drivers.
On Wednesday, 2019-05-08 12:38:51 +1000, Dave Airlie wrote: > From: Dave Airlie > > --- > src/gallium/targets/dri/meson.build | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/targets/dri/meson.build > b/src/gallium/targets/dri/meson.build > index dd40969a166..45daf647960 100644 > --- a/src/gallium/targets/dri/meson.build > +++ b/src/gallium/targets/dri/meson.build > @@ -78,8 +78,8 @@ foreach d : [[with_gallium_kmsro, [ > 'pl111_dri.so', > 'repaper_dri.so', > 'rockchip_dri.so', > - 'st7586.so', > - 'st7735r.so', > + 'st7586_dri.so', > + 'st7735r_dri.so', Reviewed-by: Eric Engestrom > 'sun4i-drm_dri.so', > ]], > [with_gallium_radeonsi, 'radeonsi_dri.so'], > -- > 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 110345] Unrecoverable GPU crash with DiRT 4
https://bugs.freedesktop.org/show_bug.cgi?id=110345 --- Comment #17 from Thomas Rohloff --- (In reply to Samuel Pitoiset from comment #16) > Are you still able to reproduce with latest mesa/llvm git? Yes. -- 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 110640] vlPostProc question
https://bugs.freedesktop.org/show_bug.cgi?id=110640 Bug ID: 110640 Summary: vlPostProc question Product: Mesa Version: 18.0 Hardware: ARM OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: baopeng88_...@163.com QA Contact: mesa-dev@lists.freedesktop.org We want to use the vce module to do the postproc operation, but the source data is in RGBA format. Welook at the vlVaPostProcBlit interface, this format is not supported. Is this the underlying limit? What can be done to solve this problem? -- 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] panfrost: Fix two uninitialized accesses in compiler
On Tue, 7 May 2019 at 23:47, Alyssa Rosenzweig wrote: > > Tentative R-b, but I'm baffled what the flip-flops would be about. Could > you link the list of failures introduced (we're maybe relying on buggy > behaviour anyway)? I was testing with dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.add_src_color_constant_color (should get into the habit of mentioning test case names in the commit messages). I guess it affected other tests, but it's hard to tell because we have other memory issues detected by valgrind that muddy the waters. Cheers, Tomeu > ___ > 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
