- 21 Jun, 2019 6 commits
-
-
Tomeu Vizoso authored
These three tests pass on RK3399, but fail on RK3288: dEQP-GLES2.functional.shaders.matrix.div.const_lowp_mat2_mat2_vertex dEQP-GLES2.functional.shaders.operator.unary_operator.pre_increment_effect.highp_ivec4_vertex dEQP-GLES2.functional.shaders.texture_functions.vertex.texture2dprojlod_vec3 They reliably pass when run individually, but reliably fail when run in a full CI run. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com>
-
Gert Wollny authored
Signed-off-by:
Gert Wollny <gert.wollny@collabora.com> Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
Iago Toral Quiroga authored
This can happen when any of our vertex buffers was written by a previous transform feedback draw. Fixes the following piglit tests: spec/ext_transform_feedback/position-render-bufferbase spec/ext_transform_feedback/position-render-bufferbase-discard spec/ext_transform_feedback/position-render-bufferoffset spec/ext_transform_feedback/position-render-bufferoffset-discard spec/ext_transform_feedback/position-render-bufferrange spec/ext_transform_feedback/position-render-bufferrange-discard Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Iago Toral Quiroga authored
If we are about to write to a transform feedback buffer, we should make sure that we flush any prior work that intended to read from any of these buffers. Fixes piglit test: spec/ext_transform_feedback/immediate-reuse Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Iago Toral Quiroga authored
v2: We should be safe assuming that bind_vs != NULL (Eric) Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Dave Airlie authored
this isn't used outside this file. Reviewed-by:
Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by:
Roland Scheidegger <sroland@vmware.com>
-
- 20 Jun, 2019 34 commits
-
-
Eric Engestrom authored
Fixes: 31696470 "util: add os_read_file() helper" Reported-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Reviewed-by:
Tapani Pälli <tapani.palli@intel.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net>
-
Tomeu Vizoso authored
These tests have been fixed recently. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com>
-
Alyssa Rosenzweig authored
Fixes regression in shaders using ball/etc by explicitly passing through the number of channels in the NIR op and broadcasting the last components of the channel appropriately, as the Midgard ops are all vec4 implicitly but NIR can be vec2/3. v2: Don't also regress every other swizzle in Equestria. v3: Don't regress the swizzles at Canterlot High either. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Acked-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com>
-
Kenneth Graunke authored
Most vertex data lives in user VBOs in IRIS_MEMZONE_OTHER, which typically have high bits set to 0xffff. The shader draw parameters were being uploaded in IRIS_MEMZONE_DYNAMIC, which have high bets set to 0x2. This was causing a lot of ping-ponging of high bits, leading to unnecessary VF cache flushing. Cuts 7.2% of the flushes in the Civizilation VI demo on Kabylake GT2.
-
Kenneth Graunke authored
If there is no buffer, then it doesn't matter. Leave the old stale high bits in place (for next time) and don't bother invalidating. Cuts 5.6% of the flushes in the Civilization VI demo on Kabylake GT2.
-
Kenneth Graunke authored
These write depth and stencil, not color writes, so there's no need to flush the render target.
-
Kenneth Graunke authored
If a buffer has no usage history, we don't have any read only cache invalidates to do. If we've written it with the CPU, we don't need to flush the render cache. The only bit remaining is the CS stall from iris_flush_bits_for_history. We can just skip the PIPE_CONTROL in this case. This is pretty common - an app creates a buffer, fills it with data, and then binds it for some purpose. Cuts 36% of the flushes in Manhattan 3.0 on Kabylake GT2.
-
Kenneth Graunke authored
If we wrote the data via the CPU, there's no point in doing a render target flush. If using BLORP, we do want a render target flush so the data lands.
-
Kenneth Graunke authored
Instead of using the combined iris_flush_and_dirty_for_history, use iris_flush_bits_for_history directly - we were already using the split out iris_dirty_for_history. There's no need to dirty twice, and we can avoid the looping altogether for non-buffers.
-
Kenneth Graunke authored
My intention was to have iris_copy_region not do flushing, and leave that up to the callers. iris_resource_copy_region needs to do this, but iris_transfer_flush_region was already doing it. The net result was that we were doing it twice for transfers. So, move the flushing from iris_copy_region to iris_resource_copy_region so that it only happens in the callers as I intended.
-
Kenneth Graunke authored
When I split iris_flush_and_dirty_history into two helper functions, I accidentally made it stop dirtying. Which was...sort of the point. Fixes: 21688a30 iris: Split iris_flush_and_dirty_for_history into two helpers.
-
Kenneth Graunke authored
Otherwise, tests which loop on glMemoryBarrier may run us out of batch space with piles of flushing. (Ideally, we'd elide those bonus PIPE_CONTROLs, but presumably this isn't that common of a case...) Piglit's arb_pipeline_statistics_query-comp would hit this case after some of the next patches remove other PIPE_CONTROLs with maybe_flushes.
-
Kenneth Graunke authored
This prints a log of every PIPE_CONTROL flush we emit, noting which bits were set, and also the reason for the flush. That way we can see which are caused by hardware workarounds, render-to-texture, buffer updates, and so on. It should make it easier to determine whether we're doing too many flushes and why.
-
Alyssa Rosenzweig authored
Looking at the scissor, we can discard some tiles. We specifially don't care about the scissor on the wallpaper, since that's a no-op if the entire tile is culled. v2: Clarify clear comment (not reviewed but trivial). Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com>
-
Eric Engestrom authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110709 Fixes: 22a9e00a ("glx: Implement the libglvnd interface.") Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Eric Engestrom authored
This `gen_scrn_dispatch.pl` has never existed, in the sense that NVIDIA never published it. There have been a number (6) of commits to fix various things in there over the years, and never anything from NVIDIA. For all intents and purposes this file is hand-written and hand-maintained, and we're on our own. Let's make this clear by removing this misleading comment. Suggested-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Acked-by:
Emil Velikov <emil.velikov@collabora.com>
-
Boris Brezillon authored
We don't expect the output of a TXS instruction to be wider than a vec3. Add an assert() to make sure this never happens. Suggested-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Tomeu Vizoso authored
Right now we are doing it at a moment when we don't have all the information we need. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Suggested-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Acked-by:
Rohan Garg <rohan.garg@collabora.com> Cc: Rohan Garg <rohan.garg@collabora.com> Fixes: bfca21b6 ("panfrost: Figure out job requirements in pan_job.c")
-
Alyssa Rosenzweig authored
Fixes: 035a07c0 ("panfrost: Switch to lima tiling") Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Hyunjun Ko authored
Fixes: a9b556d3 ("freedreno/ir3: check the type of regs of absneg opcode in is_same_type_mov") Reviewed-by:
Rob Clark <robdclark@gmail.com>
-
Alyssa Rosenzweig authored
Now that we have lima tiling code available, use it to load from a tiled source. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
Lima and Panfrost both have implementations of software tiling (the Lima one was forked off the Panfrost one which was forked off the original Lima one...). Switch to the most recent Lima code, since it's more complete than ours at this point. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
Panfrost's tiling routines (incorrectly) ignored the source stride, masking this bug; lima's routines respect this stride, causing issues when tiling NPOT textures whose stride is not a multiple of 64 (for instance, NPOT textures with bpp=1). Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
This will allow both drivers to share this code. Both drivers build-tested with meson. Android build not tested. v2: Change naming from tiling->shared, in case Lima and Panfrost can share more in the future. Fix Android build system. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-and-tested-by:
Qiang Yu <yuq825@gmail.com>
-
Kenneth Graunke authored
We have them, may as well use them.
-
Lionel Landwerlin authored
We can rely on only one kind of synchronization object (drm-syncobj) when it is available. This reduces the number of file descriptors we use in our implementation. This will be required later for timeline semaphores implementation, at this point we won't ever want to use anything else but syncobjs. v2: Only use has_syncobj for semaphores (Jason) v3: Only has_syncobj in assert on semaphores in QueueSubmit (Jason) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net>
-
Alyssa Rosenzweig authored
Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
These do more harm than good at this point. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
This is all zero for anything but fragment shaders. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
Looking at internal evidence (later fields including a literal other compute job inception-style, seeming memory corruption, no clear function, and the field after this being a pointer to *itself*), it looks like this is really a much smaller descriptor. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
In OpenGL, uniforms generally represent fp32 vec4s (at least in highp mode). In OpenCL, they represent vec2s of 64-bit pointers. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Alyssa Rosenzweig authored
Float is ambiguous. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-