Scaling between interlaced buffers, esp. for scale-up, because
blit will scale up top filed and bottom field separately. it'll
result in the weaving for these buffer with lack of accuracy.
So use shader deint for the case.
Acked-by: Christian König <christian.koenig@amd.com>
Before it's impossible to transcode an interlaced video, becasue if
in order for encoder to work, we have to force buffer to progessive,
but the deint with buffer from I to P is missing. Now along With
the new YUV deint full function, it works with weave and bob deint.
Also this will benefit transcoding video with scaling parameters.
Acked-by: Christian König <christian.koenig@amd.com>
We also set src rectangle explicitly just in case of the mismatch
of size between interlaced buffer and progressive buffer
Acked-by: Christian König <christian.koenig@amd.com>
Spec adding corner cases ...
Fixes: 969537d935 "radv: Add support for more DCC compression with VK_KHR_image_format_list."
Reviewed-by: Dave Airlie <airlied@redhat.com>
I tested this 10 times with
./deqp-vk --deqp-case=dEQP-VK.texture.filtering.3d.formats.r4g4b4a4*
and one full run of CTS, seems the issue is gone.
Also reduces CTS runtime by 30% or so.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
These changes were generated using python's `2to3` tool.
Suggested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
These changes were generated using python's `2to3` tool.
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
These changes were generated using python's `2to3` tool.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102852
Reported-by: Alex Granni <liviuprodea@yahoo.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Otherwise, the disasm string is NULL for meta shaders.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
In Vulkan, for 'z' (depth) component, the scale and translate values
for the viewport transformation are:
pz = maxDepth - minDepth
oz = minDepth
zf = pz × zd + oz
Being zd, the third component in vertex's normalized device coordinates.
Fixes: dEQP-VK.draw.inverted_depth_ranges.*
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: mesa-stable@lists.freedesktop.org
Not quite asciibetical: ARB, then EXT, then vendor, just like the GL
extension enum just below. No functional change, but it bothered me.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Add missing includes after 6ace0b8 (etnaviv: don't enable RT
full-overwrite when logicop is enabled), otherwise the etnaviv driver
won't build because of missing macros.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Andres Gomez <agomez@igalia.com>
util_pack_color may leave undefined values in the upper half of the packed
integer. As our hardware needs the upper 16 bits to mirror the lower 16bits,
this breaks clears of those formats if the undefined values aren't masked off.
I've only observed the issue with R5G6B5_UNORM surfaces, other 16bpp
formats seem to work fine.
Fixes: d6aa2ba2b2 (etnaviv: replace translate_clear_color with util_pack_color)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
We currently don't use these instructions, and since their API
changed in llvm-5.0 having them in the autogen files broke the mesa
release tarballs which ship with generated autogen files.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102847
CC: mesa-stable@lists.freedesktop.org
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
While using iterparse is potentially a little more efficient, the Vulkan
registry XML is not large and using regular element tree simplifies the
parsing logic substantially.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
New extensions can introduce additional enums. Most of the new enums
will have disjoint numbers from the initial enums. For example new
formats introduced by VK_IMG_format_pvrtc :
VK_FORMAT_ASTC_10x8_UNORM_BLOCK = 177,
VK_FORMAT_ASTC_10x8_SRGB_BLOCK = 178,
VK_FORMAT_ASTC_10x10_UNORM_BLOCK = 179,
VK_FORMAT_ASTC_10x10_SRGB_BLOCK = 180,
VK_FORMAT_ASTC_12x10_UNORM_BLOCK = 181,
VK_FORMAT_ASTC_12x10_SRGB_BLOCK = 182,
VK_FORMAT_ASTC_12x12_UNORM_BLOCK = 183,
VK_FORMAT_ASTC_12x12_SRGB_BLOCK = 184,
VK_FORMAT_PVRTC1_2BPP_UNORM_BLOCK_IMG = 1000054000,
VK_FORMAT_PVRTC1_4BPP_UNORM_BLOCK_IMG = 1000054001,
VK_FORMAT_PVRTC2_2BPP_UNORM_BLOCK_IMG = 1000054002,
VK_FORMAT_PVRTC2_4BPP_UNORM_BLOCK_IMG = 1000054003,
VK_FORMAT_PVRTC1_2BPP_SRGB_BLOCK_IMG = 1000054004,
VK_FORMAT_PVRTC1_4BPP_SRGB_BLOCK_IMG = 1000054005,
VK_FORMAT_PVRTC2_2BPP_SRGB_BLOCK_IMG = 1000054006,
VK_FORMAT_PVRTC2_4BPP_SRGB_BLOCK_IMG = 1000054007,
It's obvious we can't have a single table for handling those anymore.
Fortunately the enum values actually contain the number of the
extension that introduced the new enums. So we can build an
indirection table off the extension number and then index by
subtracting the first enum of the the format enum value.
This change makes the extension number available in the generated enum
code.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
It will be used to store extension numbers as well.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
They are now provided by -latomic, which should be linked as needed
since previous commit.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
On some platforms, gcc generates library calls when __atomic_* functions
are used, but does not link the required library (libatomic) automatically
(supposedly to allow the app to use some other atomics implementation?).
Detect this at configure time and add the library when needed. Tested
on armel (library was added) and on x86_64 (was not, as expected).
Some documentation on this is provided in GCC wiki:
https://gcc.gnu.org/wiki/Atomic/GCCMM
Fixes: 8915f0c0 "util: use GCC atomic intrinsics with explicit memory model"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102573
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Logicop is a form of blending with the framebuffer, so we must allow
framebuffer reads when logicop is enabled.
Fixes: piglit gl-1.0-logicop on GC3000, which has logicop support
Signed-off-by: Lucas Stach <dev@lynxeye.de>
drm-intel is in favor of keeping the unused pci-id's which
are still listed in the h/w specs. To keep it uniform
across multiple gfx stack components, I'm reverting below
Mesa patches:
b2dae9f8fdebc5ccf3cc.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This is not used anywhere in the codebase. It's a hashtable
implementation that is based around cso_hash, and is therefore
(and as mentioned in a comment in the source) quite similar to
u_hash_table.
CC: Brian Paul<brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
If transform feedback is recording a varying, it needs a slot in the
VUE map, regardless of whether or not the shader writes it.
Together with the previous patch, this fixes:
- KHR-GL45.enhanced_layouts.xfb_capture_struct
The test captures a structure where the vertex shader writes the first
and third members - but the second still needs a slot.
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
unify_interfaces() only updates the NIR program info, not the copy
in the gl_program itself. So, by using the old copy, we were missing
out on these updates.
The TCS/TES ones already did this correctly.
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
This can occur if the shader is capturing some of the values from the
VUE header for transform feedback, but the shader hasn't written all of
them.
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
brw_finish_batch emits commands needed at the end of every batch buffer,
including any workarounds. In the past, we freed up some "reserved"
batch space before calling it, so we would never have to flush during
it. This was error prone and easy to screw up, so I deleted it a while
back in favor of growing the batch.
There were two problems:
1. We're in the middle of flushing, so brw->no_batch_wrap is guaranteed
not to be set. Using BEGIN_BATCH() to emit commands would cause a
recursive flush rather than growing the buffer as intended.
2. We already recorded the throttling batch before growing, which
replaces brw->batch.bo with a different (larger) buffer. So growing
would break throttling.
These are easily remedied by shuffling some code around and whacking
brw->no_batch_wrap in brw_finish_batch(). This also now includes the
final workarounds in the batch usage statistics. Found by inspection.
Fixes: 2c46a67b41 (i965: Delete BATCH_RESERVED handling.)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested with AMD's Anvil OutOfOrderRasterization demo on a RX 560.
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Fixes quite a few 'texwrap [12]d border color only' tests on NV20
(10de:0201). All told, 40 more tests pass.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian RomanicK <ian.d.romanick@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Ian RomanicK <ian.d.romanick@intel.com>
v2: Force T and R wrap modes to GL_CLAMP_TO_EDGE for 1D textures.
This fixes a regression in tex1d-2dborder. The test uses a 1D texture
but it provides S and T texture coordinates. Since the T wrap mode
would (correctly) be set to GL_CLAMP, the texture would gradually
blend (incorrectly) with the border color.
I also tried setting NV20_3D_TEX_FORMAT_DIMS_1D instead of
NV20_3D_TEX_FORMAT_DIMS_2D for 1D textures, but that did not help.
It is possible that the same problem exists for 2D textures with the
R-wrap mode, but I don't think there are any piglit tests for that.
No test changes on NV20 (10de:0201).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Denotes availability of 64bit int atomic instructions
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Leo Liu
Bas Nieuwenhuizen
Eric Engestrom
Samuel Pitoiset
Samuel Iglesias Gonsálvez
David Airlie
Adam Jackson
Wladimir J. van der Laan
Lucas Stach
Tim Rowley
Jason Ekstrand
Lionel Landwerlin
Grazvydas Ignotas
Lucas Stach
Anuj Phogat
Thomas Helland
Kenneth Graunke
Nicholas Miell
Brian Paul
Ilia Mirkin
Ian Romanick
Jan Vesely