They were set only by the DRI state tracker, which is problematic
when radeonsi is used with different state trackers in the same
process.
Also, we don't need them anymore.
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
radeonsi: set drirc compiler options before calling common screen init
Also, access the options directly, allowing us to get rid of the
PIPE_SCREEN_xxx flags.
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
anv: Makefile.vulkan.am: ICD json files are now generated with python
Commit 0ab04ba979 (anv: Use python to generate ICD json files) changed
the way ICD json files are created.
Remove the old .in files from extra dist, and add the python script.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
radv: also fix texture image descriptors for mipmap tile swizzle
This fixes the image descriptors for mipmapped tile swizzle
Fixes: 2b7e8556 (ac/surface: enable tile swizzle for mipmapped textures)
Signed-off-by: Dave Airlie <airlied@redhat.com>
When Marek enabled mipmapped swizzle, radv didn't
have the code in place to handle it. This fixes the
regression.
I'll look more into GFX9 once I have a vega card (soon).
Fixes: 2b7e8556 (ac/surface: enable tile swizzle for mipmapped textures)
Signed-off-by: Dave Airlie <airlied@redhat.com>
ac/surface: align DCC size for surfaces that use tile swizzle
Note that dcc_alignment = pipe_interleave_bytes * num_pipes * num_banks,
which is greater than the previous open-coded alignment.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
ac/surface: enable tile swizzle for mipmapped textures
The tile swizzle computation was done after the whole miptree was computed,
but that was too late, because at that point AddrSurfInfoOut contained
information about the smallest miplevel, which is never 2D-tiled.
The correct way is to do the computation before the second level is computed.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
In Mesa we use the convention that if gl_renderbuffer::NumSamples
or gl_texture_image::NumSamples is zero, it's a non-MSAA surface.
Otherwise, it's an MSAA surface. But in gallium nr_samples=1 is a
non-MSAA surface.
Before, if the user called glRenderbufferStorageMultisample() or
glTexImage2DMultisample() with samples=1 we skipped the search for the
next higher number of supported samples and asked the gallium driver to
create a surface with nr_samples=1. So we got a non-MSAA surface.
This failed to meet the expection of the user making those calls.
This patch changes the sample count checks in st_AllocTextureStorage()
and st_renderbuffer_alloc_storage() to test for samples > 0 instead of > 1.
And we now start querying for MSAA support at samples=2 since gallium has
no concept of a 1x MSAA surface.
A specific example of this problem is the Piglit arb_framebuffer_srgb-blit
test. It calls glRenderbufferStorageMultisample() with samples=1 to
request an MSAA renderbuffer with the minimum supported number of MSAA
samples. Instead of creating a 4x or 8x, etc. MSAA surface, we wound up
creating a non-MSAA surface.
Finally, add a comment on the gl_renderbuffer::NumSamples field.
There is one piglit regression with the VMware driver:
ext_framebuffer_multisample-blit-mismatched-formats fails because
now we're actually creating 4x MSAA surfaces (the requested sample
count is 1) and we're hitting some sort of bug in the blitter code. That
will have to be fixed separately. Other drivers may find regressions
too now that MSAA surfaces are really being created.
v2: start quering for MSAA support with samples=2 instead of 1.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Both the GLSL 4.00 specs and DX10.1 specs specify that if a fragment
shader uses the sample ID or sample position inputs, the shader is
automatically run at per sample frequency. Document that expectation
for gallium fragment shaders.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The default values for GL_SAMPLE_SHADING and GL_MIN_SAMPLE_SHADING_VALUE
are missing from the state tables in the GL spec, but they're supposed
to be GL_FALSE and 0.0, per the GL_ARB_sample_shading spec.
Add code for that, just to be explicit.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
swr: Add arch flags to support Cray and PGI compilers
Note that the Cray flags (-target-cpu=) need to come first since the
cray programming environment uses wappers around other compilers. By
checking the wrapper flags first, you can be sure to match the wrapper
flag instead of the underlying compiler (gcc, intel, pgi, etc.) flags.
Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
v2: add libxmlconfig.la to the dynamic pipe_radeonsi driver
v3: add libxmlconfig.la to targets/opencl build
v4: add EXPAT_LIBS to opencl build
(note: for only-opencl builds, Emil's configure.ac changes
are also needed)
Fixes: bc7f41e11d ("gallium: add pipe_screen_config to screen_create functions")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102014
Tested-by: Andy Furniss <adf.lists@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (v1)
android: anv_extensions.c is generated to libmesa_vulkan_common
Fixes build error with anv_extensions.c not found for
libmesa_anv_entrypoints.
Fixes: d62063c "anv: Autogenerate extension query and lookup"
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
android: radeonsi: prepare for driver-specific driconf options
Android build changes to avoid the following building error:
In file included from external/mesa/src/gallium/targets/dri/target.c:1:
external/mesa/src/gallium/auxiliary/target-helpers/drm_helper.h:185:10:
fatal error: 'radeonsi/si_driinfo.h' file not found
^
1 error generated.
Fixes: 0f8c5de869 "radeonsi: prepare for driver-specific driconf options"
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Android build changes to avoid the following building error:
external/mesa/src/gallium/drivers/radeonsi/si_shader_nir.c:505:
error: undefined reference to 'ac_nir_translate'
Fixes: 86d4b46d66 "ac/common: always build NIR translation"
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
mesa: only check errors when the state change in glLogicOp()
When this GL call is a no-op, it should be a little faster.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
mesa: only check errors when the state change in glBlendEquationSeparateiARB()
When this GL call is a no-op, it should be a little faster.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
i965: Drop unnecessary I915_PARAM_HAS_EXEC_CAPTURE defines
These were only here to keep building without needing to update libdrm.
Now that we include i915_drm.h in Mesa, we don't need this - our copy
is new enough and has the #define.
Trivial.
Fixes:
CXXLD addrlib/libamdgpu_addrlib.la
ar: `u' modifier ignored since `D' is the default (see `U')
../../../../src/amd/common/ac_nir_to_llvm.c:33:27: fatal error:
ac_shader_abi.h: No such file or directory
#include "ac_shader_abi.h"
^
compilation terminated.
Makefile:985: recipe for target
'common/common_libamd_common_la-ac_nir_to_llvm.lo' failed
When running `make distcheck`
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
intel/vec4/gs: reset nr_pull_param if DUAL_INSTANCED compile failed.
If dual object compile fails (as seems to happen with virgl a
fair bit, and does piglit even have any tests for it?), we end up
not restarting the pull params, so we call
vec4_visitor::move_uniform_array_access_to_pull_constant
a second time and it runs over the ends of the alloc.
Fixes: tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test
running inside virgl on ivybridge.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
st/dri2 Plumb the flush_swapbuffer functionality through to dri3
Implement the state tracker manager drawable interface flush_swapbuffer
method by plumbing it through to dri3 if available.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
gallium/st: Add a method to flush outstanding swapbuffers
Add a state tracker interface method to flush outstanding swapbuffers, and
add a call to it from the mesa state tracker during glFinish().
This doesn't strictly mean the outstanding swapbuffers have actually finished
executing but is sufficient for glFinish()
to be able to be used as a replacement for glXWaitGL().
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Provide a dri3 implementation for the image loader extension method.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
dri: Add a flushSwapBuffers method to the image loader extension
This method may be used by dri drivers to make sure all outstanding
buffer swaps have been flushed to hardware.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This can be used to guard support for EXT_memory_object and related
extensions.
v2: update gallium docs
v3 (Timothy Arceri):
- add cap to nv50
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
i965/blit: Remember to include miptree buffer offset in relocs
Remember to add the offset to the start of the buffer in the relocation
or else we write 0xff into random bytes elsewhere.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
This reduces the number of BOs that we need for the BO lists during
a submission.
Currently uses a fairly simple linear search for finding free space,
that could eventually be improved to a binary tree, which with some
per-node info could make a check for space O(1) and finding it O(log n),
in the number of buffers in that slab.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
i965: Set "Subslice Hashing Mode" to 16x16 on Apollolake.
As of 4.11, the kernel isn't bothering to set the subslice hashing mode
on Apollolake, leaving it at the default of 8x8. (It initializes it to
16x4 on most platforms.)
Performance data for GPUTest Triangle on Apollolake at 1024x640:
X-tiled RT:
-----------
8x8 -> 16x4: 2.4325% +/- 0.383683% (n=107)
8x8 -> 8x4: -3.75105% +/- 0.592491% (n=40)
8x8 -> 16x16: 6.17238% +/- 0.67157% (n=30)
Y-tiled RT:
-----------
8x8 -> 16x4: 1.30307% +/- 0.297292% (n=205)
8x8 -> 8x4: -0.769282% +/- 0.729557% (n=35)
8x8 -> 16x16: 3.00254% +/- 0.715503% (n=40)
8x MSAA RT (INTEL_FORCE_MSAA=8):
--------------------------------
8x8 -> 16x4: 1.38889% +/- 0.93729% (n=7)
8x8 -> 8x4: -2.10643% +/- 1.15153% (n=3)
8x8 -> 16x16: 3.87183% +/- 1.08851% (n=5)
Based on this, we choose 16x16 for Apollolake.
Skylake GT2 with X-tiled buffers appears to be a toss-up between 16x4
and 16x16, and with Y-tiled buffers it doesn't seem to really matter.
So we'll leave Skylake alone for now.
The hashing mode doesn't seem to make a measurable impact on more
complex benchmarks.
Acked-by: Matt Turner <mattst88@gmail.com>
This isn't used in any of these drivers.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nicolai Hähnle