Michal Srb [Fri, 23 Nov 2018 15:02:27 +0000 (16:02 +0100)]
gallium: Constify drisw_loader_funcs struct
The content is not expected to change.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Michal Srb <msrb@suse.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Samuel Pitoiset [Wed, 5 Dec 2018 10:45:19 +0000 (11:45 +0100)]
radv: wait on the high 32 bits of timestamp queries
In case we are unlucky if the low part is 0xffffffff.
Fixes: 5d6a560a29 ("radv: do not use the availability bit for timestamp queries")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Wed, 5 Dec 2018 10:34:39 +0000 (11:34 +0100)]
radv: reset pending_reset_query when flushing caches
If the driver used a compute shader for resetting a query pool,
it should be completed when caches are flushed.
This might reduce the number of stalls if operations are done
between vkCmdResetQueryPool() and vkCmdBeginQuery()
(or vkCmdWriteTimestamp()).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Alex Smith <asmith@feralinteractive.com>
Lionel Landwerlin [Mon, 3 Dec 2018 14:33:35 +0000 (14:33 +0000)]
anv/query: flush render target before copying results
This change tracks render target writes in the pipeline and applies a
render target flush before copying the query results to make sure the
preceding operations have landed in memory before the command streamer
initiates the copy.
v2: Simplify logic in CopyQueryResults (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108909
Fixes: 37f9788e9a8e44 ("anv: flush pipeline before query result copies")
Cc: mesa-stable@lists.freedesktop.org
Alex Smith [Wed, 5 Dec 2018 09:45:26 +0000 (09:45 +0000)]
radv: Flush before vkCmdWriteTimestamp() if needed
As done for vkCmdBeginQuery() already. Prevents timestamps from being
overwritten by previous vkCmdResetQueryPool() calls if the shader path
was used to do the reset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108925
Fixes: a41e2e9cf5 ("radv: allow to use a compute shader for resetting the query pool")
Signed-off-by: Alex Smith <asmith@feralinteractive.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Samuel Pitoiset [Mon, 3 Dec 2018 21:45:03 +0000 (22:45 +0100)]
radv: rework the TC-compat HTILE hardware bug with COND_EXEC
After investigating on this, it appears that COND_WRITE doesn't
work correctly in some situations. I don't know exactly why does
it fail to update DB_Z_INFO.ZRANGE_PRECISION, but as AMDVLK
also uses COND_EXEC I think there is a reason.
Now the driver stores a new metadata value in order to reflect
the last fast depth clear state. If a TC-compat HTILE is fast cleared
with 0.0f, we have to update ZRANGE_PRECISION to 0 in order to
work around that hardware bug.
This fixes rendering issues with The Forest and DXVK and doesn't
seem to introduce any regressions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108914
Fixes: 68dead112e7 ("radv: update the ZRANGE_PRECISION value for the TC-compat bug")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Dieter Nützel [Tue, 4 Dec 2018 21:20:10 +0000 (22:20 +0100)]
docs/features: Delete double nv50 entry and wrong enumeration
trivial
Fix commit
d9b2234042142dc02a4844747d3c35e140da53dc
Signed-off-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Marek Olšák [Thu, 29 Nov 2018 20:34:05 +0000 (15:34 -0500)]
st/mesa: expose EXT_render_snorm on GLES
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Marek Olšák [Mon, 6 Aug 2018 06:48:12 +0000 (02:48 -0400)]
mesa: expose AMD_texture_texture4
because the closed driver exposes it. Tested by piglit.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Marek Olšák [Mon, 6 Aug 2018 04:29:00 +0000 (00:29 -0400)]
mesa: expose EXT_texture_compression_bptc in GLES
tested by piglit.
v2: rebase
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (v1)
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Marek Olšák [Mon, 6 Aug 2018 02:50:54 +0000 (22:50 -0400)]
mesa: expose EXT_texture_compression_rgtc on GLES
The spec was modified to support GLES. Tested by piglit.
v2: rebase
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (v1)
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Erik Faye-Lund [Tue, 4 Dec 2018 11:34:39 +0000 (12:34 +0100)]
mesa/main: fix up _mesa_has_rg_textures for gles2
rg-textures are supported in GLES 2.0 if EXT_texture_rg, so let's make
sure the enums are accepted.
Fixes: 510b6424607 "mesa/main: do not allow rg-textures enums before gles3"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108936
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Mon, 3 Dec 2018 19:00:34 +0000 (20:00 +0100)]
mesa/main: correct validation for GL_RGB565
Technically speaking, this validation was incorrect, because GL_RGB565
is only supported in OpenGL ES 1.x if OES_framebuffer_object is
supported. This couldn't lead to any real incorrect behavior, because
all drivers support OES_framebuffer_object. But let's keep the code
self-documenting, by correcting the check as per the spec.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Marek Olšák [Wed, 28 Nov 2018 01:42:44 +0000 (20:42 -0500)]
mesa: expose GL_EXT_texture_view as an alias of GL_OES_texture_view
There are no spec changes.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Marek Olšák [Wed, 28 Nov 2018 01:19:11 +0000 (20:19 -0500)]
st/mesa: expose GL_OES_texture_view
For format fallbacks like ETC and ASTC, switching between sRGB and linear
decoding is undefined, or at least is not bit-exact. Same as
EXT_texture_sRGB_decode on GLES.
There are no piglit or dEQP regresssions.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Eric Engestrom [Fri, 16 Nov 2018 12:26:17 +0000 (12:26 +0000)]
loader: deduplicate logger function declaration
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Eric Engestrom [Wed, 7 Nov 2018 12:30:36 +0000 (12:30 +0000)]
mesa: drop unused & deprecated lib
DeprecationWarning: the imp module is deprecated in favour of importlib
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Eric Engestrom [Tue, 4 Dec 2018 13:19:20 +0000 (13:19 +0000)]
anv: add unreachable() for VK_EXT_fragment_density_map
This silences the -Wswitch compiler warning.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Eric Engestrom [Thu, 29 Nov 2018 11:50:30 +0000 (11:50 +0000)]
meson: skip asm check when asm is disabled
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Andrii Simiklit [Wed, 14 Nov 2018 16:30:48 +0000 (18:30 +0200)]
intel/tools: make sure the binary file is properly read
1. tools/i965_disasm.c:58:4: warning:
ignoring return value of ‘fread’,
declared with attribute warn_unused_result
fread(assembly, *end, 1, fp);
v2: Fixed incorrect return value check.
( Eric Engestrom <eric.engestrom@intel.com> )
v3: Zero size file check placed before fread with exit()
( Eric Engestrom <eric.engestrom@intel.com> )
v4: - Title is changed.
- The 'size' variable was moved to top of a function scope.
- The assertion was replaced by the proper error handling.
- The error message on a caller side was fixed.
( Eric Engestrom <eric.engestrom@intel.com> )
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Toni Lönnberg [Tue, 4 Dec 2018 12:14:51 +0000 (14:14 +0200)]
intel/aubinator_error_decode: Get rid of warning for missing switch case
../src/intel/tools/aubinator_error_decode.c: In function ‘instdone_register_for_ring’:
../src/intel/tools/aubinator_error_decode.c:177:4: warning: enumeration value ‘I915_ENGINE_CLASS_INVALID’ not handled in switch [-Wswitch]
switch (class) {
^~~~~~
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Ilia Mirkin [Sun, 2 Dec 2018 22:08:03 +0000 (17:08 -0500)]
nouveau: set texture upload budget
It doesn't seem like the exact number has too much effect on the
performaince in "teximage". However setting it to just about anything
prevents some OOMs from getting hit. These values are not well-tuned,
but don't seem too bad.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Ilia Mirkin [Sun, 2 Dec 2018 04:53:00 +0000 (23:53 -0500)]
nv50,nvc0: add explicit handling of PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET
Since the max attrib stride is 2048, the max src offset makes sense as
2047.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Ilia Mirkin [Sun, 2 Dec 2018 02:28:04 +0000 (21:28 -0500)]
nv50: always keep TSC slot 0 bound
All TXF operations implicitly use sampler 0, and fail if it's not bound
to anything. This does not happen in LINKED_TSC mode, but we don't
currently use this.
We ensure that TSC entry at id 0 has the SRGB conversion bit enabled
(and all samplers we normally generate will too). Then when the TSC at
*slot* 0 (not to be confused with entry 0 in the global TSC table) is
unbound, we bind it to entry 0. This way, TXF operations are not
dependent on there being a regular sampler bound there.
Fixes arb_texture_buffer_object-subdata-sync among others. (TBO's are
particularly susceptible to this as they don't bind a sampler.)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Dave Airlie [Mon, 3 Dec 2018 04:38:28 +0000 (14:38 +1000)]
radv: use 3d shader for gfx9 copies if dst is 3d
This fixes some crucible 3d miptree tests I've been working on
when executed using the compute shader path.
Fixes: d08f267814 (radv/gfx9: fix 3d image to image transfers on compute queues.)
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Bas Nieuwenhuizen [Mon, 26 Nov 2018 15:26:37 +0000 (16:26 +0100)]
radv: Check for shareable images in central place.
One place to put the logic makes things easier to change.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Bas Nieuwenhuizen [Mon, 26 Nov 2018 15:26:36 +0000 (16:26 +0100)]
radv/android: Use buffer metadata to determine scanout compat.
These days we don't always allocate scanout compatible textures anymore.
That does mean we have to fix the radv android WSI though.
Fixes: b1444c9ccb0 "radv: Implement VK_ANDROID_native_buffer."
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Bas Nieuwenhuizen [Mon, 26 Nov 2018 15:26:35 +0000 (16:26 +0100)]
radv/android: Mark android WSI image as shareable.
Fixes: b1444c9ccb0 "radv: Implement VK_ANDROID_native_buffer."
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Matt Turner [Tue, 4 Dec 2018 00:20:43 +0000 (16:20 -0800)]
Revert "st/mesa: silenced unhanded enum warning in st_glsl_to_tgsi.cpp"
This reverts commit
198c50f4873758e9f64d89eea262af5dd1644df9.
This needs to be reverted after commit
017199d2d2e4 ("mesa: Revert
INTEL_fragment_shader_ordering support")
Matt Turner [Thu, 29 Nov 2018 23:46:18 +0000 (15:46 -0800)]
mesa: Revert INTEL_fragment_shader_ordering support
This extension is not properly tested (testing for
GL_ARB_fragment_shader_interlock is not sufficient), and since this was
noted in review on August 28th no tests have been sent.
Revert "i965: Add INTEL_fragment_shader_ordering support."
Revert "mesa: Add GL/GLSL plumbing for INTEL_fragment_shader_ordering"
This reverts commit
03ecec9ed2099f6e2b62994b33dc948dc731e7b8.
This reverts commit
119435c8778dd26cb7c8bcde9f04b3982239fe60.
Cc: mesa-stable@lists.freedesktop.org
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Eric Anholt <eric@anholt.net>
Dave Airlie [Mon, 3 Dec 2018 22:11:13 +0000 (08:11 +1000)]
virgl: fix const warning on debug flags.
Fixes: 8d4bb6e5c (virgl: Add command and flags to initiate debugging on the host (v2))
Jason Ekstrand [Mon, 3 Dec 2018 16:06:21 +0000 (10:06 -0600)]
vulkan: Update the XML and headers to 1.1.95
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tobias Klausmann [Sat, 1 Dec 2018 17:30:20 +0000 (18:30 +0100)]
amd/vulkan: meson build - use radv_deps for libvulkan_radeon
Without this the build breaks with:
FAILED: src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_pipeline.c.o
cc -Isrc/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha -Isrc/amd/vulkan
-I../src/amd/vulkan -Isrc/../include -I../src/../include -Isrc -I../src
-Isrc/mapi -I../src/mapi -Isrc/mesa -I../src/mesa -I../src/gallium/include
-Isrc/gallium/auxiliary -I../src/gallium/auxiliary -Isrc/amd -I../src/amd
-Isrc/amd/common -I../src/amd/common -Isrc/compiler -I../src/compiler
-Isrc/vulkan/util -I../src/vulkan/util -Isrc/vulkan/wsi -I../src/vulkan/wsi
-Isrc/compiler/nir -I../src/compiler/nir -I/usr/include -I/usr/include/libdrm
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-std=c99 -O2 -g '-DVERSION="18.3.0-rc5"' -DPACKAGE_VERSION=VERSION
'-DPACKAGE_BUGREPORT="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa"'
-DGLX_USE_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM -DENABLE_SHADER_CACHE
-DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ
-DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT
-DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT
-DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE
-DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN
-DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE
-DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT
-DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_FUNC_ATTRIBUTE_ALIAS
-DHAVE_FUNC_ATTRIBUTE_NORETURN -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS
-DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H -DHAVE_LINUX_FUTEX_H
-DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP
-DHAVE_POSIX_MEMALIGN -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_STRTOD_L
-DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LLVM=0x0600
-DMESA_LLVM_VERSION_PATCH=1 -DHAVE_WAYLAND_PLATFORM -DWL_HIDE_DEPRECATED
-DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -Werror=implicit-function-declaration
-Werror=missing-prototypes -Werror=return-type -fno-math-errno
-fno-trapping-math -Wno-missing-field-initializers -Wno-format-truncation -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -DNDEBUG -fPIC -pthread
-D__STDC_FORMAT_MACROS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_LIMIT_MACROS -fvisibility=hidden -Wno-override-init
-DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XLIB_KHR
-DVK_USE_PLATFORM_WAYLAND_KHR -DVK_USE_PLATFORM_DISPLAY_KHR
-DVK_USE_PLATFORM_XLIB_XRANDR_EXT -MD -MQ
'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_pipeline.c.o' -MF
'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_pipeline.c.o.d' -o
'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_pipeline.c.o' -c
../src/amd/vulkan/radv_pipeline.c
In file included from ../src/vulkan/util/vk_alloc.h:29,
from ../src/amd/vulkan/radv_private.h:52,
from ../src/amd/vulkan/radv_debug.h:27,
from ../src/amd/vulkan/radv_pipeline.c:30:
../src/../include/vulkan/vulkan.h:54:10: fatal error: wayland-client.h: Datei
oder Verzeichnis nicht gefunden
#include <wayland-client.h>
^~~~~~~~~~~~~~~~~~
compilation terminated.
The above command misses the include directory for wayland:
-I/usr/include/wayland
The missing include is contained in the (until now) unused radv_deps:
if with_platform_wayland
radv_deps += dep_wayland_client
radv_flags += '-DVK_USE_PLATFORM_WAYLAND_KHR'
libradv_files += files('radv_wsi_wayland.c')
endif
Fixes: 673dda83307 "meson: build "radv" vulkan driver for radeon hardware"
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Erik Faye-Lund [Fri, 16 Nov 2018 10:39:52 +0000 (11:39 +0100)]
mesa/main: do not require float-texture filtering for es3
The OpenGL ES 3.0 specification, table 3.13 lists half-float textures as
filterable, but not float textures. So we shouldn't depend on
ARB_float_texture, which requires full filtering support for both.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 09:28:06 +0000 (10:28 +0100)]
mesa/st: do not probe for the same texture-formats twice
This should be equalent of what we did before.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 10:15:33 +0000 (11:15 +0100)]
mesa/main: require EXT_texture_sRGB for gles3
sRGB textures is a requirement for OpenGL ES 3.0, so let's make sure
we don't incorrectly enable a too high version.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 17:35:34 +0000 (18:35 +0100)]
mesa/main: require EXT_texture_type_2_10_10_10_REV for gles3
OpenGL ES 3.0 require this functionality, so we should also test for it
to avoid incorrectly exposing a too high GLES version.
On desktop, this has been required since all the way back in OpenGL 1.2
anyway.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 09:49:55 +0000 (10:49 +0100)]
mesa/main: split float-texture support checking in two
On OpenGL ES 2.0, there's separate extensions adding support for
half-float and float textures. So we need to validate the enums
separately as well.
This also prevents these enums from incorrectly being allowed on
OpenGL ES 1.x, where there's no extension that enables this in the
first place.
While we're at it, remove the pointless default-case, and the seemingly
stale fallthrough comment.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 10:30:34 +0000 (11:30 +0100)]
mesa/main: do not allow EXT_texture_sRGB_R8 enums before gles3
ctx->Extensions.EXT_texture_sRGB_R8 is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the check.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 10:25:17 +0000 (11:25 +0100)]
mesa/main: do not allow sRGB texture enums before gles3
ctx->Extensions.EXT_texture_sRGB is set regardless of the API that's
used, so checking for those direcly will always allow the enums from
this extensions when they are supported by the driver.
There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the check.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 10:10:23 +0000 (11:10 +0100)]
mesa/main: do not allow snorm-texture enums before gles3
ctx->Extensions.EXT_texture_snorm is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the check.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 10:07:01 +0000 (11:07 +0100)]
mesa/main: do not allow floating-point texture enums on gles1
ctx->Extensions.OES_texture_float is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
There's no extension enabling floating-point textures for OpenGL
ES 1.x, so we shouldn't allow those enums there.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 17:37:18 +0000 (18:37 +0100)]
mesa/main: do not allow type_2_10_10_10_REV enums before gles3
ctx->Extensions.EXT_texture_type_2_10_10_10_REV is set regardless of
the API that's used, so checking for those direcly will always enable
extensions when they are supported by the driver.
There's no corresponding extension for OpenGL ES 1.x/2.0, so we
shouldn't allow these enums there.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 17:08:33 +0000 (18:08 +0100)]
mesa/main: do not allow MESA_ycbcr_texture enums on gles
This extension requies OpenGL, and shouldn't be available on OpenGL ES.
So let's not allow the enums from it either.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 17:00:24 +0000 (18:00 +0100)]
mesa/main: do not allow EXT_texture_shared_exponent enums before gles3
ctx->Extensions.EXT_texture_shared_exponent is set regardless of the
API that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
We also need to make sure this is enabled on OpenGL ES 3. Because the
check is repeated, let's introduce a helper.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 16:43:36 +0000 (17:43 +0100)]
mesa/main: do not allow rg-textures enums before gles3
EXT_packed_float isn't supported on OpenGL ES, we shouldn't allow
these enums there, before OpenGL ES 3.0 which also introduce support
for these enums.
Since this check is repeated a lot, let's make a helper for this.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 16:19:44 +0000 (17:19 +0100)]
mesa/main: do not allow EXT_packed_float enums before gles3
EXT_packed_float isn't supported on OpenGL ES, we shouldn't allow
these enums there, before OpenGL ES 3.0 which also introduce support
for these enums.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 16:02:32 +0000 (17:02 +0100)]
mesa/main: do not allow ARB_depth_buffer_float enums before gles3
Floating-point depth buffers are only supported on OpenGL 3.0, OpenGL ES
3.0, or if ARB_depth_buffer_float is supported. Because we checked a
driver capability rather than using an extension-check helper, we ended
up incorrectly allowing this on OpenGL ES 1.x and 2.x.
Since this logic is repeated, let's make a helper for it.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 15:55:46 +0000 (16:55 +0100)]
mesa/main: do not allow integer-texture enums before gles3
Integer textures shouldn't be implicitly exposed on OpenGL ES 1.x and
2.x, but because the code checked against a driver-capability rather
than using an extension-check helper, we ended up accidentally allowing
these enums on older versions when the driver supports it.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 15:40:31 +0000 (16:40 +0100)]
mesa/main: do not allow ARB_texture_rgb10_a2ui enums before gles3
ARB_texture_rgb10_a2ui isn't supported on OpenGL ES, we shouldn't expose
it there even if the driver supports it.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 08:56:34 +0000 (09:56 +0100)]
mesa/main: do not allow stencil-texture enums on gles1
ctx->Extensions.ARB_texture_stencil8 is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
So let's instead check for both ARB_texture_stencil8 and
OES_texture_stencil8, so we support depth textures on OpenGL and
OpenGL ES 2.0+. There's no extension enabling stencil-textures for
OpenGL ES 1.x, so we shouldn't allow those enums there.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 08:52:49 +0000 (09:52 +0100)]
mesa/main: do not allow depth-texture enums on gles1
ctx->Extensions.ARB_depth_texture is set regardless of the API that's
used, so checking for those direcly will always allow the enums from
this extensions when they are supported by the driver.
So let's instead check for both ARB_depth_texture and OES_depth_texture,
so we support depth textures on OpenGL and OpenGL ES 2.0+. There's no
extension enabling depth-textures for OpenGL ES 1.x, so we shouldn't
allow those enums there.
This fixes oes_packed_depth_stencil-depth-stencil-texture_gles1 on i965
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 08:51:26 +0000 (09:51 +0100)]
mesa/main: do not allow astc enums on gles1
ctx->Extensions.KHR_texture_compression_astc_ldr is set regardless of
the API that's used, so checking for those direcly will always enable
extensions when they are supported by the driver.
But there's no extension enabling ASTC for OpenGL ES 1.x, so we
shouldn't allow those enums there.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 15:33:49 +0000 (16:33 +0100)]
mesa/main: do not allow etc2 enums on gles1
ctx->Extensions.ARB_ES3_compatibility is set regardless of the API
that's used, so checking for those direcly will always enable
extensions when they are supported by the driver.
But there's no extension enabling ETC2 for OpenGL ES 1.x, so we
shouldn't allow those enums there.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 15:15:41 +0000 (16:15 +0100)]
mesa/main: do not allow s3tc enums on gles1
There's no extension enabling S3TC formats on OpenGL ES 1.x, so we
shouldn't allow these even if the driver can support it. So let's check
for EXT_texture_compression_s3tc instead of ANGLE_texture_compression_dxt,
which is supported on all other OpenGL variations.
We also need to use _mesa_has_EXT_texture_compression_s3tc() instead of
checking the driver cap directly, otherwise we end up enabling this on
OpenGL ES 1.x, as the API isn't checked.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 15:07:32 +0000 (16:07 +0100)]
mesa/main: use _mesa_has_FOO_bar for compressed format checks
_mesa_has_FOO_bar() knows about the APIs these extensions should be
supported under, so let's use that to simplify these checks a bit.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 15:46:36 +0000 (16:46 +0100)]
mesa/main: clean up integer texture check
This makes the logic a little bit easier to follow, and reduce a bit of
repetition.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 17:40:26 +0000 (18:40 +0100)]
mesa/main: clean up ES2_compatibility check
This makes the logic a little bit easier to follow; this is *either*
about ES2 compatibility *or* about gles. GL_RGB565 was added already in
OpenGL ES 1.0.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 10:43:00 +0000 (11:43 +0100)]
mesa/main: clean up OES_texture_float_linear check
Using the _mesa_has_FOO_bar helpers is generally more safe and should
generally be prefered over checking driver-caps like this code did,
because the _mesa_has_FOO_bar helpers also verify the API type and
version.
This shouldn't have any practical effect here, as this function only
gets called for OpenGL ES 3.x right now. But if this was to change in
the future, this makes the function behave a lot more predictable.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 15:01:49 +0000 (16:01 +0100)]
mesa/main: clean up S3_s3tc check
S3_s3tc is the extension that enables this functionality on desktop, so
let's check for that one. The _mesa_has_S3_s3tc() helper already
verifies the API according to the extension-table.
As for the second hunk, we currently already only expose
EXT_texture_compression_s3tc on desktop so by using the helper instead,
we get rid of this detail here, and once we enable it for GLES we'll
automaticall get the interaction right.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Fri, 16 Nov 2018 09:58:12 +0000 (10:58 +0100)]
mesa/main: rename format-check function
_mesa_es3_error_check_format_and_type isn't specific to OpenGL ES 3.x,
it applies to all versions of OpenGL ES. So let's rename it to reflect
this.
While we're at it, let's also rename a helper function it uses similarly.
As the helper is static, we can also remove the namespacing-prefix from
the name.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Erik Faye-Lund [Thu, 15 Nov 2018 14:57:10 +0000 (15:57 +0100)]
mesa/main: make _mesa_has_tessellation return bool
All other _mesa_has_foo functions return bool rather than GLboolean, so
let's follow that style here as well.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Chad Versace [Thu, 8 Nov 2018 20:55:35 +0000 (12:55 -0800)]
i965: Fix -Wswitch on INTEL_COPY_STREAMING_LOAD
The warning is emitted when building without INLINE_SSE41.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Karol Herbst [Sat, 24 Nov 2018 19:00:00 +0000 (20:00 +0100)]
nv50,nvc0: Fix gallium nine regression regarding sampler bindings
The new approach is that samplers don't get unbound even if they won't be used
in a draw and we should just leave them be as well.
Fixes a regression in multiple windows games using gallium nine and nouveau.
v2: adjust num_samplers to keep track of the highest sampler bound
v3: rework how to set the new value of num_samplers
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106577
Fixes: 4d6fab245eec3880e2a59424a579851f44857ce8
"cso: don't track the number of sampler states bound"
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Andre Heider [Sun, 25 Nov 2018 09:49:59 +0000 (10:49 +0100)]
d3dadapter9: use snprintf(..., "%s", ...) instead of strncpy
Fixes -Wstringop-truncation compiler warnings.
See
f836d799f9066adf58f36 "intel/decoder: use snprintf(..., "%s", ...) instead of strncpy"
Signed-off-by: Andre Heider <a.heider@gmail.com>
Reviewed-by: Axel Davy <davyaxel0@gmail.com>
Mauro Rossi [Fri, 30 Nov 2018 23:42:40 +0000 (00:42 +0100)]
android: st/mesa: fix building error due to sched_getcpu()
Android has cpufeatures library but pinning of threads is not supported
PIPE_OS_LINUX code path causes build error due to sched_getcpu() unavailable
thus we need to avoid setting HAVE_SCHED_GETCPU for Android
Fixes: 48f2160 ("st/mesa: regularly re-pin driver threads to the CCX where the app thread is")
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Vinson Lee [Mon, 5 Nov 2018 18:50:41 +0000 (10:50 -0800)]
st/xvmc: Add X11 include path.
This patch fixes this build error.
CC tests/xvmc_bench.o
In file included from tests/xvmc_bench.c:35:
tests/testlib.h:38:10: fatal error: 'X11/Xlib.h' file not found
^~~~~~~~~~~~
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Mauro Rossi [Fri, 30 Nov 2018 22:36:59 +0000 (23:36 +0100)]
android: amd/addrlib: update Mesa's copy of addrlib
Needed to fix build error in addrlib in mesa for Android
Fixes: 776b911 ("amd/addrlib: update Mesa's copy of addrlib")
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Gurchetan Singh [Mon, 26 Nov 2018 17:54:05 +0000 (09:54 -0800)]
virgl: don't mark buffers as unclean after a write
We can mark the buffer unclean if it's ever bound as a TBO,
SSBO, ABO, or image.
This improves
dEQP-GLES3.performance.buffer.data_upload.function_call.map_buffer_range.new_specified_buffer.flag_write_full.stream_draw
from 9.58 MB/s to 451.17 MB/s.
v2: Track buffer cleanliness as a function of bindings (Ilia).
v3: virgl_modify_clean --> virgl_dirty_res (Erik)
Tested-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Gurchetan Singh [Mon, 26 Nov 2018 17:54:04 +0000 (09:54 -0800)]
virgl: avoid large inline transfers
We flush everytime the command buffer (16 kB) is full, which is
quite costly.
This improves
dEQP-GLES3.performance.buffer.data_upload.function_call.buffer_data.new_buffer.usage_stream_draw
from 111.16 MB/s to 1930.36 MB/s.
In addition, I made the benchmark produce buffers from 0 --> VIRGL_MAX_CMDBUF_DWORDS * 4,
and tried ((VIRGL_MAX_CMDBUF_DWORDS * 4) / 2), ((VIRGL_MAX_CMDBUF_DWORDS * 4) / 4), etc.
I didn't notice any clear differences, so let's just go with the most obvious
heuristic.
Tested-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Gurchetan Singh [Mon, 26 Nov 2018 17:54:03 +0000 (09:54 -0800)]
virgl: quadruple command buffer size
Tested running WebGL aquarium on Nvidia host (10,000 fishes)
This moves us from 7 fps to 9 fps. After quadrupling, performance
gains diminish.
v2: Remove change ID (Erik)
Tested-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Lionel Landwerlin [Thu, 29 Nov 2018 13:02:03 +0000 (13:02 +0000)]
anv: flush pipeline before query result copies
Pipeline state pending bits should be taken into account when copying
results.
In the particular bug below, the results of the
vkCmdCopyQueryPoolResults() command was being overwritten by the
preceding vkCmdCopyBuffer() with a same destination buffer. This is
because we copy the buffers using the 3D pipeline whereas we copy the
query results using the command streamer. Those pieces of HW work in
parallel and the results are somewhat undefined.
v2: Unconditionally flush the pipeline before copying the results
(Jason)
v3: Wrap & expressions (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108894
Cc: mesa-stable@lists.freedesktop.org
Marek Olšák [Thu, 29 Nov 2018 19:45:42 +0000 (14:45 -0500)]
Revert "winsys/amdgpu: overallocate buffers for faster address translation on Gfx9"
I didn't mean to push this. I don't think it makes any difference.
This reverts commit
f737fe00a047ae1ae9ec4e15a4ea8b578389f2f6.
Roland Scheidegger [Fri, 23 Nov 2018 01:31:24 +0000 (02:31 +0100)]
draw: fix infinite loop in line stippling
The calculated length of a line may be infinite, if the coords we
get are bogus. This leads to an infinite loop in line stippling.
To prevent this test for this explicitly (although technically
on at least x86 sse it would actually work without the explicit
test, as long as we use the int-converted length value).
While here also get rid of some always-true condition.
Note this does not actually solve the root cause, which is that
the coords we receive are bogus after clipping. This seems a difficult
problem to solve. One issue is that due to float arithmetic, clip w
may become 0 after clipping if the incoming geometry is
"sufficiently degenerate", hence x/y/z ndc (and window) coords will
be all inf (or nan). Even with w not quite 0, I believe it's possible
we produce values which are actually outside the view volume.
(Also, x=y=z=w=0 coords in clipspace would be not considered subject
to clipping, and similarly result in all NaN coords.) We just hope for
now other draw stages (and rasterizers) can handle those relatively
safely (llvmpipe itself should be sort of robust against this, certainly
converstion to fixed point will produce garbage, it might fail a couple
assertions but should neither hang nor crash otherwise).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Józef Kucia [Mon, 26 Nov 2018 15:04:30 +0000 (16:04 +0100)]
nir: Fix assert in print_intrinsic_instr().
Signed-off-by: Józef Kucia <joseph.kucia@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Nicolai Hähnle [Mon, 19 Nov 2018 17:53:09 +0000 (18:53 +0100)]
amd/addrlib: update Mesa's copy of addrlib
Update to the internal master as of 2018-11-15.
This has a lot of gratuitous whitespace change, but on the plus
side it's built using the same tooling that's used for AMDVLK,
which should help going forward.
Nicolai Hähnle [Thu, 28 Jun 2018 18:55:38 +0000 (20:55 +0200)]
ac/surface/gfx9: let addrlib choose the preferred swizzle kind
Our choices here are simply redundant as long as sin.flags is set
correctly.
(v2:
- remove unused function parameter)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Nicolai Hähnle [Mon, 19 Nov 2018 17:23:40 +0000 (18:23 +0100)]
radv: remove dependency on addrlib gfx9_enum.h
v2:
- use SI_CONTEXT_REG_OFFSET
Reviewed-by: Dave Airlie <airlied@redhat.com>
Thomas Hellstrom [Mon, 26 Nov 2018 18:05:47 +0000 (19:05 +0100)]
winsys/svga: Fix a memory leak
The ioctl.cap_3d member was never freed.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Thomas Hellstrom [Mon, 26 Nov 2018 18:02:08 +0000 (19:02 +0100)]
st/xa: Fix a memory leak
Free the context after destruction.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Samuel Pitoiset [Thu, 22 Nov 2018 18:10:15 +0000 (19:10 +0100)]
radv: drop few useless state changes when doing color/depth decompressions
Viewport/scissor don't need to be updated for array textures.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Thu, 22 Nov 2018 18:10:14 +0000 (19:10 +0100)]
radv: remove unused pending_clears param in the transition path
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Fri, 23 Nov 2018 16:04:15 +0000 (17:04 +0100)]
radv: optimize CmdClear{Color,DepthStencil}Image() for layered textures
If all layers are bound we can perform a fast color or depth clear
instead of iterating over all layers. This has the advantage
to avoid trashing the framebuffer for nothing if you we end up by
doing a fast clear when calling radv_clear_image_layer(), and
clearing all layers in one shot is obviously faster.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Fri, 23 Nov 2018 16:04:14 +0000 (17:04 +0100)]
radv: refactor the fast clear path for better re-use
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Fri, 23 Nov 2018 16:04:13 +0000 (17:04 +0100)]
radv: simplify a check in emit_fast_color_clear()
Currently only true if RADV_PERFTEST=dccmsaa is set.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Fri, 23 Nov 2018 16:04:12 +0000 (17:04 +0100)]
radv: add radv_can_fast_clear_{color,depth}() helpers
For further optimisations.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Fri, 23 Nov 2018 16:04:11 +0000 (17:04 +0100)]
radv: add radv_image_view_can_fast_clear() helper
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Fri, 23 Nov 2018 16:04:10 +0000 (17:04 +0100)]
radv: add radv_image_can_fast_clear() helper
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Samuel Pitoiset [Fri, 23 Nov 2018 16:04:09 +0000 (17:04 +0100)]
radv: remove useless check in emit_fast_color_clear()
The driver doesn't support DCC/CMASK for mipmapped textures.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Vinson Lee [Wed, 28 Nov 2018 21:21:50 +0000 (13:21 -0800)]
freedreno: Fix autotools build.
Fix build error.
CXXLD pipe_msm.la
../../../../src/gallium/drivers/freedreno/.libs/libfreedreno.a(freedreno_batch.o): In function `batch_init':
src/gallium/drivers/freedreno/freedreno_batch.c:54: undefined reference to `fd_device_version'
src/gallium/drivers/freedreno/freedreno_batch.c:59: undefined reference to `fd_submit_new'
src/gallium/drivers/freedreno/freedreno_batch.c:61: undefined reference to `fd_submit_new_ringbuffer'
src/gallium/drivers/freedreno/freedreno_batch.c:64: undefined reference to `fd_submit_new_ringbuffer'
src/gallium/drivers/freedreno/freedreno_batch.c:66: undefined reference to `fd_submit_new_ringbuffer'
src/gallium/drivers/freedreno/freedreno_batch.c:70: undefined reference to `fd_submit_new_ringbuffer'
Fixes: b4476138d5ad ("freedreno: move drm to common location")
Fixes: aa0fed10d357 ("freedreno: move ir3 to common location")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Marek Olšák [Tue, 27 Nov 2018 01:55:26 +0000 (20:55 -0500)]
radeonsi: add memory management stress tests for GDS
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Marek Olšák [Tue, 27 Nov 2018 01:52:58 +0000 (20:52 -0500)]
winsys/amdgpu: add support for allocating GDS and OA resources
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Marek Olšák [Sat, 22 Sep 2018 01:01:46 +0000 (21:01 -0400)]
radeonsi: allow si_cp_dma_clear_buffer to clear GDS from any IB
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Marek Olšák [Mon, 26 Nov 2018 22:16:59 +0000 (17:16 -0500)]
winsys/amdgpu: use optimal VM alignment for CPU allocations
Acked-by: Christian König <christian.koenig@amd.com>
Marek Olšák [Mon, 26 Nov 2018 22:13:47 +0000 (17:13 -0500)]
winsys/amdgpu: use optimal VM alignment for imported buffers
Window system buffers didn't use the optimal alignment.
Acked-by: Christian König <christian.koenig@amd.com>
Marek Olšák [Mon, 26 Nov 2018 22:06:20 +0000 (17:06 -0500)]
winsys/amdgpu,radeon: pass vm_alignment to buffer_from_handle
Acked-by: Christian König <christian.koenig@amd.com>
Marek Olšák [Wed, 21 Nov 2018 23:06:54 +0000 (18:06 -0500)]
winsys/amdgpu: overallocate buffers for faster address translation on Gfx9
Sadly, the 3 games I tested (DeusEx:MD, DiRT Rally, DOTA 2) are unaffected
by the overallocation, because I guess their buffers don't fall into
the small range below a power-of-two size.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Marek Olšák [Fri, 23 Nov 2018 23:27:00 +0000 (18:27 -0500)]
winsys/amdgpu: increase the VM alignment to the MSB of the size for Gfx9
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Marek Olšák [Wed, 21 Nov 2018 22:28:13 +0000 (17:28 -0500)]
winsys/amdgpu: use >= instead of > for VM address alignment
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Marek Olšák [Fri, 23 Nov 2018 23:20:49 +0000 (18:20 -0500)]
winsys/amdgpu: clean up code around BO VM alignment
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>