[Mesa-dev] [Bug 111265] [TRACKER] Mesa 19.2 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111265 Kenneth Graunke changed: What|Removed |Added Depends on||111275 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111275 [Bug 111275] Feature: CCS_E modifier support and dri_query_image fixes -- 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 111265] [TRACKER] Mesa 19.2 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111265 Mark Janes changed: What|Removed |Added Depends on||111274 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111274 [Bug 111274] Feature: support gpu metrics in iris -- 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] egl/android: remove HAL_PIXEL_FORMAT_BGRA_8888 support
From: Emil Velikov
As said in the EGL_KHR_platform_android extensions
For each EGLConfig that belongs to the Android platform, the
EGL_NATIVE_VISUAL_ID attribute is an Android window format, such as
WINDOW_FORMAT_RGBA_.
Although it should be applicable overall.
Even though we use HAL_PIXEL_FORMAT here, those are numerically
identical to the WINDOW_FORMAT_ and AHARDWAREBUFFER_FORMAT_ ones.
Barring the said format of course. That one is only listed in HAL.
Keep in mind that even if we try to use the said format, you'll get
caught by droid_create_surface(). The function compares the format of
the underlying window, against the NATIVE_VISUAL_ID of the config.
Unfortunatelly it only prints a warning, rather than error out, likely
leading to visual corruption.
While SDL will even call ANativeWindow_setBuffersGeometry() with the
wrong format, and conviniently ignore the [expected] failure.
Signed-off-by: Emil Velikov
Acked-by: Tomasz Figa
(tfiga: Remove only respective EGL config, leave EGL image as is.)
Signed-off-by: Tomasz Figa
Signed-off-by: Lepton Wu
---
src/egl/drivers/dri2/platform_android.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index d37f6b8e447..6c54fc4f1fe 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1193,7 +1193,6 @@ droid_add_configs_for_visuals(_EGLDriver *drv,
_EGLDisplay *disp)
{ HAL_PIXEL_FORMAT_RGBA_, { 0x00ff, 0xff00, 0x00ff,
0xff00 } },
{ HAL_PIXEL_FORMAT_RGBX_, { 0x00ff, 0xff00, 0x00ff,
0x } },
{ HAL_PIXEL_FORMAT_RGB_565, { 0xf800, 0x07e0, 0x001f,
0x } },
- { HAL_PIXEL_FORMAT_BGRA_, { 0x00ff, 0xff00, 0x00ff,
0xff00 } },
};
unsigned int format_count[ARRAY_SIZE(visuals)] = { 0 };
--
2.22.0.770.g0f2c4a37fd-goog
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111264] u_thread.h:64:39: error: too many arguments to function call, expected 1, have 2
https://bugs.freedesktop.org/show_bug.cgi?id=111264 Matt Turner changed: What|Removed |Added URL||https://gitlab.freedesktop. ||org/mesa/mesa/merge_request ||s/1533 Status|NEW |ASSIGNED Assignee|mesa-dev@lists.freedesktop. |matts...@gmail.com |org | -- 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] gitlab-ci: remove software-properties-common
On Wednesday, 2019-07-31 16:07:45 +0200, Michel Dänzer wrote: > On 2019-07-31 3:26 p.m., Emil Velikov wrote: > > On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote: > >> > >> On 2019-07-31 3:04 p.m., Emil Velikov wrote: > >>> From: Emil Velikov > >>> > >>> Currently we use the python package to manage repositories. At the same > >>> time we also do that by hand - since it's a trivial echo to a file. > >>> > >>> Stay consistent, remove the package and manage things manually. > >>> > >>> Cc: Eric Engestrom > >>> Signed-off-by: Emil Velikov > >>> --- > >>> .gitlab-ci/debian-install.sh | 11 +-- > >>> 1 file changed, 5 insertions(+), 6 deletions(-) > >>> > >>> diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh > >>> index 578074ddb87..719d7830018 100644 > >>> --- a/.gitlab-ci/debian-install.sh > >>> +++ b/.gitlab-ci/debian-install.sh > >>> @@ -16,12 +16,11 @@ apt-get install -y \ > >>>curl \ > >>>wget \ > >>>unzip \ > >>> - gnupg \ > >>> - software-properties-common > >>> + gnupg > >>> > >>> curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - > >>> -add-apt-repository "deb https://apt.llvm.org/stretch/ > >>> llvm-toolchain-stretch-7 main" > >>> -add-apt-repository "deb https://apt.llvm.org/stretch/ > >>> llvm-toolchain-stretch-8 main" > >>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ > >>> llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list > >>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ > >>> llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list > >>> > >>> sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list > >>> echo 'deb https://deb.debian.org/debian stretch-backports main' > >>> >/etc/apt/sources.list.d/backports.list > >>> @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ > >>>clang-8 > >>> > >>> # Install remaining packages from Debian buster to get newer versions > >>> -add-apt-repository "deb https://deb.debian.org/debian/ buster main" > >>> -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates > >>> main" > >>> +echo "deb https://deb.debian.org/debian/ buster main" > >>> >/etc/apt/sources.list.d/buster.list > >>> +echo "deb https://deb.debian.org/debian/ buster-updates main" > >>> >/etc/apt/sources.list.d/buster-updates.list > >>> apt-get update > >>> apt-get install -y \ > >>>bzip2 \ > >>> > >> > >> This should be merged as part of an MR which requires the docker image > >> to be re-generated for another reason, and thus bumps DEBIAN_TAG. > >> > > Since this is a non-functional change, I've explicitly omitted bumping > > the DEBIAN_TAG. > > Seemingly I forgot to mention it in the commit message though, oopsie. > > > > Since the image will contain practically the same artefacts, is it > > worth carving out 30 minutes (or so) from the runners? > > No, I agree that would be wasteful for this change alone. > > However, merging this change without bumping the tag isn't good either, > because then any issues with it would only be discovered the next time > it does get bumped. Hence my request above. I agree with Michel here, it's better to waste a re-gen now and notice any issue right away. Also, could you send this as an MR so that we can see the resulting CI right away? Thanks :) I don't really know apt, but this patch looks correct: Acked-by: Eric Engestrom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111126] Build problem: meson build can not find wayland-scanner
https://bugs.freedesktop.org/show_bug.cgi?id=26 Dylan Baker changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEEDINFO|RESOLVED --- Comment #11 from Dylan Baker --- It's a meson bug. There's a PR discussing what to do here: https://github.com/mesonbuild/meson/pull/5674 -- 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 111126] Build problem: meson build can not find wayland-scanner
https://bugs.freedesktop.org/show_bug.cgi?id=26 --- Comment #10 from Jordan Justen --- (In reply to Dylan Baker from comment #9) > Are you passing PKG_CONFIG_PATH at meson setup time? such as > 'PKG_CONFIG_PATH="..." meson builddir'? Because if you are this is > definitely a meson bug, and there might be a PR for this already. Yes, PKG_CONFIG_PATH is set in the environment before running meson. In looking through meson's code (mesonmesonbuild/dependencies/base.py), it seems some effort may have been taken to ignore PKG_CONFIG_PATH if a dependency sets native. The first meson commit that seems to take related steps is 11e3011a6bf0adeb51582c590c90b0f4dccb4df8. It seems like the related code has been reworked substantially since then. Hmm, I guess af2d7af9983a04fa2dd6c073bdc41847a23012c8 is what has changed the behavior recently. -- 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 111126] Build problem: meson build can not find wayland-scanner
https://bugs.freedesktop.org/show_bug.cgi?id=26 --- Comment #9 from Dylan Baker --- Are you passing PKG_CONFIG_PATH at meson setup time? such as 'PKG_CONFIG_PATH="..." meson builddir'? Because if you are this is definitely a meson bug, and there might be a PR for this already. -- 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 111126] Build problem: meson build can not find wayland-scanner
https://bugs.freedesktop.org/show_bug.cgi?id=26 --- Comment #8 from Jordan Justen --- I found a fix for my build environment. I have to add this to my meson configuration: --build.pkg-config-path "$PKG_CONFIG_PATH" It looks like meson now ignores PKG_CONFIG_PATH if a "native" library is being located. I'm not sure if there might be a way to detect if an actual cross compilation is happening. If we are not cross compiling, then we could set "native" to false, and PKG_CONFIG_PATH could be used without the additional meson parameter. -- 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] nir: use common deref has indirect code in scratch lowering.
Reviewed-by: Jason Ekstrand
The only real difference is that the common one also handles casts. Would
probably be good to handle them here too.
--Jason
On Wed, Jul 31, 2019 at 12:36 AM Dave Airlie wrote:
> From: Dave Airlie
>
> This doesn't seem to need it's own copy here.
> ---
> src/compiler/nir/nir_lower_scratch.c | 16 +---
> 1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/src/compiler/nir/nir_lower_scratch.c
> b/src/compiler/nir/nir_lower_scratch.c
> index df0d3f43124..aacc2ddca08 100644
> --- a/src/compiler/nir/nir_lower_scratch.c
> +++ b/src/compiler/nir/nir_lower_scratch.c
> @@ -34,20 +34,6 @@
> #include "nir_builder.h"
> #include "nir_deref.h"
>
> -static bool
> -deref_has_indirect(nir_deref_instr *deref)
> -{
> - while (deref->deref_type != nir_deref_type_var) {
> - if (deref->deref_type == nir_deref_type_array &&
> - nir_src_as_const_value(deref->arr.index) == NULL)
> - return true;
> -
> - deref = nir_deref_instr_parent(deref);
> - }
> -
> - return false;
> -}
> -
> static void
> lower_load_store(nir_builder *b,
> nir_intrinsic_instr *intrin,
> @@ -128,7 +114,7 @@ nir_lower_vars_to_scratch(nir_shader *shader,
> if (!(deref->mode & modes))
> continue;
>
> -if (!deref_has_indirect(nir_src_as_deref(intrin->src[0])))
> +if
> (!nir_deref_instr_has_indirect(nir_src_as_deref(intrin->src[0])))
> continue;
>
> nir_variable *var = nir_deref_instr_get_variable(deref);
> --
> 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] [Bug 111141] [REGRESSION] [BISECTED] [DXVK] 1-bit booleans and Elite Dangerous shader mis-optimization
https://bugs.freedesktop.org/show_bug.cgi?id=41 --- Comment #18 from Steven Newbury --- (In reply to Connor Abbott from comment #17) > One other thing you can try is to build mesa with -Dbuildtype=debug (i.e. > with assertions enabled and no optimizations) and see if there's an > assertion fail somewhere, or if it magically fixes itself. > I'll try this first since it's the easiest. It is perplexing what could possibly be causing my system to act differently, especially since it didn't demonstrate anything odd prior to the boolean change. -- 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 111264] u_thread.h:64:39: error: too many arguments to function call, expected 1, have 2
https://bugs.freedesktop.org/show_bug.cgi?id=111264 --- Comment #3 from Matt Turner --- Aggravatingly, Mac OS's version takes only one parameter it seems. See https://gitlab.haskell.org/ghc/ghc/issues/9684 for example of other projects running into this. -- 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 111264] u_thread.h:64:39: error: too many arguments to function call, expected 1, have 2
https://bugs.freedesktop.org/show_bug.cgi?id=111264 Vinson Lee changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #2 from Vinson Lee --- /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/pthread.h 512 __API_AVAILABLE(macos(10.6), ios(3.2)) 513 int pthread_setname_np(const char*); -- 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 111269] GFX10: "Random" GPU hangs with Rise Of The Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=111269 --- Comment #1 from Timur Kristóf --- After the hang, the following can be observed in the dmesg log: [ 123.712426] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [ 128.832311] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=33035, emitted seq=33037 [ 128.832350] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process RiseOfTheTombRa pid 4366 thread RiseOfTheT:cs0 pid 4380 I also tried attaching gdb to the game which tells me that there is indeed a thread that waits for the fence: #0 0x7efbf969d1fb in ioctl () from /lib64/libc.so.6 #1 0x7efb34777170 in drmIoctl () from /lib64/libdrm.so.2 #2 0x7efb34705d59 in amdgpu_cs_query_fence_status () from /lib64/libdrm_amdgpu.so.1 #3 0x7efad427caa1 in radv_amdgpu_fence_wait (_ws=0x8b245c0, _fence=0x7ef940069480, absolute=true, timeout=18446744073709551615) at ../src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c:225 #4 0x7efad429e336 in radv_WaitForFences (_device=0x7ef9580d7990, fenceCount=1, pFences=0x7ef94000ecb0, waitAll=0, timeout=18446744073709551615) at ../src/amd/vulkan/radv_device.c:3992 #5 0x01a3d842 in ?? () #6 0x01a08d30 in ?? () #7 0x01a16190 in ?? () #8 0x01522a7b in ?? () #9 0x015dc170 in ?? () #10 0x015e6108 in ?? () #11 0x0268580f in ?? () #12 0x7efbfebae5a2 in start_thread () from /lib64/libpthread.so.0 #13 0x7efbf96a6303 in clone () from /lib64/libc.so.6 In the meantime another thread is busy creating a pipeline: #0 0x7efad43ae617 in u_vector_remove (vector=0x7ef890999eb0) at ../src/util/u_vector.c:101 #1 0x7efad4436a67 in nir_instr_worklist_pop_head (wl=0x7ef890999eb0) at ../src/compiler/nir/nir_worklist.h:149 #2 0x7efad4436dee in nir_opt_dce_impl (impl=0x7ef89593f6b0) at ../src/compiler/nir/nir_opt_dce.c:132 #3 0x7efad4436efc in nir_opt_dce (shader=0x7ef894905280) at ../src/compiler/nir/nir_opt_dce.c:165 #4 0x7efad430fe7e in radv_optimize_nir (shader=0x7ef894905280, optimize_conservatively=false, allow_copies=true) at ../src/amd/vulkan/radv_shader.c:208 #5 0x7efad4312543 in radv_shader_compile_to_nir (device=0x7ef9580d7990, module=0x7ef9245d02c0, entrypoint_name=0x2887089 "main", stage=MESA_SHADER_VERTEX, spec_info=0x0, flags=0, layout=0x7ef9486faa50) at ../src/amd/vulkan/radv_shader.c:438 #6 0x7efad4306af9 in radv_create_shaders (pipeline=0x7ef894934d00, device=0x7ef9580d7990, cache=0x7ef95891e230, key=0x7ef951fe4fb0, pStages=0x7ef951fe5230, flags=0, pipeline_feedback=0x0, stage_feedbacks=0x7ef951fe5200) at ../src/amd/vulkan/radv_pipeline.c:2506 #7 0x7efad430b4b4 in radv_pipeline_init (pipeline=0x7ef894934d00, device=0x7ef9580d7990, cache=0x7ef95891e230, pCreateInfo=0x7ef94b983380, extra=0x0) at ../src/amd/vulkan/radv_pipeline.c:4446 #8 0x7efad430bb98 in radv_graphics_pipeline_create (_device=0x7ef9580d7990, _cache=0x7ef95891e230, pCreateInfo=0x7ef94b983380, extra=0x0, pAllocator=0x0, pPipeline=0x7ef949454f08) at ../src/amd/vulkan/radv_pipeline.c:4576 #9 0x7efad430bc53 in radv_CreateGraphicsPipelines (_device=0x7ef9580d7990, pipelineCache=0x7ef95891e230, count=1, pCreateInfos=0x7ef94b983380, pAllocator=0x0, pPipelines=0x7ef949454f08) at ../src/amd/vulkan/radv_pipeline.c:4601 #10 0x7efb0c156078 in ?? () from /home/Timur/.local/share/Steam/ubuntu12_64/libVkLayer_steam_fossilize.so #11 0x01a7f502 in ?? () #12 0x01c26765 in ?? () #13 0x01c26f00 in ?? () #14 0x0268580f in ?? () #15 0x7efbfebae5a2 in start_thread () from /lib64/libpthread.so.0 #16 0x7efbf96a6303 in clone () from /lib64/libc.so.6 -- 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 111264] u_thread.h:64:39: error: too many arguments to function call, expected 1, have 2
https://bugs.freedesktop.org/show_bug.cgi?id=111264 Ian Romanick changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Ian Romanick --- Looking at the man page (http://man7.org/linux/man-pages/man3/pthread_setname_np.3.html), pthread_setname_np definitely takes two parameters. Dare I even ask what pthreads library this is? -- 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 111269] GFX10: "Random" GPU hangs with Rise Of The Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=111269 Bug ID: 111269 Summary: GFX10: "Random" GPU hangs with Rise Of The Tomb Raider Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: blocker Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: samuel.pitoi...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org RoTR hangs on GFX10, open the game, wait few seconds and it should hang in the main menu. It also hangs in the first benchmark scene, could be related or not. The game works fine on pre-GFX10. Apparently, the game also hangs with AMDVLK. We tried a bunch of different things without any success. -- 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] gitlab-ci: remove software-properties-common
On 2019-07-31 3:26 p.m., Emil Velikov wrote: > On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote: >> >> On 2019-07-31 3:04 p.m., Emil Velikov wrote: >>> From: Emil Velikov >>> >>> Currently we use the python package to manage repositories. At the same >>> time we also do that by hand - since it's a trivial echo to a file. >>> >>> Stay consistent, remove the package and manage things manually. >>> >>> Cc: Eric Engestrom >>> Signed-off-by: Emil Velikov >>> --- >>> .gitlab-ci/debian-install.sh | 11 +-- >>> 1 file changed, 5 insertions(+), 6 deletions(-) >>> >>> diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh >>> index 578074ddb87..719d7830018 100644 >>> --- a/.gitlab-ci/debian-install.sh >>> +++ b/.gitlab-ci/debian-install.sh >>> @@ -16,12 +16,11 @@ apt-get install -y \ >>>curl \ >>>wget \ >>>unzip \ >>> - gnupg \ >>> - software-properties-common >>> + gnupg >>> >>> curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - >>> -add-apt-repository "deb https://apt.llvm.org/stretch/ >>> llvm-toolchain-stretch-7 main" >>> -add-apt-repository "deb https://apt.llvm.org/stretch/ >>> llvm-toolchain-stretch-8 main" >>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ >>> llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list >>> +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ >>> llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list >>> >>> sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list >>> echo 'deb https://deb.debian.org/debian stretch-backports main' >>> >/etc/apt/sources.list.d/backports.list >>> @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ >>>clang-8 >>> >>> # Install remaining packages from Debian buster to get newer versions >>> -add-apt-repository "deb https://deb.debian.org/debian/ buster main" >>> -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates main" >>> +echo "deb https://deb.debian.org/debian/ buster main" >>> >/etc/apt/sources.list.d/buster.list >>> +echo "deb https://deb.debian.org/debian/ buster-updates main" >>> >/etc/apt/sources.list.d/buster-updates.list >>> apt-get update >>> apt-get install -y \ >>>bzip2 \ >>> >> >> This should be merged as part of an MR which requires the docker image >> to be re-generated for another reason, and thus bumps DEBIAN_TAG. >> > Since this is a non-functional change, I've explicitly omitted bumping > the DEBIAN_TAG. > Seemingly I forgot to mention it in the commit message though, oopsie. > > Since the image will contain practically the same artefacts, is it > worth carving out 30 minutes (or so) from the runners? No, I agree that would be wasteful for this change alone. However, merging this change without bumping the tag isn't good either, because then any issues with it would only be discovered the next time it does get bumped. Hence my request above. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 19.2.0 release plan
On 2019-07-31 at 09:38, Emil Velikov wrote: > Hi all, > > Here is the tentative release plan for 19.2.0. > > As many of you are well aware, it's time to the next branch point. > The calendar is already updated, so these are the tentative dates: > > Aug 06 2019 - Feature freeze/Release candidate 1 > Aug 13 2019 - Release candidate 2 > Aug 20 2019 - Release candidate 3 > Aug 27 2019 - Release candidate 4/final release > > This gives us around 1 week until the branch point. > > Note: In the spirit of keeping things clearer and more transparent, we > will be keeping track of any features planned for the release in > Bugzilla [1]. > > Do add a separate "Depends on" for each work you have planned. > Alternatively you can reply to this email and I'll add them for you. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=111265 Thanks! As per previous discussions (I don't remember where, sorry) as well as internal discussions, I think we should add all currently open regressions since 19.1 as blockers for this release. We should also add that to the procedure in our docs; I'll do that later today if nobody beats me to it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111265] [TRACKER] Mesa 19.2 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111265 Peter changed: What|Removed |Added CC||pbrobin...@gmail.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
Re: [Mesa-dev] [PATCH] gitlab-ci: remove software-properties-common
On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote: > > On 2019-07-31 3:04 p.m., Emil Velikov wrote: > > From: Emil Velikov > > > > Currently we use the python package to manage repositories. At the same > > time we also do that by hand - since it's a trivial echo to a file. > > > > Stay consistent, remove the package and manage things manually. > > > > Cc: Eric Engestrom > > Signed-off-by: Emil Velikov > > --- > > .gitlab-ci/debian-install.sh | 11 +-- > > 1 file changed, 5 insertions(+), 6 deletions(-) > > > > diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh > > index 578074ddb87..719d7830018 100644 > > --- a/.gitlab-ci/debian-install.sh > > +++ b/.gitlab-ci/debian-install.sh > > @@ -16,12 +16,11 @@ apt-get install -y \ > >curl \ > >wget \ > >unzip \ > > - gnupg \ > > - software-properties-common > > + gnupg > > > > curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - > > -add-apt-repository "deb https://apt.llvm.org/stretch/ > > llvm-toolchain-stretch-7 main" > > -add-apt-repository "deb https://apt.llvm.org/stretch/ > > llvm-toolchain-stretch-8 main" > > +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ > > llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list > > +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ > > llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list > > > > sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list > > echo 'deb https://deb.debian.org/debian stretch-backports main' > > >/etc/apt/sources.list.d/backports.list > > @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ > >clang-8 > > > > # Install remaining packages from Debian buster to get newer versions > > -add-apt-repository "deb https://deb.debian.org/debian/ buster main" > > -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates main" > > +echo "deb https://deb.debian.org/debian/ buster main" > > >/etc/apt/sources.list.d/buster.list > > +echo "deb https://deb.debian.org/debian/ buster-updates main" > > >/etc/apt/sources.list.d/buster-updates.list > > apt-get update > > apt-get install -y \ > >bzip2 \ > > > > This should be merged as part of an MR which requires the docker image > to be re-generated for another reason, and thus bumps DEBIAN_TAG. > Since this is a non-functional change, I've explicitly omitted bumping the DEBIAN_TAG. Seemingly I forgot to mention it in the commit message though, oopsie. Since the image will contain practically the same artefacts, is it worth carving out 30 minutes (or so) from the runners? > Reviewed-by: Michel Dänzer > Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/drm: ensure the backing gbm is set before using it
On Fri, 5 Jul 2019 at 22:58, Eric Engestrom wrote:
>
> On Friday, 2019-07-05 11:21:41 +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently, if we error out before gbm_dri is set (say due to a different
> > name of the backing GBM implementation, or otherwise) the tear down will
> > trigger a NULL ptr deref and crash out.
> >
> > Move the gbm_dri initialization as early as possible. To be on the extra
> > safe side add a NULL check in the teardown.
> >
> > Reported-by: Christian Gmeiner
> > Cc: Christian Gmeiner
> > Cc: Eric Engestrom
> > Cc: mesa-sta...@lists.freedesktop.org
> > Signed-off-by: Emil Velikov
> > ---
> > Supersedes https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1182
> > ---
> > src/egl/drivers/dri2/platform_drm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/egl/drivers/dri2/platform_drm.c
> > b/src/egl/drivers/dri2/platform_drm.c
> > index a811834114d..3e2124ad39c 100644
> > --- a/src/egl/drivers/dri2/platform_drm.c
> > +++ b/src/egl/drivers/dri2/platform_drm.c
> > @@ -704,6 +704,7 @@ dri2_initialize_drm(_EGLDisplay *disp)
> > goto cleanup;
> >}
> > }
> > + dri2_dpy->gbm_dri = gbm_dri_device(gbm);
> >
> > if (strcmp(gbm_device_get_backend_name(gbm), "drm") != 0) {
> >err = "DRI2: gbm device using incorrect/incompatible backend";
> > @@ -718,7 +719,6 @@ dri2_initialize_drm(_EGLDisplay *disp)
> >
> > disp->Device = dev;
> >
> > - dri2_dpy->gbm_dri = gbm_dri_device(gbm);
> > dri2_dpy->driver_name = strdup(dri2_dpy->gbm_dri->driver_name);
> >
> > dri2_dpy->dri_screen = dri2_dpy->gbm_dri->screen;
> > @@ -777,6 +777,6 @@ cleanup:
> > void
> > dri2_teardown_drm(struct dri2_egl_display *dri2_dpy)
> > {
> > - if (dri2_dpy->own_device)
> > + if (dri2_dpy->own_device && dri2_dpy->gbm_dri)
>
> This would only be reachable by eglTerminate()ing an uninitialised
> display, which is explicitly invalid anyway.
>
> I think you can drop this check.
>
> The gbm_dri_device(gbm) move above is:
> Reviewed-by: Eric Engestrom
>
Dropped the check in dri2_teardown_drm() and pushed to master.
Thank you
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gitlab-ci: remove software-properties-common
On 2019-07-31 3:04 p.m., Emil Velikov wrote: > From: Emil Velikov > > Currently we use the python package to manage repositories. At the same > time we also do that by hand - since it's a trivial echo to a file. > > Stay consistent, remove the package and manage things manually. > > Cc: Eric Engestrom > Signed-off-by: Emil Velikov > --- > .gitlab-ci/debian-install.sh | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh > index 578074ddb87..719d7830018 100644 > --- a/.gitlab-ci/debian-install.sh > +++ b/.gitlab-ci/debian-install.sh > @@ -16,12 +16,11 @@ apt-get install -y \ >curl \ >wget \ >unzip \ > - gnupg \ > - software-properties-common > + gnupg > > curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - > -add-apt-repository "deb https://apt.llvm.org/stretch/ > llvm-toolchain-stretch-7 main" > -add-apt-repository "deb https://apt.llvm.org/stretch/ > llvm-toolchain-stretch-8 main" > +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ > llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list > +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ > llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list > > sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list > echo 'deb https://deb.debian.org/debian stretch-backports main' > >/etc/apt/sources.list.d/backports.list > @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ >clang-8 > > # Install remaining packages from Debian buster to get newer versions > -add-apt-repository "deb https://deb.debian.org/debian/ buster main" > -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates main" > +echo "deb https://deb.debian.org/debian/ buster main" > >/etc/apt/sources.list.d/buster.list > +echo "deb https://deb.debian.org/debian/ buster-updates main" > >/etc/apt/sources.list.d/buster-updates.list > apt-get update > apt-get install -y \ >bzip2 \ > This should be merged as part of an MR which requires the docker image to be re-generated for another reason, and thus bumps DEBIAN_TAG. Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gitlab-ci: remove software-properties-common
From: Emil Velikov Currently we use the python package to manage repositories. At the same time we also do that by hand - since it's a trivial echo to a file. Stay consistent, remove the package and manage things manually. Cc: Eric Engestrom Signed-off-by: Emil Velikov --- .gitlab-ci/debian-install.sh | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/.gitlab-ci/debian-install.sh b/.gitlab-ci/debian-install.sh index 578074ddb87..719d7830018 100644 --- a/.gitlab-ci/debian-install.sh +++ b/.gitlab-ci/debian-install.sh @@ -16,12 +16,11 @@ apt-get install -y \ curl \ wget \ unzip \ - gnupg \ - software-properties-common + gnupg curl -fsSL https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - -add-apt-repository "deb https://apt.llvm.org/stretch/ llvm-toolchain-stretch-7 main" -add-apt-repository "deb https://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main" +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ llvm-toolchain-stretch-7 main" >/etc/apt/sources.list.d/llvm7.list +echo "deb [trusted=yes] https://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main" >/etc/apt/sources.list.d/llvm8.list sed -i -e 's/http:\/\/deb/https:\/\/deb/g' /etc/apt/sources.list echo 'deb https://deb.debian.org/debian stretch-backports main' >/etc/apt/sources.list.d/backports.list @@ -46,8 +45,8 @@ apt-get install -y -t stretch-backports \ clang-8 # Install remaining packages from Debian buster to get newer versions -add-apt-repository "deb https://deb.debian.org/debian/ buster main" -add-apt-repository "deb https://deb.debian.org/debian/ buster-updates main" +echo "deb https://deb.debian.org/debian/ buster main" >/etc/apt/sources.list.d/buster.list +echo "deb https://deb.debian.org/debian/ buster-updates main" >/etc/apt/sources.list.d/buster-updates.list apt-get update apt-get install -y \ bzip2 \ -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/ir: Fix CFG corruption in opt_predicated_break().
I've run the test from the https://bugs.freedesktop.org/show_bug.cgi?id=111009 with applied patch and it doesn't crash and successfully passes. Thanks! Tested-by: Paul Chelombitko ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] radv/gfx10: implement a GE bug workaround
r-b for the series
On Wed, Jul 31, 2019 at 9:36 AM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 27 +++
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index b3952846f43..d62066cbee4 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -3592,6 +3592,7 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
> *ctx_cs,
> bool es_enable_prim_id = outinfo->export_prim_id ||
> (es && es->info.info.uses_prim_id);
> bool break_wave_at_eoi = false;
> + unsigned ge_cntl;
> unsigned nparams;
>
> if (es_type == MESA_SHADER_TESS_EVAL) {
> @@ -3674,10 +3675,28 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
> *ctx_cs,
>
> S_028838_INDEX_BUF_EDGE_FLAG_ENA(!radv_pipeline_has_tess(pipeline) &&
>
> !radv_pipeline_has_gs(pipeline)));
>
> - radeon_set_uconfig_reg(ctx_cs, R_03096C_GE_CNTL,
> - S_03096C_PRIM_GRP_SIZE(ngg_state->max_gsprims)
> |
> -
> S_03096C_VERT_GRP_SIZE(ngg_state->hw_max_esverts) |
> - S_03096C_BREAK_WAVE_AT_EOI(break_wave_at_eoi));
> + ge_cntl = S_03096C_PRIM_GRP_SIZE(ngg_state->max_gsprims) |
> + S_03096C_VERT_GRP_SIZE(ngg_state->hw_max_esverts) |
> + S_03096C_BREAK_WAVE_AT_EOI(break_wave_at_eoi);
> +
> + /* Bug workaround for a possible hang with non-tessellation cases.
> +* Tessellation always sets GE_CNTL.VERT_GRP_SIZE = 0
> +*
> +* Requirement: GE_CNTL.VERT_GRP_SIZE =
> VGT_GS_ONCHIP_CNTL.ES_VERTS_PER_SUBGRP - 5
> +*/
> + if ((pipeline->device->physical_device->rad_info.family ==
> CHIP_NAVI10 ||
> +pipeline->device->physical_device->rad_info.family ==
> CHIP_NAVI12 ||
> +pipeline->device->physical_device->rad_info.family ==
> CHIP_NAVI14) &&
> + !radv_pipeline_has_tess(pipeline) &&
> + ngg_state->hw_max_esverts != 256) {
> + ge_cntl &= C_03096C_VERT_GRP_SIZE;
> +
> + if (ngg_state->hw_max_esverts > 5) {
> + ge_cntl |=
> S_03096C_VERT_GRP_SIZE(ngg_state->hw_max_esverts - 5);
> + }
> + }
> +
> + radeon_set_uconfig_reg(ctx_cs, R_03096C_GE_CNTL, ge_cntl);
> }
>
> static void
> --
> 2.22.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] Mesa 19.2.0 release plan
Hi Emil, Am Mittwoch, den 31.07.2019, 09:37 +0100 schrieb Emil Velikov: > Hi all, > > Here is the tentative release plan for 19.2.0. > > As many of you are well aware, it's time to the next branch point. > The calendar is already updated, so these are the tentative dates: > > Aug 06 2019 - Feature freeze/Release candidate 1 > Aug 13 2019 - Release candidate 2 > Aug 20 2019 - Release candidate 3 > Aug 27 2019 - Release candidate 4/final release > > This gives us around 1 week until the branch point. > > Note: In the spirit of keeping things clearer and more transparent, we > will be keeping track of any features planned for the release in > Bugzilla [1]. > > Do add a separate "Depends on" for each work you have planned. > Alternatively you can reply to this email and I'll add them for you. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=111265 The etnaviv team would like to land the experimental NIR compiler [1] and a good bunch of fixes for multithreading issues [2] before the branching. Regards, Lucas [1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1497 [2] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1190 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 19.2.0 release plan
Hi all, Here is the tentative release plan for 19.2.0. As many of you are well aware, it's time to the next branch point. The calendar is already updated, so these are the tentative dates: Aug 06 2019 - Feature freeze/Release candidate 1 Aug 13 2019 - Release candidate 2 Aug 20 2019 - Release candidate 3 Aug 27 2019 - Release candidate 4/final release This gives us around 1 week until the branch point. Note: In the spirit of keeping things clearer and more transparent, we will be keeping track of any features planned for the release in Bugzilla [1]. Do add a separate "Depends on" for each work you have planned. Alternatively you can reply to this email and I'll add them for you. [1] https://bugs.freedesktop.org/show_bug.cgi?id=111265 Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111265] [TRACKER] Mesa 19.2 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111265 Bug ID: 111265 Summary: [TRACKER] Mesa 19.2 feature tracker Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: emil.l.veli...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org This is a tracker for features planned for the 19.2 release. Note: features should be merged prior to the branchpoint. Schedule is at https://www.mesa3d.org/release-calendar.html -- 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 111262] lp_bld_misc.cpp:811:51: error: ‘llvm::AtomicOrdering’ is not a class or namespace
https://bugs.freedesktop.org/show_bug.cgi?id=111262 --- Comment #3 from Michel Dänzer --- Any idea why the GitLab CI pipeline scons-llvm job doesn't hit this, which builds against LLVM 3.4.2? (See e.g. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/460746) -- 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 2/6] radv/gfx10: implement a bug workaround for NGG -> legacy transitions
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 14 ++
src/amd/vulkan/si_cmd_buffer.c | 9 +++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 37026246aa9..cf3f81b2031 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3626,6 +3626,20 @@ void radv_CmdBindPipeline(
/* Prefetch all pipeline shaders at first draw time. */
cmd_buffer->state.prefetch_L2_mask |= RADV_PREFETCH_SHADERS;
+ if ((cmd_buffer->device->physical_device->rad_info.family ==
CHIP_NAVI10 ||
+cmd_buffer->device->physical_device->rad_info.family ==
CHIP_NAVI12 ||
+cmd_buffer->device->physical_device->rad_info.family ==
CHIP_NAVI14) &&
+ cmd_buffer->state.emitted_pipeline &&
+ radv_pipeline_has_ngg(cmd_buffer->state.emitted_pipeline) &&
+ !radv_pipeline_has_ngg(cmd_buffer->state.pipeline)) {
+ /* Transitioning from NGG to legacy GS requires
+* VGT_FLUSH on Navi10-14. VGT_FLUSH is also emitted
+* at the beginning of IBs when legacy GS ring pointers
+* are set.
+*/
+ cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_VGT_FLUSH;
+ }
+
radv_bind_dynamic_state(cmd_buffer, >dynamic_state);
radv_bind_streamout_state(cmd_buffer, pipeline);
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 94f759139ee..18b2236e54b 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -878,8 +878,7 @@ gfx10_cs_emit_cache_flush(struct radeon_cmdbuf *cs,
unsigned cb_db_event = 0;
/* We don't need these. */
- assert(!(flush_bits & (RADV_CMD_FLAG_VGT_FLUSH |
- RADV_CMD_FLAG_VGT_STREAMOUT_SYNC)));
+ assert(!(flush_bits & (RADV_CMD_FLAG_VGT_STREAMOUT_SYNC)));
if (flush_bits & RADV_CMD_FLAG_INV_ICACHE)
gcr_cntl |= S_586_GLI_INV(V_586_GLI_ALL);
@@ -998,6 +997,12 @@ gfx10_cs_emit_cache_flush(struct radeon_cmdbuf *cs,
*flush_cnt, 0x);
}
+ /* VGT state sync */
+ if (flush_bits & RADV_CMD_FLAG_VGT_FLUSH) {
+ radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
+ radeon_emit(cs, EVENT_TYPE(V_028A90_VGT_FLUSH) |
EVENT_INDEX(0));
+ }
+
/* Ignore fields that only modify the behavior of other fields. */
if (gcr_cntl & C_586_GL1_RANGE & C_586_GL2_RANGE & C_586_SEQ) {
/* Flush caches and wait for the caches to assert idle.
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] radv/gfx10: remove an obsolete VGT_REUSE_OFF workaround
Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_pipeline.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c index 4d4f86a7e24..b3952846f43 100644 --- a/src/amd/vulkan/radv_pipeline.c +++ b/src/amd/vulkan/radv_pipeline.c @@ -3641,12 +3641,6 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf *ctx_cs, S_028A84_PRIMITIVEID_EN(es_enable_prim_id) | S_028A84_NGG_DISABLE_PROVOK_REUSE(es_enable_prim_id)); - bool vgt_reuse_off = pipeline->device->physical_device->rad_info.family == CHIP_NAVI10 && - pipeline->device->physical_device->rad_info.chip_external_rev == 0x1 && -es_type == MESA_SHADER_TESS_EVAL; - - radeon_set_context_reg(ctx_cs, R_028AB4_VGT_REUSE_OFF, - S_028AB4_REUSE_OFF(vgt_reuse_off)); radeon_set_context_reg(ctx_cs, R_028AAC_VGT_ESGS_RING_ITEMSIZE, ngg_state->vgt_esgs_ring_itemsize); -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] radv/gfx10: disable LATE_ALLOC_GS on Navi14
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/si_cmd_buffer.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 3d6c672dd0f..d48ed804e63 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -311,6 +311,7 @@ si_emit_graphics(struct radv_physical_device
*physical_device,
late_alloc_limit = (num_cu_per_sh - 2) * 4;
}
+ unsigned late_alloc_limit_gs = late_alloc_limit;
unsigned cu_mask_vs = 0x;
unsigned cu_mask_gs = 0x;
@@ -324,6 +325,12 @@ si_emit_graphics(struct radv_physical_device
*physical_device,
}
}
+ /* Don't use late alloc for NGG on Navi14 due to a hw bug. */
+ if (physical_device->rad_info.family == CHIP_NAVI14) {
+ late_alloc_limit_gs = 0;
+ cu_mask_gs = 0x;
+ }
+
radeon_set_sh_reg_idx(physical_device, cs,
R_00B118_SPI_SHADER_PGM_RSRC3_VS,
3, S_00B118_CU_EN(cu_mask_vs) |
S_00B118_WAVE_LIMIT(0x3F));
@@ -336,7 +343,7 @@ si_emit_graphics(struct radv_physical_device
*physical_device,
if (physical_device->rad_info.chip_class >= GFX10) {
radeon_set_sh_reg_idx(physical_device, cs,
R_00B204_SPI_SHADER_PGM_RSRC4_GS,
3, S_00B204_CU_EN(0x) |
-
S_00B204_SPI_SHADER_LATE_ALLOC_GS_GFX10(late_alloc_limit));
+
S_00B204_SPI_SHADER_LATE_ALLOC_GS_GFX10(late_alloc_limit_gs));
}
radeon_set_sh_reg_idx(physical_device, cs,
R_00B01C_SPI_SHADER_PGM_RSRC3_PS,
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] radv/gfx10: implement a bug workaround for GE_PC_ALLOC
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 17 -
src/amd/vulkan/si_cmd_buffer.c | 13 +
2 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 5c913f29a5a..4d4f86a7e24 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3456,18 +3456,6 @@ radv_pipeline_generate_vgt_gs_mode(struct radeon_cmdbuf
*ctx_cs,
radeon_set_context_reg(ctx_cs, R_028A40_VGT_GS_MODE, vgt_gs_mode);
}
-static void
-gfx10_set_ge_pc_alloc(struct radeon_cmdbuf *ctx_cs,
- struct radv_pipeline *pipeline,
- bool culling)
-{
- struct radeon_info *info = >device->physical_device->rad_info;
-
- radeon_set_uconfig_reg(ctx_cs, R_030980_GE_PC_ALLOC,
- S_030980_OVERSUB_EN(1) |
- S_030980_NUM_PC_LINES((culling ? 256 : 128) *
info->max_se - 1));
-}
-
static void
radv_pipeline_generate_hw_vs(struct radeon_cmdbuf *ctx_cs,
struct radeon_cmdbuf *cs,
@@ -3534,9 +3522,6 @@ radv_pipeline_generate_hw_vs(struct radeon_cmdbuf *ctx_cs,
if (pipeline->device->physical_device->rad_info.chip_class <= GFX8)
radeon_set_context_reg(ctx_cs, R_028AB4_VGT_REUSE_OFF,
outinfo->writes_viewport_index);
-
- if (pipeline->device->physical_device->rad_info.chip_class >= GFX10)
- gfx10_set_ge_pc_alloc(ctx_cs, pipeline, false);
}
static void
@@ -3699,8 +3684,6 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
*ctx_cs,
S_03096C_PRIM_GRP_SIZE(ngg_state->max_gsprims) |
S_03096C_VERT_GRP_SIZE(ngg_state->hw_max_esverts) |
S_03096C_BREAK_WAVE_AT_EOI(break_wave_at_eoi));
-
- gfx10_set_ge_pc_alloc(ctx_cs, pipeline, false);
}
static void
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 18b2236e54b..3d6c672dd0f 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -382,6 +382,19 @@ si_emit_graphics(struct radv_physical_device
*physical_device,
S_00B0C0_SOFT_GROUPING_EN(1) |
S_00B0C0_NUMBER_OF_REQUESTS_PER_CU(4 - 1));
radeon_set_sh_reg(cs, R_00B1C0_SPI_SHADER_REQ_CTRL_VS, 0);
+
+ if (physical_device->rad_info.family == CHIP_NAVI10 ||
+ physical_device->rad_info.family == CHIP_NAVI12 ||
+ physical_device->rad_info.family == CHIP_NAVI14) {
+ /* SQ_NON_EVENT must be emitted before GE_PC_ALLOC is
written. */
+ radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
+ radeon_emit(cs, EVENT_TYPE(V_028A90_SQ_NON_EVENT) |
EVENT_INDEX(0));
+ }
+
+ /* TODO: For culling, replace 128 with 256. */
+ radeon_set_uconfig_reg(cs, R_030980_GE_PC_ALLOC,
+ S_030980_OVERSUB_EN(1) |
+ S_030980_NUM_PC_LINES(128 *
physical_device->rad_info.max_se - 1));
}
if (physical_device->rad_info.chip_class >= GFX8) {
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] radv: skip draw calls with 0-sized index buffers
Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_cmd_buffer.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c index e0ea47b5745..37026246aa9 100644 --- a/src/amd/vulkan/radv_cmd_buffer.c +++ b/src/amd/vulkan/radv_cmd_buffer.c @@ -4323,6 +4323,12 @@ radv_emit_draw_packets(struct radv_cmd_buffer *cmd_buffer, int index_size = radv_get_vgt_index_size(state->index_type); uint64_t index_va; + /* Skip draw calls with 0-sized index buffers. They +* cause a hang on some chips, like Navi10-14. +*/ + if (!cmd_buffer->state.max_index_count) + return; + index_va = state->index_va; index_va += info->first_index * index_size; -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] radv/gfx10: implement a GE bug workaround
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index b3952846f43..d62066cbee4 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3592,6 +3592,7 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
*ctx_cs,
bool es_enable_prim_id = outinfo->export_prim_id ||
(es && es->info.info.uses_prim_id);
bool break_wave_at_eoi = false;
+ unsigned ge_cntl;
unsigned nparams;
if (es_type == MESA_SHADER_TESS_EVAL) {
@@ -3674,10 +3675,28 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
*ctx_cs,
S_028838_INDEX_BUF_EDGE_FLAG_ENA(!radv_pipeline_has_tess(pipeline) &&
!radv_pipeline_has_gs(pipeline)));
- radeon_set_uconfig_reg(ctx_cs, R_03096C_GE_CNTL,
- S_03096C_PRIM_GRP_SIZE(ngg_state->max_gsprims) |
-
S_03096C_VERT_GRP_SIZE(ngg_state->hw_max_esverts) |
- S_03096C_BREAK_WAVE_AT_EOI(break_wave_at_eoi));
+ ge_cntl = S_03096C_PRIM_GRP_SIZE(ngg_state->max_gsprims) |
+ S_03096C_VERT_GRP_SIZE(ngg_state->hw_max_esverts) |
+ S_03096C_BREAK_WAVE_AT_EOI(break_wave_at_eoi);
+
+ /* Bug workaround for a possible hang with non-tessellation cases.
+* Tessellation always sets GE_CNTL.VERT_GRP_SIZE = 0
+*
+* Requirement: GE_CNTL.VERT_GRP_SIZE =
VGT_GS_ONCHIP_CNTL.ES_VERTS_PER_SUBGRP - 5
+*/
+ if ((pipeline->device->physical_device->rad_info.family == CHIP_NAVI10
||
+pipeline->device->physical_device->rad_info.family == CHIP_NAVI12
||
+pipeline->device->physical_device->rad_info.family == CHIP_NAVI14)
&&
+ !radv_pipeline_has_tess(pipeline) &&
+ ngg_state->hw_max_esverts != 256) {
+ ge_cntl &= C_03096C_VERT_GRP_SIZE;
+
+ if (ngg_state->hw_max_esverts > 5) {
+ ge_cntl |=
S_03096C_VERT_GRP_SIZE(ngg_state->hw_max_esverts - 5);
+ }
+ }
+
+ radeon_set_uconfig_reg(ctx_cs, R_03096C_GE_CNTL, ge_cntl);
}
static void
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
