- May 01, 2018
-
-
Lina Versace authored
Tested with a low-latency handwriting application on Android Nougat on the Chrome OS Pixelbook (codename Eve) with Kabylake. BUG=b:77899911 TEST=No android-cts-7.1 regressions on Eve. Change-Id: Ia816fa6b0a1158f81e5b63477451bf337c2001aa
-
Lina Versace authored
Specifically, implement the extension DRI_MutableRenderBufferLoader. However, the loader enables EGL_KHR_mutable_render_buffer only if the DRI driver implements its half of the extension, DRI_MutableRenderBufferDriver. BUG=b:77899911 TEST=No android-cts-7.1 regressions on Eve. Change-Id: I7fe68a5a674d1707b1e7251d900b3affd5dd7660
-
Lina Versace authored
A follow-up patch enables EGL_KHR_mutable_render_buffer for Android. This patch is separate from the Android patch because I think it's easier to review the platform-independent bits separately. BUG=b:77899911 TEST=No android-cts-7.1 regressions on Eve. Change-Id: I07470f2862796611b141f69f47f935b97b0e04a1
-
Lina Versace authored
If set, then the config will have __DRI_ATTRIB_MUTABLE_RENDER_BUFFER, which translates to EGL_MUTABLE_RENDER_BUFFER_BIT_KHR. Not used yet. BUG=b:77899911 TEST=No android-cts-7.1 regressions on Eve. Change-Id: Icdf35794f3e9adf31e1f85740b87ce155efe1491
-
Lina Versace authored
Define extensions DRI_MutableRenderBufferDriver and DRI_MutableRenderBufferLoader. These are the two halves for EGL_KHR_mutable_render_buffer. Outside the DRI code there is one additional change. Add gl_config::mutableRenderBuffer to match __DRI_ATTRIB_MUTABLE_RENDER_BUFFER. Neither are used yet. BUG=b:77899911 TEST=No android-cts-7.1 regressions on Eve. Change-Id: I4ca03d81e4557380b19c44d8d799a7cc9365d928
-
Lina Versace authored
This pulls an 'else' block into the function's main body, making the code easier to follow. Without this change, the upcoming EGL_KHR_mutable_render_buffer patch transforms dri2_make_current() into spaghetti. BUG=b:77899911 TEST=No android-cts-7.1 regressions on Eve. Change-Id: I26be2b7a8e78a162dcd867a44f62d6f48b9a8e4d
-
Lina Versace authored
Replace it with two fields in _EGLSurface, RequestedRenderBuffer and ActiveRenderBuffer. (_EGLSurface::RequestedRenderBuffer replaces _EGLSurface::RenderBuffer). There exist *two* queryable EGL_RENDER_BUFFER states in EGL: eglQuerySurface(EGL_RENDER_BUFFER) and eglQueryContext(EGL_RENDER_BUFFER). _EGLContext::WindowRenderBuffer was related to eglQueryContext but not eglQuerySurface. Post-patch, RequestedRenderBuffer is related to eglQuerySurface and ActiveRenderBuffer is related to eglQueryContext. The implementation of eglQuerySurface(EGL_RENDER_BUFFER) contained abstruse logic which required comprehending the specification complexities of how the two EGL_RENDER_BUFFER states interact. Sometimes it returned _EGLContext::WindowRenderBuffer, sometimes _EGLSurface::RenderBuffer. Why? The function tried to encode the actual logic in the EGL spec. When did the function return which variable? Go study the EGL spec, hope you understand it, then hope Mesa mutated the EGL_RENDER_BUFFER state in all the correct places. Have fun. I got a headache from the mental gymnastics. To simplify eglQuerySurface(EGL_RENDER_BUFFER), and to improve confidence in its correctness, flatten its indirect logic. For pixmap and pbuffer surfaces, return a hard-coded literal value, as the spec suggests. For window surfaces, simply return ActiveRenderBuffer. Nothing difficult here. These changes eliminate potentially very fragile code in the upcoming EGL_KHR_mutable_render_buffer implementation. BUG=b:77899911 TEST=No android-cts-7.1 regressions on Eve. Change-Id: Ic5f2ab1952f26a87081bc4f78bc7fa96734c8f2a
-
- Apr 17, 2018
-
-
Dave Airlie authored
This fixes some dEQP tests that generated bad shaders. Fixes: b6f6ead1 (virgl: drop const dimensions on first block.) Reviewed-by:
Gurchetan Singh <gurchetansingh@chromium.org> Tested-by:
Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 49c61d8b) BUG=b:78132369 TEST=play war robots under arc++ in Chrome OS for 1 hour. Change-Id: I7d8de9e2a8289e9119f839b1d1aa99012bdbd6e8 Reviewed-on: https://chromium-review.googlesource.com/1013329 Commit-Ready: Lepton Wu <lepton@chromium.org> Tested-by:
Lepton Wu <lepton@chromium.org> Reviewed-by:
Gurchetan Singh <gurchetansingh@chromium.org>
-
- Apr 12, 2018
-
-
Lepton Wu authored
Instead of handling software fallback inside platform_android, just let EGL framework to handle it. With this, we still can fall back to software driver when hardware driver actually doesn't work. BUG=b:77302150 TEST=manual - make sure betty still boot without virgl driver. Change-Id: I5d514f67c9dc6f68661e03fd9fc9546acd7277bd Reviewed-on: https://chromium-review.googlesource.com/1004006 Commit-Ready: Lepton Wu <lepton@chromium.org> Tested-by:
Lepton Wu <lepton@chromium.org> Reviewed-by:
Tomasz Figa <tfiga@chromium.org>
-
- Apr 11, 2018
-
-
Harish Krupo authored
From android cts 8.0_r4, a new test case checks if all the required egl extensions are exposed. In the current implementation we expose KHR_image if KHR_image_base and KHR_image_pixmap are supported but KHR_image spec does not mandate the existence of both the extensions. This patch preserves the current check and also provides the backend with an option to expose the KHR_image extension. Test: run cts -m CtsOpenGLTestCases -t \ android.opengl.cts.OpenGlEsVersionTest#testRequiredEglExtensions Signed-off-by:
Harish Krupo <harish.krupo.kps@intel.com> Reviewed-by:
Tapani Plli <tapani.palli@intel.com> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 96fc5fbf) Signed-off-by:
Nicolas Boichat <drinkcat@chromium.org> BUG=b:77786960 TEST=android.opengl.cts.OpenGlEsVersionTest#testRequiredEglExtensions passes on CTS 8.1 Change-Id: I7c057ea4aa00f99885259ca0a97cac4554551c80 Reviewed-on: https://chromium-review.googlesource.com/1002796 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by:
Nicolas Boichat <drinkcat@chromium.org> Reviewed-by:
Ilja H. Friedel <ihf@chromium.org> Reviewed-by:
Tomasz Figa <tfiga@chromium.org>
-
Eric Engestrom authored
My refactor in 47273d73 missed this early return; because of it, setting UseFallback one layer above actually prevented the software path from being used. Remove this early return and let each platform's dri2_initialize_*() decide what it can do with the LIBGL_ALWAYS_SOFTWARE restriction. platform_{surfaceless,x11,wayland} were already handling it themselves. Fixes: 47273d73 "egl: set UseFallback if LIBGL_ALWAYS_SOFTWARE is set" Signed-off-by:
Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reported-by:
Brendan King <Brendan.King@imgtec.com> (cherry picked from commit 2f421651) BUG=b:77302150 TEST=manual - make sure betty still boots without virgl driver. Change-Id: I5e2ddfbd7a72bf04d83cac8f08fafbe81a77e66c Reviewed-on: https://chromium-review.googlesource.com/1004005 Commit-Ready: Lepton Wu <lepton@chromium.org> Tested-by:
Lepton Wu <lepton@chromium.org> Reviewed-by:
Tomasz Figa <tfiga@chromium.org>
-
- Mar 29, 2018
-
-
Nicolas Boichat authored
When compiling with LLVM 6.0, the test fails to detect that -latomic is actually required, as the atomic call is inlined. In the code itself (src/util/disk_cache.c), we see this pattern: p_atomic_add(cache->size, - (uint64_t)size); where cache->size is an uint64_t *, and results in the following link time error without -latomic: src/util/disk_cache.c:628: error: undefined reference to '__atomic_fetch_add_8' Fix the configure test to replicate this pattern, which then correctly realizes the need for -latomic. BUG=b:76397110 TEST=cros_workon_make --board=caroline-arcnext --reconf arc-mesa (am from https://patchwork.freedesktop.org/patch/213657/ , dropped meson.build change) Change-Id: I9cdad5fd32879a3577d6ef42e278960a934b23fb Signed-off-by:
Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/985676 Reviewed-by:
Tomasz Figa <tfiga@chromium.org>
-
- Mar 14, 2018
-
-
Bas Nieuwenhuizen authored
It did not signal syncobjs in the fence, and also signalled too early if there was work on the queue already, as we have to wait till that work is done. Fixes: d27aaae4 "radv: Add external fence support." Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 0347a83b) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I887768385833112effa1e8d414bf171640bb3564 Reviewed-on: https://chromium-review.googlesource.com/913504 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Bas Nieuwenhuizen authored
Passes dEQP-VK.api.smoke.* dEQP-VK.wsi.android.* with android-cts-7.1_r12 . Unlike the initial anv implementation this does use syncobjs instead of waiting on the CPU. This is missing meson build coverage for now. One possible todo is that linux 4.15 now has a sycall that allows us to export amdgpu fence to a sync_file, which allows us not to force all fences and semaphores to use syncobjs. However, I had trouble with my kernel crashing regularly with NULL pointers, and I'm not sure how beneficial it is in the first place given that intel uses syncobjs for all fences if available. Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit b1444c9c) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I002abe9e44ceba89c15f503d8c9fa3419aa2803e Reviewed-on: https://chromium-review.googlesource.com/913503 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Lepton Wu authored
We need to set surface/sampler_view destruction callbacks for surface and sampler_view after https://chromium-review.googlesource.com/558120 BUG=b:70179880 TEST=Run android apps on bettyvirgl (rendering only works sometimes.) Change-Id: I85cedb53a3dd86caba1d8cf890f63a0a5dfce4bd Reviewed-on: https://chromium-review.googlesource.com/959231 Commit-Ready: Lepton Wu <lepton@chromium.org> Tested-by:
Lepton Wu <lepton@chromium.org> Reviewed-by:
Joe Kniss <djmk@google.com>
-
- Mar 13, 2018
-
-
Bas Nieuwenhuizen authored
If we import an image, we might not have space in the buffer for CMASK, even though it is compatible. Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit a3e241ed) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I4a5d6634e89ea8ec4ac200405e5c84d6f30dcb2f Reviewed-on: https://chromium-review.googlesource.com/913502 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
- Mar 08, 2018
-
-
Bas Nieuwenhuizen authored
Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit e344cd81) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: Ia0957ef39597416bf3750e8138047c0c748a1d1b Reviewed-on: https://chromium-review.googlesource.com/913501 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Bas Nieuwenhuizen authored
Per spec: "Additionally, exporting a fence payload to a handle with copy transference has the same side effects on the source fences payload as executing a fence reset operation. If the fence was using a temporarily imported payload, the fences prior permanent payload will be restored." And similar for semaphores: "Additionally, exporting a semaphore payload to a handle with copy transference has the same side effects on the source semaphores payload as executing a semaphore wait operation. If the semaphore was using a temporarily imported payload, the semaphores prior permanent payload will be restored." Fixes: 42bc25a7 "radv: Advertise sync fd import and export." Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit b9f4c615) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I5c79d6b69bb76b8f97018a4726d10f6b0d740350 Reviewed-on: https://chromium-review.googlesource.com/913500 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Marek Olšák authored
Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 4f19cc82) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I1b78fb53ac25131117c6ac2bf78f9f4f964eed3d Reviewed-on: https://chromium-review.googlesource.com/913499 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
- Mar 07, 2018
-
-
Bas Nieuwenhuizen authored
Passes dEQP-VK.*.sync_fd.* Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 42bc25a7) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: Icf0b6516fb015a2639bff9fd29050896f04f8980 Reviewed-on: https://chromium-review.googlesource.com/913498 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Bas Nieuwenhuizen authored
Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 52b3f50d) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I6ed541af269ceaefad15565f52b95c2e33f73a0d Reviewed-on: https://chromium-review.googlesource.com/913497 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Bas Nieuwenhuizen authored
Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit b98bbdf4) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I0e84a9df34ab22e6dd54b894e245c8df3c254c3f Reviewed-on: https://chromium-review.googlesource.com/913496 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
- Mar 06, 2018
-
-
Bas Nieuwenhuizen authored
Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit d27aaae4) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I77a8313fc5728c0fec30f2e61695b0e3e935a3e9 Reviewed-on: https://chromium-review.googlesource.com/913495 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Bas Nieuwenhuizen authored
Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 6abfa378) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: Ie185825c75dc0b45dba4b17b7edbcce5309c3dfc Reviewed-on: https://chromium-review.googlesource.com/913494 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Bas Nieuwenhuizen authored
Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 969421b7) Added WSI code for this, as the upstream WSI got a rework. BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: I0f96630935b61f9d927ea7e1d1ea0e6c71d56796 Reviewed-on: https://chromium-review.googlesource.com/913493 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
- Feb 23, 2018
-
-
Bas Nieuwenhuizen authored
First amdgpu bump after inclusion was 20 (which was done for local BOs). Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit b308bb87) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: If2cede07cd2779d1d526aecee0b4c0f1d5bb5a4a Reviewed-on: https://chromium-review.googlesource.com/913492 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
Bas Nieuwenhuizen authored
Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 1c3cda7d) BUG=b:73102056 TEST=run nougat-mr1-cts-dev deqp vulkan tests. Change-Id: Ieb018369d1bf588a27b4912475c05230c557b815 Reviewed-on: https://chromium-review.googlesource.com/913491 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org>
-
- Feb 17, 2018
-
-
Faith Ekstrand authored
This fixes some rendering corruption in a couple of Android apps that use window-system MSAA. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104741 Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Tapani Plli <tapani.palli@intel.com> (cherry picked from commit 2f7205be) Fix for Telegram and KineMaster graphic corruption BUG=b:71872728 TEST=Telegram and KineMaster work without corruption Change-Id: If8c489abe2d26a0c639dfe6d5f10f8fd4c3719c4 Signed-off-by:
Dmytro Chystiakov <dmytro.chystiakov@intel.com> Reviewed-on: https://chromium-review.googlesource.com/915190 Reviewed-by:
Chad Versace <chadversary@chromium.org> Reviewed-by:
Tomasz Figa <tfiga@chromium.org>
-
- Feb 03, 2018
-
-
Lepton Wu authored
Add a new struct kms_sw_plane which delegate a plane and use it in place of sw_displaytarget. Multiple planes share same underlying kms_sw_displaytarget. For map request, we only hold 2 pointers for ro map and rw map and return different pointers with offset. Archived-At: https://lists.freedesktop.org/archives/mesa-dev/2017-December/180761.html (am from https://patchwork.freedesktop.org/patch/195118/ ) TEST=play video with youtube android app inside emulator. BUG=b:62836711 Signed-off-by:
Lepton Wu <lepton@chromium.org> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Change-Id: I0863f522976cc8863d6e95492d9346df35c066ec Reviewed-on: https://chromium-review.googlesource.com/843934
-
- Jan 31, 2018
-
-
Bas Nieuwenhuizen authored
-1 is considered an error for EGL_ANDROID_native_fence_sync, so we need to actually create a sync file. Fixes: f536f452 "radeonsi: implement sync_file import/export" Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 5a3404d4) BUG=b:72449616 TESTED=Try play store in ARC with 4.14 kernel on Kahlee. Change-Id: Ib053b640e70a0fe529e5cea84fd4144f93c8c588 Reviewed-on: https://chromium-review.googlesource.com/886703 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Benjamin Gordon <bmgordon@chromium.org> Reviewed-by:
Chad Versace <chadversary@chromium.org> Reviewed-by:
Benjamin Gordon <bmgordon@chromium.org>
-
- Jan 18, 2018
-
-
Francisco Jerez authored
Previously the dataflow propagation algorithm would calculate the ACP live-in and -out sets in a two-pass fixed-point algorithm. The first pass would update the live-out sets of all basic blocks of the program based on their live-in sets, while the second pass would update the live-in sets based on the live-out sets. This is incredibly inefficient in the typical case where the CFG of the program is approximately acyclic, because it can take up to 2*n passes for an ACP entry introduced at the top of the program to reach the bottom (where n is the number of basic blocks in the program), until which point the algorithm won't be able to reach a fixed point. The same effect can be achieved in a single pass by computing the live-in and -out sets in lock-step, because that makes sure that processing of any basic block will pick up the updated live-out sets of the lexically preceding blocks. This gives the dataflow propagation algorithm effectively O(n) run-time instead of O(n^2) in the acyclic case. The time spent in dataflow propagation is reduced by 30x in the GLES31.functional.ssbo.layout.random.all_shared_buffer.5 dEQP test-case on my CHV system (the improvement is likely to be of the same order of magnitude on other platforms). This more than reverses an apparent run-time regression in this test-case from my previous copy-propagation undefined-value handling patch, which was ultimately caused by the additional work introduced in that commit to account for undefined values being multiplied by a huge quadratic factor. According to Chad this test was failing on CHV due to a 30s time-out imposed by the Android CTS (this was the case regardless of my undefined-value handling patch, even though my patch substantially exacerbated the issue). On my CHV system this patch reduces the overall run-time of the test by approximately 12x, getting us to around 13s, well below the time-out. v2: Initialize live-out set to the universal set to avoid rather pessimistic dataflow estimation in shaders with cycles (Addresses performance regression reported by Eero in GpuTest Piano). Performance numbers given above still apply. No shader-db changes with respect to master. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104271 Reported-by:
Chad Versace <chadversary@chromium.org> Archived-At: https://lists.freedesktop.org/archives/mesa-dev/2017-December/180489.html (am from https://patchwork.freedesktop.org/patch/194420/) BUG=b:67394445 TEST=No regressions in Android CTS, GLES tests. Fixes timeouts in dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.5 on Brasswell boards. Change-Id: I0d666c23693246b8d4fe8988f228f8c4ed7425f6 Reviewed-on: https://chromium-review.googlesource.com/862007 Reviewed-by:
Stéphane Marchesin <marcheu@chromium.org> Reviewed-by:
Ilja H. Friedel <ihf@chromium.org> Tested-by:
Ilja H. Friedel <ihf@chromium.org>
-
- Jan 17, 2018
-
-
Francisco Jerez authored
This addresses a long-standing back-end compiler bug that could lead to cross-channel data corruption in loops executed non-uniformly. In some cases live variables extending through a loop divergence point (e.g. a non-uniform break) into a convergence point (e.g. the end of the loop) wouldn't be considered live along all physical control flow paths the SIMD thread could possibly have taken in between due to some channels remaining in the loop for additional iterations. This patch fixes the problem by extending the CFG with physical edges that don't exist in the idealized non-vectorized program, but represent valid control flow paths the SIMD EU may take due to the divergence of logical threads. This makes sense because the i965 IR is explicitly SIMD, and it's not uncommon for instructions to have an influence on neighboring channels (e.g. a force_writemask_all header setup), so the behavior of the SIMD thread as a whole needs to be considered. No changes in shader-db. Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 4d1959e6) This patch is a prerequisite for 4cbe48f5 "intel/fs: Optimize and simplify the copy propagation dataflow logic". BUG=b:67394445 TEST=No regressions in Android CTS, GLES tests. Change-Id: I949f6f4e0127fec93d890e7669f870872f097a58 Reviewed-on: https://chromium-review.googlesource.com/862006 Reviewed-by:
Stéphane Marchesin <marcheu@chromium.org> Reviewed-by:
Ilja H. Friedel <ihf@chromium.org> Tested-by:
Ilja H. Friedel <ihf@chromium.org> Commit-Queue: Chad Versace <chadversary@chromium.org>
-
Francisco Jerez authored
This makes the dataflow propagation logic of the copy propagation pass more intelligent in cases where the destination of a copy is known to be undefined for some incoming CFG edges, building upon the definedness information provided by the last patch. Helps a few programs, and avoids a handful shader-db regressions from the next patch. shader-db results on ILK: total instructions in shared programs: 6541547 -> 6541523 (-0.00%) instructions in affected programs: 360 -> 336 (-6.67%) helped: 8 HURT: 0 LOST: 0 GAINED: 10 shader-db results on BDW: total instructions in shared programs: 8174323 -> 8173882 (-0.01%) instructions in affected programs: 7730 -> 7289 (-5.71%) helped: 5 HURT: 2 LOST: 0 GAINED: 4 shader-db results on SKL: total instructions in shared programs: 8185669 -> 8184598 (-0.01%) instructions in affected programs: 10364 -> 9293 (-10.33%) helped: 5 HURT: 2 LOST: 0 GAINED: 2 Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 9355116b) This patch is a prerequisite for 4cbe48f5 "intel/fs: Optimize and simplify the copy propagation dataflow logic". BUG=b:67394445 TEST=No regressions in Android CTS, GLES tests. Change-Id: I8719e67ac14d3db8a7d6989d127ca4222cbdbfe4 Reviewed-on: https://chromium-review.googlesource.com/862005 Reviewed-by:
Stéphane Marchesin <marcheu@chromium.org> Reviewed-by:
Ilja H. Friedel <ihf@chromium.org> Tested-by:
Ilja H. Friedel <ihf@chromium.org> Commit-Queue: Chad Versace <chadversary@chromium.org>
-
Francisco Jerez authored
Currently the liveness analysis pass would extend a live interval up to the top of the program when no unconditional and complete definition of the variable is found that dominates all of its uses. This can lead to a serious performance problem in shaders containing many partial writes, like scalar arithmetic, FP64 and soon FP16 operations. The number of oversize live intervals in such workloads can cause the compilation time of the shader to explode because of the worse than quadratic behavior of the register allocator and scheduler when running out of registers, and it can also cause the running time of the shader to explode due to the amount of spilling it leads to, which is orders of magnitude slower than GRF memory. This patch fixes it by computing the intersection of our current live intervals with the subset of the program that can possibly be reached from any definition of the variable. Extending the storage allocation of the variable beyond that is pretty useless because its value is guaranteed to be undefined at a point that cannot be reached from any definition. According to Jason, this improves performance of the subgroup Vulkan CTS tests significantly (e.g. the runtime of the dvec4 broadcast test improves by nearly 50x). No significant change in the running time of shader-db (with 5% statistical significance). shader-db results on IVB: total cycles in shared programs: 61108780 -> 60932856 (-0.29%) cycles in affected programs: 16335482 -> 16159558 (-1.08%) helped: 5121 HURT: 4347 total spills in shared programs: 1309 -> 1288 (-1.60%) spills in affected programs: 249 -> 228 (-8.43%) helped: 3 HURT: 0 total fills in shared programs: 1652 -> 1597 (-3.33%) fills in affected programs: 262 -> 207 (-20.99%) helped: 4 HURT: 0 LOST: 2 GAINED: 209 shader-db results on BDW: total cycles in shared programs: 67617262 -> 67361220 (-0.38%) cycles in affected programs: 23397142 -> 23141100 (-1.09%) helped: 8045 HURT: 6488 total spills in shared programs: 1456 -> 1252 (-14.01%) spills in affected programs: 465 -> 261 (-43.87%) helped: 3 HURT: 0 total fills in shared programs: 1720 -> 1465 (-14.83%) fills in affected programs: 471 -> 216 (-54.14%) helped: 4 HURT: 0 LOST: 2 GAINED: 162 shader-db results on SKL: total cycles in shared programs: 65436248 -> 65245186 (-0.29%) cycles in affected programs: 22560936 -> 22369874 (-0.85%) helped: 8457 HURT: 6247 total spills in shared programs: 437 -> 437 (0.00%) spills in affected programs: 0 -> 0 helped: 0 HURT: 0 total fills in shared programs: 870 -> 854 (-1.84%) fills in affected programs: 16 -> 0 helped: 1 HURT: 0 LOST: 0 GAINED: 107 Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit c3c1aa5a) This patch is a prerequisite for 4cbe48f5 "intel/fs: Optimize and simplify the copy propagation dataflow logic". BUG=b:67394445 TEST=No regressions in Android CTS, GLES tests. Change-Id: Icbe71f099618e45098a61502b79f3694bcc49877 Reviewed-on: https://chromium-review.googlesource.com/862004 Reviewed-by:
Stéphane Marchesin <marcheu@chromium.org> Reviewed-by:
Ilja H. Friedel <ihf@chromium.org> Tested-by:
Ilja H. Friedel <ihf@chromium.org> Commit-Queue: Chad Versace <chadversary@chromium.org>
-
- Jan 16, 2018
-
-
Francisco Jerez authored
This should allow the post-RA scheduler to do a slightly better job at hiding latency in presence of instructions incurring bank conflicts. The main purpuse of this patch is not to improve performance though, but to get conflict cycles to show up in shader-db statistics in order to make sure that regressions in the bank conflict mitigation pass don't go unnoticed. Acked-by:
Matt Turner <mattst88@gmail.com> (cherry picked from commit acf98ff9) This patch is a prerequisite for 4cbe48f5 "intel/fs: Optimize and simplify the copy propagation dataflow logic". BUG=b:67394445 TEST=No regressions in Android CTS, GLES tests. Change-Id: Ie10e8bf2116b28a637fd7a3829a44a00b2867f11 Reviewed-on: https://chromium-review.googlesource.com/862003 Commit-Ready: Chad Versace <chadversary@chromium.org> Tested-by:
Ilja H. Friedel <ihf@chromium.org> Reviewed-by:
Ilja H. Friedel <ihf@chromium.org> Reviewed-by:
Stéphane Marchesin <marcheu@chromium.org>
-
Francisco Jerez authored
Unnecessary GRF bank conflicts increase the issue time of ternary instructions (the overwhelmingly most common of which is MAD) by roughly 50%, leading to reduced ALU throughput. This pass attempts to minimize the number of bank conflicts by rearranging the layout of the GRF space post-register allocation. It's in general not possible to eliminate all of them without introducing extra copies, which are typically more expensive than the bank conflict itself. In a shader-db run on SKL this helps roughly 46k shaders: total conflicts in shared programs: 1008981 -> 600461 (-40.49%) conflicts in affected programs: 816222 -> 407702 (-50.05%) helped: 46234 HURT: 72 The running time of shader-db itself on SKL seems to be increased by roughly 2.52%1.13% with n=20 due to the additional work done by the compiler back-end. On earlier generations the pass is somewhat less effective in relative terms because the hardware incurs a bank conflict anytime the last two sources of the instruction are duplicate (e.g. while trying to square a value using MAD), which is impossible to avoid without introducing copies. E.g. for a shader-db run on SNB: total conflicts in shared programs: 944636 -> 623185 (-34.03%) conflicts in affected programs: 853258 -> 531807 (-37.67%) helped: 31052 HURT: 19 And on BDW: total conflicts in shared programs: 1418393 -> 987539 (-30.38%) conflicts in affected programs: 1179787 -> 748933 (-36.52%) helped: 47592 HURT: 70 On SKL GT4e this improves performance of GpuTest Volplosion by 3.64% 0.33% with n=16. NOTE: This patch intentionally disregards some i965 coding conventions for the sake of reviewability. This is addressed by the next squash patch which introduces an amount of (for the most part boring) boilerplate that might distract reviewers from the non-trivial algorithmic details of the pass. The following patch is squashed in: SQUASH: intel/fs/bank_conflicts: Roll back to the nineties. Acked-by:
Matt Turner <mattst88@gmail.com> (cherry picked from commit af2c3201) This patch is a prerequisite for 4cbe48f5 "intel/fs: Optimize and simplify the copy propagation dataflow logic". BUG=b:67394445 TEST=No regressions in Android CTS, GLES tests. Change-Id: I21b0563b3855434a702989fbc947b786c486f7e3 Reviewed-on: https://chromium-review.googlesource.com/862002 Commit-Ready: Chad Versace <chadversary@chromium.org> Tested-by:
Ilja H. Friedel <ihf@chromium.org> Reviewed-by:
Ilja H. Friedel <ihf@chromium.org> Reviewed-by:
Stéphane Marchesin <marcheu@chromium.org>
-
- Dec 15, 2017
-
-
Bas Nieuwenhuizen authored
We never supported it. Missed during copy and pasting. Fixes: 17201a2e "radv: port to using updated anv entrypoint/extension generator." Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry-picked from 4eb0dca4) BUG=b:67506532 TEST=run vkinfo on kahlee Change-Id: I09f5053383cc9eded33510c24f953b496383f798 Reviewed-on: https://chromium-review.googlesource.com/827017 Commit-Ready: Bas Nieuwenhuizen <basni@chromium.org> Tested-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
Kristian H. Kristensen <hoegsberg@chromium.org>
-
- Nov 30, 2017
-
-
Not to be confused with variablePointersStorageBuffer which is the subset of VK_KHR_variable_pointers required to enable the extension. This means we now have "full" support for variable pointers. Archived-At: https://lists.freedesktop.org/archives/mesa-dev/2017-October/173537.html (am from https://patchwork.freedesktop.org/patch/183830/) Needed for SPIR-V VariablePointers capability. Testing: Tests for this feature were released in Vulkan CTS 1.0.2.4 on 2017-07-11, and were later merged into the oreo branches of deqp. But in that release some testcases were buggy, causing some drivers to crash. In particular, the bugs crashed Anvil. All but one of the required fixes have landed in vk-gl-cts master@e52de55c. The last fix is still under review in Khronos's internal Gerrit as https://gerrit.khronos.org/#/c/1864/. I've pushed a public vk-gl-cts branch[1] containing the remaining fix, and tagged[2] the vk-gl-cts commit I tested against. Likewise for Mesa, I tagged[3] the commit I tested, based on branch cros/arc-17.3. Android is hard. Running the Oreo CTS on Nougat is even harder. I confirmed that some testcases for this feature passed when running the Oreo CTS on ARC++ Nougat, though the CTS eventually crashed due to the reasons explained above. I verified everything on Fedora instead. All 949 of the following tests passed: dEQP-VK.spirv_assembly.instruction.compute.variable_pointers.* dEQP-VK.spirv_assembly.instruction.graphics.variable_pointers.* [1]: http://git.kiwitree.net/cgit/~chadv/vk-gl-cts/log/?h=fixes/spirv-variable-pointers [2]: http://git.kiwitree.net/cgit/~chadv/vk-gl-cts/log/?h=chadv/test/spirv-variable-pointers-2017-11-29 [3]: http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=chadv/test/arc-17.3-anv-variable-pointers-2017-11-29 BUG=b:68708929 TEST=No regressions on Eve in `cts-tradefed run cts -m CtsDeqpTestCases`. Change-Id: I93f94a0d5f976575826397d60b42d3b11a919269 Reviewed-on: https://chromium-review.googlesource.com/799681 Tested-by:
Chad Versace <chadversary@chromium.org> Reviewed-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Commit-Queue: Kristian H. Kristensen <hoegsberg@chromium.org>
-
Before, we always left workgroup variables as shared nir_variables and let the driver call nir_lower_io. This adds an option to do the lowering directly in spirv_to_nir. To do this, we implicitly assign the variables a std430 layout and then treat them like a UBO or SSBO and immediately lower all the way to an offset. As a side-effect, the spirv_to_nir pass now handles variable pointers for workgroup variables. Archived-At: https://lists.freedesktop.org/archives/mesa-dev/2017-October/173534.html (am from https://patchwork.freedesktop.org/patch/183827/) Needed for SPIR-V VariablePointers capability. BUG=b:68708929 TEST=No regressions on Eve in `cts-tradefed run cts -m CtsDeqpTestCases`. Change-Id: Ibdfb71194fd43fe899a71e7da162ee0633d2d11a Reviewed-on: https://chromium-review.googlesource.com/799680 Tested-by:
Chad Versace <chadversary@chromium.org> Reviewed-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Commit-Queue: Kristian H. Kristensen <hoegsberg@chromium.org>
-
Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Archived-At: https://lists.freedesktop.org/archives/mesa-dev/2017-October/173536.html (am from https://patchwork.freedesktop.org/patch/183829/) Needed for SPIR-V VariablePointers capability. BUG=b:68708929 TEST=No regressions on Eve in `cts-tradefed run cts -m CtsDeqpTestCases`. Change-Id: I096da96d15e7536b5536aa9f5d527ce8c47e9eaa Reviewed-on: https://chromium-review.googlesource.com/799679 Tested-by:
Chad Versace <chadversary@chromium.org> Reviewed-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Commit-Queue: Kristian H. Kristensen <hoegsberg@chromium.org>
-