We had a lot of memcpy call overhead because gpu_stride wasn't being
inlined. But if you split out the stride==8 and stride==16 cases like
this code does while still using memcpy, you'd no longer have glibc's
NEON memcpy applied at which point we'd be doing 16 uncached reads
instead of 64/(NEON memcpy granularity), for about a 30% performance
hit. By hand writing the assembly, we can get a whole cacheline
loaded at a time.
Unfortunately, NEON intrinsics turned out to be unusable -- they
didn't have the vldm instruction available.
Note that, for now, the NEON code is only enabled when building for ARMv7
(Pi 2+). We may want to do runtime detection for the Raspbian case, in
the future.
Improves 1024x1024 GetTexImage by 208.256% +/- 7.07029% (n=10).
Saves a measly 20 bytes on IA32 and nothing on x64. Depending on
exactly when this is applied, a lot of variation is possible due to
function alignment.
text data bss dec hex filename
6670131 228340 22552 6921023 699b3f lib/i965_dri.so before
6670111 228340 22552 6921003 699b2b lib/i965_dri.so after
6342932 293872 29880 6666684 65b9bc lib64/i965_dri.so before
6342932 293872 29880 6666684 65b9bc lib64/i965_dri.so after
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
By putting the parameters first that match the parameters to the call
site, 4 (of 14) instructions are saved at _mesa_Uniform4fv on x64. On
IA32, the details of the instructions change, but it is the same count
and mix of instructions.
Before:
0000000000000830 <_mesa_Uniform4fv>:
830: 48 83 ec 10 sub $0x10,%rsp
834: 49 89 d0 mov %rdx,%r8
837: 48 8b 15 00 00 00 00 mov 0x0(%rip),%rdx # 83e <_mesa_Uniform4fv+0xe>
83e: 89 f8 mov %edi,%eax
840: 89 f1 mov %esi,%ecx
842: 41 b9 02 00 00 00 mov $0x2,%r9d
848: 64 48 8b 3a mov %fs:(%rdx),%rdi
84c: 48 8b 97 c8 01 02 00 mov 0x201c8(%rdi),%rdx
853: 48 8b 72 70 mov 0x70(%rdx),%rsi
857: 6a 04 pushq $0x4
859: 89 c2 mov %eax,%edx
85b: e8 00 00 00 00 callq 860 <_mesa_Uniform4fv+0x30>
860: 48 83 c4 18 add $0x18,%rsp
864: c3 retq
After:
00000000000007f0 <_mesa_Uniform4fv>:
7f0: 48 83 ec 10 sub $0x10,%rsp
7f4: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 7fb <_mesa_Uniform4fv+0xb>
7fb: 41 b9 02 00 00 00 mov $0x2,%r9d
801: 64 48 8b 08 mov %fs:(%rax),%rcx
805: 48 8b 81 c8 01 02 00 mov 0x201c8(%rcx),%rax
80c: 6a 04 pushq $0x4
80e: 4c 8b 40 70 mov 0x70(%rax),%r8
812: e8 00 00 00 00 callq 817 <_mesa_Uniform4fv+0x27>
817: 48 83 c4 18 add $0x18,%rsp
81b: c3 retq
Saves a measly 416 bytes of text on x64. Depending on exactly when this
is applied, a lot of variation is possible due to function alignment.
text data bss dec hex filename
6670131 228340 22552 6921023 699b3f lib/i965_dri.so before
6670131 228340 22552 6921023 699b3f lib/i965_dri.so after
6343348 293872 29880 6667100 65bb5c lib64/i965_dri.so before
6342932 293872 29880 6666684 65b9bc lib64/i965_dri.so after
There is likely to be no performance change with just this patch.
_mesa_uniform immediately calls validate_uniform_parameters with
parameters in the "wrong" (different from the call site) order.
v2: Rebase on GL_ARB_gpu_shader_fp64.
v3: Rebase on GL_ARB_gpu_shader_int64.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The size of the pool is slightly smaller than the size of the
structure containing the whole pool. We need to take that into account
on when setting up the internals.
Fixes a crash due to out of bound memory access in:
dEQP-VK.api.descriptor_pool.out_of_pool_memory
v2: Drop debug traces (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org>
When trying to blit larger tiled surfaces, the pitch can be larger than
32768 bytes, which means it won't fit in a GLshort. Passing it in will
truncate the stride to 0, which has...surprising results.
The pitch can be up to 32,768 DWords, or 128kB. We measure it in bytes,
but divide by 4 when programming it. So we need to handle values up to
131,072. Switch from GLshort to int32_t to avoid the truncation.
Fixes GL45-CTS.gtf30.GL3Tests.depth_texture.depth_texture_copyteximage
at widths greater than 8192.
v2: Use int32_t as negative values can be used (Jason).
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
SIMD16 compute shaders use a send(16) with mlen 1 for the EOT message,
using a source of g127 for the single register. With a UD type, this
supposedly could read g128, which doesn't exist, causing the simulator
to get cranky. Use a UW type to avoid this.
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
According to GL_KHR_vulkan_glsl, the signature of subpassLoad() is:
gvec4 subpassLoad(gsubpassInput subpass);
gvec4 subpassLoad(gsubpassInputMS subpass, int sample);
So the multisampled case always receives an explicit sample index that we
should use. The current implementation was ignoring this parameter
and using gl_SampleID value instead.
Fixes:
dEQP-VK.pipeline.multisample_shader_builtin.sample_id.*
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
I hadn't bothered to set this bit because I figured it would just
paper over us getting the rectangle wrong. But it turns out that
there is a legitimate reason to use it, so let's do so.
The alternative would be to chop up 16k clears to multiple 8k clears,
which is pointlessly painful.
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Add a helper function, anv_get_queue_family_properties(), which fills the
struct. This patch reduces churn in the following patch that implements
vkGetPhysicalDeviceQueueFamilyProperties2KHR.
Reviewed-by: Jason Ekstranad <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Add a helper function, anv_get_image_format_properties(), which does all
the work and has a VkPhysicalDeviceImageFormatInfo2KHR parameter. This
patch reduces churn in the following patch that implements
vkGetPhysicalDeviceImageFormatProperties2KHR.
Reviewed-by: Jason Ekstranad <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
The struct was deleted by:
commit efe9d1cde3
Author: Edward O'Callaghan <funfunctor@folklore1984.net>
Subject: anv: Clean up some unused variables
Unlike the original anv_common, the new one has a non-const pNext
pointer because we will use it for the output structs of
VK_KHR_get_physical_device_properties2.
v2:
- Retype pNext from void* to struct anv_common*.
Reviewed-by: Jason Ekstranad <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This is a printf-like macro that prints a debug message to stderr when
built with DEBUG. If no DEBUG, then do nothing.
Reviewed-by: Jason Ekstranad <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
All of the functions were passing 1 to _mesa_uniform instead of passing
count.
Fixes 16 unsed parameter warnings like:
main/uniforms.c: In function ‘_mesa_Uniform1i64vARB’:
main/uniforms.c:1692:47: warning: unused parameter ‘count’ [-Wunused-parameter]
_mesa_Uniform1i64vARB(GLint location, GLsizei count, const GLint64 *value)
^~~~~
This is why I build with extra warnings enabled. Unfortunately, there
are so many unused parameter warnings in Mesa that I didn't notice these
added warnings for over 6 months. :(
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The spec section 5.2 says:
"vkAllocateCommandBuffers can be used to create multiple command
buffers. If the creation of any of those command buffers fails, the
implementation must destroy all successfully created command buffer
objects from this command, set all entries of the pCommandBuffers
array to VK_NULL_HANDLE and return the error."
Fixes:
dEQP-VK.api.object_management.alloc_callback_fail_multiple.command_buffer_primary
dEQP-VK.api.object_management.alloc_callback_fail_multiple.command_buffer_secondary
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org>
In swr_update_derived() update texture and sampler state on a new fragment
shader. GALLIUM_HUD can update fs using a previously bound texture and
sampler.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Useful when debugging applications which map a ton of buffers
and also because we used to run into Linux's limit on the number
of simultaneous mmap() calls.
v2: - update the commit message
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
SPIR-V maps both gl_SampleMask and gl_SampleMaskIn to the same
builtin (SampleMask). The only way to tell which one we are dealing with
is to check if it is an input or an output.
Fixes:
dEQP-VK.pipeline.multisample_shader_builtin.sample_mask.write.*
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Along the lines of what
3b804819 anv: Default PointSize to 1.0 if not written by the shader
does for anv, program a default point size in the hw of 1.0.
This preempt fixes a bunch of geom shader tests.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If radeonsi starts compiling an optimized shader variant asynchronously
with a GL debug callback set and the application destroys the GL context,
radeonsi crashes when trying to write shader stats into the debug output
of a non-existent context after compilation, because st/mesa was destroyed
before pipe_context.
Firefox with WebGL2 enabled hits this bug.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99456
v2: protect against a double destroy in st_create_context_priv and callers.
Cc: 17.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The original number was chosen in an attempt to match the limits applied to
GLSL IR.
A look at the git history of the why these limits were chosen for GLSL IR
shows it was more to do with the slow speed of unrolling large loops in
GLSL IR than anything else. The speed of loop unrolling in NIR is not a
problem so we may wish to bump this even higher in future.
No shader-db change, however a furture change will disbale the GLSL IR
optimisation loop in the i965 backend results in 4 loops from The Talos
Principle failing to unroll. Bumping the limit allows them to unroll which
results in the instruction count matching the previous output from when the
GLSL IR opts were still enabled.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Previously the constant array would not get copy propagated until the backend
did its GLSL IR opt loop. I plan on removing that from i965 shortly which
caused huge regressions in Deus-ex and Tomb Raider which have large
constant arrays. Moving lowering before the opt loop in the GLSL linker
fixes this and unexpectedly improves some compute shaders also.
shader-db results BDW:
instructions helped: shaders/closed/steam/deus-ex-mankind-divided/374.shader_test CS SIMD16: 204 -> 194 (-4.90%)
instructions helped: shaders/closed/steam/deus-ex-mankind-divided/318.shader_test CS SIMD8: 1010 -> 741 (-26.63%)
instructions helped: shaders/closed/steam/deus-ex-mankind-divided/144.shader_test CS SIMD8: 542 -> 385 (-28.97%)
cycles helped: shaders/closed/steam/deus-ex-mankind-divided/318.shader_test CS SIMD8: 1831382 -> 1818492 (-0.70%)
cycles helped: shaders/closed/steam/deus-ex-mankind-divided/144.shader_test CS SIMD8: 216238 -> 206180 (-4.65%)
cycles helped: shaders/closed/steam/deus-ex-mankind-divided/374.shader_test CS SIMD16: 18484 -> 16644 (-9.95%)
total instructions in shared programs: 13060313 -> 13059877 (-0.00%)
instructions in affected programs: 1756 -> 1320 (-24.83%)
helped: 3
HURT: 0
total cycles in shared programs: 256586698 -> 256561910 (-0.01%)
cycles in affected programs: 2066104 -> 2041316 (-1.20%)
helped: 3
HURT: 0
V3: only call the opt loop if lowering progressed (Suggested by Eric)
V2: call opts before and after lowering (Suggested by Ken)
Reviewed-by: Eric Anholt <eric@anholt.net>
OpenGL ES implementations are not allowed to ship ARB extensions, and
OpenGL implementations are not allowed to ship OES extensions.
The functionality is also included in GL_ARB_ES2_compatibility. Ever
OpenGL core-profile driver currently exposes both extensions. I don't
know of any applications that explicitly check for GL_OES_read_format,
so removing it seems very unlikely to cause problems. No functionality
is removed.
I have left this extension in place for compatibility profile. There
are still OpenGL 1.x drivers in Mesa, and adding code to check for
compatibility profile and not GL_ARB_ES2_compatibility for
GL_IMPLEMENTATION_COLOR_READ_TYPE and GL_IMPLEMENTATION_COLOR_READ_FORMAT
just feels dumb.
Three other other alternatives considered:
- Remove the string from compatibility profile drivers but leave the
functionality in place.
- Add a flag to expose the extension string, and set it in every OpenGL
driver that does not expose GL_ARB_ES2_compatibility (and those
drivers only). I tried this. You can't have two instances of an
extension in the extension table (one dummy_true for ES1 and one with
a flag for compatibility profile), so the implementation requires a
bit of effort.
- Only expose the extension in compatibility if the version is less
than 2.0. I didn't see an easy way to do this.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
As per VK_KHR_maintenance1, clients can render to a slice of a 3D image
by creating a VK_IMAGE_VIEW_TYPE_2D view of it.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
As of VK_KHR_maintenance1, these are supposed to be reported for any
formats on which we support transfer operations. For us, this is
anything that we can texture from.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Our command buffers already efficiently use a global pool so trimming
doesn't really need to do anything.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
As per VK_KHR_maintenance1, setting a negative height in the viewport
can be used to get flipped coordinates. This is, aparently, very useful
when porting D3D apps to Vulkan. All we need to do to support this is
to make sure we actually set the min and max correctly.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
define __STDC_FORMAT_MACROS and include <inttypes.h> (same as
ir_builder_print_visitor.cpp already does).
Otherwise, some mingw build errors out (since
8e7e1ae036 and
bbce1c538d presumably) with:
src/compiler/glsl/ir_print_visitor.cpp:479:40: error: expected ‘)’ before ‘PRIu64’
case GLSL_TYPE_UINT64:fprintf(f, "%" PRIu64, ir->value.u64[i]); break;
(Note even with that fix I get other format specifier warnings:
src/compiler/glsl/ir_print_visitor.cpp:473:47:
warning: unknown conversion type character ‘a’ in format [-Wformat=]
fprintf(f, "%a", ir->value.f[i]);
^
src/compiler/glsl/ir_print_visitor.cpp:473:47:
warning: too many arguments for format [-Wformat-extra-args]
but it still compiles at least)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The use of fast rcp instruction is disabled, and will always fall back
to use a division instead (1 / x). Hence, if we get a division opcode,
it doesn't make much sense trying to split that into rcp/mul.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
we can't use the cpu implementation of fdiv, as this one uses different
lp_build_context, which causes assertion failure.
Just use default fdiv action (there is no fast rcp for doubles which we
could potentially use anyway).
Cc: 17.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
In brw_blorp_copyteximage, we use the format from the render buffer.
This could be a combined depth/stencil format. In this case, we handle
stencil properly but we give blorp the wrong ISL format. Specifically,
we would give blorp ISL_FORMAT_R32G32B32A32_FLOAT which is the wrong
size was causing GPU hangs.
Fixes: GL45-CTS.gtf30.GL3Tests.packed_depth_stencil.packed_depth_stencil_copyteximage
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org>
state_tracker/st_glsl_to_tgsi.cpp:302:28: warning: ‘glsl_to_tgsi_instruction::tex_type’
is too small to hold all values of ‘enum glsl_base_type’
glsl_base_type tex_type:4;
Fixes: 8ce53d4a2f ("glsl: Add basic ARB_gpu_shader_int64 types")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Other things are out of order, but I need to add a getter so I'm just
fixing those.
This helps people adding to GBM know where the right place to put things
is.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Acked-by: Daniel Stone <daniels@collabora.com>
This sets the dnz flag on all the relevant multiplication operations. At
emission time, this will only be supported by nvc0+, so nv50 will need a
different solution.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This will be useful for proper D3D9 emulation, where this behavior is
expected by some shaders.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Some CIK-VI docs say this is the default behavior on SI. That doesn't
answer whether it's also the default behavior on CIK-VI.
Cc: 17.0 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
so that most shaders can get lower VGPR usage thanks to lazy input loading.
I think this is a more accurate constraint that prevents the black transitions
in Witcher 2.
Affected shaders (7758):
Max Waves: 57437 -> 58231 (1.38 %)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
It's also possible to monitor them via performance counters but
the hardware can only use two counters simultaneously. It seems
easier to re-use the existing code which reads from MMIO instead
of writing a multi-pass approach.
v2: - add new lines after ':'
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This will allow to expose more queries in order to know which
blocks are busy/idle.
v2: - add new lines after ':'
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Some query results struct contents are declared as cache line aligned.
Use aligned malloc, and align the whole struct, to be safe.
Fixes crash when compiling with clang.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
CalculateProcessorTopology tries to figure out system topology by
parsing /proc/cpuinfo to determine the number of threads, cores, and
NUMA nodes. There are some architectures where the "physical id" begins
with 1 rather than 0, which was creating and empty "0" node and causing a
crash in CreateThreadPool.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97102
Reviewed-By: George Kyriazis <george.kyriazis@intel.com>
CC: <mesa-stable@lists.freedesktop.org>
This allows eglCreateImageKHR to access P010 surfaces created by vaapi
Signed-off-by: Rainer Hochecker <fernetmenta@online.de>
Acked-by: Ben Widawky <ben@bwidawsk.net>
This fixes "st/va: delay calling begin_frame until we have all parameters".
v2: call begin frame after decoder (re)creation as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Tested-by: Andy Furniss <adf.lists@gmail.com>
It seems clear that trying to multiply two pairs of doubles would result
in the temporary register getting overwritten by the second pair. So
make the code more explicit.
Tested-by: Glenn Kennard <glenn.kennard@gmail.com>
Tested-by: James Harvey <lothmordor@gmail.com>
Cc: 17.0 <mesa-stable@lists.freedesktop.org>
There are some line wrapping violations here but those lines will get
deleted in the following patch.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Now that the i965 backend doesn't depend on this field we can
make it more generic and short circuit a bunch of code paths.
The new field will be used in a following patch for another
clean-up.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This makes much more sense and should be more performant in some
critical paths such as SSO validation which is called at draw time.
Previously the CurrentProgram array could have contained multiple
pointers to the same struct which was confusing and we would often
need to fish out the information we were really after from the
gl_program anyway.
Also it was error prone to depend on the _LinkedShader array for
programs in current use because a failed linking attempt will lose
the infomation about the current program in use which is still
valid.
V2: fix validate_io() to compare linked_stages rather than the
consumer and producer to decide if we are looking at inward
facing shader interfaces which don't need validation.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
To avoid build regressions the following 2 patches were squashed in to
this commit:
mesa/meta: rewrite _mesa_shader_program_use() and _mesa_program_use()
These are rewritten to do what the function name suggests, that is
_mesa_shader_program_use() sets the use of all stage and
_mesa_program_use() sets the use of a single stage.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
mesa: update active relinked program
This likely fixes a subroutine bug were
_mesa_shader_program_init_subroutine_defaults() would never have been
called for the relinked program as we previously just set
_NEW_PROGRAM as dirty and never called the _mesa_use* functions when
linking.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
What a3xx docs call IJPERSPCENTERREGID.. the xy coord passed into
bary.f. We were incorrectly setting both this and gl_FragCoord.xy to
the same register resulting in all sorts of hilarity.
Fixes stk, vdrift, 0ad, probably a bunch others.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
The previous code always compared integers as 64-bit. Due to variations
in sign-extension in the code generated by nir_opt_algebraic.py, this
meant that nir_search doesn't always do what you want. Instead, 32-bit
values should be matched as 32-bit and 64-bit values should be matched
as 64-bit. While we're here we unify the unsigned and signed paths.
Now that we're using the right bit size, they should be the same since
the only difference we had before was sign extension.
This gets the UE4 bitfield_extract optimization working again. It had
stopped working due to the constant 0xff00ff00 getting sign-extended
when it shouldn't have.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org>
In order to handle CCS_E, we stomp the image format to a UINT format and
then do some bitcasting logic in the shader. This works fine since SKL
render compression only considers the channel layout of the format and
not the format itself. In order for this to work on images that have
been fast-cleared, we need to also convert the clear color so that, when
interpreted as UINT, it provides the same bit value as it would have in
the original format. This fixes a bunch of OpenGL ES CTS tests for
copy_image when we start using CCS more aggressively.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
basetsd.h on Windows defines INT64 and UINT64 typedefs which conflict
with these. Append "_TOK" to avoid conflicts.
Should fix the Windows build.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Gen8 adds Q/UQ types. We attempted to change the types back to DF in the
generator (commit c95380c40), but an assertion added in the FP64 series
(commit e481dcc3) triggers before that code has a chance to execute.
In fact, using Q/UQ in the IR and then changing to DF in the generator
would not work in the presence of source modifiers, etc.
Fixes: d6fcede6 ("i965: Return Q and UQ types for int64 and uint64")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Integer comparison functions (e.g., nir_op_ilt) are handled in the next
commit.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2 (idr): Make the "from" type in a cast unsized. This reduces the
number of required cast operations at the expensive slightly more
complex code. However, this will be a dramatic improvement when other
sized integer types are added. Suggested by Connor.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Fixup assertion in brw_reg_type_to_hw_type to allow
BRW_REGISTER_TYPE_{UQ,Q} on Gen8+.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
It seems like maybe this should return a different type based on Gen. Q
and UQ only exist on Gen8+, but, based on the old comment, I believe
previous Gens can generate 64-bit moves.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
It's much easier to do this in the generator rather than while coming
out of NIR. brw_type_for_nir_type doesn't know the Gen, so we'd have to
add a bunch of plumbing. The alternate fix is to not emit int64 moves
for doubles in the first place... but that seems even more difficult.
This change won't catch non-MOV instructions that try to use 64-bit
integer types on Gen < 8. This may convert certain kinds of bugs in to
different kinds of bugs that are more difficult to detect (since the
assertions in the function won't catch them).
NOTE: I don't think anything can emit mixed-type 64-bit moves until the
same platform supports both ARB_gpu_shader_fp64 and
ARB_gpu_shader_int64. When we enable int64 on Gen < 8, we can solve
this problem other ways.
This prevents regressions on HSW in the next patch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Don't up-convert the shift count parameter if shift instructions.
Suggested by Connor. Add type_is_singed() function. This will make
adding 8- and 16-bit types easier.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Previously both sources were unsized. This caused problems when the
thing being shifted was 64-bit but the shift count was 32-bit. The
expectation in NIR is that all unsized sources (and destination) will
ultimately have the same size.
The changes in nir_opt_algebraic.py are to prevent errors like:
Failed to parse transformation:
03:12:25 (('extract_i8', 'a', 'b'), ('ishr', ('ishl', 'a', ('imul', ('isub', 3, 'b'), 8)), 24), 'options->lower_extract_byte')
03:12:25 Traceback (most recent call last):
03:12:25 File "/home/jenkins/workspace/Leeroy_2/repos/mesa/src/compiler/nir/nir_algebraic.py", line 610, in __init__
03:12:25 xform = SearchAndReplace(xform)
03:12:25 File "/home/jenkins/workspace/Leeroy_2/repos/mesa/src/compiler/nir/nir_algebraic.py", line 495, in __init__
03:12:25 BitSizeValidator(varset).validate(self.search, self.replace)
03:12:25 File "/home/jenkins/workspace/Leeroy_2/repos/mesa/src/compiler/nir/nir_algebraic.py", line 311, in validate
03:12:25 validate_dst_class = self._validate_bit_class_up(replace)
03:12:25 File "/home/jenkins/workspace/Leeroy_2/repos/mesa/src/compiler/nir/nir_algebraic.py", line 414, in _validate_bit_class_up
03:12:25 src_class = self._validate_bit_class_up(val.sources[i])
03:12:25 File "/home/jenkins/workspace/Leeroy_2/repos/mesa/src/compiler/nir/nir_algebraic.py", line 420, in _validate_bit_class_up
03:12:25 assert src_class == src_type_bits
03:12:25 AssertionError
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Suggested-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
This change makes me wonder whether double packing should be
reimplemented as int64BitsToDouble(packInt2x32(v)). I'm a little on the
fence since not all platforms that support fp64 natively support int64.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
v2 (idr): "cut them down later" => Remove ir_unop_b2u64 and
ir_unop_u642b. Handle these with extra i2u or u2i casts just like
uint(bool) and bool(uint) conversion is done.
v3 (idr): Make the "from" type in a cast unsized. This reduces the
number of required cast operations at the expensive slightly more
complex code. However, this will be a dramatic improvement when other
sized integer types are added. Suggested by Connor.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
The lowering passes 64-bit integer operations will generate a lot of
these.
v2: Modify the HANDLE_PACK_UNPACK_INVERSE so that the breaks apply to
the switch instead of the 'do { } while(true)' loop.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These functions are directly available in shaders. A #define is added
to detect the presence. This allows these functions to be tested using
piglit regardless of whether the driver uses them for lowering. The
GLSL spec says that functions and macros beginning with __ are reserved
for use by the implementation... hey, that's us!
v2: Use function inlining.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These functions are directly available in shaders. A #define is added
to detect the presence. This allows these functions to be tested using
piglit regardless of whether the driver uses them for lowering. The
GLSL spec says that functions and macros beginning with __ are reserved
for use by the implementation... hey, that's us!
v2: Use function inlining.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These functions are directly available in shaders. A #define is added
to detect the presence. This allows these functions to be tested using
piglit regardless of whether the driver uses them for lowering. The
GLSL spec says that functions and macros beginning with __ are reserved
for use by the implementation... hey, that's us!
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Rename lower_64bit.cpp and lower_64bit_test.cpp to lower_int64.
Suggested by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These functions are directly available in shaders. A #define is added
to detect the presence. This allows these functions to be tested using
piglit regardless of whether the driver uses them for lowering. The
GLSL spec says that functions and macros beginning with __ are reserved
for use by the implementation... hey, that's us!
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Just add operations to the switch statement here.
v2 (idr): "cut them down later" => Remove ir_unop_b2u64 and
ir_unop_u642b. Handle these with extra i2u or u2i casts just like
uint(bool) and bool(uint) conversion is done.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2 (idr): "cut them down later" => Remove ir_unop_b2u64 and
ir_unop_u642b. Handle these with extra i2u or u2i casts just like
uint(bool) and bool(uint) conversion is done.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
If ARB_gpu_shader_int64 is supported, ARB_shader_clock also adds
clockARB() that returns a uint64_t. Rather than add new opcodes and
intrinsics for this, just wrap the existing intrinsic with a
packUint2x32.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These are all the allowed 64-bit functions from ARB_gpu_shader_int64
spec.
v2: restrict int64/double functions better.
v3 (idr): Delete spurious blank lines. Suggested by Matt.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
As for the double code, but using the 64-bit integer conversions.
v2 (idr): Remove some spurious u2i() and i2u() operations when packing
and unpacking, respectively, int64_t varyings.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Reviewed-by: Matt Turner <mattst88@gmail.com>
This adds 64-bit integer support to some AST and IR operations where
it is needed.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This adds support to call the new operations on conversions.
v2 (idr): Delete an unnecessary break-statement. Noticed by Matt. Add
a missing blank line. Noticed by Ian.
v3 (idr): "cut them down later" => Remove ir_unop_b2u64 and
ir_unop_u642b. Handle these with extra i2u or u2i casts just like
uint(bool) and bool(uint) conversion is done.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Reviewed-by: Matt Turner <mattst88@gmail.com> [v2]
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This just adds the new operations and add 64-bit integer support to all
the existing cases where it is needed.
v2: fix some issues found in testing.
v2.1: add unreachable (Ian), add missing int/uint pack/unpack (Dave).
v3 (idr): Rebase on top of idr's series to generate
ir_expression_operation_constant.h. In addition, this version:
Adds missing support for ir_unop_bit_not, ir_binop_all_equal,
ir_binop_any_nequal, ir_binop_vector_extract,
ir_triop_vector_insert, and ir_quadop_vector.
Removes support for uint64_t from ir_unop_abs and ir_unop_sign.
v4 (idr): "cut them down later" => Remove ir_unop_b2u64 and
ir_unop_u642b. Handle these with extra i2u or u2i casts just like
uint(bool) and bool(uint) conversion is done.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v2]
Reviewed-by: Matt Turner <mattst88@gmail.com> [v3]
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This adds all the conversions in the world, I'm not 100% sure of all of
these are needed, but add all of them and we can cut them down later.
v2: fix issue with packing output types.
v3 (idr): Rebase on top of idr's series to generate
ir_expression_operation_constant.h. Fix transposed ir_validate
assertions for ir_unop_u642i64 and ir_unop_i642u64. Add missing
automatic type setup for ir_unop_u642i64 and ir_unop_i642u64.
v4 (idr): "cut them down later" => Remove ir_unop_b2u64 and
ir_unop_u642b. Handle these with extra i2u or u2i casts just like
uint(bool) and bool(uint) conversion is done.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v2]
Reviewed-by: Matt Turner <mattst88@gmail.com> [v3]
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This adds support for 64-bit integer constants to the parser,
ast and ir.
v2: fix a few issues found in testing.
v3: Add missing ir_constant copy contructor support.
v4: Use PRIu64 and PRId64 in printfs in glsl_parser_extras.cpp.
Suggested by Nicolai. Rebase on Marek's linalloc changes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v2]
Reviewed-by: Matt Turner <mattst88@gmail.com> [v3]
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This hooks up the API to the internals for 64-bit integer uniforms.
v2: update to use non-strict aliased alternatives
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This adds the builtins and the lexer support.
To avoid too many warnings, it adds basic support to the type in a few
other places in mesa, mostly in the trivial places.
It also adds a query to be used later for if a type is an integer 32 or 64.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Just add the boilerplate xml code.
v2 (idr): Update dispatch_sanity. Only add extension functions in core
profile.
v3 (idr): Remove comment line from gl_API.xml. Suggested by Matt.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Reviewed-by: Matt Turner <mattst88@gmail.com>
Blorp can deal with depth/stencil surfaces blits/copies without the
render target requirement. Also having both render target and
depth/stencil requirement is incompatible from isl's point of view.
This fixes an image creation issue in the high level quality settings
of the Unity3D player, which requires a depth texture with src/dst
transfer & 4x multisampling.
v2: Simply aspect checking condition (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: 13.0 17.0 <mesa-stable@lists.freedesktop.org>
src1 must be a descriptor (including the information to determine that
the SEND is doing an extended math operation), but src0 can actually be
null since it serves as the source of the implicit GRF -> MRF move.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
desc will always be non-NULL, because brw_validate_instructions() does
not attempt to validate any instructions that fail the
is_unsupported_inst() check.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We want to rely on brw_opcode_desc() always returning non-NULL in other
validation functions. Other validation functions will be in the else
case of the block added in this patch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
inst, whose assignment can be seen in the last line of context pointed
to the correct instruction in the SIMD16 program, but src_offset was the
offset from the beginning of the SIMD16 program.
So if an instruction at offset 0x100 in the SIMD16 program was illegal,
we would mark an error on the instruction at offset 0x100 (which is
likely in the SIMD8 program).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Using a UD-typed operand makes the execution size D, and if the size of
the execution type is greater than the size of the destination type, the
destination must be appropriately strided.
We actually just want UW-types all around.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We change the immediate source type to VF to allow instruction
compaction, but there are no entires in the compaction table for DF, so
there's no point in doing this.
Additionally, I mixing floating-point types is now allowed except for
F and VF.
Use the resource_changed callback to invalidate internal resources
derived from external textures when they are (re-)bound. This is needed
to comply with the requirement from the GL_OES_EGL_image_external
extension that a call to glBindTexture guarantees that all further
sampling will return values that correspond to the values in the
external texture at or after the time that glBindTexture was called.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
To comply with the requirement from the GL_OES_EGL_image_external
extension that a call to glBindTexture guarantees that all further
sampling will return values that correspond to the values in the
external texture at or after the time that glBindTexture was called,
do not bail out early from mesa_BindTextures if the target is
external.
This will later allow the state tracker to instruct the pipe driver
to invalidate internal resources derived from the external texture.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Implement the resource_changed pipe callback to invalidate internal
resources derived from imported buffers. This is needed to update the
texture for re-imported renderables.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Imported resources already have contents that we want to be copied to
texture resources derived from them. Set initial seqno of imported
resources to 1, just as if it had already been rendered to.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
For imported buffers that can't be used directly as a source to the
texture samplers, the pipe driver might need to create an internal
copy, for example in a different tiling layout. When buffers are
reimported they may contain new image data, so the driver internal
copies need to be recreated.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Add a hook to tell drivers that an imported resource may have changed
and they need to update their internal derived resources.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
We were including it once per value, so probably around 10k times.
Let's not cause the compiler any more work than we have to.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
It's harmless to use ALIGN_NPOT() for uncompressed formats
because they have block width/height = 1.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Fixes crash in piglit
`egl_khr_gl_renderbuffer_image-clear-shared-image GL_DEPTH_COMPONENT24`
on Skylake.
The crash happened because blorp attempted to execute a pending hiz
clear after the hiz buffer was deleted. Deleting the pending hiz ops
when the hiz buffer gets deleted fixes the crash.
For good measure, this patch also deletes all pending CCS/MCS ops when
the CCS/MCS buffer gets deleted. I'm now aware of any bugs
caused by the dangling ops, but deleting them is clearly the right thing
to do.
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99265
In situations where libdrm_amdgpu and mesa are installed to the same
location, the mesa installed headers will take precedence over the git
source headers.
This is due to the AMDGPU_CFLAGS containing the install directory.
This situation can cause build errors if the git version of a header is
newer than the currently installed version of a header (e.g. git pull
updates vulkan.h)
Note: using the same install prefix for mesa and libdrm is probably a
common occurrence since it is described in the radeonBuildHowTo wiki:
https://www.x.org/wiki/radeonBuildHowTo/
v2: added sign-off
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
PresentPixmap only works if the pixmap depth matches with the
window depth, otherwise it returns a BadMatch protocol error.
Even if the depths match, the result won't look correctly
if the VDPAU RGB component order doesn't match the X11 one so
we only allow the X11 format.
For other buffers we copy them to a buffer which is send to X.
v2: only send buffers with format VDP_RGBA_FORMAT_B8G8R8A8
v3: reword commit message
v4: add comment explaining the code
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
At least on VI, texture gather doesn't work with a 24_8 data format, so
use 8_8_8_8 and a modified swizzle instead.
A bit of background: When creating a GL_STENCIL_INDEX8 texture, we select
the X24S8 pipe format because we don't support stencil-only render targets
properly. With mip-mapping this can lead to a setup where the tiling is
incompatible with stencil texturing, and a flushed stencil texture is
used. For the flushed stencil, a literal X24S8 is used because there were
issues with an 8bpp DB->CB copy.
Longer term, it would be good if we could get away from these workarounds,
i.e. properly support an S8 format for stencil-only rendering and flushed
stencil. Since stencil texturing is somewhat rare, it's not a high
priority.
Fixes GL45-CTS.texture_cube_map_array.sampling.
Cc: 17.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
When the attachment type is NONE (att->Type),
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE should be NONE always.
Note that technically, the current behaviour follows the spec. From
OpenGL 4.5 spec, Section 9.2.3 "Framebuffer Object Queries":
"If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
either no framebuffer is bound to target; or the default
framebuffer is bound, attachment is DEPTH or STENCIL, and the
number of depth or stencil bits, respectively, is zero."
Reading literally this paragraph, for the default framebuffer, NONE
should be only returned if attachment is DEPTH and STENCIL without
being allocated.
But it doesn't makes too much sense to return DEFAULT_FRAMEBUFFER if
the attachment type is NONE. For example, this can happens if the
attachment is FRONT_RIGHT run on monoscopic mode, as that attachment
is only available on stereo mode.
With the current behaviour, defensive querying of the object type
would not work properly. So you could query the object type checking
for NONE, get DEFAULT_FRAMEBUFFER, and then get and INVALID_OPERATION
when requesting other pnames (like RED_SIZE), as the real attachment
type is NONE.
This fixes:
GL45-CTS.direct_state_access.framebuffers_get_attachment_parameters
v2: don't change the behaviour for att->Type != GL_NONE, as caused
some ES CTS regressions
v3: simplify condition (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Here we remove the single use of this field in gl_linked_shader
which allows us to move the field out of gl_shader_info
While we are at it we rewrite link_xfb_stride_layout_qualifiers()
to be more clear.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
There is no reason for this to be in the shared gl_shader_info or
to copy it to gl_program at the end of linking (its already there).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This is only used by gl_linked_shader as a temp during linking
so use a temp there instead.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This is only used by gl_linked_shader as a temp during linking
so use a temp there instead.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This is only used by gl_linked_shader as a temp during linking
so use a temp there instead.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This is never used in gl_linked_shader other than as a temp
during linking so just use a temp instead.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
We also move EarlyFragmentTests out of the gl_shader_info struct
as it is now only used by gl_shader.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
There is no need to go via the pointer in nir_shader. This change
is required for the shader cache as we don't create a nir_shader.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
We only need to set it when linking was successful and the program
being linked is currently active.
The programs_in_use mask is just used as a flag for now but in
a future change we will use it to update the CurrentProgram array.
V2: make sure to flush vertices before linking (suggested by Marek)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
A later patch will result in SSO programs calling this helper
per gl_program rather than per gl_shader_program.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
We also move NumProgramResourceList at the same time.
GLES does interface validation on SSO at runtime so we need to move
this to be able to switch to storing gl_program pointers in
CurrentProgram.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This allows us to cleanup the functions that pass this count around,
but more importantly we will be able to call the uniform linking
functions from that backends linker without having to pass this
information to the backend directly via Driver.LinkShader().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Currently this just breaks up the linking code a bit but in the
future i965 will call this from the backend via Driver.LinkShader()
so that we can do NIR optimisations before assigning uniform
locations.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Blits do not need any special treatment as the target buffer
object is added to render cache just as one does for normal draw.
Color clears and resolves in turn require explicit "end of pipe
synchronization". It is not clear what this means exactly but the
assumption is that render cache flush with command stream stall
should be sufficient.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Current blorp logic issues unconditional "flush everything"
(see brw_emit_mi_flush()) after each render. For example, all
blits issue this unconditionally which shouldn't be needed if
they set render cache properly so that subsequent renders do
necessary flushing before drawing.
In case of piglit:
ext_framebuffer_multisample-accuracy all_samples depth_draw small
intel_hiz_exec() is always preceded by blorb blit and the
unconditional flush looks to hide the lack of stall and flushes
in depth clears. By removing the brw_emit_mi_flush() I get gpu
hangs.
This patch adds the stalls and flushes mandated by the spec
and gets rid of those hangs.
v2 (Jason, Ken): Document the rational for separating
depth cache flush and stall on Gen7.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Earlier commit imported a SHA1 implementation and relaxed the SHA1 and
disk cache handling, broking the Windows builds.
Restrict things for now until we get to a proper fix.
Fixes: d1efa09d34 "util: import sha1 implementation from OpenBSD"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
At the moment we support 5+ different implementations each with varying
amount of bugs - from thread safely problems [1], to outright broken
implementation(s) [2]
In order to accommodate these we have 150+ lines of configure script and
extra two configure toggles. Whist an actual implementation being
~200loc and our current compat wrapping ~250.
Let's not forget that different people use different code paths, thus
effectively makes it harder to test and debug since the default
implementation is automatically detected.
To minimise all these lovely experiences, import the "100% Public
Domain" OpenBSD sha1 implementation. Clearly document any changes needed
to get building correctly, since many/most of those can be upstreamed
making future syncs easier.
As an added bonus this will avoid all the 'fun' experiences trying to
integrate it with the Android and SCons builds.
v2: Manually expand __BEGIN_DECLS/__END_DECLS and document (Tapani).
Furthermore it seems that some games (or surrounding runtime) static
link against OpenSSL resulting in conflicts. For more information see
the discussion thread [3]
Bugzilla [1]: https://bugs.freedesktop.org/show_bug.cgi?id=94904
Bugzilla [2]: https://bugs.freedesktop.org/show_bug.cgi?id=97967
[3] https://lists.freedesktop.org/archives/mesa-dev/2017-January/140748.html
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Vinson Lee <vlee@freedesktop.org>
Cc: Tapani Pälli <tapani.palli@intel.com>
Cc: Jonathan Gray <jsg@jsg.id.au>
Tested-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com> (v1)
Acked-by: Jason Ekstrand <jason@jlekstrand.net> (v1)
struct brw_cache_item is an implementation detail of the program cache.
We don't need to make those internals available to the entire driver.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
This reverts commit b7ac0f5671.
This is a half baked solution needs some rework to fixes issues
with reported counter bits (GL_QUERY_COUNTER_BITS_ARB).
Also it enables PIPE_CAP_QUERY_TIME_ELAPSED accidently.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This patch is the porting to android of the following commits:
b838f64 "ac/debug: Move sid_tables.h generation to common code."
0ef1b4d "ac/debug: Move IB decode to common code."
Fixes android building errors due to sid_tables.h
and ac_debug.c, ac_debug.h moved to amd/common
Tested by building nougat-x86
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Conditional libLLVMCore static library dependency is added,
for the case when MESA_ENABLE_LLVM is true
Fixes the following building error with Android 7.0:
In file included from
external/mesa/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp:62:
...
external/llvm/include/llvm/IR/Attributes.h:68:14: fatal error:
'llvm/IR/Attributes.inc' file not found
#include "llvm/IR/Attributes.inc"
^
1 error generated.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
LLVMInitializeAMDGPU* functions need to be explicitly declared
and mesa expects them via <llvm-c/Target.h> header,
but LLVM needs to be instructed to invoke its own LLVM_TARGET(AMDGPU) macro,
or the functions will not be available.
A new llvm cflag (-DFORCE_BUILD_AMDGPU) serves this purpose,
the same mechanism is used also by other llvm targets e.g. FORCE_BUILD_ARM
A necessary prerequisite is to have AMDGPU target handled accordingly
in llvm config files i.e. {Target,AsmParser,AsmPrinter}.def
for llvm device build includes.
This avoids the following building errors:
external/mesa/src/amd/common/ac_llvm_util.c:43:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetInfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
LLVMInitializeAMDGPUTargetInfo();
^
external/mesa/src/amd/common/ac_llvm_util.c:44:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTarget' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
LLVMInitializeAMDGPUTarget();
^
external/mesa/src/amd/common/ac_llvm_util.c:45:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetMC' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
LLVMInitializeAMDGPUTargetMC();
^
external/mesa/src/amd/common/ac_llvm_util.c:46:2: error: implicit declaration of function 'LLVMInitializeAMDGPUAsmPrinter' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
LLVMInitializeAMDGPUAsmPrinter();
^
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
LLVMInitializeAMDGPU* functions need to be explicitly declared
and mesa expects them via <llvm-c/Target.h> header,
but LLVM needs to be instructed to invoke its own LLVM_TARGET(AMDGPU) macro,
or the functions will not be available.
A new llvm cflag (-DFORCE_BUILD_AMDGPU) serves this purpose,
the same mechanism is used also by other llvm targets e.g. FORCE_BUILD_ARM
A necessary prerequisite is to have AMDGPU target handled accordingly
in llvm config files i.e. {Target,AsmParser,AsmPrinter}.def
for llvm device build includes.
This avoids the following building errors:
external/mesa/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c:129:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetInfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
LLVMInitializeAMDGPUTargetInfo();
^
external/mesa/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c:130:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTarget' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
LLVMInitializeAMDGPUTarget();
^
external/mesa/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c:131:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetMC' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
LLVMInitializeAMDGPUTargetMC();
^
external/mesa/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c:132:2: error: implicit declaration of function 'LLVMInitializeAMDGPUAsmPrinter' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
LLVMInitializeAMDGPUAsmPrinter();
^
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
LLVMInitializeAMDGPU* functions need to be explicitly declared
and mesa expects them via <llvm-c/Target.h> header,
but LLVM needs to be instructed to invoke its own LLVM_TARGET(AMDGPU) macro,
or the functions will not be available.
A new llvm cflag (-DFORCE_BUILD_AMDGPU) serves this purpose,
the same mechanism is used also by other llvm targets e.g. FORCE_BUILD_ARM
A necessary prerequisite is to have AMDGPU target handled accordingly
in llvm config files i.e. {Target,AsmParser,AsmPrinter}.def
for llvm device build includes.
This avoids the following building errors:
external/mesa/src/gallium/drivers/radeon/radeon_llvm_emit.c:121:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetInfo' [-Werror=implicit-function-declaration]
LLVMInitializeAMDGPUTargetInfo();
^
external/mesa/src/gallium/drivers/radeon/radeon_llvm_emit.c:122:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTarget' [-Werror=implicit-function-declaration]
LLVMInitializeAMDGPUTarget();
^
external/mesa/src/gallium/drivers/radeon/radeon_llvm_emit.c:123:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetMC' [-Werror=implicit-function-declaration]
LLVMInitializeAMDGPUTargetMC();
^
external/mesa/src/gallium/drivers/radeon/radeon_llvm_emit.c:124:2: error: implicit declaration of function 'LLVMInitializeAMDGPUAsmPrinter' [-Werror=implicit-function-declaration]
LLVMInitializeAMDGPUAsmPrinter();
^
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
The implementation was added with commit d085a5dff5 and effectively
provided a hidden dependency.
Namely: the codepath used was determined solely during build time. Thus
if we built again new wayland and then run against older (yet still
within the requirements, as per the configure) one will get undefined
symbols.
As of earlier commit 36b9976e1f "egl/wayland: Avoid race conditions
when on non-main thread" the required version was bumped to one which
provides the API, thus we can drop the quirky solution.
Cc: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Current code warns out in such cases and falls-back to either static or
shared. That can be easily missed amongst the volume produced by our
configure script.
Replace the warning with an error such that one gets direct feedback
when they're doing something wrong.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
We've been using and depending on it for at least a couple of years.
Make it obvious and error out, should one opt for it.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
We have them for local purposes in configure, where we can use their
direct dependency.
With the only remaining instance in the makefile(s) being always true,
as it can be seen in the configure snippet.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Both libraries implicitly require shared GLAPI which in itself mandates
shared libraries.
Stop pretending that one can use it and error out at configure stage.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
We should be using LIBS rather than the LDFLAGS variable. Furthermore
try to keep the linking to the final stage, rather than intermetent
static library.
Cc: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Rather than having two almost identical codepaths (one for HW/wl_drm and
another for SW/wl_shm), just factorise and reuse in both places.
v2: Rebase
v3: Rebase
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com> (v2)
As described in commit 690ead4a13 ("egl/wayland-egl: Fix for segfault
in dri2_wl_destroy_surface.") if we attempt to destroy a EGL surface
attached to already destroyed Wayland window we'll get a segfault.
v2: set the correct callback alongside the window->private. (Dan)
Cc: Daniel Stone <daniels@collabora.com>
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
No point in having an identical code in two places.
Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
type. This change is both API and ABI safe since the header uses the
correct GLXPbufferSGIX and both types are a typedef of the same
primitive XID.
Cc: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jeremy Sequoia <jeremyhu@apple.com>
We must make sure that xserver has an equivalent one-line
change to its configure.ac as the glx/glapi headers get copied over.
Then again, xserver does _not_ seem to set HAVE_ALIAS to begin with so
one might want to look into that first.
Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Analogous to previous two commits.
Strictly speaking it's not be applicable for Android since we don't
build GLX and related code.
Regardless keep things consistent with the other build systems.
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Currently we have two macros - HAVE_ALIAS and GLX_ALIAS_UNSUPPORTED.
To make it even better former of which is explicitly cleared in some
cases while not in others.
Clear all that up by using a single macro properly set during configure.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Quick search through git history (of both mesa and xserver) hows no
instances where this was ever set.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This enables the PIPE_CAP_OCCLUSION_QUERY capability without adding an
occlusion query type.
This is necessary to get Mesa to report desktop GL 2.0 support (to run
exciting things such as ioq3's OpenGL 2 renderer), and should be valid
because exposing the capability does not guarantee that any
counters are actually implemented.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This reverts changes 903eb09b5fb78d47d0f8a4bdf826a113ca2aff40..1a0aa468f354f0ee94dd383cd40ae915584624aa:
Tobias Droste (5):
configure.ac: Rename MESA_LLVM to FOUND_LLVM
configure.ac: Only set LLVM_LIBS if LLVM is used
configure.ac: Only define HAVE_LLVM if LLVM is used
configure.ac: Set and use HAVE_GALLIUM_LLVM define
configure.ac: Don't check LLVM version in gallium_require_llvm
They break scons build, and I'm not convinced this is the right fix. In
particular changing HAVE_LLVM in the C code is something I'd rather
avoid no matter what. So it's better to discuss without the pressure of
broken builds.
The doc wasn't update since we moved the glsl compiler to src/compiler/glsl.
I also updated the description of the standalone compiler.
v2:
- Mention that just-log argument removes headers/separators.
- Mention that version argument is mandatory.
Since version argument is mandatory, add --version to the command line
example.
Signed-off-by: Elie Tournier <tournier.elie@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Otherwise the file might not end up in the tarball.
Fixes: dbd677efb4 "vulkan: add API registry"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
When compiling LLVM headers, including llvm-config.h, we need to respect
LLVM_CFLAGS. This is especially crucial if LLVM is located in a
non-standard location and it happens that llvm-config.h includes another
header. In such case the detection would fail due to missing header,
because the path is provided in LLVM_CFLAGS.
Let's add LLVM_CFLAGS to global CFLAGS for the time of detection and then
restore the original flags, as done in other places of the script.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This is actually not needed because the version is checked later.
Line 2609:
if test "x$enable_gallium_llvm" == "xyes"; then
llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
llvm_add_default_components "gallium"
HAVE_GALLIUM_LLVM=xyes
DEFINES="${DEFINES} -DHAVE_GALLIUM_LLVM"
fi
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Gallium code used HAVE_LLVM to check if it needs to compile code for
LLVM in header and source files.
With the new logic HAVE_LLVM is always set. Use extra define to figure
out if LLVM is used.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99010
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Make sure that HAVE_LLVM compiler define is only set if LLVM is
actually used.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
v2 [Emil] fold within the existing conditional
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This renames llvm_check_version_for to llvm_require_version and let it
set a variable to mark that LLVM will be used.
Use this to make a usefull configure output and to only check if the
libs are found in LLVM if it is actually used.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99010
Signed-off-by: Tobias Droste <tdroste@gmx.de>
This renames MESA_LLVM to FOUND_LLVM and updates the config.log report
to say if LLVM is found or not, to make clear that this does not mean
that it is used.
There are no MESA_LLVM users so drop the AC_SUBST.
v2 [Emil]
- Polish test: -a over && test, = over ==, unquiote xyes
- other ?
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We have a persistent mapping. Don't map it a second time or try to
unmap it. Just use the pointer.
This most likely would wreak havoc except that this code is unused
(it's only called from an if (0) debug block).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
It makes sense to put a function which prints out the entire contents
of the program cache in the file that implements the program cache.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
We had five copies of the same "walk the cache and look for an
existing shader variant for this program" code. Now we have one
helper function that returns the key.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
A number of games have large arrays of constants, which we promote to
uniforms. This introduces copies from the uniform array to the original
temporary array. Normally, copy propagation eliminates those copies,
making everything refer to the uniform array directly.
A number of shaders in "Deus Ex: Mankind Divided" recently exposed a
limitation of copy propagation - if we had any intrinsics (i.e. image
access in a compute shader), we weren't able to get rid of these copies.
That meant that any variable indexing remained on the temporary array
rather being moved to the uniform array. i965's scalar backend
currently doesn't support indirect addressing of temporary arrays,
which meant lowering it to if-ladders. This was horrible.
According to Marek, on radeonsi/GCN, "F1 2015" uses 64% less
spilled-temp-array memory.
On i965/Skylake:
total instructions in shared programs: 13362954 -> 13329878 (-0.25%)
instructions in affected programs: 43745 -> 10669 (-75.61%)
helped: 12
HURT: 0
total cycles in shared programs: 248081010 -> 245949178 (-0.86%)
cycles in affected programs: 4597930 -> 2466098 (-46.37%)
helped: 12
HURT: 0
total spills in shared programs: 9493 -> 9507 (0.15%)
spills in affected programs: 25 -> 39 (56.00%)
helped: 0
HURT: 1
total fills in shared programs: 12127 -> 12197 (0.58%)
fills in affected programs: 110 -> 180 (63.64%)
helped: 0
HURT: 1
Helps Deus Ex: Mankind Divided. The one shader with hurt spills/fills
is from Tomb Raider at Ultra settings, but that same shader has a
-39.55% reduction in instructions and -14.09% reduction in cycle counts,
so it seems like a win there as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(Co-authored by Matt Turner.)
Image atomics, for example, return a value - but the shader may not
want to use it. We assigned a useless VGRF destination. This seemed
harmless, but it can actually be quite harmful. The register allocator
has to assign that VGRF to a real register. It may assign the same
actual GRF to the destination of an instruction that follows soon after.
This results in a write-after-write (WAW) dependency, and stall.
A number of "Deus Ex: Mankind Divided" shaders use image atomics, but
don't use the return value. Several of these were hitting WAW stalls
for nearly 14,000 (poorly estimated) cycles a pop. Making dead code
elimination null out the destination avoids this issue.
This patch cuts one shader's estimated cycles by -98.39%! Removing the
message response should also help with data cluster bandwidth.
On Skylake:
(instruction counts remain identical)
total cycles in shared programs: 255413890 -> 248081010 (-2.87%)
cycles in affected programs: 12019948 -> 4687068 (-61.01%)
helped: 24
HURT: 10
v2: Make can_omit_write independent of can_eliminate (Curro).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
In theory we might have incorrectly NOP'd instructions that write the
flag, but where that flag value isn't used, and yet the instruction
either writes the accumulator or has side effects.
I don't believe any such instructions exist, so this is mostly a
code cleanup.
Curro pointed out that FS_OPCODE_FB_WRITE has a null destination and
actually writes the flag on Gen4-5 to dynamically decide whether to
write some payload data. The hunk removed in this patch might have
NOP'd it, except that we don't actually mark flags_written() in the
IR, so it doesn't think the flag is touched at all. That's sketchy,
but it means it wouldn't hit this today (though there are likely other
problems!).
v2: Properly replace the inst->regs_written() check in the second
hunk with the flag being live (mistake caught by Curro).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
According to Matt, the dead code pass explicitly avoided IF and WHILE
because on Sandybridge, these could have conditional modifiers and
null destination registers. Normally, those instructions use BAD_FILE
for the destination register. Nowadays, we don't do that anymore, so
we could technically drop these checks.
However, it's clearer to explicitly leave control flow instructions
alone, so change it to the more generic !inst->is_control_flow().
This should have no actual change.
[This patch implements review feedback from Curro and Matt.]
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This fixes some issues we'd hit later if using viewport
indexes.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just always use the layer clear pipelines,
the overhead of emitting the layer shouldn't be
too large.
v2: Bas suggested we always use it.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just adds the infrastructure to allow writing layer
and viewport index. It's just a first patch out of the geom
shader tree, and doesn't do much on its own.
v2: add missing if statement change (Bas)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
the hack was introduced to avoid an extra copying
but now with dri3 we don't need it anymore
v1.1: rebasing
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Acked-by: Christian König <christian.koenig@amd.com>
this avoids an extra copy which occurs in case of dri2
v1.1: fallback to dri2 if dri3 fails to initialize
v2: add PIPE_BIND_SCANOUT to output buffers as they will
be send to X server directly (Michel)
Suggested-by: Christian König <christian.koenig@amd.com>
Tested-by: Andy Furniss <adf.lists@gmail.com>
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying
v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
use constant number of buffer and we can avoid calls to present
extension for every frame
Reviewed and Suggested-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Andy Furniss <adf.lists@gmail.com>
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
The same we do in the OpenGL driver (comment copied from there).
This is required to ensure that we execute the fragment shader stage when
side-effects (such as image or ssbo stores) are present but there are no
color writes.
I found this while writing a test to check rendering to a framebuffer
without attachments where the fragment shader does not produce any
color outputs but writes to an image via imageStore(). Without this patch
the fragment shader does not execute and the image is not written,
which is not correct.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes crash in dEQP-VK.ubo.random.all_shared_buffer.48 due to a
fragment shader code bigger than 128 kB.
This patch increases the allocation size limit to 1 MB.
v2:
- Increase it to 1 MB (Jason)
- Increase device->instruction_block_pool allocation size in
anv_device.c (Jason)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Address loading can often end up as shl + shr + shl combinations. The
latter two are equal shifts, which get converted into an and mask.
However if the previous shl is more than the mask is trying to remove
(in terms of low bits), we can just remove the and entirely. This
reduces some large shaders by as many as 3% of instructions (out of 2K).
total instructions in shared programs : 6495509 -> 6491076 (-0.07%)
total gprs used in shared programs : 954621 -> 954623 (0.00%)
local gpr inst bytes
helped 0 0 1014 1014
hurt 0 2 0 0
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
We don't need to support all the color buffers for advanced blend, just
cb0. For Fermi, we use the special binding slots so that we don't
overlap with user textures, while Kepler+ gets a dedicated position for
the fb handle in the driver constbuf.
This logic is only triggered when a FBFETCH is actually present so it
should be a no-op most of the time.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This implements support for emitting FBFETCH ops, using the existing
lowering pass for advanced blend logic, and disabling hw blend when
advanced blending is enabled.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This is so that we can differentiate between flushing any framebuffer
reading caches from regular sampler caches.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The extension spec is not currently published, so it's a bit premature
to require it for BlendBarrier usage.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This is just prep work for layered clears, it doesn't change
anything.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pretty straightforward. Also deleted the big comment block as it
is a pretty standard pattern for filling in arrays.
Also removed the error message on non-existent devices, as getting
7 errors printed to the console each time you enumerate the
devices is pretty confusing.
v2: Add constant for number of DRM devices.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Just noticed this while in the area.
v2: one replacement was incorrect.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We only need one per samples (maybe not even that), reduce
all the unneeded ones.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The existing lowering is in place to lower that to RCP + MUL, or fancier
things down the line if necessary.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Renaming data sources was added in
e8bb97ce30
It was possible to use a new name longer than
the name array in hud_graph of 128. This
patch truncates the name to fit the array.
CC: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
It should be close to the GPU load, but it can be much lower if something
is stalling shader execution (e.g. CP DMA).
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
In commit 7428e6f86a we switched the barrier SEND message's
destination type to UW to avoid problems in SIMD16 compute shaders.
Tessellation control shaders also use barriers, and in vec4 mode, we
were emitting them in align16 mode. The simulator warns that only UD,
D, F, and DF are valid destination types - UW is technically illegal.
So, switch to align1 mode. Either mode should work fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We were using impl->num_blocks, but that isn't guaranteed to be
up-to-date until after the block_index metadata is required. If we were
unlucky, this could lead to overwriting memory.
Noticed by inspection.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Each physical device may have different extensions than one another.
Furthermore, depending on the software stack, some extensions may not be
accessible.
If an extension is conditional, it can be registered only when
necessary.
v2: removed unused function and fixed indentation
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
All extension arrays are global, but only one of them refers to instance
extensions.
The device extension array refers to extensions that are common across
all physical devices. This disctinction will be more imporant once we
have dynamic extension support for devices.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Queues are independent execution streams. The vulkan spec provides no
ordering guarantees for different queues.
By using a single context for all queues, we are forcing all commands
into an unecessary FIFO ordering.
This change is a preparation step to allow our-of-ordering scheduling of
certain work tasks.
v2: Fix a rebase error with radv_QueueSubmit() and trace_bo
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This fixes glxgears rendering, which had surprisingly been broken since
late October! Specifically, commit 91d61fbf7c.
glxgears uses glShadeModel(GL_FLAT) when drawing the main portion of the
gears, then uses glShadeModel(GL_SMOOTH) for drawing the Gouraud-shaded
inner portion of the gears. This results in the same fragment program
having two different state-dependent interpolation maps: one where
gl_Color is flat, and another where it's smooth.
The problem is that there's only one gen4_fragment_program, so it can't
store both. Each FS compile would trash the last one. But, the FS
compiles are cached, so the first one would store FLAT, and the second
would see a matching program in the cache and never bother to compile
one with SMOOTH. (Clearing the program cache on every draw made it
render correctly.)
Instead, move it to brw_wm_prog_data, where we can keep a copy for
every specialization of the program. The only downside is bloating
the structure a bit, but we can tighten that up a bit if we need to.
This also lets us kill gen4_fragment_program entirely!
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The Vulkan rules for point size are a bit whacky. If you only have a
vertex shader and you use points, then you must write PointSize in your
vertex shader. If you have a geometry or tessellation shader, then it's
dependent on the shaderTessellationAndGeometryPointSize device feature.
From the Vulkan 1.0.38 specification:
"shaderTessellationAndGeometryPointSize indicates whether the
PointSize built-in decoration is available in the tessellation
control, tessellation evaluation, and geometry shader stages. If this
feature is not enabled, members decorated with the PointSize built-in
decoration must not be read from or written to and all points written
from a tessellation or geometry shader will have a size of 1.0. This
also indicates whether shader modules can declare the
TessellationPointSize capability for tessellation control and
evaluation shaders, or if the shader modules can declare the
GeometryPointSize capability for geometry shaders. An implementation
supporting this feature must also support one or both of the
tessellationShader or geometryShader features."
In other words, if the feature is disbled (the client can disable
features!) then they don't write PointSize and we provide a 1.0 default
but if the feature is enabled, they do write PointSize and we use the
one they wrote in the shader. There are at least two valid ways we can
implement this:
1) Track whether or not shaderTessellationAndGeometryPointSize is
enabled and set the 3DSTATE_SF bits based on that and what stages
are enabled, ignoring the shader source.
2) Just look at the last geometry stage VUE map and see if they wrote
PointSize and set the 3DSTATE_SF accordingly.
The second solution is the easiest and the most robust against invalid
usage of the Vulkan API, so we choose to go with that one.
This fixes all of the dEQP-VK.tessellation.primitive_discard.*point_mode
tests. The tests are also broken because they unconditionally enable
shaderTessellationAndGeometryPointSize if it's supported by the
implementation and then don't write PointSize in the evaluation shader.
However, since this is the "robust against invalid API usage" solution,
the tests happily pass. :-)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch reverts 57bab6708f, which was
causing issues with ILK and earlier VS programs.
1. brw_nir.c: Revert "i965/vec4/nir: vec4 also needs to remap vs attributes"
Do not perform a remap in vec4 backend. Rather, do it later when
setup attributes
2. brw_vec4.cpp: This fixes mapping ATTRx to proper GRFn.
Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99391
[jordan.l.justen@intel.com: merge Juan's two patches from bugzilla]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When multiple shader stages exist in the same SPIR-V module, we compile
all entry points and their inputs/outputs, then dead code eliminate the
ones not related to the specific entry point later.
nir_lower_wpos_center was being run prior to eliminating those random
other variables, which made it trip up, thinking it found gl_FragCoord
when it actually found something else like gl_PerVertex[3].
Fixes dEQP-VK.spirv_assembly.instruction.graphics.module.same_module.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
According to the "Gather4 R32G32_FLOAT Bug" internal documentation
page, the R32G32_UINT and R32G32_SINT formats are affected by the
same bug as R32G32_FLOAT. Applying the same workarounds should be
viable - apparently the R32G32_FLOAT_LD format shouldn't corrupt
integer data which is NaN or other sketchy floating point values.
One irritating caveat is that, because it's a FLOAT format, the
alpha channel or any set to SCS_ONE return 0x3f8 (1.0) rather than
integer 1. So we need shader code to whack those channels to 1.
Fixes GL45-CTS.texture_gather.plain-gather-int-cube-rg on Haswell.
v2: Fix swizzle component zeroing (caught by Jordan Justen).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This is a copy of commit 536003c11e
except for i915.
Original log for the i965 commit follows:
Some application, such as drm backend of weston, uses XRGB8888 config as
default. i965 doesn't provide this format, but before commit 65c8965d,
the drm platform of EGL takes ARGB8888 as XRGB8888. Now that commit
65c8965d makes EGL recognize format correctly so weston won't start
because it can't find XRGB8888. Add XRGB8888 format to i965 just as
other drivers do.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Boyan Ding <boyan.j.ding@gmail.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>
Applications may query the back buffer age to efficiently perform
partial updates. Generally the application will keep a fixed length
damage history, and use this to calculate what needs to be redrawn
based on the age of the back buffer it's about to render to.
If presented with a buffer that has an age greater than the
length of the damage history, the application will likely have
to completely repaint the buffer.
Our current buffer selection strategy is to pick the first available
buffer without considering its age. If an application frequently
manages to fit within two buffers but occasionally requires a third,
this extra buffer will almost always be old enough to fall outside
of a reasonably long damage history, and require a full repaint.
This patch changes the buffer selection behaviour to prefer the oldest
available buffer.
By selecting the oldest available buffer, the application will likely
always be able to use its damage history, at a cost of having to
perform slightly more work every frame. This is an improvement if
the cost of a full repaint is heavy, and the surface damage between
frames is relatively small.
It should be noted that since we don't currently trim our queue in
any way, an application that briefly needs a large number of buffers
will continue to receive older buffers than it would if it only ever
needed two buffers.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
When EGL is used on some other thread than the thread that drives the
main wl_display queue, the Wayland EGL dri2 implementation is
vulnerable to a race condition related to display round trips and global
object advertisements.
The race that may happen is that after after a proxy is created, but
before the queue is set, events meant to be emitted via the yet to be
set queue may already have been queued on the wrong queue.
In order to make it possible to avoid this race, wayland 1.11
introduced new API that allows creating a proxy wrapper that may be used
as the factory proxy when creating new proxies via Wayland requests. The
queue of a proxy wrapper can be changed without effecting what queue
events emitted by the actual proxy will be queued on, while still
effecting what default queue proxies created from it will have.
By introducing a wl_display proxy wrapper and using this when performing
round trips (via wl_display_sync()) and retrieving the global objects (via
wl_display_get_registry()), the mentioned race condition is avoided.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Daniel Stone <daniels@collabora.com>
This will flush the pipeline,which will allow to share dma-buf based
buffers.
Signed-off-by: Suresh Guttula <Suresh.Guttula@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
In most cases, if a call to get_attachment fails is because attachment
is a INVALID_ENUM. But for some specific cases, if COLOR_ATTACHMENTm
(where m >= MAX_COLOR_ATTACHMENTS) is used, it should raise an
INVALID_OPERATION exception instead.
Fixes:
GL45-CTS.direct_state_access.framebuffers_get_attachment_parameter_errors
GL45-CTS.direct_state_access.framebuffers_renderbuffer_attachment_errors
v2: extra new line before quote block. Include "color attachment" on both
new message errors (Nicolai).
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Some callers would need that info to know if they should raise
INVALID_ENUM or INVALID_OPERATION. An alternative would be the caller
to check if the attachment is a GL_COLOR_ATTACHMENTm, but that seems
redundant as get_attachment is already doing that.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Add a proper check for feature support, and raise an invalid enum for
GL_CLAMP_VERTEX/FRAGMENT_COLOR unconditionally in core profiles, since
those enums were explicitly removed after the extension was promoted
to core functionality (not in the profile sense) with OpenGL 3.0.
This matches the behavior of the AMD closed source driver and fixes
GL45-CTS.gtf30.GL3Tests.half_float.half_float_textures.
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Currently, we can store up to 256 immediates in a static array,
but this is not always enough. Instead, allocate a dynamic array
like what we currently do for temps.
This fixes a segfault with
dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23
No regressions found with full piglit run.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
These seem unlikely to be used.
Also remove irrelevant comment about SKL.
v2: forgot to rebase on master
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Avoid the resolves that would be required if fast depth clears were
allowed for such buffers.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This is a better mapping to the Vulkan API and improves performance in
all tested workloads.
v2: Remove unnecessary image view aspect checks (Jason Ekstrand)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Store the current and requested depth stencil layouts so that we can
perform the appropriate HiZ resolves for a given transition while
recording a render pass.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Add an entry point for resolving using BLORP's gen8 HiZ op function.
v2: Manually add the aux info
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Add an entry point for the optimized gen8 BLORP HiZ sequence. commit
c9eaf12de2 fixed a bug that was
unknowingly worked around by forcing additional clear rectangle
alignment restrictions not specified in the PRMs. Now that the bug is no
longer present, omit the additional alignment restrictions.
v2: Adjust code comment about padding
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We'll be using layout transitions later on in the series which can occur
within and between subpasses. Turn this on now to simplify the change
later.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We're about to enable HiZ support for multiple subpasses. Use this field
to keep track of whether or not subpass operations should treat the
depth buffer as having an auxiliary HiZ buffer.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The helper doesn't provide additional functionality over the current
infrastructure.
v2: Add comment to anv_image::aux_usage (Jason Ekstrand)
v3: Clarify comment for aux_usage (Jason Ekstrand)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Prevent assert failures that would occur in the next patch.
v2: Don't remove asserts from blorp/blit (Jason Ekstrand)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We'll be switching to layout-transition based resolves which can occur
outside of a render pass. Add this sequence to BLORP, as using BLORP
will enable emitting depth stencil state outside of a render pass (among
other benefits). The depth buffer extent is ignored to enable eventual
usage in VkCmdClearAttachments().
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Typos do happen as people nominate patches for stable. This script aims
to catch most of those.
Due to the subtle nature of things, one has to pay special attention to
the output, similar to get-extra-pick-list.sh.
At the moment only the following is handled:
grep -i "CC:.*mesa-dev"
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
There's a levelZero flag which forces texturing to pick level zero (and
not consume an explicit LOD argument). This is set for MS targets, but
could also be set for any other incoming instruction. As that is what
determines whether a LOD argument is present, check that rather than the
more indirect isMS logic.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Ever since a long time ago when I messed around with fences, I ensure
that after a PUSH_SPACE call there is enough space to write a fence out
into the pushbuf.
However the PUSH_SPACE macro is not all-knowing, and so sometimes we
have to invoke nouveau_pushbuf_space manually with the relocs/pushes
args set. If we don't take the extra allocation from PUSH_SPACE into
account, then we will end up accidentally flushing when the code was not
expecting a flush. This can lead to various runtime and rendering
failures.
The amount of extra allocation isn't that important - it has to be at
least 8 based on the current nouveau_winsys.h setting, but even more
won't hurt. I just rounded up to powers of 2.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99354
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
... and eliminate emit_fdiv and nir_to_llvm_context::fpmath_md_*, which
are now unused.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
... and eliminate the non-ac copies. Mostly straight-forward
search & replace.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
... by straight-forward search & replace, and eliminate
emit_llvm_intrinsic.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Code is taken from a combination of radv (for the more basic functions,
to avoid gallivm dependencies) and radeonsi (for the new and improved
derivative calculations).
v2: add 0.5 offset to tex coords only after derivative calculation
v3:
- really only touch the first three coordinates
- rebase on the removal of the 1.5 --> 0.5 offset change
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (v2)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Sourcing coords_arg[4] is actually never correct, since bias is handled
differently in tex_fetch_args anyway.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
As remarked by the comment in the original code, the old algorithm fails when
(tc + deriv) points at a different cube face. Instead, simply project the
derivative directly to the plane of the selected cube face.
The new code is based on exactly differentiating (using the chain rule)
the projection onto a plane corresponding to a fixed cube map face (which
is still selected in the usual way based on the texture coordinate itself).
The computations end up fairly involved, but we do save two reciprocal
computations.
Fixes GL45-CTS.texture_cube_map_array.sampling.
v2: add 0.5 offset to tex coords only after derivative calculation
v3: go back to 1.5 offset
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (v2)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
b838f642 "ac/debug: Move sid_tables.h generation to common code." moved
sid_tables.h but forgot the corresponding .gitignore.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes a bug in code motion that occurred when the best block is the
same as the schedule early block. In this case, because we're checking
(lca != def->parent_instr->block) at the top of the loop, we never get to
the check for loop depth so we wouldn't move it out of the loop. This
commit reworks the loop to be a simple for loop up the dominator chain and
we place the (lca != def->parent_instr->block) check at the end of the
loop.
Reviewed-by: Matt Turner <mattst88@gmail.com>
The generated file is correctly stored in the builddir as of earlier
commit. Yet the commit forgot to add the respective include flag thus
the compiler would error out failing to find sid_tables.h
Bugzila: https://bugs.freedesktop.org/show_bug.cgi?id=99389
Fixes: d1dc22eb46 "ac: automake: rework sid_tables.h generation"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
When the flag D3DCREATE_MULTITHREAD is set, a global mutex is used
to protect nine calls.
However for performance reasons, AddRef and Release didn't hold the mutex,
and instead used atomics.
Unfortunately at item release, the item can be destroyed, and that
destruction path should be protected by a mutex (at least for
some objects).
Without this patch, it is possible an app thread is in a dtor
while another thread is making gallium nine calls. It is possible
that two threads are using the same gallium pipe, which is forbiden.
The problem has been made worse with csmt, because it can cause hang,
since nine_csmt_process is not threadsafe.
Fixes Hitman hang, and possibly others.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Flush the queue to get refcounts right, and properly
release the items, instead of throwing away all pending
commands.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
nine_context uses NineSurface9 fields, thus we need to flush
pending commands using the surface before changing the fields.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
There is no need to check on csmt_active before
calling nine_csmt_process, because the function
checks already.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
When dirty region is empty, u_box_union_* incorrectly expands
the new region.
This fixes broken font rendering issue in WOLF RPG Editor v2.10 games.
Signed-off-by: Masanori Kakura <kakurasan@gmail.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Drop $(srcdir)/ prefix analogous to before the file (and rule) movement
and move it outside of the NEED_RADEON_LLVM conditional.
Otherwise the build may fail as below.
make[3]: *** No rule to make target 'common/sid_tables.h', needed by 'distdir'. Stop.
Fixes: b838f64237 "ac/debug: Move sid_tables.h generation to common
code."
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Changes from V1 -> V2:
- updated Copyright
- added $(top_srcdir)/src/gallium/winsys to include path (suggested by Emil)
- adapted driver to new renderonly API
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
This driver supports a wide range of Vivante IP cores like GC880,
GC1000, GC2000 and GC3000.
Changes from V1 -> V2:
- added missing files to actually integrate the driver into build system.
- adapted driver to new renderonly API
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
This a very lightweight library to add basic support for renderonly
GPUs. A kms gallium driver must specify how a renderonly_scanout
objects gets created. Also it must provide file handles to the used
kms device and the used gpu device.
This could look like:
struct renderonly ro = {
.create_for_resource = renderonly_create_gpu_import_for_resource,
.kms_fd = fd,
.gpu_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC)
};
The renderonly_scanout object exits for two reasons:
- Do any special treatment for a scanout resource like importing the
GPU resource into the scanout hw.
- Make it easier for a gallium driver to detect if anything special
needs to be done in flush_resource(..) like a resolve to linear.
A GPU gallium driver which gets used as renderonly GPU needs to be
aware of the renderonly library.
This library will likely break android support and hopefully will get
replaced with a better solution based on gbm2.
Changes from V1 -> V2:
- reworked the lifecycle of renderonly object (suggested by Nicolai Hähnle)
- killed the midlayer (suggested by Thierry Reding)
- made the API more explicit regarding gpu and kms fd's
- added some docs
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Once again, SPIR-V is insane... It allows you to place "patch"
decorations on structure members. Presumably, this is so that you can
do something such as
out struct S {
layout(location = 0) patch vec4 thing1;
layout(location = 0) vec4 thing2;
} str;
And have your I/O "nicely" organized. While this is a bit silly, it's
allowed and well-defined so whatever. Where it really gets interesting
is when you have an array of struct. SPIR-V says nothing about not
allowing you to have those qualifiers on the members of a struct that's
inside an array and GLSLang does this. Specifically, if you have
layout(location = 0) out patch struct S {
vec4 thing1;
vec4 thing2;
} str[2];
then GLSLang will place the "patch" decorations on the struct members.
This is ridiculous there is no way that having some of them be patch and
some not would be well-defined given that patch and non-patch outputs
are in effectively different storage classes. This commit moves around
the way we handle the "patch" decoration so that we can detect even the
crazy cases and handle them.
Fixes: dEQP-VK.tessellation.user_defined_io.per_patch_block_array.*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch implements vk_icdNegotiateLoaderICDInterfaceVersion(), which
brings us to loader interface v3.
v2:
- Drop the pragmas. [emil]
- Advertise v3 instead of v2. Anvil supported more than I
thought. [jason]
- s/Surface/SurfaceKHR/ in comments. [emil]
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Cc: mesa-stable@lists.freedesktop.org
Cc: Jason Ekstrand <jason@jlekstrand.net>
We can't import the latest vk_icd.h because the new header breaks the
Mesa build. This patch defines new casting macros,
ICD_DEFINE_NONDISP_HANDLE_CASTS() and ICD_FROM_HANDLE(), which can
handle both the old and new vk_icd.h, and will prevent the build from
breaking when we update the header.
In the old vk_icd.h, types were defined as:
typedef struct _VkIcdFoo {
...
} VkIcdFoo;
Commit 6ebba1f6 in the Vulkan loader changed the above to
typedef {
...
} VkIcdFoo;
because the old definitions violated the C and C++ specs. According to
the specs, identifiers that begins with an underscore followed by an
uppercase letter are reserved. (It's pedantic, I know), See the Github
issue referenced below.
References: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/7
References: 6ebba1f630
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Cc: mesa-stable@lists.freedesktop.org
Defer delete on regular resources. This ensures that any work being done
on the resource is completed before freeing up the resource's memory.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Although, arb_shader_image_load_store-atomicity will most likely
hang your box, I think it's now quite reasonable to enable GL 4.3
on Maxwell/Pascal GPUs. I suspect that test to be wrong because
it doesn't even work on the NVIDIA blob.
I have tested a bunch of benchmarks (UE4 demos) and real games
like Shadow of Mordor and they all work fine.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Yes, IMUL/IMAD require dependency barriers and we should
definitely replace these instructions by XMAD but the
different flags need to be figured out. Note that XMAD only
supports 16-bits integers.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre Moreau <pierre.morrow@free.fr>
This makes use of scheduling control codes which are very useful
for improving the instruction pipelining.
This patch will increase performance on Maxwell GPUs by, at least,
x1.5 up to x3.5 for some benchmarks.
Although this has been fairly well tested, I would not be suprised
if someone hit a corner case somewhere. That way, the scheduler
is enabled by default but it can be deactivated by using
NV50_PROG_SCHED=0.
Thanks to Scott Gray for the reverse engineering work available from
https://github.com/NervanaSystems/maxas/wiki/Control-Codes.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Pierre Moreau <pierre.morrow@free.fr>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
It's actually useless to insert those texture barriers post RA
because the current control code (ie. st 0x0) will wait for all
dependencies before issuing a new instruction.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Pierre Moreau <pierre.morrow@free.fr>
GL_ARB_vertex_attrib_64bit was the last piece missing.
v2: update docs (Jordan)
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
For dvec3 and dvec4 types, a single GRF do not have enough space to
allocate two inputs from two different vertices (SIMD4x2).
So the GRF only contains first two components for the two vertices, and
the next GRF has the remaining components.
We want to put all the components for the same vertex in the same
register. Thus, we do a shuffle to reorder the data.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Doubles needs more that one slot per attribute. So when filling the
attribute_map we check if it is a double in order to allocate one
extra register.
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Doubles need extra space, so we would need to do a remapping for vec4
too in order to take that into account. We reuse the already
existing remap_vs_attrs, but passing is_scalar, so they could
remap accordingly.
v2: code-format remap_vs_attrs_params initialization (Matt)
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
As part of the payload setup, setup_attributes is called with the first
GRF that can be used for the attributes (first ones are used for
uniforms for example) and returns the first GRF that is not part of the
payload. Before this patch, it adds directly the number of attributes.
But as with 64-bit attributes can consume more than one slot, that is
not valid anymore. This patch change the addition to use the number of
slots consumed.
gen >= 8 would not be affected, as they use the scalar mode. For that
case, the vs configuration is done at fs_visitor::assign_vs_urb_setup.
v2: add explanation in commit log (Jordan)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
gen < 8 doesn't support *64*PASSTHRU formats when emitting
vertices. So in order to provide the equivalent functionality, we need
to downsize the format to equivalent *32*FLOAT, and in some cases
(R64G64B64 and R64G64B64A64) submit two 3DSTATE_VERTEX_ELEMENTS for
each vertex element.
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Although gen7 doesn't include surface types as a valid conversion format,
we return it, as it reflects what we want to achieve, even if we need
to workaround it on gen < 8.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
From OpenGL 3.1 spec, section 4.3.1 "Reading Pixels", page 190 (203 PDF)
"When READ FRAMEBUFFER BINDING is zero, i.e. the default
framebuffer, src must be one of the values listed in table 4.4,
including NONE . FRONT_AND_BACK , FRONT , and LEFT refer to the
front left buffer."
There is an equivalent text on OpenGL 4.5 spec, section 18.2.1
"Selecting Buffers for Reading", page 502 (524 PDF), so the behaviour
is still the same.
Part of the fix for:
GL45-CTS.direct_state_access.framebuffers_draw_read_buffers_errors
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Before 4.5, GL_BACK was not allowed as a value of bufs. Since 4.5 it
is allowed under some circumstances:
From the OpenGL 4.5 specification, Section 17.4.1 "Selecting Buffers
for Writing", page 493 (page 515 of the PDF):
"An INVALID_ENUM error is generated if any value in bufs is FRONT,
LEFT, RIGHT, or FRONT_AND_BACK . This restriction applies to both
the de- fault framebuffer and framebuffer objects, and exists
because these constants may themselves refer to multiple buffers, as
shown in table 17.4."
And on page 492 (page 514 of the PDF):
"If the default framebuffer is affected, then each of the constants
must be one of the values listed in table 17.6 or the special value
BACK . When BACK is used, n must be 1 and color values are written
into the left buffer for single-buffered contexts, or into the back
left buffer for double-buffered contexts."
This patch keeps the same behaviour if OpenGL version is < 4. We
assume that for 4.x this is the intended behaviour, so a fix, but for
3.x the intended behaviour is the already in place.
Part of the fix for:
GL45-CTS.direct_state_access.framebuffers_draw_read_buffers_errors
v2: remove forgot printf
v3: remove spaces before commas on spec quote, split line too
long (Anuj)
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Predication needs cmd parser only on gen7. For newer platforms, it
should be available without it.
v2 (Ken): rebase on recent changes.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Currently its dependant on the user calling and checking the result
of list_empty() before using the result of list_is_singular().
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Without this check, the kernel::bind() method would fail with a
std::out_of_range exception, letting an exception escape from the
library into the client, rather than returning the corresponding error
code CL_INVALID_PROGRAM_EXECUTABLE.
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Otherwise we will end up with an extra instruction to compare the
result of the inot.
On BDW:
total instructions in shared programs: 13060620 -> 13060481 (-0.00%)
instructions in affected programs: 103379 -> 103240 (-0.13%)
helped: 127
HURT: 0
total cycles in shared programs: 256590950 -> 256587408 (-0.00%)
cycles in affected programs: 11324730 -> 11321188 (-0.03%)
helped: 114
HURT: 21
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We turn these from bcsel into inot/b2f combos in order for other
optimisation passes to get further. Once we have finished turn
the ones that remain and are used in more than a single expression
back into a bcsel.
On BDW:
total instructions in shared programs: 13060965 -> 13060297 (-0.01%)
instructions in affected programs: 835701 -> 835033 (-0.08%)
helped: 670
HURT: 2
total cycles in shared programs: 256599536 -> 256598006 (-0.00%)
cycles in affected programs: 114655488 -> 114653958 (-0.00%)
helped: 419
HURT: 240
LOST: 0
GAINED: 1
The 2 HURT is because inserting bcsel creates the only use of
const 1.0 in two shaders from tri-of-friendship-and-madness.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
While the below stats are encouraging this pass will also become
very usefull for avoiding regression once
brw_do_channel_expressions() and brw_do_vector_splitting() are
disabled.
On Broadwell:
total instructions in shared programs: 13078787 -> 13060898 (-0.14%)
instructions in affected programs: 1809827 -> 1791938 (-0.99%)
helped: 4527
HURT: 157
total cycles in shared programs: 256562762 -> 256590424 (0.01%)
cycles in affected programs: 159749392 -> 159777054 (0.02%)
helped: 5583
HURT: 2289
total spills in shared programs: 14929 -> 14923 (-0.04%)
spills in affected programs: 62 -> 56 (-9.68%)
helped: 1
HURT: 0
total fills in shared programs: 20144 -> 20141 (-0.01%)
fills in affected programs: 253 -> 250 (-1.19%)
helped: 1
HURT: 3
LOST: 0
GAINED: 2
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I'm going to add a boolean scheduling pass that I want run late, but
after copy propagation and dead code elimination. Yet, I don't want
to have to think about registers. So, move the register conversion
a little later.
No impact on shader-db. Suggested by Jason Ekstrand.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This tries to move comparisons (a common source of boolean values)
closer to their first use. For GPUs which use condition codes,
this can eliminate a lot of temporary booleans and comparisons
which reload the condition code register based on a boolean.
V2: (Timothy Arceri)
- fix move comparision for phis so we dont end up with:
vec1 32 ssa_227 = phi block_34: ssa_1, block_38: ssa_240
vec1 32 ssa_235 = feq ssa_227, ssa_1
vec1 32 ssa_230 = phi block_34: ssa_221, block_38: ssa_235
- add nir_op_i2b/nir_op_f2b to the list of comparisons.
V3: (Timothy Arceri)
- tidy up suggested by Jason.
- add inot/fnot to move comparison list
V4: (Jason Ekstrand)
- clean up move_comparison_source
- get rid of the tuple
- rework phi handling
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
before commit f871946594
image_loader_extension was always present in dri2_dpy->extensions,
after that commit it is only present for render nodes.
Its removal broke partial render based on buffer age on (at least)
raspberry pi.
Fixes: f871946594 "egl/dri2: rework dri2_egl_display::extensions storage"
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In parse_identifier, it doesn't stop copying '*pcur'
untill encounter the NULL. As the 'ret' has a
fixed-size buffer, if the '*pcur' has a long string,
there will be a buffer overflow. This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
this is to avoid following compilation error on Android:
error: control may reach end of non-void function [-Werror,-Wreturn-type]
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Geometry and Tessellation stages do handle this as a system value instead.
Fixes:
dEQP-VK.geometry.basic.primitive_id
Reviewed-by: Dave Airlie <ailried@redhat.com>
Sometimes it is useful to disable the "growable" cmdstream buffers for
debugging. (See 419a154d in libdrm)
Signed-off-by: Rob Clark <robdclark@gmail.com>
Now that issues glamor was hitting w/ glsl>=130 (aka missing INSTANCED
bit in vertex attribute state) is fixed, remove hack.
Signed-off-by: Rob Clark <robdclark@gmail.com>
When there are no framebuffer attachments, fb->width and fb->height will
be 0. Subtracting 1 results in 4294967295 which is too large for the
field, causing genxml assertions when trying to create the packet.
In this case, we can just program it to 1.
Caught by dEQP-VK.tessellation.tesscoord.triangles_equal_spacing.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
In Vulkan, we always have both the TCS and TES available in the same
pipeline, so we can simply use the TCS OutputVertices execution mode
value as the TES PatchVertices built-in.
For GLSL, we handle this in the linker. But we could use this pass
in the case when both TCS and TES are linked together, if we wanted.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We need to:
- handle the extra array level for per-vertex varyings
- handle the patch qualifier correctly
- assign varying locations
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Annoyingly, SPIR-V lets you specify all of these fields in either the
TCS or TES, which means that we need to be able to store all of them
for either shader stage. Putting them in a union won't work.
Combining both is an easy solution, and given that the TCS struct only
had a single field, it's pretty inexpensive.
This patch renames the combined struct to "tess" to indicate that it's
for tessellation in general, not one of the two stages.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
With shaders using a lot of inputs/outputs, like this (from Gtk+) :
layout(location = 0) in vec2 inPos;
layout(location = 1) in float inGradientPos;
layout(location = 2) in flat int inRepeating;
layout(location = 3) in flat int inStopCount;
layout(location = 4) in flat vec4 inClipBounds;
layout(location = 5) in flat vec4 inClipWidths;
layout(location = 6) in flat ColorStop inStops[8];
layout(location = 0) out vec4 outColor;
we're missing the programming of the input_slots_valid field leading
to an assert further down the backend code.
v2: Use valid slots of the geometry or vertex stage (Jason)
v3: Use helper to find correct vue map (Jason)
v4: Set the valid slots off the previous stages (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fix this build error with GCC 4.4.7.
CC nir/nir_opt_copy_prop_vars.lo
nir/nir_opt_copy_prop_vars.c: In function ‘copy_prop_vars_block’:
nir/nir_opt_copy_prop_vars.c:765: error: unknown field ‘deref’ specified in initializer
nir/nir_opt_copy_prop_vars.c:765: warning: missing braces around initializer
nir/nir_opt_copy_prop_vars.c:765: warning: (near initialization for ‘(anonymous).<anonymous>’)
nir/nir_opt_copy_prop_vars.c:765: warning: initialization from incompatible pointer type
Fixes: 62332d139c ("nir: Add a local variable-based copy propagation pass")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
This just adds the nir->llvm support, enabling
the extension causes some failures on llvm 3.9 at least,
but this code seems fine.
NIR passes the sampler in src[1].x, and we LLVM/SI requires
it as the last parameters in the coords (coord[2] for 2D,
coord[3] for 2DArray).
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
According to OpenGL Shading Language 4.50 spec, Section 8.7 "Vector
Relational Functions", functions of this type do not operate on scalar
types, so remove scalar types from signature definitions to make the
behavior consistent with glslangValidator and other drivers.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
The foreach loop was called both in the else case and right after. The
indentation seems to indicate that the extra call was from a previous
version with an else section with out curly brackets.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We want vue_map->num_slots to be one more than the final slot.
When assigning fixed slots, built-in slots, and non-SSO user varyings,
we do slot++. This leaves "slot" as one past the most recently assigned
slot. But for SSO user varyings, we computed slot based on the varying
location value...and left it at that slot value.
To work around this inconsistency, I made num_slots be "slot + 1" if
separate and "slot" otherwise. The problem is...if there are no user
varyings in SSO mode...then we would have done slot++ when assigning
built-ins, so it would be off by one. This resulted in loops from 0
to vue_map->num_slots hitting a bonus BRW_VARYING_SLOT_PAD at the end.
This used to break the SIMD8 VS/TES backends, but I fixed that in
commit 480d6c1653. It's probably safe
at this point, but we should fix it anyway.
To fix this, do slot++ in all cases. For SSO mode, we overwrite slot
for every varying, so this increment only matters on the last varying.
Because we process varyings in order, this will set slot to 1 more
than the highest assigned slot.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
vtn_ssa_value() can produce variable loads, and the cursor might
be after a return statement, causing nir_builder assert failures
about not inserting instructions after a jump.
This fixes:
dEQP-VK.spirv_assembly.instruction.graphics.barrier.in_if
dEQP-VK.spirv_assembly.instruction.graphics.barrier.in_switch
Cc: "13.0 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This fixes broken depth texturing after:
commit 22639a6e19
Author: Timothy Arceri <timothy.arceri@collabora.com>
Date: Mon Nov 21 00:29:29 2016 +1100
st/mesa: get Version from gl_program rather than gl_shader_program
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Also changed RADV_SHOW_QUEUES to a no compute queue option. That
would make more sense later when the compute queue is established,
but the transfer queue still experimental.
v2: Don't include the trace flag.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This is for handling chained command buffers and secondary command
buffers. It doesn't handle the trace id for secondary command buffers
yet, but I don't think that is possible in general with just writes,
as we could call a secondary command buffer multiple times.
I think this is good enough for now, as the most useful case is the
chaining when we grow an IB.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
v2:
- Now use the filename specified by RADV_TRACE_FILE env var.
- Use the same var to enable tracing.
I thought we could as well always set the filename explicitly
instead of having some arbitrary defaults, and at that point
we don't need a separate feature enable.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This fixes layered rendering Vulkan CTS tests with cube (arrays). We
also do this in the GL driver, see this code from gen8_depth_state.c
for example:
case GL_TEXTURE_CUBE_MAP_ARRAY:
case GL_TEXTURE_CUBE_MAP:
/* The PRM claims that we should use BRW_SURFACE_CUBE for this
* situation, but experiments show that gl_Layer doesn't work when we do
* this. So we use BRW_SURFACE_2D, since for rendering purposes this is
* equivalent.
*/
surftype = BRW_SURFACE_2D;
depth *= 6;
break;
So I guess we simply forgot to port this workaround to Vulkan.
v2: tweak the conditions so the special case is cube texture sampling
rather than anything else (Jason)
Fixes:
dEQP-VK.geometry.layered.cube*
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This is the same we do in the GL driver: the hardware provides gl_Layer
in the VUE header, so when the fragment shader reads it we can't skip it.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v2 (Jason):
- Use nir_spirv_supported_extensions to check if the feature is enabled.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
So far, input_reads was a bitmap tracking which vertex input locations
were being used.
In OpenGL, an attribute bigger than a vec4 (like a dvec3 or dvec4)
consumes just one location, any other small attribute. So we mark the
proper bit in inputs_read, and also the same bit in double_inputs_read
if the attribute is a dvec3/dvec4.
But in Vulkan, this is slightly different: a dvec3/dvec4 attribute
consumes two locations, not just one. And hence two bits would be marked
in inputs_read for the same vertex input attribute.
To avoid handling two different situations in NIR, we just choose the
latest one: in OpenGL, when creating NIR from GLSL/IR, any dvec3/dvec4
vertex input attribute is marked with two bits in the inputs_read bitmap
(and also in the double_inputs_read), and following attributes are
adjusted accordingly.
As example, if in our GLSL/IR shader we have three attributes:
layout(location = 0) vec3 attr0;
layout(location = 1) dvec4 attr1;
layout(location = 2) dvec3 attr2;
then in our NIR shader we put attr0 in location 0, attr1 in locations 1
and 2, and attr2 in location 3 and 4.
Checking carefully, basically we are using slots rather than locations
in NIR.
When emitting the vertices, we do a inverse map to know the
corresponding location for each slot.
v2 (Jason):
- use two slots from inputs_read for dvec3/dvec4 NIR from GLSL/IR.
v3 (Jason):
- Fix commit log error.
- Use ladder ifs and fix braces.
- elements_double is divisible by 2, don't need DIV_ROUND_UP().
- Use if ladder instead of a switch.
- Add comment about hardware restriction in 64bit vertex attributes.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We use *64*_PASSTHRU formats to upload vertex attributes of 64 bits
to avoid conversions. From the BDW PRM, Volume 2d, page 586
(VERTEX_ELEMENT_STATE):
"When SourceElementFormat is set to one of the *64*_PASSTHRU
formats, 64-bit components are stored in the URB without any
conversion. In this case, vertex elements must be written as 128
or 256 bits, with VFCOMP_STORE_0 being used to pad the output
as required. E.g., if R64_PASSTHRU is used to copy a 64-bit Red
component into the URB, Component 1 must be specified as
VFCOMP_STORE_0 (with Components 2,3 set to VFCOMP_NOSTORE)
in order to output a 128-bit vertex element, or Components 1-3 must
be specified as VFCOMP_STORE_0 in order to output a 256-bit vertex
element. Likewise, use of R64G64B64_PASSTHRU requires Component 3
to be specified as VFCOMP_STORE_0 in order to output a 256-bit vertex
element."
v2,v3 (Jason):
- Don't delete unused formats.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
SPIR-V does not have special opcodes for DF conversions. We need to identify
them by checking the bit size of the operand and the result.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This function returns the nir_op corresponding to the conversion between
the given nir_alu_type arguments.
This function lacks support for integer-based types with bit_size != 32
and for float16 conversion ops.
v2:
- Improve readiness of the code and delete cases that don't happen now (Jason)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We need to pick two 32-bit values per component to perform the right shuffle operation.
v2 (Jason):
- Add assert to check matching bit sizes (Jason)
- Simplify the code to pick components (Jason)
v3:
- Switch on bit_size once (Jason)
- Add comment to explain the constant value for unused components (Erik)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
In Vulkan, we'll compile the TCS and TES at the same time, so I can just
pass the TCS output VUE map to brw_compile_tes as the TES input VUE map.
So, we only need to do this in GL. Move it to the GL-specific layer.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The vertex order is either clockwise or counterclockwise. We can just
store a "ccw" boolean rather than GLenum values. I don't want to use
GLenums in a Vulkan driver, and even in GL a simple boolean works fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I apparently broke mark_whole_variable in ir_set_program_inouts.
It was passing a type that wasn't var->type, so the wrapper didn't
work out. It's all broken, revert it and start over.
Fixes all kinds of things on other drivers.
Revert "glsl: Make is_fixed_function_array actually check for varyings."
This reverts commit 42699e1271.
Revert "glsl: Mark whole variable used for ClipDistance and TessLevel*."
This reverts commit 5c580e64cc.
Revert "glsl: Override the # of varying slots for ClipDistance and TessLevel*."
This reverts commit 8b5749f65a.
Revert "glsl: Create and use a new ir_variable::count_attribute_slots() wrapper."
This reverts commit 6aa5cb34d0.
We can't check VARYING_SLOT_* locations until we've determined that
the variable is actually a varying.
Fixes assert failures in drivers which actually use this path,
such as radeonsi and i915.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99314
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Marking operations as redundant if they are equal to the base
range is fine when the tree structure is something like this:
max
/ \
max b
/ \
3 max
/ \
3 a
But the opt falls apart with a tree like this:
max
/ \
max max
/ \ / \
3 a b 3
The problem is that both branches are treated the same: descending in
the left branch will prune the constant, and then descending the right
branch will prune the constant there as well, because limits[0] wasn't
updated to take the change on the left branch into account, and so we
still get [3,\infty) as baserange.
In order to fix the bug we just disable the marking of redundant expressions
when they match the baserange.
NIR algebraic opt will clean up the first tree for anyway, hopefully
other backends are smart enough to do this also.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
We run this after nir_lower_vars_to_ssa so that as many load/store_var
intrinsics as possible before copy_prop_vars executes. This is because the
pass isn't particularly efficient (it does a lot of linear walks of a
linked list) so we'd like as much of the work as possible to be done before
copy_prop_vars runs.
Shader DB results on Sky Lake:
total instructions in shared programs: 12020290 -> 12013627 (-0.06%)
instructions in affected programs: 26033 -> 19370 (-25.59%)
helped: 16
HURT: 13
total cycles in shared programs: 137772848 -> 137549012 (-0.16%)
cycles in affected programs: 6955660 -> 6731824 (-3.22%)
helped: 217
HURT: 237
total loops in shared programs: 3208 -> 3208 (0.00%)
loops in affected programs: 0 -> 0
helped: 0
HURT: 0
total spills in shared programs: 4112 -> 4057 (-1.34%)
spills in affected programs: 483 -> 428 (-11.39%)
helped: 2
HURT: 0
total fills in shared programs: 5519 -> 5102 (-7.56%)
fills in affected programs: 993 -> 576 (-41.99%)
helped: 2
HURT: 0
LOST: 0
GAINED: 0
Broadwell had similar results. On older hardware, the impact isn't as
large because they don't advertise GL 4.5. Of the hurt programs, all but
one are hurt by a single instruction and the one is hurt by 3 instructions.
All of the helped programs, on the other hand, are helped by at least 3
instructions and one kerbal space program shader is helped by 44.59%.
The real star of the show, however, is the Gl43CSDof synmark2 benchmark
which has two shaders which are cut by 28% and 40% and the over-all runtime
performance of the benchmark on my Sky Lake laptop is improved by around
25-30% (it's a bit hard to be exact due to thermal throttling).
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Because border color is handled pre-swizzle, when we move the alpha
channel around in the format, the OPAQUE_BLACK border colors don't work
correctly on B4G4R4A4_UNORM_PACK16 with the hack. This fixes the
following Vulkan CTS tests on Broadwell:
dEQP-VK.pipeline.sampler.view_type.2d_array.format.b4g4r4a4_unorm_pack16.address_modes.all_mode_clamp_to_border_opaque_black
dEQP-VK.pipeline.sampler.view_type.1d_array.format.b4g4r4a4_unorm_pack16.address_modes.all_mode_clamp_to_border_opaque_black
dEQP-VK.pipeline.sampler.view_type.2d.format.b4g4r4a4_unorm_pack16.address_modes.all_mode_clamp_to_border_opaque_black
dEQP-VK.pipeline.sampler.view_type.1d.format.b4g4r4a4_unorm_pack16.address_modes.all_mode_clamp_to_border_opaque_black
dEQP-VK.pipeline.sampler.view_type.3d.format.b4g4r4a4_unorm_pack16.address_modes.all_mode_clamp_to_border_opaque_black
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Interpreting layerCount literally would try to create billions of image
views in radv_process_depth_image_inplace().
Signed-off-by: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Treating everything as scalar arrays allows us to drop a bunch of
special case input/output munging all throughout the backend.
Instead, we just need to remap the TessLevel components to the
appropriate patch URB header locations in remap_patch_urb_offsets().
We also switch to treating the TES input versions of these as ordinary
shader inputs rather than system values, as remap_patch_urb_offsets()
just makes everything work out without special handling.
This regresses one Piglit test:
arb_tessellation_shader-large-uniforms/GL_TESS_CONTROL_SHADER-array-at-limit
The compiler starts promoting the constant arrays assigned to gl_TessLevel*
to uniform arrays. Since the shader also has a uniform array that uses
the maximum number of uniform components, this puts it over the uniform
component limit enforced by the linker. This is arguably a bug in the
constant array promotion code (it should avoid pushing us over limits),
but is unlikely to penalize any real application.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
It's only used in one place, it ignores the offset parameter currently,
and I want to add more parameters...at which point, passing in a bunch
of integers seems less obvious than writing it out.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This is harmless today because gl_TessLevelInner/Outer in the TES is
currently treated as system values. However, when we move to treating
them as inputs, this would cause a bug: with no TCS present, it would
propagate TES reads of VARYING_SLOT_TESS_LEVEL into the VS output VUE
map slots. This is totally bogus - those don't even exist in the VS.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Upcoming reworks in i965 are going to make it easy to handle this
like any other input. Having it as a system value will just require
additional code for no benefit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
There's no point in trying to mark partial array access for
gl_ClipDistance, gl_TessLevelOuter, or gl_TessLevelInner - they're
special built-in variables that control fixed function hardware,
and will likely be used in an all-or-nothing fashion.
Since these arrays only occupy 1-2 varying slots, we have to avoid
our normal processing which increments the slot value by the array
index.
(I wrote this code before i965 switched from ir_set_program_inouts
to nir_shader_gather_info. It's not used by anyone today, and I'm
not sure how valuable it is...the alternative to GLSL IR lowering
is NIR compact arrays, at which point you should use nir_gather_info.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Right now, this shouldn't have any effect, as all drivers use
LowerClipDist and LowerTessFactors to turn the float[] arrays into
vectors.
However, it should help make it possible for drivers to avoid that
lowering.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This wraps glsl_type::count_attribute_slots(), but will soon contain a
couple of overrides for a couple of GLSL built-ins variables.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Generally we should do tranpose after conversion, if the format has less than
32 bits per channel (if it has 32 bits, conversion is going to be a no-op
anyway...). This is obviously because there's less vectors to deal with.
Though the advantage for 16 bit formats isn't that big, and in fact with AVX
there isn't really any (as the 32bit unpacks can be done with 256bit, but
the smaller ones cannot, although that would change again with proper AVX2
support).
Only makes sense for 2d and not 1d cases. And to keep things easy, only handle
1,2 and 4 channels (rgbx is just fine).
For rgba unorm8 format the backend conversion sums up to these instruction
totals (not counting the movs for SSE2 due to 2-op syntax - generally every 2
unpacks need an additional mov).
SSE2 AVX
transpose: 32 unpack 16 unpack
untwiddle: 0 8 (128bit low/high permutes)
convert: 16 mul + 16 cvt 8 mul + 8 cvt
32->8bit: 12 pack 8 (128bit extract) + 12 pack
When doing transpose/untwiddle afterwards we get:
convert: 16 mul + 16 cvt 8 mul + 8 cvt
32->8bit: 12 pack 8 (128bit extract) + 12 pack
transpose/untwiddle 12 unpack 12 unpack
So for SSE2, this drops 20 unpacks (total instruction count 76->56)
whereas for AVX it replaces the 16 256bit unpacks with 8 128bit ones
and drops the 8 lo/hi permutes (in total 60->48). (Albeit to be fair,
the permutes could be dropped even when doing the transpose first,
they are extremely pointless but we'd need to be able to tell
lp_build_conv to reorder the vectors, for AVX2 we're going to need to
be able to tell lp_build_conv about ordering in any case.)
(With different ordering going into conversion, it would be possible
to do 4 unpacks + 4 pshufbs instead of 12 unpacks, but that might not
be better, and not all cpus can do it. Proper AVX2 support should eliminate
the 8 128bit extracts, reduce these 12 packs to 6 and the 12 unpacks to 2
pshufb + 2 permq ideally (+ 2 final 128bit extracts).)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This special packing path can be easily extended to handle not just
float->unorm8 but also float->snorm8 and uint32->uint8 and int32->int8
(i.e. all interesting cases for llvmpipe fs backend code).
The packing parts all stay the same (only the last step packing will
be signed->signed instead of signed->unsigned but luckily even sse2 can do
both).
While here also note some bugs with that (we keep the bugs identical to
what we did before on x86, albeit other archs may differ). In particular
float->unorm8 too large values will still get clamped to 0, not 255, and for
float->snorm8 NaNs will end up as -1, not 0 (but we do the clamp against 1.0
there to prevent too large values ending up as -1.0 - this is inconsistent
to unorm8 handling but is what we ended up before, I'm not sure we can get
away without it). This is quite fishy in any case as we depend on
arch-dependent behavior of the iround (my understanding is in fact with
altivec the conversion would actually saturate although I've no idea about
NaNs, so probably wouldn't need to do anything for snorm).
(There are only minimal piglit tests for unorm clamping behavior AFAICT, in
particular nothing seems to test values which are too large to be handled by
the float->int conversion.)
For uint32->uint8 we also do a min against MAX_INT, since the source for
the packs is always signed (again, on x86 - should probably be able to
express these arch-dependent bits better some day).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
For rgbx formats, there is no point in doing alpha conversion again (and
with different tranpose even, so llvm can't eliminate it).
Albeit it looks like there's some minimal changes needed in the blend code
(found by code inspection, no test seemed to complain) if we do this -
the blend factors are already sanitized if we have no destination alpha,
however for src_alpha_saturate it looks like it still might make a
difference (note that we forced has_alpha to true before for some formats
and nothing complained, but this seems safer).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvm has _huge_ problems trying to load things like <4 x i8> vectors and
stitching such loads together to form 128bit vectors. My understanding
of the problem is that the type legalizer tries to extend that to
really a <4 x i32> vector and not a <16 x i8> vector with the 4 elements
first then followed by padding, so the shuffles for then combining things
together are more or less impossible - you can in fact see the pmovzxd
llvm generates. Pre-4.0 llvm just gives up on it completely and does a 30+
pextrb/pinsrb sequence instead.
It looks like current llvm has fixed this behavior (my guess would be
due to better shuffle combination and load/shuffle folds), but we can
avoid this by just loading as <1 x i32> values, combine that and only
cast at the end. (I suspect it might also work if we'd pad the loaded
vectors immediately before shuffling them together, instead of directly
stitching 2 such vectors together pairwise before combining the pair.
But this _might_ lose the ability to load the values directly into
their right place in the vector with pinsrd.). But using 32bit values
is probably easier for llvm as it will never give it funny ideas how
the vector should look like.
(This is possibly only a problem for 1x8bit formats, since 2x8bit will
end up fetching 64bit hence only two vectors are stitched together,
not 4, but we use the same strategy anyway.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The only reason we didn't previously enable this was the dependency on
OpenGL ES 3.1. These should have been enabled as soon as HSW got
stencil texturing. We also needed to fixup setting MaxViewports.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since 9d6ca7c3, there should be no performance hit for having
MaxViewports > 1. Always set this context state. This eliminates the
need to update this conditional as we add support for OES_viewport_array
on older GPUs.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The CS thread is needed to ensure proper ordering of operations and can't
be disabled (without complicating the code).
Discovered by Nine CSMT, which ended up in a deadlock.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Fixes a number of transform feedback tests when run with Linux 4.8,
which allows us to use the MI_LOAD_REGISTER_REG command, at which point
we started using this new broken path.
ES3-CTS.functional.transform_feedback.array_element.interleaved.lines.*
and Piglit's arb_transform_feedback2/draw-auto are both fixed by this
patch, for example.
Thanks to Chris Wilson for catching this mistake!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99030
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
We were failing to zero m0.2 of the sampler message header for TCS and
GS messages in the simple case. fs_generator has done this for about
a year now, but we missed it in vec4_generator.
Fixes ES31-CTS.core.texture_cube_map_array.sampling,
GL45-CTS.texture_cube_map_array.sampling, and many
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler subtests:
- dynamically_uniform.tessellation_control.isampler3d
- dynamically_uniform.tessellation_control.isamplercube
- dynamically_uniform.tessellation_control.sampler2d
- dynamically_uniform.tessellation_control.usamplercube
- dynamically_uniform.tessellation_control.sampler2darray
- dynamically_uniform.tessellation_control.isampler2darray
- dynamically_uniform.tessellation_control.usampler3d
- dynamically_uniform.tessellation_control.usampler2darray
- dynamically_uniform.tessellation_control.usampler2d
- dynamically_uniform.tessellation_control.sampler3d
- dynamically_uniform.tessellation_control.samplercube
- dynamically_uniform.tessellation_control.isampler2d
- uniform.tessellation_control.isampler3d
- uniform.tessellation_control.isamplercube
- uniform.tessellation_control.usampler2d
- uniform.tessellation_control.usampler3d
- uniform.tessellation_control.sampler2darray
- uniform.tessellation_control.isampler2darray
- uniform.tessellation_control.usampler2darray
- uniform.tessellation_control.sampler2d
- uniform.tessellation_control.usamplercube
- uniform.tessellation_control.sampler3d
- uniform.tessellation_control.samplercube
- uniform.tessellation_control.isampler2d
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fix incorrect swizzling in SIMD16 Transpose_16_16 breaking the
two-channel 16-bpc formats like R16G16_FLOAT.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
A while ago, we stopped using Luca's GLSL IR lower_jumps pass in favor
of nir_lower_returns(). Marek's commit d3cb79e043
put it in do_common_optimization, which resulted in us calling it again.
Dropping the EmitNoMainReturn setting makes us skip that pass again.
Apparently that pass doesn't work properly, because this fixes Piglit's
tests/spec/glsl-1.10/execution/vs-nested-return-sibling-loop.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99287
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The T images are composed of effectively swizzled-around blocks of LT (4x4
utile) images, so we can reduce the t_utile_address() calls by 16x by
calling into the simpler LT loop.
This also adds support for calling down with non-utile-aligned
coordinates, which will be part of lifting the utile alignment requirement
on our callers and avoiding the RMW on non-utile-aligned stores.
Improves 1024x1024 TexSubImage by 2.55014% +/- 1.18584% (n=46)
Improves 1024x1024 GetTexImage by 2.242% +/- 0.880954% (n=32)
They now have less of a dependency on the cpp, and don't have to do a
divide.
Hacking up mesa-demos teximage to do only one subtest and not draw
points, I saw 1024x1024 glTexSubImage2D() improve by 4.86939% +/-
1.40408% (n=30) and glGetTexImage() by 2.18978% +/- 0.140268% (n=5).
If we get up toward 256MB (or whatever the CMA area size is),
VC4_GEM_CREATE will start throwing errors. Even if we don't trigger
that, when we flush the kernel's BO allocation for the CLs or bin
memory may end up throwing an error, at which point our job won't get
rendered at all.
Just flush early (half of maximum CMA size) so that hopefully we never
get to that point.
This will help allow us to simplify the handling of samplers by
storing them in a single location rather than duplicating them in
both gl_linked_shader and gl_program.
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that we create gl_program earlier there is no need to mess about
copying things to gl_linked_shader then to gl_program.
Reviewed-by: Eric Anholt <eric@anholt.net>
There is no need to loop over active samplers the code above this
would have already exited if the sampler was inactive, or errored
if the count was larger than the uniforms array size.
Reviewed-by: Eric Anholt <eric@anholt.net>
Making this point to a gl_program struct rather than a gl_shader_program
struct will allow use to later also make the CurrentProgram array hold
gl_program structs which in turn will allow for code simpilifcation.
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that we have the is_arb_asm flag we can just skip the
initialisation.
V2: remove hack from standalone compiler where it was never
needed since it only compiles glsl shaders.
Reviewed-by: Eric Anholt <eric@anholt.net>
Set the flag via the _mesa_init_gl_program() and NewProgram()
helpers.
In i965 we currently check for the existance of gl_shader_program
to decide if this is an ARB assembly style program or not.
Adding a flag makes the code clearer and will help removes a
dependency on gl_shader_program in the i965 codegen functions.
Also this will allow use to skip initialising sampler units for
linked shaders, we currently memset it to zero again during linking.
Reviewed-by: Eric Anholt <eric@anholt.net>
We can now just get the data needed from the gl_shader_program_data
pointer in gl_program.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Having it here rather than in gl_linked_shader allows us to simplify
the code.
Also it is error prone to depend on the gl_linked_shader for programs
in current use because a failed linking attempt will free infomation
about the current program. In i965 we could be trying to recompile
a shader variant but may have lost some required fields.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Here we also remove the duplicate field in gl_linked_shader and always
get the value from shader_info instead.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This will help allow us to store pointers to gl_program structs in the
CurrentProgram array resulting in a bunch of code simplifications.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This also removes the duplicate field in gl_linked_shader, and
gets num_ubos from shader_info instead.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Having it here rather than in gl_linked_shader allows us to simplify
the code.
Also it is error prone to depend on the gl_linked_shader for programs
in current use because a failed linking attempt will free infomation
about the current program. In i965 we could be trying to recompile
a shader variant but may have lost some required fields.
We drop the memset on ImageUnits because gl_program is already
created using rzalloc().
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This removes another dependency on gl_shader_program from the codegen functions,
this will help allow us to use gl_program for the CurrentProgram array rather
than gl_shader_program.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Rather then passing gl_shader_program.
The only field use was Name which is the same as the Id field in
gl_program.
For wm and vs we also make the functions static and move them before
the codegen functions.
This change reduces the codegen functions dependency on gl_shader_program.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fix typo using wrong (uninitialized) build context introduced by
4634cb5921. (This only affects very rare
small packed formats which have a PIPE_SWIZZLE_0 channel, such as
r4a4, which is never used by mesa/st. Nevertheless it broke lp_test_format.)
Using bit replication. This path now resembles something which might make
sense. (The logic was mostly copied from llvmpipe fs backend.)
I am not convinced though it is actually faster than SoA sampling (actually
I'm quite certain it's always a loss with AVX).
With SoA it's just shift/mask/cvt/mul for getting the colors, whereas
there's still roughly 3 shifts, 3 or/and per channel for AoS
(i.e. for SoA it's exactly the same as it would be for a rgba8 format,
whereas the extra effort for AoS is significant). The filtering
might still be faster (albeit with FMA the instruction count gets down
quite a bit there on the SoA float filtering path on new cpus). And those
small unorm formats often don't have an alpha channel (which makes things
worse relatively for AoS path).
(This also fixes a trivial bug in the llvmpipe fs code this was derived
from, albeit it was only relevant for 4-bit channels.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This code uses a vector shift which has to be emulated on x86 unless
there's AVX2. Luckily in some cases we can actually avoid the shift
altogether, so do that.
Also make sure we hit the fast lp_build_conv() path when applicable,
albeit that's quite the hack...
That said, this path is taken for AoS sampling for small unorm (smaller
than rgba8) formats, and it is completely hopeless even with those
changes, with or without AVX.
(Probably should have some code similar to the one in the llvmpipe fs
backend code, using bit replication to extend to rgba8888 - rounding
is not quite 100% accurate but if it's good enough there it should be
here as well.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
If we only feed one source vector at a time, we cannot use pack intrinsics
(as we only have a 64bit destination dst vector). lp_bld_conv_auto is
specifically designed to alter the length and number of destination vectors,
so this works just fine (if we use single source vectors at a time, afterwards
we immediately reassemble the vectors).
For AVX though this isn't really possible, since we expect 128bit output
already for a single 256bit input. (One day we should handle AVX2 which again
would need multiple inputs, however there's the problem that we get different
ordered output there and we don't want to reorder, so would need to be able
to tell build_conv to handle upper and lower halfs independently.)
A similar strategy would probably work for 32->8bit too (if it doesn't hit
the special case) but I'm going to try something different for that...
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
simd instruction sets usually have comparisons for equal, not unequal.
So use a different comparison against the mask itself - which also means
we don't need a all-zero as well as a all-one (for the pxor) reg.
Also add code to avoid scalar expansion of i1 values which we definitely
shouldn't do. There's problems with this though with llvm select
interaction, so it's disabled (basically using llvm select instead of
intrinsics may still produce atrocious code, even in cases where we
figured it should not, albeit I think this could probably be fixed
with some better selection of optimization passes, but I have zero
idea there really).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The specification section 9.4 says :
When an application attempts to create many pipelines in a single
command, it is possible that some subset may fail creation. In that
case, the corresponding entries in the pPipelines output array will
be filled with VK_NULL_HANDLE values. If any pipeline fails
creation (for example, due to out of memory errors), the
vkCreate*Pipelines commands will return an error code. The
implementation will attempt to create all pipelines, and only
return VK_NULL_HANDLE values for those that actually failed.
Fixes :
dEQP-VK.api.object_management.alloc_callback_fail_multiple.graphics_pipeline
dEQP-VK.api.object_management.alloc_callback_fail_multiple.compute_pipeline
v2: C is hard let's go shopping (Lionel)
v3: Remove unnecessary condition in for loops (Lionel)
v4: Document why we return on first failure (Eduardo)
Move i declaration inside for() (Eduardo)
v5: Move array cleanup out of loop (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
In OpenGL 3.0 and later it is legal to make a context current without
a default framebuffer.
This has been broken since DRI3 support was introduced.
Cc: "13.0 12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Draw calls no longer flush SDMA IBs. r600_need_dma_space is
responsible for synchronizing execution between both IBs.
Initial buffer clears and fast clears will stay unflushed in the SDMA IB
(up to 64 MB) as long as the GFX IB isn't flushed either.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Call r600_dma_emit_wait_idle only when there is a possibility of
a read-after-write hazard. Buffers not yet used by the SDMA IB don't
have to wait.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
r600_dma_emit_wait_idle is going away in its current form.
The only difference is that the moved code is executed before DMA calls
instead of after them.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Old test caused breakage with llvm-svn (4.0.0svn), and not needed as
the minimum required llvm version for swr is 3.6.
Reviewed-by: George Kyriazis <george.kyriazis@intel.com>
wrap lp_bld_type.h around extern "C".
Windows decorates global variables, so when used from .cpp files, need
to use an undecorated version.
Also, removed related and unneeded code from swr_screen.cpp
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
GLSL compilation now takes 24% less time with the Gallium noop driver.
I used my shader-db for the measurement. The difference for the whole
radeonsi driver can be ~10%.
The generated TGSI is mostly the same. For example, the compilation success
rate with a TGSI->GCN bytecode converter without any optimizations is
the same. Note that glsl_to_tgsi does its own copy propagation and simple
register allocation.
shader-db GCN report:
- Talos spills fewer SGPRs.
- DOTA 2 spills more SGPRs.
- The average shader-db score is better, but it's just due to randomness.
29045 shaders in 17564 tests
Totals:
SGPRS: 1325929 -> 1325017 (-0.07 %)
VGPRS: 1010808 -> 1010172 (-0.06 %)
Spilled SGPRs: 1432 -> 1399 (-2.30 %)
Spilled VGPRs: 93 -> 92 (-1.08 %)
Private memory VGPRs: 688 -> 688 (0.00 %)
Scratch size: 2540 -> 2484 (-2.20 %) dwords per thread
Code Size: 39336732 -> 39342936 (0.02 %) bytes
Max Waves: 217937 -> 217969 (0.01 %)
Reviewed-by: Eric Anholt <eric@anholt.net>
If the VUE map has slots at the end which the shader does not write,
then we'd "flush" (constructing an URB write) on the last output it
actually wrote. Then, we'd construct another SEND with EOT, but with
no actual payload data. That's not legal.
For example, SSO programs have clip distance slots allocated no matter
what, but the shader may not write them. If it doesn't write any user
defined varyings, then the clip distance slots will be the last ones.
Found while debugging
dEQP-VK.tessellation.shader_input_output.gl_position_vs_to_tcs_to_tes
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We can use this to track various features that may or may not be supported
by the hw / kernel. Currently, we usually do this by checking the generation
and supported command parser versions in various places thoughtout the driver
code. With this patch, we centralize all these checks in just once place at
screen creation time, then we just query the bitfield wherever we need to
check if a particular feature is supported.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Moving the test to the screen places it alongside the other global HW
feature tests that want to be shared between contexts.
Also, we need to know if we support pipelined register writes at
screen creation time so that we can tell if we can expose OpenGL 4.0
in gen7.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Some of the existing tests were using '@' and '"' incidentally within the test
body. Neither of these characters are actually legal for GLSL. And since we
are planning to start generating errors for illegal characters, we need to
first make the test suite clean.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Here, each legal character (as defined by GLSL Language Specification version
4.30.6, section 3.1) appears at least once in the input file. Obviously,
characters with special meaning (like '#' and '\') aren't treated exhaustively
with respect to all their possible uses. We have many other tests for that.
Here, we're simply ensuring that the test suite sees every legal character at
least once.
v2 (by Ken): Fix expectations, move to src/compiler, renumber tests.
Carl's .expected: Updated .expected:
.. ..
. . . .
. . . .
. . . .
. . . .
. ..
. .
. .
.
(For some reason, the original test expected ".." to produce two lines.
glcpp, cpp, and mcpp all follow my updated behavior, so I believe it to
be correct.)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Of course, these aren't really useful for anything, but the GLSL language
specification does allow them:
The source character set used for the OpenGL shading languages,
outside of comments, is a subset of UTF-8. It includes the following
characters:
...
White space: the space character, horizontal tab, vertical tab, form
feed, carriage-return, and line- feed.
[GLSL Language Specification 4.30.6, section 3.1]
So treat vertical tab ('\v' or ^K) and form-feed ('\f' or ^L) as horizontal
space characters.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
GCC's preprocessor accepts a macro definition where there is no space between
the macro's identifier name and the replacementlist. (GCC does emit a "missing
space" warning that we don't, but that's fine.)
This is an exhaustive test that verifies that all legal GLSL characters that
could possibly be interpreted as separating the macro name from the
replacement list are interpreted as such. So the testing here includes all
valid GLSL symbols except for:
* Characters that can be part of an identifier (a-z, A-Z, 0-9, _)
* Backslash, (allowed only as line continuation)
* Hash, (allowed only to introduce pre-processor directive, or as part of a
paste operator in a replacement list---but not as first token of
replacement list)
* Space characters (since the point of the testing is to have missing space)
* Left parenthesis (which would indicate a function-like macro)
v2 (Ken): Move to src/compiler, renumber tests.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Useful when debugging with R600_DEBUG=vm,check_vm to match
addr in both outputs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes performance regression in SynMark PSPom caused by loops with float
counters not always unrolling.
For example:
for (float i = 0.02; i < 0.9; i += 0.11)
...
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Make sure unused ops and their references are removed, prior to entering
the GCM (global code motion) pass, to stop GCM from breaking the loop
logic and thus hanging the GPU.
Turns out, that sb has problems with loops and node optimizations
regarding associative folding:
- the global code motion (gcm) pass moves ops up a loop level/basic block
until they've fulfilled their total usage count
- if there are ops folded into others, the usage count won't be
fulfilled and thus the op moved way up to the top
- within GCM the op would be visited and their deps would be moved
alongside it, to fulfill the src constaints
- in a loop, an unused op is moved out of the loop and GCM would move
the src value ops up as well
- now here arises the problem: if the loop counter is one of the src
values it would get moved up as well, the loop break condition would
never get hit and the shader turn into an endless loop, resulting in the
GPU hanging and being reset
A reduced (albeit nonsense) piglit example would be:
[require]
GLSL >= 1.20
[fragment shader]
uniform int SIZE;
uniform vec4 lights[512];
void main()
{
float x = 0;
for(int i = 0; i < SIZE; i++)
x += lights[2*i+1].x;
}
[test]
uniform int SIZE 1
draw rect -1 -1 2 2
Which gets optimized to:
===== SHADER #12 OPT ================================== PS/BARTS/EVERGREEN =====
===== 42 dw ===== 1 gprs ===== 2 stack =========================================
ALU 3 @24
1 y: MOV R0.y, 0
t: MULLO_UINT R0.w, [0x00000002 2.8026e-45].x, R0.z
LOOP_START_DX10 @22
PUSH @6
ALU 1 @30 KC0[CB0:0-15]
2 M x: PRED_SETGE_INT __.x, R0.z, KC0[0].x
JUMP @14 POP:1
LOOP_BREAK @20
POP @14 POP:1
ALU 2 @32
3 x: ADD_INT R0.x, R0.w, [0x00000002 2.8026e-45].x
TEX 1 @36
VFETCH R0.x___, R0.x, RID:0 MFC:16 UCF:0 FMT[..]
ALU 1 @40
4 y: ADD R0.y, R0.y, R0.x
LOOP_END @4
EXPORT_DONE PIXEL 0 R0.____ EOP
===== SHADER_END ===============================================================
Notice R0.z being the loop counter/break condition relevant register
and being never incremented at all. Also some of the loop content
has been moved out of it, to fulfill the requirements for the one unused
op.
With a debug build of mesa this would produce an error like
error at : PRED_SETGE_INT __, __, EM.2, R1.x.2||FP@R0.z, C0.x
: operand value R1.x.2||FP@R0.z was not previously written to its gpr
and the compilation would fail due to this. On a release build it gets
passed to the GPU.
When using this patch, the loop remains intact:
===== SHADER #12 OPT ================================== PS/BARTS/EVERGREEN =====
===== 48 dw ===== 1 gprs ===== 2 stack =========================================
ALU 2 @24
1 y: MOV R0.y, 0
z: MOV R0.z, 0
LOOP_START_DX10 @22
PUSH @6
ALU 1 @28 KC0[CB0:0-15]
2 M x: PRED_SETGE_INT __.x, R0.z, KC0[0].x
JUMP @14 POP:1
LOOP_BREAK @20
POP @14 POP:1
ALU 4 @30
3 t: MULLO_UINT T0.x, [0x00000002 2.8026e-45].x, R0.z
4 x: ADD_INT R0.x, T0.x, [0x00000002 2.8026e-45].x
TEX 1 @40
VFETCH R0.x___, R0.x, RID:0 MFC:16 UCF:0 FMT[..]
ALU 2 @44
5 y: ADD R0.y, R0.y, R0.x
z: ADD_INT R0.z, R0.z, 1
LOOP_END @4
EXPORT_DONE PIXEL 0 R0.____ EOP
===== SHADER_END ===============================================================
Piglit: ./piglit summary console -d results/*_gpu_noglx
name: unpatched_gpu_noglx patched_gpu_noglx
---- ------------------- -----------------
pass: 18016 18021
fail: 748 743
crash: 7 7
skip: 1124 1124
timeout: 0 0
warn: 13 13
incomplete: 0 0
dmesg-warn: 0 0
dmesg-fail: 0 0
changes: 0 5
fixes: 0 5
regressions: 0 0
total: 19908 19908
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94900
Tested-by: Heiko Przybyl <lil_tux@web.de>
Tested-on: Barts PRO HD6850
Signed-off-by: Heiko Przybyl <lil_tux@web.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Our editorconfig file looked sensible, saying that we wanted to indent
with spaces and use 3/4/whatever space indentation. However, the spec has
this little surprise:
"tab_width: a whole number defining the number of columns used to
represent a tab character. This defaults to the value of indent_size
and doesn't usually need to be specified."
so once my editor started respecting editorconfig, the files that have
tabs left in them started getting rendered wrong, showing up like this in
brw_program.c:
case GL_COMPUTE_PROGRAM_NV: {
struct brw_program *prog = rzalloc(NULL, struct brw_program);
if (prog) {
prog->id = get_new_program_id(brw->screen);
return _mesa_init_gl_program(&prog->program, target, id);
}
else
return NULL;
}
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Fixes tests 'dEQP-GLES3.functional.texture.mipmap.*.generate.rgba5551*' on
Intel Broadwell 0x1616.
The GL 4.5 spec describes the algorithm of glGenerateMipmap as:
The contents of the derived images are computed by repeated, filtered
reduction of the level base image. [...] No particular filter algorithm is
required, though a box filter is recommended as the default filter.
Consider a texture for which all pixels are identical at level 0.
From the spec's description above, one may reasonably assume that the "filtered
reduction" of level 0 produces a new miplevel for which again all pixels are
identical. For any 2x2 subspan of identical pixels, it is difficult to see how
the "filtered reduction" of that subspan can produce a pixel that differs from
the source pixels.
Dithering during _mesa_meta_GenerateMipmap() violated that reasonable
assumption.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99210
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
In its current state the unified i965 backend for
AMD_performance_monitor and INTEL_performance_query isn't able to report
meaningful Observation Architecture metrics since we haven't so far had
the necessary kernel support to fully configure the OA unit, nor the
corresponding support for normalizing the counters into a form that can
be usefully interpreted by application developers (as opposed to raw
values that may, for example, scale by the number of EUs there are).
So that we can focus on implementing just one of these extensions fully
and since we anticipate some significant backend changes as we look to
use a new kernel interface to configure the OA unit, this patch removes
the current backend. This will simplify our ability to update the
frontend infrastructure and backend interface before updating our
support for performance counters.
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
FROM_DOUBLE opcodes are setup so that they use a dst register
with a size of 2 even if they only produce a single-precison
result (this is so that the opcode can use the larger register to
produce a 64-bit aligned intermediary result as required by the
hardware during the conversion process). This creates a problem for
spilling though, because when we attempt to emit a spill for the
dst we see a 32-bit destination and emit a scratch write that
allocates a single spill register, making the intermediary writes
go beyond the size of the allocation.
Prevent this by avoiding to spill the destination register of these
opcodes.
Alternatively, we can avoid this by splitting the opcode in two: one
that produces a 64-bit aligned result and one that takes the 64-bit
aligned result as input and produces a 32-bit result from it.
Reviewed-by: Matt Turner <mattst88@gmail.com>
When 64-bit registers are (un)spilled, we need to execute data shuffling
code before writing to or after reading from memory. If we have instructions
that operate on 64-bit data via 32-bit instructions, (un)spills for the
register produced by 32-bit instructions will not do data shuffling at all
(because we only see a normal 32-bit istruction seemingly operating on
32-bit data). This means that subsequent reads with that register using DF
access will unshuffle data read from memory that was never adequately
shuffled when it was written.
Fixing this would require to identify which 32-bit instructions write
64-bit data and emit spill instructions only when the full 64-bit
data has been written (by multiple 32-bit instructions writing to different
offsets of the same register) and always emit 64-bit unspills whenever
64-bit data is read, even when the instruction uses a 32-bit type to read
from them.
Reviewed-by: Matt Turner <mattst88@gmail.com>
The current spilling code can't spill vgrf allocations larger than 1
but SIMD4x2 doubles require 2 vgrfs, so we need to permit this case (which
is handled properly for DF data types by emitting 2 scratch messages and
doing data shuffling). We accomplish this by not auto-disabling spilling
for vgrf allocations with a size of 2, and then disable spilling on any
register with an offset != 0B (which indicates array access).
Disable spilling of partial DF reads/writes because these don't read/write
data for both logical threads and our scratch messages for 64-bit data
need data for both threads to be present.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Spilling of 64-bit data requires data shuffling for the corresponding
scratch read/write messages. This produces unsupported swizzle regions
and writemasks that we need to scalarize.
Reviewed-by: Matt Turner <mattst88@gmail.com>
8-wide compressed DF operations are executed as two separate 4-wide
DF operations. In that scenario, we have to be careful when we allocate
register space for their operands to prevent the case where the first
half of the instruction overwrites the source of the second half.
To do this we mark compressed instructions as having hazards to make
sure that ther register allocators assigns a register regions for the
destination that does not overlap with the region assigned for any
of its source operands.
Reviewed-by: Matt Turner <mattst88@gmail.com>
By exploiting gen7's hardware decompression bug with vstride=0 we gain the
capacity to support additional swizzle combinations.
This also fixes ZW writes from X/Y channels like in:
mov r2.z:df r0.xxxx:df
Because DF regions use 2-wide rows with a vstride of 2, the region generated
for the source would be r0<2,2,1>.xyxy:DF, which is equivalent to r0.xxzz, so
we end up writing r0.z in r2.z instead of r0.x. Using a vertical stride of 0
in these cases we get to replicate the XX swizzle and write what we want.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Certain swizzles like XYZW can be supported by translating only the first two
64-bit swizzle channels to 32-bit channels. This happens with swizzles such
that the first two logical components, when translated to 32-bit channels and
replicated across the second dvec2 row, select the same channels specified by
the 3rd and 4th logical swizzle components.
Notice that this opens up the possibility that some instructions are not
scalarized and can end up with XY or ZW 32-bit writemasks. Make sure we always
scalarize in such cases.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Stages that use interleaved attributes generate regions with a vstride=0
that can hit the gen7 hardware decompression bug.
v2:
- Make static the function and fix indent (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
This came in handy when debugging the payload setup for Tess Eval,
since it prints correct subnr for attributes that can be loaded
in the second half of a register.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Use a width of 2 with 64-bit attributes.
Also, if we have a dvec3/4 attribute that gets split across two registers
such that components XY are stored in the second half of a register and
components ZW are stored in the first half of the next, we need to fix
regioning for any instruction that reads components Z/W of the attribute.
Notice this also means that we can't support sources that read cross-dvec2
swizzles (like XZ for example).
v2: don't assert that we have a single channel swizzle in the case that we
have to fix up Z/W access on the first half of the next register. We
can handle any swizzle that does not cross dvec2 boundaries, which
the double scalarization pass should have prevented anyway.
Reviewed-by: Matt Turner <mattst88@gmail.com>
We need to shuffle the data before it is written to the URB. Also,
dvec3/4 need two vec4 slots.
v2: use byte_offset() instead of offset().
Reviewed-by: Matt Turner <mattst88@gmail.com>
This way callers don't need to know about 64-bit particularities and
we reuse some code.
v2:
- use byte_offset() instead of offset()
- only mark the surface as used once
Reviewed-by: Matt Turner <mattst88@gmail.com>
Mostly the same stuff as usual: we ned to shuffle the data before we
write and we need to emit two 32-bit write messages (with appropriate
32-bit writemask channels set) for a full dvec4 scratch write.
v2: use byte_offset() instead of offset().
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Setup for a 64-bit scratch read by checking the type size of the
correct register
v3: Use byte_offset() instead of offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
A vec4 is 16 bytes and a dvec4 is 32 bytes so for doubles we have
to multiply the reladdr by 2. The reg_offset part is in units of 16
bytes and is used to select the low/high 16-byte chunk of a full
dvec4, so we don't want to multiply that part of the address.
Reviewed-by: Matt Turner <mattst88@gmail.com>
64-bit scratch read/writes require to shuffle data around so we need
to have access to the full 64-bit data. We will do the right thing
for these when we emit the messages.
Reviewed-by: Matt Turner <mattst88@gmail.com>
The BDW PRM says that it is not supported, but it seems that gen7 is also
affected, since doing DepCtrl on double-float instructions leads to
GPU hangs in some cases, which is probably not surprising knowing that
this is not supported in new hardware iterations. The SKL PRMs do not
mention this restriction, so it is probably fine.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This means we would copy propagate partial reads or writes and that can affect
the result.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Otherwise we end up producing code that violates the register region
restriction that says that when execsize == width and hstride != 0
the vstride can't be 0.
Reviewed-by: Matt Turner <mattst88@gmail.com>
In gen < 8 instructions that write more than one register need to read
more than one register too. Make sure we don't break that restriction
by copy propagating from a uniform.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Because the meaning of the swizzles and writemasks involved is different,
so replacing the source would lead to different semantics.
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Also check if the instruction source target is 64-bit. (Samuel)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
In this case we need to shuffle the 64-bit data before we write it
to memory, source from reg_offset + 1 to write components Z and W
and consider that each DF channel is twice as big.
v2: use byte_offset() instead of offset().
Reviewed-by: Matt Turner <mattst88@gmail.com>
Same requirements as for UBO loads.
v2:
- use byte_offset() instead of offset() (Iago)
- keep the const. offset as an immediate like the original code did (Juan)
Reviewed-by: Matt Turner <mattst88@gmail.com>
We need to emit 2 32-bit load messages to load a full dvec4. If only
1 or 2 double components are needed dead-code-elimination will remove
the second one.
We also need to shuffle the result of the 32-bit messages to form
valid 64-bit SIMD4x2 data.
v2:
- use byte_offset() instead of offset() (Iago)
- keep the const. offset as an immediate like the original code did (Juan)
Reviewed-by: Matt Turner <mattst88@gmail.com>
SIMD4x2 64bit data is stored in register space like this:
r0.0:DF x0 y0 z0 w0
r1.0:DF x1 y1 z1 w1
When we need to write data such as this to memory using 32-bit write
messages we need to shuffle it in this fashion:
r0.0:DF x0 y0 x1 y1
r0.1:DF z0 w0 z1 w1
and emit two 32-bit write messages, one for r0.0 at base_offset
and another one for r0.1 at base_offset+16.
We also need to do the inverse operation when we read using 32-bit messages
to produce valid SIMD4x2 64bit data from the data read. We can achieve this
by aplying the exact same shuffling to the data read, although we need to
apply different channel enables since the layout of the data is reversed.
This helper implements the data shuffling logic and we will use it in
various places where we read and write 64bit data from/to memory.
v2 (Curro):
- Use the writemask helper and don't assert on the original writemask
being XYZW.
- Use the Vec4 IR builder to simplify the implementation.
v3 (Iago):
- Use byte_offset() instead of offset().
v3:
- Fix typo (Matt)
- Clarify the example and fix indention (Matt).
Reviewed-by: Matt Turner <mattst88@gmail.com>
The previous patch made sure that we do not generate MAD instructions
for any NIR's 64-bit ffma, but there is nothing preventing i965 from
producing MAD instructions as a result of lowerings or optimization
passes. This patch makes sure that any 64-bit MAD produced inside the
driver after translating from NIR is also converted to MUL+ADD before
we generate code.
v2:
- Use a copy constructor to copy all relevant instruction fields from
the original mad into the add and mul instructions
v3:
- Rename the lowering and fix commit log (Matt)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
RepCtrl=1 does not work with 64-bit operands so we need to use RepCtrl=0.
In that situation, the regioning generated for the sources seems to be
equivalent to <4,4,1>:DF, so it will only work for components XY, which
means that we have to move any other swizzle to a temporary so that we can
source from channel X (or Y) in MAD and we also need to split the instruction
(we are already scalarizing DF instructions but there is room for
improvement and with MAD would be more restricted in that area)
Also, it seems that MAD operations like this only write proper output for
channels X and Y, so writes to Z and W also need to be done to a temporary
using channels X/Y and then move that to channels Z or W of the actual dst.
As a result the code we produce for native 64-bit MAD instructions is rather
bad, and much worse than just emitting MUL+ADD. For reference, a simple case
of a fully scalarized dvec4 MAD operation requires 15 instructions if we use
native MAD and 8 instructions if we emit ADD+MUL instead. There are some
improvements that we can do to the emission of MAD that might bring the
instruction count down in some cases, but it comes at the expense of a more
complex implementation so it does not seem worth it, at least initially.
This patch makes translation of NIR's 64-bit FMMA instructions produce MUL+ADD
instead of MAD. Currently, there is nothing else in the vec4 backend that emits
MAD instructions, so this is sufficient and it helps optimization passes see
MUL+ADD from the get go.
Reviewed-by: Matt Turner <mattst88@gmail.com>
We make scalar sources in 3src instructions use subnr instead of
swizzles because they don't really use swizzles.
With doubles it is more complicated because we use vstride=0 in
more scenarios in which they don't produce scalar regions. Also
RepCtrl=1 is not allowed with 64-bit operands, so we should avoid
this.
v2: Fix typo (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Specifically, at least for now, we don't want to deal with the fact that
channel sizes for fp64 instructions are twice the size, so prevent
coalescing from instructions with a different type size.
Also, we should check that if we are coalescing a register from another
MOV we should be writing the same amount of data in both operations, otherwise
we end up wiring more or less than the original instruction. This can happen,
for example, when we have split fp64 MOVs with an exec size of 4 that only
write one register each and then a MOV with exec size of 8 that reads both.
We want to avoid the pass to think that it can coalesce from the first split
MOV alone. Ideally we would like the pass to see that it can coalesce from both
split MOVs instead, but for now we keep it simple.
Finally, the pass doesn't support coalescing of multiple registers but in the
case of normal SIMD4x2 double-precision instructions they naturally write two
registers (one per vertex) and there is no reason why we should not allow
coalescing in this case. Change the restriction to bail if we see instructions
that write more than 8 channels, where the channels can be 32-bit or 64-bit.
v2:
- Make sure that scan_inst and inst write the same amount of data.
Reviewed-by: Matt Turner <mattst88@gmail.com>
There is a single bit for this, so it is a binary 0 or 1 meaning
offset 0B or 16B respectively.
v2:
- Since brw_inst_dst_da16_subreg_nr() is known to be 1, remove it
from the expression (Curro)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The general idea is that with 32-bit swizzles we cannot address DF
components Z/W directly, so instead we select the region that starts
at the the 16B offset into the register and use X/Y swizzles.
The above, however, has the caveat that we can't do that without
violating register region restrictions unless we probably do some
sort of SIMD splitting.
Alternatively, we can accomplish what we need without SIMD splitting
by exploiting the gen7 hardware decompression bug for instructions
with a vstride=0. For example, an instruction like this:
mov(8) r2.x:DF r0.2<0>xyzw:DF
Activates the hardware bug and produces this region:
Component: x0 y0 z0 w0 x1 y1 z1 w1
Register: r0.2 r0.3 r0.2 r0.3 r1.2 r1.3 r1.2 r1.3
Where r0.2 and r0.3 are r0.z:DF for the first vertex of the SIMD4x2
execution and r1.2 and r1.3 are the same for the second vertex.
Using this to our advantage we can select r0.z:DF by doing
r0.2<0,2,1>.xyxy and r0.w by doing r0.2<0,2,1>.zwzw without needing
to split the instruction.
Of course, this only works for gen7, but that is the only hardware
platform were we implement align16/fp64 at the moment.
v2: Adapted to the fact that we now do this after converting to
hardware registers (Iago)
Reviewed-by: Matt Turner <mattst88@gmail.com>
The hardware can only operate with 32-bit swizzles, which is a rather
limiting restriction. However, the idea is not to expose this to the
optimization passes, which would be a mess to deal with. Instead, we let
the bulk of the vec4 backend ignore this fact and we fix the swizzles right
at codegen time.
At the moment the pass only needs to handle single value swizzles thanks to
the scalarization pass that runs before it.
Notice that this only works for X/Y swizzles. We will add support for Z/W
swizzles in the next patch, since they need a bit more work.
v2 (Sam):
- Do not expand swizzle of 64-bit immediate values.
v3:
- Do this after translation to hardware registers instead of doing it right
before so we don't need the force_vstride0 flag (Curro).
- Squashed patch that included FIXED_GRF in the list of register files that
need this translation (Iago).
- Remove swizzle assignments for VGRF and UNIFORM files in
convert_to_hw_regs(), they will be set by apply_logical_swizzle() (Iago).
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The hardware only supports 32-bit swizzles, which means that we can
only access directly channels XY of a DF making access to channels ZW
more difficult, specially considering the various regioning restrictions
imposed by the hardware. The combination of both things makes handling
ramdom swizzles on DF operands rather difficult, as there are many
combinations that can't be represented at all, at least not without
some work and some level of instruction splitting depending on the case.
Writemasks are 64-bit in general, however XY and ZW writemasks also work
in 32-bit, which means these writemasks can't be represented natively,
adding to the complexity.
For now, we decided to try and simplify things as much as possible to
avoid dealing with all this from the get go by adding a scalarization
pass that runs after the main optimization loop. By fully scalarizing
DF instructions in align16 we avoid most of the complexity introduced
by the aforementioned hardware restrictions and we have an easier path
to an initial fully functional version for the vector backend in Haswell
and IvyBridge.
Later, we can improve the implementation so we don't necessarily
scalarize everything, iteratively adding more complexity and building
on top of a framework that is already working. Curro drafted some ideas
for how this could be done here:
https://bugs.freedesktop.org/show_bug.cgi?id=92760#c82
v2:
- Use a copy constructor for the scalar instructions so we copy all
relevant instructions fields from the original instruction.
v3: Fix indention in one switch (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
There is a hardware bug affecting compressed double-precision SEL
instructions in align16 mode by which they won't read predication mask
properly. The bug does not affect other predicated instructions
and it does not affect SEL in Align1 mode either. This was found
empirically and verified by Curro in the simulator.
Fix this by splitting double-precision SEL in Align16 mode to use an
execution size of 4.
v2: Check that the dst type is 64-bit, since we can have 16-wide single
precision bcsel instructions that also write 2 registers.
v3: Replace bcsel by SEL in all the comments as bcsel is the nir opcode
but SEL is the actual assembly instruction (Matt).
Reviewed-by: Matt Turner <mattst88@gmail.com>
We can't propagate the conditional modifier from one instruction to
another of a different execution size / group, since that would change
the channels affected by the conditional.
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2 (Curro):
- Print it also for execsize < 4.
- QtrCtrl is still in effect, so print 2 * qtr_ctl + nib_ctl + 1
- Do not read the nib ctl from the instruction in gen < 7,
the field only exists in gen7+.
Reviewed-by: Matt Turner <mattst88@gmail.com>
From the HSW PRM, Command Reference, QtrCtrl:
"NibCtrl is only allowed for SIMD4 instructions with a DF (Double Float)
source or destination type."
v2: Assert that the type is DF (Samuel)
v3: Don't set the default group to 0 and then set it only for 4-wide
instructions. Instead, assert that exec size and group are always
a correct match and then always set the default group from the
instruction. (Curro)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Generally, instructions in Align16 mode only ever write to a single
register and don't need any form of SIMD splitting, that's why we
have never had a SIMD splitting pass in the vec4 backend. However,
double-precision instructions typically write 2 registers and in
some cases they run into certain hardware bugs and limitations
that we need to work around by splitting the instructions so we only
write to 1 register at a time. This patch implements a SIMD splitting
pass similar to the one in the scalar backend.
Because we only use double-precision instructions in Align16 mode
in gen7 (gen8+ is fully scalar and gens < 7 do not implement fp64)
the pass should be a no-op on any other generation.
For now the pass only handles the gen7 restriction where any
instruction that writes 2 registers also needs to read 2 registers.
This affects double-precision instructions reading uniforms, for
example. Later patches will extend the lowering pass adding a few
more cases.
v2:
- Move the simd lowering pass after the main optimization loop and
run copy-propagation and dce if it reports progress (Curro)
- Compute number of registers written instead of fixing it to 1 (Iago)
- Use group from backend_instruction (Iago)
- Drop assertion that checked that we only split 8-wide instructions
into 4-wide. (Curro)
- Don't assume that instructions can only be 8-wide, we might want
to use 16-wide instructions in the future too (Curro)
- Wrap gen7 workarounds in a conditional to ease adding workarounds
for other gens in the future (Curro)
- Handle dst/src overlap hazard (Curro)
- Use the horiz_offset() helper to simplify the implementation (Curro)
- Drop the assertion that checks that each split instruction writes
exactly one register (Curro)
- Use the copy constructor to generate split instructions with all
the relevant fields initialized to the values in the original
instruction instead of copying only a handful of them manually (Curro)
v3 (Iago):
- When copying to a temporary, allocate the number of registers required
for the copy based on the size written of the lowered instruction
instead of assuming that all lowered instructions produce single-register
writes
- Adapt to changes in offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Just like the exec_size, we are going to need this in the vec4 backend
when we implement a simd splitting pass.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This will come in handy when we implement a simd lowering pass in a
follow-up patch.
v2: use byte_offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Our current data flow analysis does not take into account that channels
on 64-bit operands are 64-bit. This is a problem when the same register
is accessed using both 64-bit and 32-bit channels. This is very common
in operations where we need to access 64-bit data in 32-bit chunks,
such as the double packing and packing operations.
This patch changes the analysis by checking the bits that each source
or destination datatype needs. Actually, rather than bits, we use
blocks of 32bits, which is the minimum channel size.
Because a vgrf can contain a dvec4 (256 bits), we reserve 8
32-bit blocks to map the channels.
v2 (Curro):
- Simplify code by making the var_from_reg helpers take an extra
argument with the register component we want.
- Fix a couple of cases where we had to update the code to the new
way of representing live variables.
v3:
- Fix indent in multiline expressions (Matt)
- Fix comment's closing tag (Matt)
- Use DIV_ROUND_UP(inst->size_written, 16) instead of 2 * regs_written(inst)
to avoid rounding issues. The same for regs_read(i). (Curro).
- Add asserts in var_from_reg() to avoid exceeding the allocated
registers (Curro).
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
In the vec4 backend the generator sets to 8 the execution size for all
instructions by default, however, to implement 64-bit floating-point we
will need to split certain instruction into smaller sizes so we need the
IR to convey this information like we do in the scalar backend. This patch
uses the execution size from the vec4 IR.
We will use this feature in a later patch when we implement a SIMD
splitting pass.
v2:
- Drop the assertion on the execution size being 8 or 4 (Curro)
- Use exec_size from backend_instruction (Curro)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Gen7 hardware does not support double immediates so these need
to be moved in 32-bit chunks to a regular vgrf instead. Instead
of doing this every time we need to create a DF immediate,
create a helper function that does the right thing depending
on the hardware generation.
v2 (Curro):
- Use swizzle() and writemask() helpers and make tmp const.
v3 (Iago):
- Adapt to changes in offset()
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: use a MOV with a conditional_mod instead of a CMP, like we do in d2b, to skip
loading a double immediate.
v3: Fix comment (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2 (Curro):
- Generate the flag register with a MOV with conditional_mod instead of a CMP
instruction, which has the benefit that we can skip loading a DF
0.0 constant.
- Avoid the PICK_LOW_32BIT + MOV by using the flag result and a
SEL to set the boolean result.
v3:
- Fix comment (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
From the BDW PRM, Workarounds chapter:
"DF->f format conversion for Align16 has wrong emask calculation when
source is immediate."
Notice that Broadwell and later are strictly scalar at the moment though, so
this is not really necessary.
v2: Instead of moving the immediate to a vgrf and converting from there, just
convert the double immediate to float in the compiler and move the result
to the destination (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Use these helpers to implement d2f and f2d. We will reuse these helpers when
we implement things like d2i or i2d as well.
v2:
- Rename the helpers (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
The opcodes are not specific for conversions to/from float since we need
the same for conversions to/from other 32-bit types. Rename the opcodes
accordingly and change the asserts to check the size of the types involved
instead.
v2:
- Rename to VEC4_OPCODE_TO_DOUBLE and VEC4_OPCODE_FROM_DOUBLE (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Make dst_reg_for_nir_reg() handle this for nir_register since we
want to have the correct type set before we call offset().
Reviewed-by: Matt Turner <mattst88@gmail.com>
Basically, ALIGN1 mode will ignore swizzles on the input vectors so we don't
want the copy propagation pass to mess with them.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These align1 opcodes do partial writes of 64-bit data. The problem is that we
want to use them to write on the same register to implement packDouble2x32 and
from the point of view of DCE, since both opcodes write to the same register,
only the last one stands and decides to eliminate the first, which is
not correct, so prevent this from happening.
v2: Make a helper in vec4_instruction to know if the instruction is an
align1 partial write. This will come in handy when we implement a
simd splitting pass in a later patch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These opcodes will set the low/high 32-bit in each 64-bit data element
using Align1 mode. We will use this to implement packDouble2x32.
We use Align1 mode because in order to implement this in Align16 mode
we would need to use 32-bit logical swizzles (XZ for low, YW for high),
but the IR works in terms of 64-bit logical swizzles for DF operands
all the way up to codegen.
v2:
- use suboffset() instead of get_element_ud()
- no need to set the width on the dst
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These opcodes will pick the low/high 32-bit in each 64-bit data element
using Align1 mode. We will use this, for example, to do things like
unpackDouble2x32.
We use Align1 mode because in order to implement this in Align16 mode
we would need to use 32-bit logical swizzles (XZ for low, YW for high),
but the IR works in terms of 64-bit logical swizzles for DF operands
all the way up to codegen.
v2:
- use suboffset() instead of get_element_ud()
- no need to set the width on the dst
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Add asserts so we remember to address this when we enable 64-bit
integer support, as suggested by Connor and Jason.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
For 32-bit instructions we want to use <4,4,1> regions for VGRF
sources so we should really set a width of 4 (we were setting 8).
For 64-bit instructions we want to use a width of 2 because the
hardware uses 32-bit swizzles, meaning that we can only address 2
consecutive 64-bit components in a row. Also, Curro suggested that
the hardware is probably fixing the width to 2 for 64-bit instructions
anyway, so just go with that and use <2,2,1>.
v2:
- No need to explicitly set the vertical stride of 64-bit regions to 2,
brw_vecn_grf with a width of 2 will do that for us.
- No need to adjust the width of dst registers.
v3 (Ian):
- Make type_size and width const.
Signed-off-by: Connor Abbott <connor.w.abbott@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These need to be emitted as align1 MOV's, since they need to have a
stride of 2 on the float register (whether src or dest) so that data
from another thread doesn't cross the middle of a SIMD8 register.
v2 (Iago):
- The float-to-double needs to align 32-bit data to 64-bit before doing the
conversion. This was doable in align16 when we tried to use an execsize
of 4, but with an execsize of 8 we would need another align1 opcode to do
that (since we need data to cross the middle of a SIMD register). Just
making the opcode handle this internally seems more practical that adding
another opcode just for this purpose and having the caller know about this
before converting.
- The double-to-float conversion produces 32-bit elements aligned to 64-bit
so we make the opcode re-pack the result to 32-bit and fit in one register,
as expected by SIMD4x2 operation. This still requires that callers reserve
two registers for the float data destination because we need to produce
64-bit aligned data first, and repack it later on the same destination
register, but it saves the need for a re-pack opcode only to achieve this
making the operation complete in a single opcode. Hopefully that is worth
the weirdness of the double register allocation...
Signed-off-by: Connor Abbott <connor.w.abbott@intel.com>
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Basically, this involves considering the bit-size information to set
the appropriate type on both operands and destination.
v2 (Curro)
- Don't use two temporaries (and write one of them twice ) to obtain
the nir_alu_type.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2 (Curro):
- Do not special-case for a bit-size of 64, divide the bit_size by 32
instead.
- Use DIV_ROUND_UP so we can handle sub-32-bit types.
v3 (Ian):
- Make num_regs const.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Less duplication, one one less case to handle for doubles and support
for sized NIR types.
v2: Fix call to get_instance by swapping rows and columns params (Iago)
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
max_vector_size is used in the vec4 backend to pad out the uniform
components to match a size that is a multiple of a vec4. Double and dvec2
uniforms only require a single vec4 slot, not two.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Otherwise, DIM instructions will be emitted with the default exec size
which could be 16 in some cases, that is not legal.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Suggested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We can just get this information from shader_info instead.
Note that passing gen6_gs_visitor() gl_program via _LinkedShaders
will go away in a later patch.
Reviewed-by: Eric Anholt <eric@anholt.net>
This removes another dependency on gl_shader_program in the codegen
functions which will help allow us to use gl_program in the
CurrentProgram array rather than gl_shader_program.
Reviewed-by: Eric Anholt <eric@anholt.net>
This disallows fancy varyings in tessellation and geometry shaders,
as required by ES 3.2.
Fixes:
dEQP-GLES31.functional.tessellation.user_defined_io.negative.per_patch_array_of_structs
dEQP-GLES31.functional.tessellation.user_defined_io.negative.per_patch_structs_containing_arrays
(Not a candidate for stable branches as it only disallows things which
should be working as desktop GL allows them.)
v2: Update error messages to not say "vertex shader" (caught by Iago).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
As CCS buffers are passed to KMS, it becomes useful to be able to
determine exactly what type of aux buffers are disabled. This was
previously not entirely needed (though the code was a little more
confusing), however it becomes very desirable after a recent patch from
Chad:
commit 1c8be049be
Author: Chad Versace <chadversary@chromium.org>
Date: Fri Dec 9 16:18:11 2016 -0800
i965/mt: Disable aux surfaces after making miptree shareable
The next patch will handle CCS and get rid of no_ccs.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Dump values for every selected data source in GALLIUM_HUD.
Every data source has its own file and the filename is
equal to the data source identifier.
Set GALLIUM_HUD_DUMP_DIR to dump values to files in this directory.
No values are dumped if the environment variable is not set, the
directory doesn't exist or the user doesn't have write access.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
The SPIR-V capability isn't even marked as enabled, and there are no
tests in Vulkan-CTS. Per Jason Ekstrand, this won't work in anv as such
write-only surfaces require additional setup which is currently not
performed.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
upload_3dstate_streamout can be called when there's no currently bound
transform feedback object. In this case, we get the default object,
which has a NULL shader (previously gl_shader_program, now gl_program).
The old code did something sketchy, but which worked:
const struct gl_transform_feedback_info *linked_xfb_info =
&xfb_obj->shader_program->LinkedTransformFeedback;
Here, if shader_program is NULL, this would be a bogus pointer of 0x60.
But we never actually dereferenced it, so it worked out.
With Timothy's recent reworks, we actually end up dereferencing
xfb_obj->program along the way, which crashes since it's NULL.
The solution is to move this pointer initialization into the "active"
block, where we know it actually exists and won't be bogus.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99231
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We also add the stubs for the standalone compiler in this change.
By adding a reference here we can now refactor some code to use
gl_program where we were previously awkwardly using gl_shader_program.
Reviewed-by: Eric Anholt <eric@anholt.net>
We were passing around a void *mem_ctx and using that to initialize the
builder which was wrong since that pointed to ralloc_parent(impl) which
is the shader but the builder is supposed to be initialized with the
nir_function_impl.
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This lets us get rid of the void *mem_ctx parameter and make things a
bit more type safe.
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We rename it to nir_deref_clone, re-order the sources to match the other
clone functions, and expose nir_deref_var_clone. This past part, in
particular, lets us get rid of quite a few lines since we no longer have
to call nir_copy_deref and wrap it in deref_as_var.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
See:
dEQP-GLES2.functional.shaders.swizzles.vector_swizzles.mediump_vec2_yyyy_fragment
if we only access (in FS) varying.y then it ends up in slot zero.. I'm
not sure the hw likes that..
Signed-off-by: Rob Clark <robdclark@gmail.com>
I forgot to do this in commit 76b97d544e ("anv: enable storage image
extended formats"). Since both drivers support this now, no need for the
conditional enable.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
I had this on transfers due to the clear color cmd, but
it seems like that path shouldn't get fast clears.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
After we figure out the value that we are going to return, we have a
loop that walks up the dominance tree and sets the value in each of the
blocks that doesn't have one yet. In the case of the phi, the def is
set to NEEDS_PHI not NULL, so the last one where the phi node actually
goes never gets filled out. This can lead to duplicating the phi node
unnecessarily.
After removing brw_shader in the previous commit this is no longer
needed.
V2: remove use in src/compiler/glsl/test_optpass.cpp
Reviewed-by: Eric Anholt <eric@anholt.net>
This will let us to make _CurrentFragmentProgram a gl_program pointer
allowing for simpilifications to be made.
We also need to add a field to gl_shader to hold it during parsing.
In gl_program we put it inside a union in anticipation of moving
more fields here that can be only fs or vertex stage fields.
Reviewed-by: Eric Anholt <eric@anholt.net>
This will allow us to make the CurrentProgram array store gl_program which allows
us to do a bunch of simplifications.
Reviewed-by: Eric Anholt <eric@anholt.net>
This will help allow us to store gl_program in the CurrentProgram array rather
than gl_shader_program which will allow a bunch of simplifications.
Note that we make LinkedTransformFeedback a pointer so we don't waste
memory creating a struct for each stage. We also store a pointer to
the gl_program that will contain the pointer in gl_shader_program so
we can get easy access to the correct stage.
Reviewed-by: Eric Anholt <eric@anholt.net>
We have already set the gl_shader_program pointer to the correct
shader program in _mesa_BeginTransformFeedback() so use it.
This is more consistent with how we do it for gen7.
Reviewed-by: Eric Anholt <eric@anholt.net>
This will be used in api_validate.c in a following patch when we
switch to using gl_program pointers for the pipelines CurrentProgram
array.
Reviewed-by: Eric Anholt <eric@anholt.net>
This will allow us to store gl_program rather than gl_shader_program
as the current program perstage which allows us to simplify code
that makes use of the CurrentProgram list.
Reviewed-by: Eric Anholt <eric@anholt.net>
This will allow us to simplify the current program logic for SSO.
Also since we aim to detach shader_info from nir_shader this will come
in handy avoiding passing nir_shader around just to keep track of
the stage we are dealing with.
V2: set stage for arb asm programs also.
Reviewed-by: Eric Anholt <eric@anholt.net>
Jonas's patch got us most of the benefit of scheduling instructions into
the delay slots of thread switch, but if there had been nothing to pair
the thrsw with, it would move the thrsw up and leave a NOP where the thrsw
was.
Instead, don't pair anything with thrsw through the normal scheduling
path, and have a separate helper function that inserts the thrsw earlier
if possible and inserts any necessary NOPs.
total instructions in shared programs: 93027 -> 92643 (-0.41%)
instructions in affected programs: 14952 -> 14568 (-2.57%)
Scan for instructions without a signal set in front of the switching
instruction and move the signal up there.
shader-db results:
total instructions in shared programs: 94494 -> 93027 (-1.55%)
instructions in affected programs: 23545 -> 22078 (-6.23%)
v2: Fix re-emitting of the instruction in the loop trying to emit NOPs,
drop a scheduling change from branch delay slots. (by anholt)
Signed-off-by: Jonas Pfeil <pfeiljonas@gmx.de>
I'm sure anv has support for these as well, but this is just
a first use of the interface to allow different supported spir-v
features.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use atomic ops when updating gl_shader::RefCount.
Fixes intermittent failures and crashes in
'dEQP-EGL.functional.sharing.gles2.multithread.*'.
All tests in that group now pass except
'dEQP-EGL.functional.sharing.gles2.multithread.simple_egl_server_sync.textures.copyteximage2d_texsubimage2d_render'.
Tested with:
mesa: branch 'master' at d6545f2
deqp: branch 'nougat-cts-dev' at 4acf725 with additional local fixes
DEQP_TARGET: x11_egl
hw: Intel Broadwell 0x1616
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99085
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Haixia Shi <hshi@chromium.org>
It should actually be 32 for a4xx/a5xx.. we still only advertise 16 but
for a5xx the linkage map includes position/psize.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We need this in case it is streamed out. Not sure why we were treating
it specially before. Having it as a VS out is harmless if FS doesn't
have a matching input.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We'll need to revisit when adding hw binning pass support, whether we
can still do this in main draw step, as we do w/ a3xx/a4xx, or if we
needed to move it to the binning stage.
Still some failing piglits but most tests pass and the common cases seem
to work.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Rework how we lay out driver constants (driver-params, UBO/TFBO buffer
addresses, immediates) for more flexibility. For a5xx+ we need to deal
with the fact that gpu ptrs are 64b instead of 32b, which makes the
fixed offset scheme not work so well. While we are dealing with that
we might also make the layout more dynamic to account for varying # of
UBOs, etc.
Signed-off-by: Rob Clark <robdclark@gmail.com>
For dealing w/ 32b vs 64b gpu addresses, I need to rework how we pass
UBO buffer addresses to shader, and knowing up front the # of UBOs is
useful. But I noticed ttn wasn't setting this.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The spec implicitly allows the incoming count to be 0. From the Vulkan
1.0.38 spec, Section 4.1 Physical Devices:
If the value referenced by pQueueFamilyPropertyCount is not 0 [then
do stuff].
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes dEQP-EGL.functional.create_context_ext.robust_*
on Intel with GBM.
If the user sets the EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR in
EGL_CONTEXT_FLAGS_KHR when creating an OpenGL ES context, then
EGL_KHR_create_context spec requires that we unconditionally emit
EGL_BAD_ATTRIBUTE because that flag does not exist for OpenGL ES. When
creating an OpenGL context, the spec requires that we emit EGL_BAD_MATCH
if we can't support the request; that error is generated in the egl_dri2
layer where the driver capability is actually checked.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99188
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
The Vulkan spec indicates that
vkGetPhysicalDeviceQueueFamilyProperties() should overwrite
pQueueFamilyPropertyCount with the number of structures actually
written to pQueueFamilyProperties.
Signed-off-by: Damien Grassart <damien@grassart.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Cc: mesa-stable@lists.freedesktop.org
To my knowledge, this fixes no tests. I simply wrote the patch for
completeness as a follow-up to the previous two patches.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
_mesa_choose_tex_format() already handles GL_RGBA + GL_UNSIGNED_SHORT_1_5_5_5_REV
by converting it to MESA_FORMAT_B5G5R5A1_UNORM. Teach it do the same for
the non-reversed type. Otherwise, the switch's fallthrough converts it
to an 8888 format, which has incompatible precision in the alpha
channel.
Patch 2/2 to fix dEQP-EGL.functional.image.modify.tex_rgb5_a1_tex_subimage_rgba8
on Intel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99185
Cc: Haixia Shi <hshi@chromium.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
(airlied: fixes DOOM hang with compute queue enabled)
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Don't call the QueueSubmit interface, just call direct to the
winsys, so we can pass the wait semaphores.
Noticed while debugging doom, doesn't fix anything.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
doom was causing a printf about an illegal color, it was due the
non-void returning -1, and the other function checking for 4,
align these.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Presently errors from frontend are handled only if they occur in
clang::CompilerInvocation::CreateFromArgs(). This patch uses
clang::DiagnosticsEngine to detect errors such as invalid values for
Clang frontend arguments.
Fixes Piglit's cl/program/build/fail/invalid-version-declaration.cl
test.
v2: fix inconsistent code formatting
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Aaron Watry <awatry@gmail.com>
The Vulkan spec indicates that
vkGetPhysicalDeviceQueueFamilyProperties() should overwrite
pQueueFamilyPropertyCount with the number of structures actually
written to pQueueFamilyProperties.
Signed-off-by: Damien Grassart <damien@grassart.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
In this case we were dying when we tried to do SHL addr sampler imm(8)
because that puts an immediate in src0 of a two source instruction. This
fixes 2704 of the new separate sampler Vulkan CTS tests on Sky Lake.
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
These are taken from the amdgpu-pro driver, and cause no
CTS change.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
it appears from the amdgpu-pro results the hw can do more,
but let's just align with radeonsi for now.
No CTS regressions.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This sequence shows up The Talos Principal, at least under Vulkan,
and prevents loop analysis from properly computing trip counts in a
few loops.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
When shaders come in from SPIR-V, we handle continue blocks by placing
the contents of the continue inside of a "if (!first_iteration)". We do
this so that we can properly handle the fact that continues in SPIR-V
jump to the continue block at the end of the loop rather than jumping
directly to the top of the loop like they do in NIR. In particular, the
increment step of a simple for loop ends up in the continue block. This
pass looks for this case in loops that don't actually have any continues
and moves the continue contents to the end of the loop instead. We need
this because loop unrolling doesn't work if the increment is inside of a
condition.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Unless an if statement contains nested returns we can simply add
any following instructions to the branch without the return.
V2: fix handling if_nested_return value when there is a sibling if/loop
that doesn't contain a return. (Spotted by Ken)
V3:
- add a better comment to the new variable
- remove instructions after if when both branches return
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
There is a single regression in loop unrolling which is:
loops HURT: shaders/orbital_explorer.shader_test GS SIMD8: 0 -> 1
However the loop is huge so it seems reasonable not to unroll it. It's
surprising that GLSL IR does unroll it.
shader-db results BDW:
total instructions in shared programs: 13037455 -> 13036947 (-0.00%)
instructions in affected programs: 17982 -> 17474 (-2.83%)
helped: 63
HURT: 25
total cycles in shared programs: 262217870 -> 262227990 (0.00%)
cycles in affected programs: 2287046 -> 2297166 (0.44%)
helped: 969
HURT: 844
total loops in shared programs: 2951 -> 2952 (0.03%)
loops in affected programs: 0 -> 1
helped: 0
HURT: 1
LOST: 0
GAINED: 1
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
V2:
- tidy ups suggested by Connor.
- tidy up cloning logic and handle copy propagation
based of suggestion by Connor.
- use nir_ssa_def_rewrite_uses to fix up lcssa phis
suggested by Connor.
- add support for complex loop unrolling (two terminators)
- handle case were the ssa defs use outside the loop is already a phi
- support unrolling loops with multiple terminators when trip count
is know for each terminator
V3:
- set correct num_components when creating phi in complex unroll
- rewrite update remap table based on Jasons suggestions.
- remove unrequired extract_loop_body() helper as suggested by Jason.
- simplify the lcssa phi fix up code for simple loops as per Jasons suggestions.
- use mem context to keep track of hash table memory as suggested by Jason.
- move is_{complex,simple}_loop helpers to the unroll code
- require nir_metadata_block_index
- partially rewrote complex unroll to be simpler and easier to follow.
V4:
- use rzalloc() when creating nir_phi_src but not setting pred right away
fixes regression cause by ralloc() no longer zeroing memory.
V5:
- simplify calling of complex_unroll()
- use new loop terminator fields to get the break/continue from blocks
and simplify loop unrolling code
- handle slightly less trivial loop terminators. if branches can
now have instructions but can only contain a single block.
- use nir print type IR snippets in unroll function descriptions
- add better explanation and variable for why we need to clone
additional times when the second terminator it the limiting
terminator.
- partially convert out of ssa before unrolling loops (suggested by Jason)
v6:
- remove unused nir_builder
- use Jasons new from ssa helper
- tidy/fixup cursor use
- unroll terminators that contain control flow correctly
- unroll complex loops with control flow before the terminators
correctly
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
V2:
- updated to create a generic list clone helper nir_cf_list_clone()
- continue to assert on clone when fallback flag not set as suggested
by Jason.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
V2: Do a "depth first search" to convert to LCSSA
V3: Small comment fixup
V4: Rebase, adapt to removal of function overloads
V5: Rebase, adapt to relocation of nir to compiler/nir
Still need to adapt to potential if-uses
Work around nir_validate issue
V6 (Timothy):
- tidy lcssa and stop leaking memory
- dont rewrite the src for the lcssa phi node
- validate lcssa phi srcs to avoid postvalidate assert
- don't add new phi if one already exists
- more lcssa phi validation fixes
- Rather than marking ssa defs inside a loop just mark blocks inside
a loop. This is simpler and fixes lcssa for intrinsics which do
not have a destination.
- don't create LCSSA phis for loops we won't unroll
- require loop metadata for lcssa pass
- handle case were the ssa defs use outside the loop is already a phi
V7: (Timothy)
- pass indirect mask to metadata call
v8: (Timothy)
- make convert to lcssa a helper function rather than a nir pass
- replace inside loop bitset with on the fly block index logic.
- remove lcssa phi validation special cases
- inline code from useless helpers, suggested by Jason.
- always do lcssa on loops, suggested by Jason.
- stop making lcssa phis special. Add as many source as the block
has predecessors, suggested by Jason.
V9: (Timothy)
- fix regression with the is_lcssa_phi field not being initialised
to false now that ralloc() doesn't zero out memory.
V10: (Timothy)
- remove extra braces in SSA example, pointed out by Topi
V11: (Timothy)
- add missing support for LCSSA phis in if conditions.
V12: (Timothy)
- small tidy up suggested by Jason.
- always create lcssa phi even if it just points to an lcssa
phi from an inner loop
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This pass detects induction variables and calculates the
trip count of loops to be used for loop unrolling.
V2: Rebase, adapt to removal of function overloads
V3: (Timothy Arceri)
- don't try to find trip count if loop terminator conditional is a phi
- fix trip count for do-while loops
- replace conditional type != alu assert with return
- disable unrolling of loops with continues
- multiple fixes to memory allocation, stop leaking and don't destroy
structs we want to use for unrolling.
- fix iteration count bugs when induction var not on RHS of condition
- add FIXME for && conditions
- calculate trip count for unsigned induction/limit vars
V4: (Timothy Arceri)
- count instructions in a loop
- set the limiting_terminator even if we can't find the trip count for
all terminators. This is needed for complex unrolling where we handle
2 terminators and the trip count is unknown for one of them.
- restruct structs so we don't keep information not required after
analysis and remove dead fields.
- force unrolling in some cases as per the rules in the GLSL IR pass
V5: (Timothy Arceri)
- fix metadata mask value 0x10 vs 0x16
V6: (Timothy Arceri)
- merge loop_variable and nir_loop_variable structs and lists suggested by Jason
- remove induction var hash table and store pointer to induction information in
the loop_variable suggested by Jason.
- use lowercase list_addtail() suggested by Jason.
- tidy up init_loop_block() as per Jasons suggestions.
- replace switch with nir_op_infos[alu->op].num_inputs == 2 in
is_var_basic_induction_var() as suggested by Jason.
- use nir_block_last_instr() in and rename foreach_cf_node_ex_loop() as suggested
by Jason.
- fix else check for is_trivial_loop_terminator() as per Connors suggetions.
- simplify offset for induction valiables incremented before the exit conditions is
checked.
- replace nir_op_isub check with assert() as it should have been lowered away.
V7: (Timothy Arceri)
- use rzalloc() on nir_loop struct creation. Worked previously because ralloc()
was broken and always zeroed the struct.
- fix cf_node_find_loop_jumps() to find jumps when loops contain
nested if statements. Code is tidier as a result.
V8: (Timothy Arceri)
- move is_trivial_loop_terminator() to nir.h so we can use it to assert is
the loop unroll pass
- fix analysis to not bail when looking for terminator when the break is in the else
rather then the if
- added new loop terminator fields: break_block, continue_from_block and
continue_from_then so we don't have to gather these when doing unrolling.
- get correct array length when forcing unrolling of variables
indexed arrays that are the same size as the iteration count
- add support for induction variables of type float
- update trival loop terminator check to allow an if containing
instructions as long as both branches contain only a single
block.
V9: (Timothy)
- bunch of tidy ups and simplifications suggested by Jason.
- rewrote trivial terminator detection, now the only restriction is there
must be no nested jumps, anything else goes.
- rewrote the iteration test to use nir_eval_const_opcode().
- count instruction properly even when forcing an unroll.
- bunch of other tidy ups and simplifications.
V10: (Timothy)
- some trivial tidy ups suggested by Jason.
- conditional fix for break inside continue branch by Jason.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This moves the nir_lower_indirect_derefs() call into
brw_preprocess_nir() so thats is called by both OpenGL and Vulkan
and removes that call to the old GLSL IR pass
lower_variable_index_to_cond_assign()
We want to do this pass in nir to be able to move loop unrolling
to nir.
There is a increase of 1-3 instructions in a small number of shaders,
and 2 Kerbal Space program shaders that increase by 32 instructions.
The changes seem to be caused be the difference in the GLSL IR vs
NIR variable index lowering passes. The GLSL IR pass creates a
simple if ladder for arrays of size 4 or less, while the NIR pass
implements a binary search for all arrays regardless of size.
Shader-db results BDW:
total instructions in shared programs: 13021176 -> 13021819 (0.00%)
instructions in affected programs: 57693 -> 58336 (1.11%)
helped: 20
HURT: 190
total cycles in shared programs: 299805580 -> 299750826 (-0.02%)
cycles in affected programs: 2290024 -> 2235270 (-2.39%)
helped: 337
HURT: 442
total fills in shared programs: 19984 -> 19984 (0.00%)
fills in affected programs: 0 -> 0
helped: 0
HURT: 0
LOST: 4
GAINED: 0
V2: remove the do_copy_propagation() call from the i965 GLSL IR
linking code. This call was added in f7741c5211 but since we are
moving the variable index lowering to NIR we no longer need it and
can just rely on the nir copy propagation pass.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Without this we will regress the max-samplers piglit test on Gen6
and lower when loop unrolling is done in NIR. There is a check
in the GLSL IR linker that errors when it finds indirects and
EmitNoIndirectSampler is set.
As far as I can tell there is no reason for not enabling this for
all gens regardless of whether they fully support ARB_gpu_shader5
or not.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
These are designed for use within an optimization pass when SSA becomes
more pain than it's worth. They're very naive and don't generate
anything close to optimal register-based NIR. Also, they may result in
shaders which do not validate because of, for instance, registers in phi
sources. However, the register-based into-SSA pass should be pretty
efficient at cleaning up the mess.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
When application window closed unexpectedly due to
lost window visualtypes getting invlaid parameters
which is causing a crash. Necessary check is added
to prevent the crash.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Hashcat needs MAX_GLOBAL_BUFFERS to be 21 or even 22 for some modes. It'll crash otherwise.
I'm adding an assert to see if programs need it to be even higher.
Signed-off-by: Christian Inci <chris.bugsfd@broke-the-inter.net>
[Handle first properly; should be NFC, since clover always uses first == 0.]
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The clipper hardware doesn't consider points as primitives that can be
clipped. Simply setting the corresponding cull bits works, and should not
have an adverse effect on other primitive types according to the hardware
team.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Should have no effect (other than perhaps on power consumption), but
Vulkan does this.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Fix linking error with 'make check'.
CXXLD lp_test_format
../../../../src/gallium/auxiliary/.libs/libgallium.a(os_time.o): In function `os_time_get_nano':
src/gallium/auxiliary/os/os_time.c:59: undefined reference to `clock_gettime'
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Add the index to the location when assigning driver locations for
output variables.
Otherwise two fragment shader outputs declared as:
layout (location = 0, index = 0) out vec4 output1;
layout (location = 0, index = 1) out vec4 output2;
will end up aliasing one another.
Note that this patch will make the second output variable in the above
example alias a possible third output variable with location = 1 and
index = 0. But this shouldn't be a problem in practice since only one
color attachment is supported when dual-source blending is used.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Thanks to Ilia's patch this works fine on radv.
No regressions in CTS, all enabled tests pass.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The spec says to ignore these fields for exclusive images.
Fixes crashes in:
dEQP-VK.clipping.*
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The GL 4.5 spec says:
"If any enabled array’s buffer binding is zero when DrawArrays
or one of the other drawing commands defined in section 10.4 is
called, the result is undefined."
This commits avoids crashing the code, which is not a very good
"undefined result".
This fixes spec/!opengl 3.1/vao-broken-attrib piglit test.
As per the C spec, it is illegal to alias pointers to different
types. This results in undefined behaviour after optimization
passes, resulting in very subtle bugs that happen only on a
full moon..
Use a memcpy() as a well defined coercion between the isomorphic
bit-field interpretations of memory.
V.2: Use C99 compat STATIC_ASSERT() over C11 static_assert().
Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Now that there's some SoA fetch which never falls back, we should always get
results which are better or at least not worse (something like rgba32f will
stay the same).
For cases which get way better, think something like R16_UNORM with 8-wide
vectors: this was 8 sign-extend fetches, 8 cvt, 8 muls, followed by
a couple of shuffles to stitch things together (if it is smart enough,
6 unpacks) and then a (8-wide) transpose (not sure if llvm could even
optimize the shuffles + transpose, since the 16bit values were actually
sign-extended to 128bit before being cast to a float vec, so that would be
another 8 unpacks). Now that is just 8 fetches (directly inserted into
vector, albeit there's one 128bit insert needed), 1 cvt, 1 mul.
v2: ditch the old AoS code instead of just disabling it.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This can now handle rgtc (unorm) too - this path no longer handles plain
formats, but that's unnecessary they now all have their proper SoA unpack
(this will still be dog-slow though due to the actual fetch being per-pixel
util fallbacks).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This previously always fell back to AoS conversion. Even for 4-float formats
(which is the optimal case by far for that fallback case) this was suboptimal,
since it meant the conversion couldn't be done with 256bit vectors. While this
may still only be partly possible for some formats, (unless there's AVX2
support) at least the transpose can be done with half the unpacks
(and before using the transpose for AoS fallbacks, it was worse still).
With less than 4 channels, things got way worse with the AoS fallback
quickly even with 128bit vectors.
The strategy is pretty much the same as the existing one for formats
which fit into 32 bits, except there's now multiple vectors to be
fetched (2 or 4 to be exact), which need to be shuffled first (if it's 4
vectors, this amounts to a transpose, for 2 it's a bit different),
then the unpack is done the same (with the exception that the shift
of the channels is now modulo 32, and we need to select the right
vector).
In fact the most complex part about it is to get the shuffles right
for separating into lo/hi parts for AVX/AVX2...
This also makes use of the new ability of gather to use provided type
information, which we abuse to outsmart llvm so we get decent shuffles,
and to fetch 3x32bit vectors without having to ZExt the scalar.
And just because we can, we handle double formats too, albeit they are
a bit different (draw sometimes needs to handle that).
v2: fix typo float/int bug (generating inefficient code).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
By using a dst_type in the the gather interface, gather has some more
knowledge about how values should be fetched.
E.g. if this is a 3x32bit fetch and dst_type is 4x32bit vector gather
will no longer do a ZExt with a 96bit scalar value to 128bit, but
just fetch the 96bit as 3x32bit vector (this is still going to be
2 loads of course, but the loads can be done directly to simd vector
that way).
Also, we can now do some try to use the right int/float type. This should
make no difference really since there's typically no domain transition
penalties for such simd loads, however it actually makes a difference
since llvm will use different shuffle lowering afterwards so the caller
can use this to trick llvm into using sane shuffle afterwards (and yes
llvm is really stupid there - nothing against using the shuffle
instruction from the correct domain, but not at the cost of doing 3 times
more shuffles, the case which actually matters is refusal to use shufps
for integer values).
Also do some attempt to avoid things which look great on paper but llvm
doesn't really handle (e.g. fetching 3-element 8 bit and 16 bit vectors
which is simply disastrous - I suspect type legalizer is to blame trying
to extend these vectors to 128bit types somehow, so fetching these with
scalars like before which is suboptimal due to the ZExt).
Remove the ability for truncation (no point, this is gather, not conversion)
as it is complex enough already.
While here also implement not just the float, but also the 64bit avx2
gathers (disabled though since based on the theoretical numbers the benefit
just isn't there at all until Skylake at least).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We should do transpose, not extract/insert, at least with "sufficient" amount
of channels (for 4 channels, extract/insert shuffles generated otherwise look
truly terrifying). Albeit we shouldn't fallback to that so often in any case.
v2: ditch the extract/insert path, not worth keeping (we're going to avoid
hitting the fallback that often with future patches).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
soa fetch so far always assumed that data was aligned. However, we want to
use this for vertex fetch, and data might not be aligned there, so handle
it in this path too (basically just pass through alignment through to other
functions). (It looks like it wouldn't work for for cached s3tc but this is
no different than with AoS fetch.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Avoid synchronization by using the secondary context
for uploading the vertex data for Draw*Up.
v2: Rely on u_upload_mgr to use persistent coherent
buffers. Do not flush.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
This new buffer upload path enables to lock
faster than the normal path when using
DISCARD/NOOVERWRITE.
v2: Diverse cleanups and fixes.
v3: Fix allocation size for 'lone' buffers and
add more debug info.
v4: Rewrite of the path to handle when DISCARD/NOOVERWRITE
is not used anymore. The resource content is copied to the
new resource used.
v5: flush for safety after unmap (not sure it is really required
here, but safer to flush).
v6: Do not use the path if persistent coherent mapping is unavailable.
Fix buffer creation flags.
v7: Do not flush since it is not needed.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
If the volumes (and the texture container) are not referenced,
then they are no pending operations on them. We can lock directly.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
If the surfaces (and the texture container) are not referenced,
then they are no pending operations on them. We can lock directly.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Will enable to use the bind count as an information for
whether the surface/volume is used in the worker thread.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Will enable to use the bind count as an information for
whether the surface/volume is used in the worker thread.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Use nine_context_box_upload for uploads:
. systemmem volume to default volume
. managed volume internal content to its resource.
Check the uploads are executed before any action
that can alter the data, that is LockBox and
volume destruction.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Use nine_context_box_upload for uploads:
. systemmem surface to default surface
. managed surface internal content to its resource.
Check the uploads are executed before any action
that can alter the data, that is LockRect,
NineSurface9_CopyDefaultToMem and surface destruction.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Do the upload in the other thread.
Usually managed buffers are used once per frame.
It is then very likely pending_upload is 0 at Lock
time.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
BackBuffers can survive swapchain dtor if
the user has a reference on them.
The swapchain itself has no reference on the buffer.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Similar to the other macros, but introduces a counter,
which enables to know when the instructions has been
executed.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Use the secondary pipe for DISCARD/NOOVERWRITE, which
avoids stalling to get the pipe from the worker thread.
v2: flush at unmap. This is required for example if
the driver does hidden draw calls or copies. In the case
of unsynchronized it is probably not required, but
it is more safe.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Tests show SYSTEMMEM should ignore DISCARD.
Prevents game bugs with following patches reimplementing
DISCARD. Halo is affected.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Previously we were uploading Managed buffers at the next draw call
after they were set dirty.
This is not the expected behaviour. Instead upload just before
draw call needing the content.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
BASETEX_REGISTER_UPDATE was adding the texture to the list
of textures to upload in too many cases. tex->base.base.bind
will be set to true if the texture is in a stateblock, whereas
we want to upload only if bound to the device, which is
what bind_count is for.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Use an offloading thread for all nine_context functions.
Macros are used to ease the reading of the code.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
The new version uses nine_context functions instead of
applying the changes directly to nine_context.
This will enable it to work with CSMT.
v2: Fix nine_context_light_enable_stateblock
The memcpy arguments were wrong, and the state
wasn't set dirty.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
nine_bind didn't need atomics up to now,
because it's use what always within a protected
mutex. We need to use atomics because with the
next patches several threads may use nine_bind.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
And make nine_state_access_transform take this
new structure as input.
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
For device vs shader float constants and may_swvp,
the same tips than for the other constant types is
used.
Also memset the constants properly.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
And move programmable_vs storage and computation.
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
And move samplers_shadow to nine_context.
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
v2: Release buffers for Draw*Up functions in device9.c,
instead of nine_context. This prevents a leak with csmt
where the wrong pointers were released.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Part of the refactor to move all gallium calls to
nine_state.c, and have all internal states required
for those calls in nine_context.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
nine_context is a new structure which goal will be
to contain all internal states. It will be the states
of the second thread in the to-be-introduced CSMT mode.
This patch moves several internal states to nine_context,
while the next patches add the other fields.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
We were advertising support for WFOG (like all win drivers),
but we weren't implementing it.
This patch implements the behaviour. See comments.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
The code was wrongly detecting which texture coordinates
to generate when the coordinate index was different to
the stage index.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
if first alpha stage is disabled and writes to temp,
diffuse alpha is written to temp.
Last stage always writes to current.
Behaviour was deduced by tests with a test app.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
When a texture is read by a stage for colorop, it should
be disabled, and disable following stages.
When a texture is read for alphaop, 1.0f is read for the input,
which is the behaviour for a dummy texture.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Fix the check for computing ff specular.
This seems to match the opengl behavior,
and give the correct output on windows.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
The computation was wrong. COLOR0's last component
should be equal to the material diffuse w component.
The behaviour was checked with a test app on Windows.
Wine has the same behaviour.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
We were ignoring MULTISAMPLEMASK for non-maskable multisample
modes, but we were missing the non-multisampled case.
Fixes a crash in Halo.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Add precision on the behaviour of WaitBufferReleased.
All implementers and users of the API were expecting
that behaviour.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
SetCursor assumes for now a 32x32 argb cursor with pitch 128.
32x32 argb doesn't have pitch 128 on all hw, thus use a
temporary surface with the correct pitch when needed.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
The cap should be advertised for d3d10 able cards,
but only for Ex contexts.
Unfortunately at this point Mesa has no way to know if
Ex is used or not (the info is got later).
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Add documentation to explicit what can be expected and what is allowed
when using several contexts.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Add documentation for the requirements related to threading
for screens and contexts.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
If the provided EGLConfig does not support the requested surface type,
then emit EGL_BAD_MATCH.
Fixes dEQP-EGL.functional.negative_api.create_pbuffer_surface
on GBM.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
We were using ir_var_auto for the inlined function parameter variables,
which is wrong, as it suggests that those are real variables declared
by the program.
Normally this doesn't matter. However, if you called built-ins at
global scope, it would pollute the global variable namespace with
these new parameter temporaries. If the shader already had variables
with those names, the linker might see contradictory global variable
declarations and raise an error.
Making them temporaries indicates that these are just things generated
by the compiler internally. This avoids confusing the linker.
Fixes a new Piglit test: glsl-fs-multiple-builtins.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99154
Reported-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Commit 929fcee47e introduced code that
attempts to unlock an unlocked mutex which is undefined behaviour.
On OpenBSD this leads to an abort:
0 0x0000124dadfa96ba in thrkill () at <stdin>:2
1 0x0000124dadf3da39 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
2 0x0000124d2c1165b5 in *_libpthread_pthread_mutex_unlock (mutexp=<optimized out>)
at /usr/src/lib/librthread/rthread_sync.c:221
3 0x0000124d279c02e4 in init_attrib_groups (ctx=0x124df0fda000) at main/context.c:825
4 _mesa_initialize_context (ctx=ctx@entry=0x124df0fda000, api=api@entry=API_OPENGL_CORE,
visual=visual@entry=0x7f7ffffbdfd0, share_list=share_list@entry=0x0,
driverFunctions=driverFunctions@entry=0x7f7ffffbda60) at main/context.c:1204
5 0x0000124d27b507ec in st_create_context (api=api@entry=API_OPENGL_CORE,
pipe=pipe@entry=0x124dc4910000, visual=visual@entry=0x7f7ffffbdfd0,
share=share@entry=0x0, options=options@entry=0x7f7ffffbe128)
at state_tracker/st_context.c:545
6 0x0000124d27b8639f in st_api_create_context (stapi=<optimized out>,
smapi=0x124d1b608800, attribs=0x7f7ffffbe100, error=0x7f7ffffbe0fc, shared_stctxi=0x0)
at state_tracker/st_manager.c:669
7 0x0000124d27cc5b9c in dri_create_context (api=<optimized out>, visual=0x124d8a0f8a00,
cPriv=0x124de473f240, major_version=<optimized out>, minor_version=<optimized out>,
flags=<optimized out>, notify_reset=false, error=0x7f7ffffbe2b4,
sharedContextPrivate=0x0) at dri_context.c:123
8 0x0000124d27cc5029 in driCreateContextAttribs (screen=0x124d8a0f8400,
api=<optimized out>, config=0x124d8a0f8a00, shared=<optimized out>,
num_attribs=<optimized out>, attribs=<optimized out>, error=0x7f7ffffbe2b4,
data=0x124d77814a00) at dri_util.c:448
9 0x0000124d8e109b00 in drisw_create_context_attribs (base=0x124df3e08700,
config_base=0x124d7a0e7300, shareList=<optimized out>, num_attribs=<optimized out>,
attribs=<optimized out>, error=0x7f7ffffbe2b4) at drisw_glx.c:476
10 0x0000124d8e104b4a in glXCreateContextAttribsARB (dpy=0x124d533f0000,
config=0x124d7a0e7300, share_context=0x0, direct=1, attrib_list=0x7f7ffffbe300)
at create_context.c:78
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
From page 27 (page 33 of the PDF) of the GLSL 1.20 spec:
" Only variables output from a vertex shader can be candidates for
invariance."
But this later changes to:
From page 37 (page 43 of the PDF) of the GLSL 1.30 spec:
" Only variables output from a shader can be candidates for
invariance."
We can also find:
From page 37 (page 43 of the PDF) of the GLSL 1.30 spec:
" Initially, by default, all output variables are allowed to be
variant. To force all output variables to be invariant, use the
pragma
#pragma STDGL invariant(all)
before all declarations in a shader. If this pragma is used after
the declaration of any variables or functions, then the set of
outputs that behave as invariant is undefined. It is an error to
use this pragma in a fragment shader."
But this needs to be corrected and it is being addressed at:
https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16140
Fixes GL45-CTS.shading_language_420pack.qualifier_order.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Andres Gomez <agomez@igalia.com>
It's possible that nir_shader was cloned and it no longer contains
a pointer to the shader_info in gl_program. So we need to copy
shader_info back to gl_program if that is the case.
Fixes a regression with NIR_TEST_CLONE=true
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98840
nir/nir_constant_expressions.c:290:25: warning: unused parameter 'num_components' [-Wunused-parameter]
evaluate_ball3(unsigned num_components, nir_const_value *_src)
^
nir/nir_constant_expressions.c: In function 'evaluate_fddx':
nir/nir_constant_expressions.c:1282:57: warning: unused parameter '_src' [-Wunused-parameter]
evaluate_fddx(unsigned num_components, nir_const_value *_src)
^
v2: Unconditionally mark the parameters as MAYBE_UNUSED instead of
conditionally adding (void) casts to keep the generator simple.
Suggested by Jason.
Number of total warnings in my build reduced from 1575 to 1485
(reduction of 89).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
nir/nir_constant_expressions.c: In function 'evaluate_ball2':
nir/nir_constant_expressions.c:279:7: warning: missing initializer for field 'z' of 'struct bool_vec' [-Wmissing-field-initializers]
};
^
nir/nir_constant_expressions.c:234:10: note: 'z' declared here
bool z;
^
Number of total warnings in my build reduced from 2532 to 2304
(reduction of 228).
v2: Initialize bool vectors with 0 instead of false to keep the
generator simpler. Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Now that information about which array-of-arrays elements are accessed
is tracked, use that information to only mark an instance array element
as used-by-stage if, in fact, it is.
Fixes GL45-CTS.program_interface_query.uniform-block-types.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Very soon this visitor will get more complicated. The users of the
existing ir_variable_refcount visitor won't need the coming
functionality, and this use doesn't need much of the functionality of
ir_variable_refcount.
v2: ir_array_refcount_visitor::get_variable_entry cannot return NULL, so
don't check it. Suggested by Timothy.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
One for the array parts and one for the leaf members. This will
simplify later changes.
The indentation is wonkey after this patch. This was done to make it
more obvious that the function is just getting split. The next patch
will fix the indentation.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes 555 dEQP tests (using the nougat-cts-dev branch), Piglit's
arb_program_interface_query/arb_program_interface_query-resource-query,
and GL45-CTS.program_interface_query.separate-programs-{tess-control,
tess-eval,geometry}. Only one dEQP program interface failure remains.
I would have liked to split this up into several distinct changes, but
I wasn't sure how to do that given thet tangled nature of these issues.
So, the issues:
* We need to treat interface blocks declared as an array of instances
as a single block - removing the outer array. The resource list
entry's name should not include the array length. Properties such
as GL_ARRAY_SIZE should refer to the variable inside the block, not
the interface block's array properties.
* We need to do this prefixing even for structure variables.
* We need to do this for built-ins (such as gl_PerVertex.gl_Position).
* After interface array unwrapping, any variable which is an array
should have [0] appended. It doesn't matter if it's a TCS/TES/GS
input or TCS output - that looked like an attempt to unwrap for
per-vertex variables, but that didn't consider per-patch variables,
and as far as I can tell there's nothing to justify this.
Several Mesa developers have suggested that Issue 16 contradicts the
main specification, but I believe that it doesn't - the main spec just
isn't terribly clear. The main ARB_program_interface query spec says:
"* For an active interface block not declared as an array of block
instances, a single entry will be generated, using the block name from
the shader source.
* For an active interface block declared as an array of instances,
separate entries will be generated for each active instance. The name
of the instance is formed by concatenating the block name, the "["
character, an integer identifying the instance number, and the "]"
character."
Issue 16 says that built-ins should be named "gl_PerVertex.gl_Position",
but several people suggested the second bullet above means that it
should be named "gl_PerVertex[array length].gl_Position".
There are two important things to note. Those bullet points say
"an active interface block", while the others say "variable" or "active
shader storage block member". They also don't mention applying the
rules recursively (unlike the other bullets). Both suggest that
these rules apply to blocks themselves, not members of blocks.
In fact, for GL_UNIFORM_BLOCK queries, we do have "block[0]",
"block[1]", ... resource list entries - so those rules are real,
and actually used. So if they don't apply to block members, then how
should members be named? Unfortunately, I don't see any rules outside
of issue 16 - where the rationale is very unclear. I hope to clarify
the spec in the future.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
stage_mask is a bitmask of shader stages, so the proper comparison would
be (1 << MESA_SHADER_VERTEX), not MESA_SHADER_VERTEX itself.
But we only care for structure types, and VS inputs cannot be structs.
So we can just drop this entirely.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
These are listed as Z+ in the GL spec, and often have values of
0xFFFFFFFF. For glGetFloat, we should return 4294967295.0 rather than
-1.0. Similarly, for glGetInteger64v, we should return 0xFFFFFFFF, not
the sign extended 0xFFFFFFFFFFFFFFFF.
Fixes 6 dEQP tests matching the pattern
dEQP-GLES3.functional.state_query.integers.stencil*value*mask*getfloat
when run in a single process (with state reset code happening between
tests, which makes dEQP set the stencil value mask to 0xFFFFFFFF).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The "State Tables" section of the OpenGL specification lists many values
as belonging to Z+ (non-negative integers), not Z (all integers).
For ordinary glGetInteger queries, this doesn't matter. However, when
accessing Z+ values via glGetFloat or glGetInteger64, we need to treat
the source value as an unsigned value. Otherwise, we'll produce a
negative number when bit 31 is set.
This commit merely adds the plumbing. It doesn't convert any values.
v2: Gotta catch 'em all (add missing cases caught by Ilia)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
GetFloat of integer valued things is supposed to perform a simple
int -> float conversion. INT_TO_FLOAT is not that. Instead, it
converts [-2147483648, 2147483647] to a normalized [-1.0, 1.0] float.
This is only used for COMPRESSED_TEXTURE_FORMATS, which nobody in
their right mind would try and access via glGetFloat(), but we may
as well fix it.
Found by inspection.
v2: Gotta catch 'em all (fix another case of this caught by Ilia)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Remove currently bound sampler states from the hash table before pruning
entries from the hash table, so they cannot accidentally be deleted by
the pruning.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Only copy/memset the pointers that actually need to be.
v2:
* Cast info->nr_samplers to int for calculating delta (Nicolai)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
If info->nr_samplers > ctx->nr_fragment_samplers_saved, the assignment
would prevent cso_single_sampler_done from unbinding the no longer used
samplers from the driver, which could result in use-after-free. This is
probably unlikely to happen in practice though.
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Some dri drivers will pass multiple bits in buffer_mask parameter
to droid_image_get_buffer(), more than the actual supported buffer
type combination. For such case, will go through all the bits, and
will not return error when unsupported buffer is requested, only
return error when the allocation for supported buffer failed.
v2: coding style and log changes
v3: coding style changes and update patch format
Signed-off-by: Liu Zhiquan <zhiquan.liu@intel.com>
Signed-off-by: Long, Zhifang <zhifang.long@intel.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Not sure where the 16k comes from, but pretty sure 2k is the max.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
These aren't used yet but we will want to use them when we
implement a separate compute queue.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This is required for having a separate compute queue, we
probably can't use this on GFX queue due to DCC.
v2: Set coord_components = 2 for itoi texture fetch. (Bas)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This implements the reverse of the current buffer->image path
and can be used when we need to do image transfer on compute queues
This just adds the code turned off as we don't support separate
computes queues yet, and we don't want to use this path on the GFX
queues for DCC reasons.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Needed when accessing a comrpessed texture as R32G32B32A32 from a shader. This
was not encountered previously, as we used the CB for the reinterpretation, which
does not use this pitch.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
A bit of a hack, but we need to do this until we can do tiled zs in
sysmem (and associated tile/until blits for transfer_map).
Fixes xonotic and glmark2 "refract", when reorder wasn't enabled.
(reorder would paper over the issue by avoiding the extra round-
trip to system memory and back to gmem.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Refactor out into a common helper, since this is the same across
generations when we need equiv z/s gmem restore format.
Next patch needs this in a5xx, rather than creating yet another
helper push this into core.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Fixes some issues at least with GMEM bypass mode, where we'd sometimes
end up with some FS quads not hitting memory.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Swap/component-order doesn't seem to be quite what that is. At least
blob was always setting it to XYZW ('11') but we weren't. Causing
problems w/ formats like sint16.. Hard-coding this instead at least
seems to get glamor working.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Might not be 100% accurate, mostly just copy from a4xx to get started.
We are defn lying about occlusion query at this point (not implemented
yet) but need it to expose anything higher than gl1.4 (glamor needs
gl2.1)
Signed-off-by: Rob Clark <robdclark@gmail.com>
Not sure what this event is, but blob writes it.. and it seems to solve
random write faults at mystery address that would sometimes happen on
first BYPASS draw.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The spec says we have to try to create all, and only set failed
pipelines to VK_NULL_HANDLE. If one of them fails, we have to return
an error, but as far as I can see, the spec does not care which of
the suberrors.
Fixes
dEQP-VK.api.object_management.alloc_callback_fail_multiple.compute_pipeline
dEQP-VK.api.object_management.alloc_callback_fail_multiple.graphics_pipeline
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The strategy is to do the same thing that the GLSL lower_offset_arrays
pass does - create 4 separate texture gather ops, one per offset, and
read in the results from each gather's w component to recreate the
desired result.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This fixes a regression in a bunch of image store vulkan CTS tests
from commit ad38ba1134, which started
using OWORD block read messages to implement UBO loads. The reason
for the failure is that we were giving bogus buffer alignment limits
to the application (1B), so the CTS would happily come back with
descriptor sets pointing at not even word-aligned uniform buffer
addresses.
Surprisingly the sampler messages used to fetch pull constants before
that commit were able to cope with the non-texel aligned addresses,
but the dataport messages used to fetch pull constants after that
commit and the ones used to access storage buffers (before and after
the same commit) aren't as permissive with unaligned addresses.
Cc: <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99097
Reported-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We do nothing but initialize it, add to it, and delete it.
This is a fallout from removing constant initializer support.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Work can now be added to fences and triggered by fence completion. This
allows for deferred resource deletion, and other asynchronous tasks.
Reviewed-by: George Kyriazis <george.kyriazis@intel.com>
No functional change, just rewriting it in an easier-to-understand way.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We should make the dest in the textureLod() operation have the same number
of components as the destination in the original textureGrad()
Fixes regression in ES3-CTS.gtf.GL3Tests.shadow
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99072
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reverts commit 6aa730000f.
This was changing the size of the undef to always be 1 (the number of inputs
to imov and fmov) which is wrong, we could be moving a vec4 for example.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
We want to perform the URB read to a vec4 temporary, with no writemask,
then issue a MOV to swizzle the data and store it to the actual
destination, using the final writemask.
We were doing this wrong. For example, let's say we wanted to read
a vec2 stored in components 2-3 of a vec4. We would generate a URB
read message of:
SEND <actual destination>.XY <header with mask set to XY>
MOV <actual destination>.XY <actual destination>.ZW
This doesn't work, because the URB message reads the .XY components
of the vec4, rather than the ZW. It writes to the right place, but
with the wrong data. Then the MOV comes along and overwrites it
with data that didn't even come from the URB at all.
Instead we want to do:
SEND <temporary> <header with mask set to ZW>
MOV <actual destination>.XY <temporary>.ZW
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Asking the DC for less than one cacheline (4 owords) of data for
uniform pull constants is suboptimal because the DC cannot request
less than that from L3, resulting in wasted bandwidth and unnecessary
message dispatch overhead, and exacerbating the IVB L3 serialization
bug. The following table summarizes the overall framerate improvement
(with statistical significance of 5% and sample size ~10) from the
whole series up to this patch for several benchmarks and hardware
generations:
| SKL | BDW | HSW
SynMark2 OglShMapPcf | 24.63% ±0.45% | 4.01% ±0.70% | 10.31% ±0.38%
GfxBench4 gl_manhattan31 | 5.93% ±0.35% | 3.92% ±0.31% | 6.62% ±0.22%
GfxBench4 gl_4 | 2.52% ±0.44% | 1.23% ±0.10% | N/A
Unigine Valley | 0.83% ±0.17% | 0.23% ±0.05% | 0.74% ±0.45%
Note that there are two versions of the Manhattan demo shipped with
GfxBench4, one of them is the original gl_manhattan demo which doesn't
use UBOs, so this patch will have no effect on it, and another one is
the gl_manhattan31 demo based on GL 4.3/GLES 3.1, which this patch
benefits as shown above.
I haven't observed any statistically significant regressions in the
benchmarks I have at hand. Note that the comparatively huge
improvement on SKL in the OglShMapPcf test case is due to the combined
effect of this patch and the register pressure benefit on SKL+ of
"i965/fs: Switch to the constant cache for uniform pull constants.",
part of the same series.
Going up to 8 oword blocks would improve performance of pull constants
even more, but at the cost of some additional bandwidth and register
pressure, so it would have to be done on-demand based on the number of
constants actually used by the shader.
v2: Fix for Gen4 and 5.
v3: Non-trivial rebase. Rework to allow the visitor specifiy
arbitrary pull constant block sizes.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Change the FS generator to ask the dataport for enough owords worth of
constants to fill the execution size of the instruction -- Which means
that the visitor now needs to set the execution size correctly for
uniform pull constant load instructions, which we were kind of
neglecting until now.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We'll need roughly the same logic in other places and it would be
annoying to duplicate it. Instead factor it out into a function-like
macro that takes the number of dwords per block (which will prove more
convenient than taking the same value in owords or some other unit).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reverts to using the oword block read messages for uniform pull
constant loads, as used to be the case until
4c1fdae0a0. There are two important differences
though: Now the L3 cacheability bits are set up correctly for UBOs
(since 11f5d8a5d4), and we target the
constant cache instead of the data cache. The latter used to get no
L3 way allocation on boot on all platforms that existed at the time,
so oword read messages wouldn't get cached on L3 regardless of the
MOCS bits, what probably explains the apparent slowness of oword
fetches.
Constant cache loads seem to perform better than SIMD4x2 sampler loads
in a number of cases, they alleviate some of the cache thrashing
caused by the competition with textures for the L1/L2 sampler caches,
and they allow fetching up to 128B worth of constants with a single
oword fetch message.
Note that IVB devices suffer from a hardware bug that leads to
serialization of L3 read requests overlapping the same cacheline as
result of a (on IVB buggy) mechanism of the L3 to preserve coherency.
Since read requests for matching cachelines from any L3 client are not
pipelined, throughput may decrease in cases where there are no
non-overlapping requests left in the queue that can be processed
between them.
This situation should be relatively uncommon as long as we make sure
that we don't use the 1/2 oword messages in cases where the shader
intends to read from any other location of the same cacheline at some
other point. This is generally a good idea anyway on all generations
because using the 1 and 2 oword messages is expected to waste
bandwidth since the minimum L3 request size for the DC is exactly 4
owords (i.e. one cacheline). A future commit will have this effect.
I haven't been able to find any real-world example where this would
still result in a regression on IVB, but if someone happens to find
one it shouldn't be too difficult to add an IVB-specific check to have
it fall back to the sampler cache for pull constant loads.
Note that on SKL+ this change has the additional benefit of reducing
the register footprint of pull constant loads. The following table
summarizes the effect of the whole series on several shader-db stats:
Total instructions Total cycles
BWR: 4571248 -> 4568342 (-0.06%) 123375740 -> 123373296 (-0.00%)
ELK: 3989020 -> 3985402 (-0.09%) 98757068 -> 98754058 (-0.00%)
ILK: 6383591 -> 6376787 (-0.11%) 143649910 -> 143648914 (-0.00%)
SNB: 7528395 -> 7501446 (-0.36%) 103503796 -> 102460370 (-1.01%)
IVB: 6949221 -> 6943317 (-0.08%) 60592262 -> 60584422 (-0.01%)
HSW: 6409753 -> 6403702 (-0.09%) 60609070 -> 60604414 (-0.01%)
BDW: 8043467 -> 7976364 (-0.83%) 68427730 -> 68483042 (0.08%)
CHV: 8045019 -> 7977916 (-0.83%) 68297426 -> 68352756 (0.08%)
SKL: 8204037 -> 7939086 (-3.23%) 66583900 -> 65624378 (-1.44%)
Lost->Gained Total spills Total fills
BWR: 5 -> 5 1488 -> 1488 (0.00%) 1957 -> 1957 (0.00%)
ELK: 5 -> 5 1489 -> 1489 (0.00%) 1958 -> 1958 (0.00%)
ILK: 1 -> 4 1449 -> 1449 (0.00%) 1921 -> 1921 (0.00%)
SNB: 0 -> 0 549 -> 549 (0.00%) 52 -> 52 (0.00%)
IVB: 13 -> 3 1271 -> 1271 (0.00%) 1162 -> 1162 (0.00%)
HSW: 11 -> 0 1271 -> 1271 (0.00%) 1162 -> 1162 (0.00%)
BDW: 12 -> 0 1340 -> 1340 (0.00%) 1452 -> 1452 (0.00%)
CHV: 12 -> 0 1340 -> 1340 (0.00%) 1452 -> 1452 (0.00%)
SKL: 0 -> 120 1269 -> 375 (-70.45%) 1563 -> 690 (-55.85%)
v3: Non-trivial rebase.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
brw_set_dp_read_message already had a target_cache argument, but its
interpretation was rather convoluted (on Gen6 the render cache was
used if the caller asked for it, otherwise it was ignored using the
sampler cache instead), and the constant cache wasn't representable at
all. brw_set_dp_write_message used the data cache on Gen7+ except for
RENDER_TARGET_WRITE messages, in which case it would use the render
cache. On Gen6 the render cache was always used.
Instead of the above, provide the shared unit SFID that the caller
expects will be used. Makes no functional changes.
v3: Non-trivial rebase.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In order to make sure that the constant cache is coherent with
previous rendering when we start using it for pull constant loads.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Suggested by Marek.
v2: Use new driver flag (Marek)
v3: Fix i965 comments (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Even if lower_txd_cube_map isn't. Suggested by Ken to make the flag more
consistent with its name.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This gets the lowering on the Vulkan driver too, which is required for
hardware that does not have the sample_l_d message (up to IvyBridge).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is ported from the Intel lowering pass that we use with GLSL IR.
This takes care of lowering texture gradients on shadow samplers other
than cube maps. Intel hardware requires this for gen < 8.
v2 (Ken):
- Use the helper function to retrieve ddx/ddy
- Swizzle away size components we are not interested in
v3:
- Get rid of the ddx/ddy helper and use nir_tex_instr_src_index
instead (Ken, Eric)
v4:
- Add a 'continue' statement if the lowering makes progress because it
replaces the original texture instruction
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v3)
This is ported from the Intel lowering pass that we use with GLSL IR.
The NIR pass only handles cube maps, not shadow samplers, which are
also lowered for gen < 8 on Intel hardware. We will add support for
that in a later patch, at which point we should be able to remove
the GLSL IR lowering pass.
v2:
- added a helper to retrieve ddx/ddy parameters (Ken)
- No need to make size.z=1.0, we are only using component x anyway (Iago)
v3:
- Get rid of the ddx/ddy helper and use nir_tex_instr_src_index
instead (Ken, Eric)
v4:
- When emitting the textureLod operation, copy all texture parameters
from the original textureGrad() (except for ddx/ddy) using a loop
- Add a 'continue' statement if the lowering makes progress because it
replaces the original texture instruction
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v3)
This was written specifically for RECT samplers. Make it more generic so
we can call this from the gradient lowerings too.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
git grep -l comparitor | xargs sed -i 's/comparitor/comparator/g'
Just happened to notice this in a patch that was sent and included one
of the tokens in question.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
In 19a541f (nir: Get rid of nir_constant_data) a number of places that
operated on nir_constant::values were mechanically converted to operate
on the whole array without regard for the base type. Only
GLSL_TYPE_FLOAT and GLSL_TYPE_DOUBLE can be matrices, so only those
types can have data in the non-0 array element.
See also b870394.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Cc: Iago Toral Quiroga <itoral@igalia.com>
We shouldn't ever see a SEL with conditional mod other than GE (for max)
or L (for min), but we might see one with predication and no conditional
mod.
total instructions in shared programs: 8241806 -> 8241902 (0.00%)
instructions in affected programs: 13284 -> 13380 (0.72%)
HURT: 62
total cycles in shared programs: 84165104 -> 84166244 (0.00%)
cycles in affected programs: 75364 -> 76504 (1.51%)
helped: 10
HURT: 34
Fixes generated code in at least Sanctum 2, Borderlands 2, Goat
Simulator, XCOM: Enemy Unknown, and Shogun 2.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92234
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We can hardcode all of the fields for swizzling in the geometry shader.
The advantage is that we use fewer descriptor slots and we no longer have to
update any of the (ring) descriptors when the geometry shader changes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Note that the memory layout of one vertex stream inside one "item" (= memory
written by one GS wave) on the GSVS ring is:
t0v0c0 ... t15v0c0 t0v1c0 ... t15v1c0 ... t0vLc0 ... t15vLc0
t0v0c1 ... t15v0c1 t0v1c1 ... t15v1c1 ... t0vLc1 ... t15vLc1
...
t0v0cL ... t15v0cL t0v1cL ... t15v1cL ... t0vLcL ... t15vLcL
t16v0c0 ... t31v0c0 t16v1c0 ... t31v1c0 ... t16vLc0 ... t31vLc0
t16v0c1 ... t31v0c1 t16v1c1 ... t31v1c1 ... t16vLc1 ... t31vLc1
...
t16v0cL ... t31v0cL t16v1cL ... t31v1cL ... t16vLcL ... t31vLcL
...
t48v0c0 ... t63v0c0 t48v1c0 ... t63v1c0 ... t48vLc0 ... t63vLc0
t48v0c1 ... t63v0c1 t48v1c1 ... t63v1c1 ... t48vLc1 ... t63vLc1
...
t48v0cL ... t63v0cL t48v1cL ... t63v1cL ... t48vLcL ... t63vLcL
where tNN indicates the thread number, vNN the vertex number (in the order of
EMIT_VERTEX), and cNN the output component (vL and cL are the last vertex and
component, respectively).
The vertex streams are laid out sequentially.
The swizzling by 16 threads is hard-coded in the way the VGT generates the
offset passed into the GS copy shader, and the jump every 16 threads is
calculated from VGT_GSVS_RING_OFFSET_n and VGT_GSVS_RING_ITEMSIZE in a way
that makes it difficult to deviate from this layout (at least that's what
I've experimentally confirmed on VI after first trying to go the simpler
route of just interleaving the vertex streams).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
SimplifyCFG generates a switch instruction anyway when all four streams
are present, but is simultaneously not smart enough to eliminate some
redundant jumps that it generates.
The generated assembly is still a bit silly, probably because the
control flow annotation doesn't know how to handle a switch with uniform
condition.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When running the copy shader for vertex streams != 0, the SX does not need
any data from us (there is no rasterization for the higher vertex streams,
only streamout).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This affects for GS copy shaders. When an output is meant for vertex
stream != 0, then we don't have to make it available to the pixel
shader.
There is a minor inefficiency here because the GLSL varying packing pass
does not group varyings of the same vertex stream together, but it
shouldn't be important in practice.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Vertex emits beyond the specified maximum number of vertices are supposed to
have no effect, which is why we used to always kill GS that reached the limit.
However, if the GS also writes to memory (SSBO, atomics, shader images), then
we must keep going and only skip the vertex emit itself.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is for geometry shader outputs. Without it, drivers have no way of
knowing which stream each output is intended for, and have to
conservatively write all outputs to all streams.
Separate stream numbers for each component are required due to output
packing.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
As per the C spec, it is illegal to alias pointers to different
types. This results in undefined behaviour after optimization
passes, resulting in very subtle bugs that happen only on a
full moon..
Use a memcpy() as a well defined coercion between the double
to uint64_t interpretations of the memory.
V.2: Use static_assert() instead of assert().
V.3: Use C99 compat STATIC_ASSERT() over C11 static_assert().
Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Acked-by: Dave Airlie <airlied@redhat.com>
We now print
START B15 <-B14 (42774 cycles)
indicating that we estimate B15 will take 42,774 cycles. Printing
this should make it easier where time is spent in the program.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
GetFramebufferAttachmentParameteriv should return GL_LINEAR for the
window system default framebuffer's GL_DEPTH or GL_STENCIL attachments
when there are zero depth or stencil bits.
The GL 4.5 spec's GetFramebufferAttachmentParameteriv section says:
"If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is not NONE,
these queries apply to all other framebuffer types:
[...]
If attachment is not a color attachment, or no data storage or texture
image has been specified for the attachment, then params will contain
the value LINEAR."
Note that we already return LINEAR for the case where there is an actual
depth or stencil renderbuffer attached. In the case modified by this
patch, FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE returns FRAMEBUFFER_DEFAULT
rather than NONE.
Fixes a CTS test when run in a visual without depth / stencil buffers:
GL45-CTS.gtf30.GL3Tests.framebuffer_srgb.framebuffer_srgb_default_encoding
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Doesn't look like this can work on 32bit, just rids of annoying
warning.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Mark some paths unreachable so that compiler knows variables are
initialized in all valid paths.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Otherwise we get 32bit warnings because handle is plain uint64_t there
and NULL is not suited to initialize that.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
The new implementation is more correct because it clamps the incoming value
to 10 to avoid floating-point overflow. It also uses a much reduced
version of the formula which only requires 1 exp() rather than 2. This
fixes all of the dEQP-VK.glsl.builtin.precision.tanh.* tests.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "13.0" <mesa-dev@lists.freedesktop.org>
The formula we have used in the past is a trivial reduction from the
definition by simply multiplying both the numerator and denominator of the
formula by 2. However, multiplying by e^x, you can further reduce it.
This allows us to get rid of one side of the clamp and two of exponential
functions which should make it faster. The new formula still passes the
dEQP precision tests for tanh so it should be fine.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Mesa requires ax_pthread_ok = yes, thus we can fold/rewrite the
conditional to follow the more common "if test" pattern.
No functional change intended.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Document what has been the unofficial way to self-reject stable patches.
Namely: drop the mesa-stable tag and push the commit.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Nobody else makes use of this function.
We can always re-export it if someone ever needs it.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Clamp input scalar value to range [-10, +10] to avoid precision problems
when the absolute value of input is too large.
Fixes dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.* test
failures.
v2: added more explanation in the comment.
v3: fixed a typo in the comment.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "13.0" <mesa-dev@lists.freedesktop.org>
This is a step towards using NIR optimisations over GLSL IR
optimisations. Delaying adding built-in uniforms until after
we convert to NIR gives it a chance to optimise them away.
V2: move the new code back to brw_link_shader()
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Large points become pairs of triangles when rasterized, so we must feed
it three clip distances, one for each vertex.
The clip distance is not subject to sprite coord replacement, so there's
no interpolation of it. We just take its value and put it in the "z"
component of the barycentric-ready plane equation.
(We could also just cull it at an earlier point in time, but that would
require larger changes.)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Clip distances need to be perspective-divided. This fixes all the
interpolation-*-{distance,vertex} piglits.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
We don't set the push constants slot up unless
something will cause us to need it.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This only emits enough descriptor sgprs for the number
of sets in the layout, and only emits the descriptors
necessary for the current stage.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This isn't fully what we want yet, but is a good step on the way.
This allows the compiler to create the information structures
for the state setting side, however the state setting still expects
things to be pretty much in 2 sgpr wide register sets, and can't
handle the indirect setting yet.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just refactors out some common code to make future changes
easier to understand.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This copies the push constant code and only binds descriptor
sets to the stages that need them. It also now has to dirty
descriptors on pipeline binds.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is another step towards having the compiler decide the
user sgpr layout.
This still emits the descriptors sets for all shader types, but
we will fix this later.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just moves some common code into a utility function
to avoid having to change multiple places later.
v1.1: rename function to better reflect what it does. (Bas)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes random radeonsi GPU hangs in Batman Arkham: Origins (Wine) and
probably many other games too.
cso_cache deletes sampler states when the cache size is too big and doesn't
check which sampler states are bound, causing use-after-free in drivers.
Because of that, radeonsi uploaded garbage sampler states and the hardware
went bananas. Other drivers may have experienced similar issues.
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Enabling this debug switch causes surface shrinking to happen by
default, and lowers the surface size limit which causes blorp blits to
be split.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Detect when the surface sizes are too large for a blorp blit. When it
is too large, the blorp blit will be split into a smaller operation
and attempted again.
For gen7, this fixes the cts test:
ES3-CTS.gtf.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_multisampled_to_singlesampled_blit
It will also enable us to increase our renderable size from 8k x 8k to
16k x 16k.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
In blorp_copy, when RGB surfaces are copied, we convert the
destination surface to a Red only surface, but 3 times as wide. This
introduces an implicit restriction of "mod 3" for the destination
width.
It is easier to handle the blorp split buffer offsetting with the
original RGB surface, and do the RGB=>R after this.
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
If try_blorp_blit() previously returned that a blit was too large,
shrink_surface_params() will be used to update the surface parameters
for the smaller blit so the blit operation can proceed.
v2:
* Use double instead of float. (Jason)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We rename do_blorp_blit() to try_blorp_blit(), and add a return error
if the surface size for the blit is too large. Now, do_blorp_blit() is
rewritten to try to split the blit into smaller operations if
try_blorp_blit() fails.
Note: In this commit, try_blorp_blit() will always attempt to blit and
never return an error, which matches the previous behavior. We will
enable the size checking and splitting in a future commit.
The motivation for this splitting is that in some cases when we
flatten an image, it's dimensions grow, and this can then exceed the
programmable hardware limits. An example is w-tiled+MSAA blits.
v2:
* Use double instead of float. (Jason)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This will be useful for splitting blits into smaller sizes.
We also make the coordinates of type double rather than float. Since
we will be splitting and scaling the coordinates, we might require
extra precision in the calculations.
v2:
* Use double instead of float. (Jason)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Following the spirit of commit 23d1799f, fixes compilation
warnings on Android build due to lack of C11 features.
Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This extension allows the fragment shader to control whether values in
gl_SampleMaskIn[] reflect the coverage after application of the early
depth and stencil tests.
Signed-off-by: Plamena Manolova <plamena.manolova@intel.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This extension allows the fragment shader to control whether values in
gl_SampleMaskIn[] reflect the coverage after application of the early
depth and stencil tests.
Signed-off-by: Plamena Manolova <plamena.manolova@intel.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
This was uninitialized, which resulted in weird looking printouts where
it appeared that the TCS output and TES input patch URB entries differed
in SSO/non-SSO layout. There is no "separable" layout for both, as
they're tied together.
It should have no other actual effect.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
GRAS_SU_DEPTH_PLANE_CNTL doesn't in fact seem to be anything to do with
alpha test. This fixes xonotic and (other than some iommu faults) gets
gnome-shell working.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We don't need varying interpolators enabled for pos/psize out of the VS
(despite the fact that they show up in VS_OUT map), so emit these before
we append pos/psize to the linkage.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This was a hack which worked around the VS and TCS disagreeing on their
shared interface due to the lack of varying packing. In particular, it
was needed by Piglit's tcs-input-read-array-interface test.
However, that was just one case where things could go awry, so the
previous commit forcibly made interfaces match. This hack is no longer
necessary.
It also seems to be broken, though I'm not sure why. It fixes Piglit
regressions in spec/arb_shader_image_load_store/semantics from commit
ec1f159ac8.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98893
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
A while ago, I made i965 start compiling shaders independently. The VUE
map layouts were based entirely on each shader's input/output bitfields.
Assuming the interfaces match, this works out well - both sides will
compute the same layout, and outputs are correctly routed to inputs.
At the time, I had assumed that the linker would guarantee that the
interfaces match. While it usually succeeds, it unfortunately seems
to fail in some cases.
For example, Piglit's tcs-input-read-array-interface test has a VS
output array with two elements, but the TCS only reads one. The linker
isn't able to eliminate the unused element from the VS, which makes the
interfaces not match.
Another case is where a shader other than the last writes clip/cull
distances. These should be demoted to ordinary varyings, but they
currently aren't - so we think they still have some special meaning,
and prevent them from being eliminated.
Fixing the linker to guarantee this in all cases is complicated. It
needs to be able to optimize out dead code. It's tied into varying
packing and other messiness. While we can certainly improve it---and
should---I'd rather not rely on it being correct in all cases.
This patch ORs adjacent stages' input/output bitfields together,
ensuring that their interface (and hence VUE map layout) will be
compatible. This should safeguard us against linker insufficiencies.
Fixes line rendering in Dolphin, and the Piglit test based on it:
spec/glsl-1.50/execution/geometry/clip-distance-vs-gs-out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97232
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We would really like it to be false as that's what you get on hardware that
doesn't have RegisterPoleMode (Sky Lake for example). While we're at it,
we change it to a boolean. This fixes dEQP-VK.synchronization.smoke.events
on Broxton.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
LLVM can't really optimize anything which crosses scalar/vector boundaries,
so help a bit with some particular gather operations when the width is
expanded (only do it for 16->32bit expansion for now), by doing expansion
after fetch. That is probably a better solution anyway even if llvm would
recognize it, makes for cleaner IR...
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Note that we really want to _never_ reach the bottom of the function, which
resorts to AoS fetch.
Half floats can be handled just like other formats which fit into 32bit
vectors (so, only 1x16 and 2x16 formats, albeit with more channels things
are not THAT bad), with minimal plumbing. I've seen code size go down nearly
by a factor of 3 for a complete texture sampling function (including bilinear
filtering) using R16F.
(What we should do for everything not special cased is to do AoS gather,
shuffle/shift things into SoA vectors, and then do the conversion there.
Otherwise it's particularly bad with 1 or 2 channel formats - that r16f
format with either 4 or 8-wide vectors was still doing one element at a
time, essentially doing exactly the same work as for rgba16f. Also replacing
the channels with SWIZZLE0/1 (particularly the latter) adds even more
work, as it has to be done per aos vector, and not just straightforward
at the end with the SoA vector.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The PRMs for HSW and newer say that other than the opcode and DebugCtrl
bits of the instruction word, the rest must be zero.
By zeroing the instruction word manually, we avoid using any of the
state inherited through brw_codegen.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96959
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Allocating zero URB space is a really bad idea. The hardware has to
give threads a handle to their URB space, and threads have to use that
to terminate the thread. Having it be an empty region just breaks a
lot of assumptions. Hence, why we asserted that it isn't possible.
Unfortunately, it /is/ possible prior to Gen8, if max_vertices = 0.
In theory a geometry shader could do SSBO/image access and maybe
still accomplish something. In reality, this is tripped up by
conformance tests.
Gen8+ already avoids this problem by placing the vertex count DWord
in the URB entry header. This fixes things on earlier generations.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
As per GL 4.5 rules, which fixed a spec mistake in GL_ARB_stencil_texturing.
The extension spec wasn't updated, but just allow it with older GL versions
as well, hoping there aren't any crazy tests which want to see an error
there... (Compile tested only.)
Reported by Józef Kucia <joseph.kucia@gmail.com>
Acked-by: Józef Kucia <joseph.kucia@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Trivial, this just resurrects the code which was there once upon a time
(the code can't lower instructions generated in the lowering pass there,
and even if it could it would probably be suboptimal).
This fixes piglit mesa_shader_integer_functions fs-ldexp.shader_test and
vs-ldexp.shader_test with llvmpipe.
Reviewed-by: Matt Turner <mattst88@gmail.com>
All of these are happily set from glsl_to_nir or spirv_to_nir but their
values are never used for anything.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Constant initializers have been a constant (ha!) pain for quite some time.
While they're useful from a language perspective, people writing passes or
backends really don't want deal with them most of the time. This commit
removes most of the constant initializer support from NIR. It is expected
that you call nir_lower_constant_initializers VERY EARLY to ensure that
they're gone before you do anything interesting.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
It's only ever called on single-function shaders. At this point, there are
a lot of helpers that can make it all much simpler.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
When I originally implemented the ARB_copy_image extension, the fast-path
was written in meta using texture views. This path only worked if both
images were uncompressed color images. All of the other cases fell back to
the blitter or, in the worst case, mapping and memcpy on the CPU. Now that
we have the blorp path, it handles all copies ever and the old meta,
blitter, and CPU paths are only used on gen5 and below. The primary reason
why we needed the meta path (apart from having a slow blitter on later
hardware) was to handle multisampling which gen5 and earlier don't support
anyway. Since the blitter is reasonably fast on gen5, we can just delete
the meta path and get rid of all that terrible code.
If we decide that we're ok with just disabling ARB_copy_image on gen5 and
earlier (I personally am), then we could get rid of another 300 lines or so
of semi-hairy code.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
By using emit_miptree_blit which does chunking, this fixes the blitter path
for the case where the image is too tall to blit normally. We also pull it
into intel_blit as intel_miptree_copy. This matches the naming of the
blorp blit and copy functions brw_blorp_blit and brw_blorp_copy.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "13.0" <mesa-dev@lists.freedesktop.org>
This moves the nir_lower_indirect_derefs() call into
brw_preprocess_nir() so thats is called by both OpenGL and Vulkan
and removes that call to the old GLSL IR pass
lower_variable_index_to_cond_assign()
We want to do this pass in nir to be able to move loop unrolling
to nir.
There is a increase of 1-3 instructions in a small number of shaders,
and 2 Kerbal Space program shaders that increase by 32 instructions.
Shader-db results BDW:
total instructions in shared programs: 8705873 -> 8706194 (0.00%)
instructions in affected programs: 32515 -> 32836 (0.99%)
helped: 3
HURT: 79
total cycles in shared programs: 74618120 -> 74583476 (-0.05%)
cycles in affected programs: 528104 -> 493460 (-6.56%)
helped: 47
HURT: 37
LOST: 2
GAINED: 0
Use llvm provided API based on cpuid rather than our own
manually mantained list of mattr enabling/disabling.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
And declare coded_buf in vlVaContext as "vlVaBuffer *" instead of
"struct vlVaBuffer *".
This fixes several warnings later about assignment from incompatible
pointer type.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Remove some transitional left overs from the gallium pipe-loader rework
and kill off unneeded AM_CPPFLAGS.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This makes sure that we handle LLVM minor version >= 10 correctly.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Major and minor version are included in the header file since LLVM
version 3.1.0. Since the minimal required version is 3.3.0 we can
remove the workaround if no values for major/minor were found in the
header.
Since LLVM 3.6.0 the patch version is inside the header file of LLVM.
Only radeon drivers need the patch version and they depend on
LLVM >= 3.6.0, so this is safe too.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Consolidate the required LLVM versions at the top where the other
versions for dependencies are listed.
v5:
Splitted out separate changes (see patch 19 and 20)
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
LLVM components are only added when LLVM is needed.
This means gallium adds this as soon as "--enable-gallium-llvm"
is "yes" and radv + opencl add it explicitly.
v5:
Removed hunk that disabled LLVM for gallium if it was not found.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This moves the LLVM check for radv to the corresponding driver section.
No functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This moves llvm_set_environment_variables to its final destination
and moves all the LLVM AC_SUBST() below the function call.
No functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The LLVM checks can be anywhere below line 1161 now.
Move the openCL LLVM checks to the section with the other openCL checks.
No functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
[Emil Velikov: s/ipos/ipo/, drop "yes" argument from llvm_add_component]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This moves the function to get the LLVM environment variables higher
in the file. It still needs to be below the "--enable-opencl" because
it uses $enable_opencl.
It can be called without condition now as it only throws errors if
openCL is enabled.
v5:
HAVE_MESA_LLVM is only used for gallium. Rename it to HAVE_GALLIUM_LLVM.
In order to only link LLVM when it is needed, HAVE_GALLIUM_LLVM is only
set if "$enable-gallium-llvm" is yes.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
No need for an additional function here.
Use the same style for LLVM checks as the other drivers
(e.g. r300, llvmpipe) that don't need a load of other checks.
Instead of open conding the LLVM version check, use the
function used by other drivers.
"enable_gallium_llvm" is checked by gallium_require_llvm().
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This moves the LLVM version check to the helper function
gallium_require_llvm() and uses the llvm_check_version_for() helper
instead of open conding the LLVM version check.
gallium_require_llvm is functionally the same as before, because
"enable_gallium_llvm" is only set to "yes" if the host cpu is x86:
if test "x$enable_gallium_llvm" = xauto; then
case "$host_cpu" in
i*86|x86_64|amd64) enable_gallium_llvm=yes;;
esac
fi
This function is also only called now when needed.
Before this patch llvmpipe would call this as soon as LLVM is
installed. Now it only gets called by llvmpipe if gallium
LLVM is actually enabled (i.e. only on x86).
Both reasons mentioned above remove the need to check host cpu
in the gallium_require_llvm function.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
There are no non gallium r300 and r600 drivers anymore.
No need to explicilty mention gallium here.
Just cosmetics, no functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
There's no harm in always searching llvm-config.
This way it's available as soon as possible for all functions.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This just moves code around so that all LLVM related stuff is at the
top of the file in the correct order.
No functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
A function with the LLVM version checked is moved to the top.
The function is called where the old code was.
No functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
[Emil Velikov: s/ipos/ipo/, drop "yes" argument from llvm_add_component]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Use the new helper function to add LLVM targets and components.
The components are added one by one to later find out which component
is missing in case there is one.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
[Emil Velikov: s/ipos/ipo/, drop "yes" argument from llvm_add_component]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Add functions to add and check targets/components.
Not used in this patch.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This way LLVM_CONFIG can bet set from an env variable if it's outside
the $llvm_prefix.
This is not a must, but it helps testing.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The gop_size in rate control is the budget window for internal rate
control calculation, and shouldn't always equal to idr period. Define
a coefficient to let budget window contains a number of idr period for
proper rate control calculation. Adjust the number of i/p frame remaining
accordingly.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98005
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
The gop_size in rate control is the budget window for internal rate
control calculation, and shouldn't always equal to idr period. Define
a coefficient to let budget window contains a number of idr period for
proper rate control calculation. Adjust the number of i/p frame remaining
accordingly.
v2: fixed regression issues introduced by previous version
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98005
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
The active_query count was incorrect for query types that don't require
a begin_query. Removed the unnecessary assert.
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
This has bothered me for about as long as NIR has been around. Why do we
have two different unions for constants? No good reason other than one of
them is a direct port from GLSL IR.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This is mostly just used during linking however the st uses it
when updating textures.
In order to store gl_program in the CurrentProgram array
rather than gl_shader_program we need to move this field to
the shared gl_shader_program_data struct.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
If app tries to create a fence but there is no rendering to submit, we
need a dummy/no-op submit. Use a string-marker for the purpose.. mostly
since it avoids needing to realize that the packet format changes in
later gen's (so one less place to fixup for a5xx).
Signed-off-by: Rob Clark <robdclark@gmail.com>
Prep-work for next patch, mostly move to tracking last_fence as a
pipe_fence_handle (created now only in fd_gmem_render_tiles()), and a
bit of superficial renaming.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This enables gallium support for EGL_ANDROID_native_fence_sync, for
drivers which support PIPE_CAP_NATIVE_FENCE_FD.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This will be needed for explicit synchronization with devices outside
the gpu, ie. EGL_ANDROID_native_fence_sync.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We were previously also verifying that no backing buffers were available
when an array wasn't enabled. This is has no basis in the spec, and it
causes GLupeN64 to fail as a result.
Fixes: c2e146f487 ("mesa: error out in indirect draw when vertex bindings mismatch")
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Noticed in shaders with branching, where we ended up scheduling delay
slots near the start of a block for the uniforms reset setup.
total instructions in shared programs: 93970 -> 93951 (-0.02%)
instructions in affected programs: 3117 -> 3098 (-0.61%)
3DMMES performance +0.423087% +/- 0.133521% (n=9,10)
This helps us get the delay slots between SFU writes and reads filled.
total instructions in shared programs: 94494 -> 93970 (-0.55%)
instructions in affected programs: 59206 -> 58682 (-0.89%)
3DMMES performance +1.89967% +/- 0.157611% (n=10,9)
The latency_between was trying to handle the delay between the coordinate
write ("before") and the corresponding sample read ("after"), but we were
handing in the two instructions swapped.
This meant that we tried to fit things between a tex_s and its *preceding*
tex_result. This made us only interleave normal texture coordinates by
accident, and pessimized UBO reads by pushing the tex_result collection
earlier until there was nothing but it (and then its preceding coordinate
setup) left.
In addition to latency reduction, things end up packing better (probably
due to reduced live ranges of the texture results):
total instructions in shared programs: 98121 -> 94775 (-3.41%)
instructions in affected programs: 91196 -> 87850 (-3.67%)
3DMMES performance +1.15569% +/- 0.124714% (n=8,10)
I'm not sure how I managed to write the SF merge code
(7d8b79f398) without allowing merges with
NOPs. *Everything* we try to merge with will have a NOP on one or the
other side of the instruction, and that's why that commit showed no
benefit.
total instructions in shared programs: 99347 -> 95128 (-4.25%)
instructions in affected programs: 91906 -> 87687 (-4.59%)
3DMMES performance +2.57105% +/- 0.135276% (n=6,8)
This should be a win for most loops, which tend to have uniform control
flow.
More importantly, it exposes important information to live variables: that
the break/continue here means that our jump target may have access to
values that were live on our input. Previously, we were just setting the
exec mask and letting control flow fall through, so an intervening def
between the break and the end of the loop would appear to live variables
as if it screened off the variable, when it didn't actually.
Fixes a regression in glsl-vs-loop-redundant-condition.shader_test when a
perturbing of register allocation caused a live variable to get stomped.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
This is already supported in genX_state.c, expose the extension string.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
In an attempt to fix 3DSTATE_DEPTH_BUFFER for stencil-only cases, I
accidentally kept setting the SurfaceType to 2D in the stencil-only case
thanks to a copy+paste error.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
The buffer_size does not take the offset into account. Just add the
offset into the pointer which lines up the structures much better.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
There is no support for resuming streamout. Furthermore, this also
controls glDrawTransformFeedback functionality which requires the same
ability to query how many primitives were sent out of TF.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
We need to take the instance divisor and number of instances into
account for instanced client-side arrays, rather than the vertex
parameters.
Loosely based on the comparable nvc0 logic.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
We now support clearing these, and actually rendering to multiple layers
would require GS support, which will fail in much more spectacular ways
for now. Once that is hooked up, there won't be anything else to do
here.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Since we don't pass a renderTargetArrayIndex in, and the current hot
tile may be for a different index, we may end up loading the RTAI=0 into
the hot tile for no reason.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Internal docs don't mention it, but they also don't mention that the bug
has been fixed (like other CI bugs fixed in VI).
Vulkan does this too.
v2: also update r600_gfx_write_fence_dwords
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
34953f8907 added this bitmask but it wasn't being reset when
a program was relinked. If a stage was removed from the new
program then it could case a crash as we expect the linked shader
for that stage to not be null.
Fixes crashes in:
ESEXT-CTS.tessellation_shader.single.xfb_captures_data_from_correct_stage
ES31-CTS.core.tessellation_shader.single.xfb_captures_data_from_correct_stage
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98917
Looks like immed branch offset size increased again.. making what we
think is a small negative number look to hw like a huge positive number.
And things go badly when shader tries to jump to hyperspace.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Android doesn't build all the files that normal linux/autotools build
does (mainly standalond ir3_compiler).. but possibly we should pull
C_SOURCES + aNxx_SOURCES into a single variable picked up by both
Android.mk and Makefile.am? (Suggested by Rob H.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
Set the include paths to consider in-tree headers before out-of-tree
headers.
Avoids the build failing due to stale headers being present in
$prefix. Previosuly 'make -ki install' or something similar was required
to update the out-of-tree headers to allow the build to succeed.
Also avoids having to rebuild the entire thing after every 'make
install'.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
On a3xx/a4xx, the SP_VS_VPC_DST_REG.OUTLOCn is offset by 8, so we used
to add this offset into fs->inputs[n].inloc. But a5xx drops this extra
offset-by-8. So instead make inloc zero based and add the offset when
we emit OUTLOCn values (for the gen's that need the offset).
Signed-off-by: Rob Clark <robdclark@gmail.com>
Helps simplify things on a5xx, where pos/psize get added to the vs-out
map. And anyways, simplifies a3xx and a4xx.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Drivers that support this benefit by saving one lowering pass in the
GLSL-to-TGSI conversion.
radeonsi already supports this because all outputs are stored in temporary
variables before the export (except for TCS outputs, which have always
been readable in TGSI anyway due to their special semantics).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
With nir_intrinsic_ssbo_atomic_comp_swap we run out of params.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This one was split across two dwords as "Kernel Start Pointer" and
"Kernel Start Pointer High", which looks like it works when the driver
only accesses "Kernel Start Pointer". This breaks, of course, with BO
offsets > 4G.
Signed-off-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When the state fields where shuffled around for gen8, the compare
function enums were downgraded to just uints. Change them to enum
3D_Compare_Function.
Signed-off-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The previous commits got rid of any clashes between #defines and enum
values and we can now emit the genxml enums as debugger friendly C
enums.
Signed-off-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
These values were defined both as an enum and as inline values. Remove
the inline values and reference the 3D_Compare_Function enum instead.
Signed-off-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This lets us reference enums in the type attribute of a field.
Signed-off-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cleaner this way and we avoid including gen9_pack.h when we compile with
gen8_pack.h. We also avoid the if (cherryview) condition for non-gen8
gens that don't need it.
Signed-off-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The batch chain logic only needs the pre-gen8 size of
MI_BATCH_BUFFER_START, which seems like something we can make a special
case for. The other two gen7 references, MI_BATCH_BUFFER_END and
MI_NOOP, are the same on all gens.
Signed-off-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We'll need to define them before we can reference them in structs and
instructions. Enums have no dependencies, so move them first in the
file.
Signed-off-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Remove duplicate .alphaToOne, add missing .shaderResourceMinLod, and
reorder a few entries to match their vulkan.h order. All the sparse
features are still left out entirely.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Without this, the X server may accumulate stale Present event contexts
if a client creates and destroys multiple swapchains using the same
window.
v2: Based on Chris Wilson's review:
* Use xcb_present_select_input_checked so that protocol errors
generated by old X servers can be handled gracefully
* Use xcb_discard_reply() instead of free(xcb_request_check())
v3: Rebased on top of this code having been refactored out of anv
Reviewed-by: Dave Airlie <airlied@redhat.com>
This should be faster than looping over every stage and null checking, but
will also make the code a bit cleaner when we switch to getting more fields
from gl_program rather than from gl_linked_shader as we can just copy the
pointer and not need to worry about null checking then copying.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now that we have a linked_stages bitfield we can use this
to check if the program is used at a later stage.
This change is also required to be able to use gl_program
rather than gl_shader_program in the CurrentProgram array.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This will be used to enable us to store the current gl_program
rather than gl_shader_program in the gl_pipline_object allowing
us to simplify handing of validation.
Also we should not be depending on _LinkedShader for this information
as it may contain shaders from a failed linking attempt rather than
the current program still in use.
We could also use this mask to iterate over the stages during linking
with _mesa_bit_scan() rather then the current method of NULL checking
each stage.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Instead of (incorrectly) biasing the snorm value to make it look like a
unorm, just use signed integer math.
This fixes arb_color_buffer_float-render GL_RGBA8_SNORM
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
I find this a lot more readable and compact - much easier to scan
through the list and see what's on and what's off.
No functional change intended.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
This fixes dual source blending on Stoney. The fix was copied from Vulkan.
The problem was discovered during internal testing.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes:
dEQP-VK.pipeline.multisample_interpolation.offset_interpolate_at_sample_position.*
This should probably be 2 when sample shading is enabled, but I'm
not sure.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to force persample shading when
a) shader uses sample_id
b) shader uses sample_position
c) shader uses sample qualifier.
Also since ps_iter_samples can now change independently of the
rasterizer samples we need to move setting the regs more often.
This fixes:
dEQP-VK.pipeline.multisample_interpolation.centroid_interpolate_at_consistency.*
dEQP-VK.pipeline.multisample_interpolation.centroid_qualifier_inside_primitive.137_191_1.*
dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_distinct_values.*
dEQP-VK.pipeline.multisample_interpolation.sample_qualifier_distinct_values.128_128_1.*
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This only useful for spir-v shaders, but I keep finding myself
having to add it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In commit 45cd76e342 schedule_instructions(bblock_t *) began
setting bblock_t::cycle_count, but that function was not called on
trivial blocks.
Remove the code to skip trivial blocks so that cycle_count is set.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
schedule_instructions(bblock_t *) isn't called on blocks with a single
instruction, and since it is the only thing that set cycle_count,
cycle_count would be uninitialized.
A non-empty block with bblock_t::cycle_count == 0 is arguably a bug.
That'll be fixed in the next commit.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Meta was using it before it was set. I suspect we typically don't
want to dump meta shaders, so just set it to false in the beginning.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Debugging a shader-db reported cycle count regression from the tex
coalescing, I eventually figured out that the texture latencies were
totally bogus. Really fixing it will probably involve mirroring
vc4_qir_schedule.c's texture fifo management here.
This isn't as complete as I would like (can't merge interpolation because
of the implicit r5 dependency, doesn't work with control flow), but this
was cheap and easy.
Improves 3DMMES Taiji performance by 1.15353% +/- 0.299896% (n=29, 16)
total instructions in shared programs: 99810 -> 99059 (-0.75%)
instructions in affected programs: 10705 -> 9954 (-7.02%)
The VPM write logic will be basically the same as the texture coordinate
write logic we need, and it's not really related to the VPM read logic
other than the reuse of the use_count array.
Every caller was dereffing the qinst, and this will let us make the number
of sources vary depending on the destination of the qinst so that we can
have general ALU ops that store to tex_[strb] and get an implicit uniform.
This may have made a tiny bit of sense when we had one 4-arg inst per
shader, but if we only ever put 2 things in, having a pointer to 2 things
almost every instruction is pointless indirection.
This matches what NVIDIA and AMD hardware expose, as well as what Intel
hardware supports.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Offsets that don't fit into 4 bits need to force gather_po to be
selected. Adjust the logic so that this happens.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Previously, we had an OFFSET_VALUE source for logical texture instructions
that was intended to mean exactly what it says, "offset". In reality, we
only fully used it for tg4 offsets. We used offset_value.file == IMM to
mean, "you have a constant offset, go look in instr->offset" and didn't
actually use the contents of the register at all in that case except for
in nir_emit_texture where we used it as a temporary before we copy it into
instr->offset.
This commit renames OFFSET_VALUE to TG4_OFFSET and restricts its usage to
indirect tg4 offsets only. The nir_emit_texture code is refactored so that
we explicitly build a header_bits value which is placed in instr->offset
and the constant offset values (both for tg4 and regular texture
operations) are used to construct header_bits and don't go through the
offset source at all. Finally, we stop passing offset_value in to
lower_sampler_logical_send_gen5 because we can't do indirect offsets until
gen7 anyway.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Not sure about the deprecation path, but this intrinsic
can be lowered to SMEM loads. This results in a significant
Talos performance improvement.
v2: Fix for LLVM attribute changes.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
07fe2d565b introduced a big hack in order to return
NumSubroutineUniforms when querying ACTIVE_RESOURCES for
<shader>_SUBROUTINE_UNIFORM interfaces. However this is the
wrong fix we are meant to be returning the number of active
resources i.e. the count of subroutine uniforms in the
resource list which is what the code was previously doing,
anything else will cause trouble when trying to retrieve
the resource properties based on the ACTIVE_RESOURCES count.
The real problem is that NumSubroutineUniforms was counting
array elements as separate uniforms but the innermost array
is always considered a single uniform so we fix that count
instead which was counted incorrectly in 7fa0250f9.
Idealy we could probably completely remove
NumSubroutineUniforms and just compute its value when needed
from the resource list but this works for now.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
The 1-D special case doesn't actually apply to depth or HiZ. I discovered
this while converting BLORP over to genxml and ISL. The reason is that the
1-D special case only applies to the new Sky Lake 1-D layout which is only
used for LINEAR 1-D images. For tiled 1-D images, such as depth buffers,
the old gen4 2-D layout is used and the QPitch should be in rows.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
The gen7/8_cmd_buffer logic already sets the clamp, and it's piped
through via the dynamic state.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These are all regularly available in desktop GL, so the backend fully
supports them.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This commit does two things. One is to pull useful and/or interesting
information from the AUB file header and display it as a header above your
decoded batches. Second, it is now capable of pulling the PCI ID from the
AUB file comment left by intel_aubdump. This removes the need to use the
--gen flag all the time.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We were reading from the "comment size" dword and incrementing by that
amount. This never caused a problem because that field was always zero.
However, experimenting with actual aub file comments indicates, the
simulator seems to include the comment size in the packet size provided in
the header. We should do the same.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The helper automatically handles masking for us so we don't have to worry
about whether or not something is in the bottom bits.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
This new helper is automatically handles 32 vs. 48-bit GTT issues. It also
handles 48-bit canonical addresses on Broadwell and above.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
The original aubinator that Kristian wrote had a bug in the handling of
MI_BATCH_BUFFER_START that propagated into the version in upstream mesa.
In particular, it ignored the "2nd level" bit which tells you whether this
MI_BATCH_BUFFER_START is a subroutine call (2nd level) or a goto. Since
the Vulkan driver uses batch chaining, this can lead to a very confusing
interpretation of the batches. In some cases, depending on how things are
laid out in the virtual GTT, you can even end up with infinite loops in
batch processing.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Among other things, blits would clear existing SO targets which would
cause a bunch of updates from u_blitter to be missed.
Fixes fbo-scissor-blit fbo, probably among many others.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
I asked Emil to switch from 0 (success) vs. -1 (fail) to use a boolean
in my review comments. The "not" went missing. Easy mistake, but the
result is that nothing runs at all :)
Fix whitespace while we're here too.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
anv_queue_init() always returns VK_SUCCESS, so caller does not need
to check return value of anv_queue_init().
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When the memfd_create() and u_vector_init() fail on anv_block_pool_init(),
this patch makes to return VK_ERROR_INITIALIZATION_FAILED.
All of initialization success on anv_block_pool_init(), it makes to return
VK_SUCCESS.
CID 1394319
v2: Fixes from Emil's review:
a) Add the return type for propagating the return value to caller.
b) Changed anv_block_pool_init() to return VK_ERROR_INITIALIZATION_FAILED
on failure of initialization.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
If radv_device_get_cache_uuid() fails result will be VK_SUCCESS as set
by the radv_init_wsi() call above.
Fixes: d943839 (radv: Use library mtime for cache UUID.)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Inspired by a similar commit for radv.
Rather than recomputing the timestamp on each make invocation, just
fetch it at runtime.
Thus we no longer get the constant rebuild of anv_device.c and the
follow-up libvulkan_intel.so link, when nothing has changed.
I.e. using make && make install is a little bit faster.
v2: Use bool return type (Ken).
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Port of an equivalent commit for radv.
v2: Move the call just after MMAP_VERSION (Ken).
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I've used an ancient version of the script which did not cover:
- version expansion (cd mesa-* does not work)
- --enable-glx-tls
- EGL and es2* testing
- Vulkan and DOTA2
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This fixes:
dEQP-VK.api.image_clearing.clear_color_image.3d*
These were hitting an assert as the code wasn't taking the
baseMipLevel into account when minify the image depth.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
This fixes b56b54cbf1:
radv/ac/llvm: shadow samplers only return one value
It makes sure we only do that for shadow sampling, as
opposed to sizing requests.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
radv_queue_init() always returns VK_SUCCESS, so caller does not need
to check return value of radv_queue_init().
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is not allowed for indirect accesses because the source
GPR might be erased by a subsequent instruction (WaR hazard)
if we don't emit a read dep bar.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This will allow to use MOV instead of LD. The main advantage is
that MOV doesn't require a read dependency barrier while LD does,
and so this will both reduce barriers pressure and the number of
stall counts needed to read data from constant memory.
This is currently only for user uniform accesses. I should do
something similar when loading from the driver constant buffer
but it seems like a bit tricky to handle for now.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
One can now also delete intel_get_non_msrt_mcs_alignment().
v2 (Jason): Do not leak aux buf but allocate only after getting
ISL surfaces.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Note that RESOLVED is not tracked in the map explicitly. Absence
of item implicitly means RESOLVED state.
v2: Added intel_resolve_map_clear() into intel_miptree_release()
v3 (Jason): Properly handle the assumption of resolve map not
containing any items with state RESOLVED. Removed
unnecessary intel_miptree_set_fast_clear_state() call
in brw_blorp_resolve_color() preventing
intel_miptree_set_fast_clear_state() from asserting
against RESOLVED.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Status is still tracked per miptree. Next patch will switch to
resolve map per slice/level.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Until now fast clear has been supported only for non-layered and
non-mipmapped buffers. However, from gen8 onwards there is hardware
support also for layered/mipmapped. Once this is enabled, fast clear
operations target specific layer/level and call for the state to be
tracked in the same granularity. This is the first step providing
the details from callers to the state tracking.
Patch introduces new interface for reading and writing the state
hiding the upcoming bookkeeping changes in the call sites. There is
bunch of sanity checks added that will be relaxed per hardware
generation later on when the actual functionality is enabled.
v2: Rebased on top current master setting the state in
blorp_surf_for_miptree().
v3: Replace open-coded resolved check in surface state emission
with intel_miptree_has_color_unresolved().
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This patch also introduces getter and setter for fast clear state
preparing for tracking the state per slice.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Currently the status bits for fast clear include the flag telling
if non-multisampled mcs buffer should be used at all. Once the
state tracking is changed to follow individual levels/layers one
still needs to have the mcs enabling information in the miptree.
Therefore simply split it out to its own boolean.
Possible follow-up work is to combine disable_aux_buffers and
no_ccs into single enum.
v2 (Jason): Changed no_msrt_mcs to no_ccs and updated comment
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v2: Make intel_miptree_resolve_color() take start layer and
layer count.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Upcoming patches will introduce fast clear in level/layer
granularity like the driver does already for depth/hiz. This patch
introduces equivalent full resolve option.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Essentially this moves fast clear state update away from surface
state setup into brw_postdraw_set_buffers_need_resolve() that gets
called just after draw submission.
Calling intel_miptree_used_for_rendering() can be drop for gen6
and earlier as it is no-op.
v2: Rebased on top current master setting the state in
blorp_surf_for_miptree().
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This reverts commit aaa69c79cd.
The commit was erroneous because the ast_layout_expression class is
meant to hold a list used for an after check that all the declared
values for a layout-qualifier-name are consistent.
Therefore, the check for the possibility of duplicated values was
previously fixed to happen much sooner, in the GLSL parser and the
merge of layout qualifiers, and the process_qualifier_constant method
only needs to check that the values are consistent.
By now, those layout-qualifier-name represented as a
ast_layout_expression are "max_vertices", "invocations", "vertices",
"local_size_[x|y|z]" and "xfb_stride".
From page 40 (page 46 of the PDF) of the GLSL 1.50 spec:
" All geometry shader output layout declarations in a program must
declare the same layout and same value for max_vertices."
From page 44 (page 50 of the PDF) of the GLSL 4.00 spec:
" If an invocation count is declared, all such declarations must
specify the same count."
From page 47 (page 53 of the PDF) of the GLSL 4.00 spec:
" All tessellation control shader layout declarations in a program
must specify the same output patch vertex count."
From page 60 (page 66 of the PDF) of the GLSL 4.30 spec:
" Also, if such a layout qualifier is declared more than once in the
same shader, all those declarations must set the same set of local
work-group sizes and set them to the same values; otherwise a
compile-time error results. If multiple compute shaders attached
to a single program object declare local work-group size, the
declarations must be identical; otherwise a link-time error
results."
From page 73 (page 79 of the PDF) of the GLSL 4.40 spec:
" While xfb_stride can be declared multiple times for the same
buffer, it is a compile-time or link-time error to have different
values specified for the stride for the same buffer."
Fixes GL44-CTS.enhanced_layouts.xfb_duplicated_stride
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
This reverts commit 4c86399378.
The commit was erroneous because the ast_layout_expression class was
created to hold a list of values for a layout-qualifier-name which is
allowed to appear in more than one expression in the same
shader/program but not to hold different values.
In other words, the list is used for an after check that all the
declared values for a layout-qualifier-name are consistent.
Therefore, the values stored must match always, not just for
"max_vertices" or any other eventual layout-qualifier-name.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
After the previous modifications in the merging of the
layout-qualifier-name values, we no longer push the final value in a
declaration to the global values.
This regression happens because we don't call for merging on the
right-most layout qualifier of a declaration which is also the
overriding one in case of multiple appearances.
Now, we add a new method to push these values to the global ones and
we call for this just after all the layout-qualifier collapsing has
happened in a declaration.
This simplifies how this was working in two ways; we make a clear
differentiation of when we are pushing this to the global values since
before it was mixed in the merging call and we only run this once all
the processing for layout-qualifiers in a declaration has happened.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
The GLSL parser has been simplified to check for the needed
GL_ARB_shading_language_420pack extension just when merging the
qualifiers in the proper cases.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Since we modified the way in which multiple repetitions of the same
layout-qualifier-name in a single declaration collapse into the
ast_type_qualifier class, we can simplify the
merge_into_[in|out]_qualifier APIs through removing the create_node
parameter.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
From page 46 (page 52 of the PDF) of the GLSL 4.20 spec:
" More than one layout qualifier may appear in a single
declaration. If the same layout-qualifier-name occurs in multiple
layout qualifiers for the same declaration, the last one overrides
the former ones."
Consider this example:
" #version 150
#extension GL_ARB_shading_language_420pack: enable
layout(max_vertices=2) layout(max_vertices=3) out;
layout(max_vertices=3) out;"
Although different values for "max_vertices" results in a compilation
error. The above code is valid because max_vertices=2 is ignored.
Hence, when merging qualifiers in an ast_type_qualifier, we now ignore
new appearances of a same layout-qualifier-name if the new
"is_multiple_layouts_merge" parameter is on, since the GLSL parser
works in this case from right to left.
In addition, any special treatment for the buffer, uniform, in or out
layout defaults has been moved in the GLSL parser to the rule
triggered just after any previous processing/merging on the
layout-qualifiers has happened in a single declaration since it was
run too soon previously.
Fixes GL44-CTS.shading_language_420pack.qualifier_override_layout
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Several layout-qualifier validations are duplicated in the
merge_qualifier and validate_in_qualifier methods.
We would rather have them refactored into single calls.
Suggested by Timothy.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
The point mode value in an ast_type_qualifier can only be true if the
flag is already set since this layout-id-qualifier can only be or not
be present in a shader.
Hence, it is useless to check for its value if the flag is already
set. Just replaced with an assert.
V2: assert instead of checking for coherence and raising a compilation
error. Suggested by Timothy.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
The validation of the default in layout qualifier already assures that
we won't have 2 ast_gs_input_layout objects with different primitive
type values. In fact, the validation already assures that we won't
have 2 ast_gs_input_layout objects in the AST tree at all.
The check for an error in the shader has been replaced by an assert.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
The merge into the default in layout qualifier duplicates a lot of
code that can be reused from the generic merge method.
Now, we use the generic merge method inside the specific merge for the
default in layout qualifier. The generic merge method has been
completed with some bits that were only present in the merge for the
default in layout qualifier and the specific validation bits have been
moved to the validation method for the default in layout qualifier.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Currently, the default in layout qualifier merge performs specific
validation and merge.
We want to split out the validation from the merge so they can be done
independently.
Additionally, for simplification, the direction of the validation and
merge is changed so the ast_type_qualifier calling the method is the
one validated and merged against the default in qualifier.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Currently, the default out layout qualifier merge performs specific
validation and merge.
We want to split out the validation from the merge so they can be done
independently.
Additionally, for simplification, the direction of the validation and
merge is changed so the ast_type_qualifier calling the method is the
one validated and merged against the default out qualifier.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Consider this example:
" #version 150 core
#extension GL_ARB_shading_language_420pack: require
#extension GL_ARB_explicit_attrib_location: require
layout(location=0) out vec4 o;
layout(binding=2) layout(binding=3, std140) uniform U {
vec4 a;
} u[2];"
As there is 2 layout-qualifiers for the uniform U and the binding
layout-qualifier-id is duplicated, the rules set by the
ARB_shading_language_420pack spec state that the rightmost should
prevail.
Our ast_type_qualifier merges with others in a way that if the value
for a layout-qualifier-id is set in both, the object being merged
overwrites the value of the object invoking the merge. Hence, the
merge has to happen from the left layout towards the right one and
this was not happening for interface blocks because we were merging
into the default layout qualifier.
Now, the merge is done from left to right and, as a last step, we
merge into the default layout qualifier if needed, so the values of
the explicit layouts prevail over it.
V2: added a default_layout variable instead of a layout_helper and
make the merge directly over the layout one. Suggested by Timothy.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
When a layout contains a duplicated layout-qualifier-name in a single
declaration, only the last occurrence should be taken into account.
From page 59 (page 65 of the PDF) of the GLSL 4.40 spec:
" More than one layout qualifier may appear in a single
declaration. Additionally, the same layout-qualifier-name can
occur multiple times within a layout qualifier or across multiple
layout qualifiers in the same declaration. When the same
layout-qualifier-name occurs multiple times, in a single
declaration, the last occurrence overrides the former
occurrence(s)."
Consider this example:
" #version 150
#extension GL_ARB_enhanced_layouts: enable
layout(max_vertices=2, max_vertices=3) out;
layout(max_vertices=3) out;"
Although different values for "max_vertices" results in a compilation
error. The above code is valid because max_vertices=2 is ignored.
When merging qualifiers in an ast_type_qualifier, we now simply ignore
new appearances of a same layout-qualifier-name if the
"is_single_layout_merge" parameter is true, this works because the GLSL
parser processes qualifiers from right to left.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Fixes multiple Vulkan CTS tests that combine anisotropy and VK_FILTER_NEAREST
in dEQP-VK.texture.filtering_anisotropy.*
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The code didn't limit the offsets to the number supplied, so
if we expected 3 but only got 2 we were accessing undefined memory.
This fixes random failures in:
dEQP-VK.glsl.texture_functions.texelfetchoffset.sampler2darray_*
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There is an specific list of texture targets that can be used with
glGetTextureImage. From OpenGL 4.5 spec, section '8.11 Texture Queries',
page 234 of the PDF:
"An INVALID_ENUM error is generated if the effective target is
not one of TEXTURE_1D , TEXTURE_2D , TEXTURE_3D , TEXTURE_1D_-
ARRAY , TEXTURE_2D_ARRAY , TEXTURE_CUBE_MAP_ARRAY , TEXTURE_-
RECTANGLE , one of the targets from table 8.19 (for GetTexImage
and GetnTexImage only), or TEXTURE_CUBE_MAP (for GetTextureImage
only)."
We are currently not validating the target for glGetTextureImage. As
an example, calling this function on a texture with target
GL_TEXTURE_2D_MULTISAMPLE should return INVALID_ENUM, but instead it
hits an assertion down the road in the i965 driver.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
_mesa_lookup_texture_err() is not currently checking that the
texture-id can be zero, but _mesa_HashLookup() doesn't expect the key
to be zero, and will fail an assertion.
Considering that _mesa_lookup_texture_err() is called from
_mesa_GetTextureImage and _mesa_GetTextureSubImage with user provided
arguments, we must validate the texture-id before looking it up in the
hash-table.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes rendering in Dolphin on Vulkan since we enabled clip
distances. (Dolphin on GL has a similar bug because the linker
fails to eliminate unused clip distance built-in arrays, but it
isn't using SSO...so that needs more fixing.)
Also fixes a Piglit test:
spec/glsl-1.50/execution/geometry.clip-distance-vs-gs-out-sso
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Currently clears only operate on the 0th array index (ignoring surface
layout parameters). Instead normalize to take a RTAI like all the
load/store tile logic does, and use ComputeSurfaceAddress to properly
take the surface state's lod/array index into account.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
The non-fast-clear path was never updated after clear colors were passed
in as floats. Remove the now-harmful conversion from unorm8.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
When switching render target array indexes (as might happen in a GS, or
in a future change, with layered clears), if the previous state is
HOTTILE_CLEAR, we should actually clear the tile before saving it off.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Commit 6d416bcd84 (i965: Use arrays in
Gen7+ URB code.) introduced a regression which caused us to fail to
allocate all of our URB space.
- total_wants -= ds_wants;
+ total_wants -= additional;
The new line should have been total_wants -= wants[i].
Fixes a large performance regression in TessMark.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98815
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Gen6-7.5 specify the user clip distance enable bitmask in 3DSTATE_CLIP.
Gen8+ normally uses the new internal signalling mechanism to select the
one specified in the last enabled shader stage (3DSTATE_VS, DS, or GS).
This is a pretty good fit for Vulkan, or even newer GL, where the
bitmask comes entirely from the shader. But with glClipPlane(),
this is dynamic state, and we have to listen to _NEW_TRASNFORM.
Clip plane enables are the only reason the VS/DS/GS atoms need to
listen to _NEW_TRANSFORM. 3DSTATE_CLIP already has to listen to it
in order to support ARB_clip_control settings.
Setting the "Use the 3DSTATE_CLIP bitmask" force enable bit allows
us to drop _NEW_TRANSFORM from all the shader stage atoms, so we can
re-emit them less often.
Improves performance of OglBatch7 (version 6) by 2.70773% +/- 0.491257%
(n = 38) at 1024x768 on Cherryview.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This fixes:
dEQP-VK.api.copy_and_blit.blit_image.simple_tests.mirror*
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is just a cleanup before I rework this code to fix mirrored
blits.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radv_tex_wrap() already supports VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE,
so all that's needed is to advertise support for the extension.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Ported from radeonsi.
Note that si_make_texture_descriptor() already sets img7 to the mask
value referred to in the comment.
Reviewed-by: Dave Airlie <airlied@redhat.com>
We can't render to 8x MSAA if the width is greater than 64 bits. (see
brw_render_target_supported)
Fixes ES31-CTS.sample_variables.mask.rgba32f.samples_8.mask_*
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Driver should enumerate only up-to min2(num_available, num_requested)
properties and return VK_INCOMPLETE if the # of requested props is
smaller than the ones available.
Presently we assert out in such cases.
Inspired by a similar fix for RADV.
v2: Use MIN2 + typed_memcpy (Jason).
Should fix: dEQP-VK.api.info.device.extensions
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v2 (Jason):
- Use PRM citation for SKL now that it is available
- Also return false for gen < 8 mipmapped/arrayed
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
instead of in intel_miptree_init_mcs(). For lossless compression
the status is immediately overwritten in
intel_miptree_alloc_non_msrt_mcs() while the status for
non-compressed non-msaa miptrees is explicitly set in
do_blorp_clear().
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This path is not yet taken for fast cleared or compressed buffers
but later patches will enable it.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And fix a mangled comment while at it.
v2 (Ben): Return the converted color.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This was detected when examining CCS_E failures with piglit test:
"fbo-generatemipmap-formats". Test creates a 2D texture with
dimensions 293x277. It manually loops over all levels and calls
glTexImage2D(). Level one triggers creation of full miptree:
intel_alloc_texture_image_buffer() realizes that there is only one
level in the miptree and calls intel_miptree_create_for_teximage()
to re-allocate the miptree with all 9 levels. However, the end result
is a miptree with level zero dimensions of 292x276.
Related, and possibly calling for treatment of its own is mip-map
generation:
After calling glTexImage2D() against every level test continues by
replacing content for levels one to eight with data derived from level
zero by calling glGenerateMipmapEXT(). This results into the miptree
being allocated anew for every level:
Mip-map generation goes thru meta which ends up validating the texture
(brw_validate_textures()->intel_finalize_mipmap_tree()->
intel_miptree_match_image()) where one finds texture with base level
size 292:276. This results into new miptree being created for the npot
size 293:277. Only here intel_finalize_mipmap_tree() is asked for only
one level, and therefore such is created. Generation for level one in
turn finds right base level size but only one level when two is needed.
And the same goes on for all eight levels.
This patch prevents the shrink maintaining the NPOT size of 293x277.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
In get_tex_memcpy, when copying texture data directly from source
to destination (when row strides match for both src and dst), the
copy size is currently calculated using the full texture height
instead of the sub-region height parameter that was passed.
This can cause a read past the end of the mapped buffer when y-offset
is greater than zero, leading to a segfault.
Fixes CTS test (from crash to pass):
* GL45-CTS/get_texture_sub_image/functional_test
v2: (Jason) Use the passed 'height' instead of copying til the
end of the buffer (tex-height - yoffset).
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Besides the logical operation involved, these also require that we test if the
operands are ordered / unordered.
For ordered operations, both operands must be ordered (and they must pass the
conditional test) while for unordered operations it is sufficient if only one
of the operands is unordered (or they pass the logical test).
Fixes the following Vulkan CTS tests:
dEQP-VK.spirv_assembly.instruction.compute.opfunord.equal
dEQP-VK.spirv_assembly.instruction.compute.opfunord.greater
dEQP-VK.spirv_assembly.instruction.compute.opfunord.greaterequal
dEQP-VK.spirv_assembly.instruction.compute.opfunord.less
dEQP-VK.spirv_assembly.instruction.compute.opfunord.lessequal
v2: Fixed typo: s/nir_eq/nir_feq
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Since bind image memory started memsetting surfaces, the
device node can't be NULL, since we lookup device->info.has_llc.
Not sure why it ever was NULL before.
Fixes some things on my Ivybridge.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes a few things:
- sprite coords only apply to generic varyings, and are a bitmask
- back color only applies in 2-sided lighting mode
- handle some odd situations between only some front/back colors being
there. This is only semi-legal in GL, but we shouldn't start
crashing.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
We were previously not marking the "regular" flat outputs as flat when
flatshading was enabled.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
The way that dual-source blending is described for GLES2 is very odd,
and we end up with a shader that both has this property set *and* has a
color1 value to be used as the second source. While changing the state
tracker is an option, it seems more reliable to verify that the
broadcast is only done on color0.
Fixes arb_blend_func_extended-fbo-extended-blend-pattern_gles2
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
This is the same value that llvmpipe uses. Since swr uses the same
sampler logic, makes sense for this value to also be the same. Most
applications don't care.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
I was getting a weird segfault from GCC 4.9.3:
0x00007ffff54f27aa in strlen () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff54f27aa in strlen () from /lib64/libc.so.6
#1 0x00007ffff4f128e5 in get_cie_encoding (cie=cie@entry=0x7ffff6e09813)
at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:272
#2 0x00007ffff4f1318e in classify_object_over_fdes (ob=ob@entry=0xd7bb90, this_fde=0x7ffff7f11010)
at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:628
#3 0x00007ffff4f135ba in init_object (ob=0xd7bb90)
at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:749
#4 search_object (ob=ob@entry=0xd7bb90, pc=pc@entry=0x7ffff4f11f4d <_Unwind_RaiseException+61>)
at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:961
#5 0x00007ffff4f13e62 in _Unwind_Find_registered_FDE (bases=0x7fffffffd358, pc=0x7ffff4f11f4d <_Unwind_RaiseException+61>)
at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:1025
#6 _Unwind_Find_FDE (pc=0x7ffff4f11f4d <_Unwind_RaiseException+61>, bases=bases@entry=0x7fffffffd358)
at /gcc-4.9.3/libgcc/unwind-dw2-fde-dip.c:450
#7 0x00007ffff4f11197 in uw_frame_state_for (context=context@entry=0x7fffffffd2b0, fs=fs@entry=0x7fffffffd100)
at /gcc-4.9.3/libgcc/unwind-dw2.c:1245
#8 0x00007ffff4f11b15 in uw_init_context_1 (context=context@entry=0x7fffffffd2b0, outer_cfa=outer_cfa@entry=0x7fffffffd660, outer_ra=0x7ffff518d23b <__cxa_throw+91>)
at /gcc-4.9.3/libgcc/unwind-dw2.c:1566
#9 0x00007ffff4f11f4e in _Unwind_RaiseException (exc=0xd7c250)
at /gcc-4.9.3/libgcc/unwind.inc:88
#10 0x00007ffff518d23b in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#11 0x00007ffff51ed556 in std::__throw_out_of_range(char const*) ()
from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#12 0x00007fffea778be0 in std::map<pipe_format, SWR_FORMAT, std::less<pipe_format>, std::allocator<std::pair<pipe_format const, SWR_FORMAT> > >::at (
this=0x7fffebeb4c40 <mesa_to_swr_format(pipe_format)::mesa2swr>,
__k=@0x7fffffffd73c: PIPE_FORMAT_RGTC1_UNORM)
at /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/bits/stl_map.h:549
#13 0x00007fffea776aee in mesa_to_swr_format (format=PIPE_FORMAT_RGTC1_UNORM) at swr_screen.cpp:597
We can just void this whole issue by not using exceptions in the
first place.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This table exists for the purpose of determining renderable formats.
Without a StoreTile implementation, that can't happen.
This basically removes rendering support to all L/LA/I formats. They can
be re-added when/if StoreTile implementations are added.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This is a bit of a mega-commit, but unfortunately there's no great way
to break this up since a lot of different pieces have to match up. Here
we do the following:
- change surface layout to match swr's Load/StoreTile expectations
- fix sampler settings to respect all sampler view parameters
- fix stencil sampling to read from secondary resource
- respect pipe surface format, level, and layer settings
- fix resource map/unmap based on the new layout logic
- fix resource map/unmap to copy proper parts of stencil values in and
out of the matching depth texture
These fix a massive quantity of piglits, including all the
tex-miplevel-selection ones.
Note that the swr native miptree layout isn't extremely space-efficient,
and we end up using it for all textures, not just the renderable ones. A
back-of-the-envelope calculation suggests about 10%-25% increased memory
usage for miptrees, depending on the number of LODs. Single-LOD textures
should be unaffected.
There are a handful of regressions as a result of this change:
- Some textureGrad tests, these failures match llvmpipe. (There are
debug settings allowing improved gallivm sampling accurancy.)
- Some layered clearing tests as swr doesn't currently support that. It
was getting lucky before because enough other things were broken.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Fixes tgsi error introduced in commit 3817a7a. The error complains missing
swizzle component in the conversion string "UMIN TEMP[0], TEMP[0], IMM[0].x".
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
My thought in having both arguments conditionally moved was that it should
theoretically save some power by not doing work in those channels.
However, it ends up costing us instructions because we can't
register-coalesce the first of the MOVs, and it also introduces extra
scheduling dependencies. The instruction cost would swamp whatever power
benefit I was hoping for.
shader-db results:
total instructions in shared programs: 100548 -> 99741 (-0.80%)
instructions in affected programs: 42450 -> 41643 (-1.90%)
With obvious outliers removed (I had an X11 emacs running over the network
in the "after" case), 3DMMES Taiji showed 1.07231% +/- 0.488241% fps
improvement (n=18, 30).
I screwed this up in fdad4d2402 which was
supposed to be making this code more maintainable. What's amazing is
multithreaded FS showed the wins it did despite this bug.
shader-db results:
total instructions in shared programs: 103535 -> 100548 (-2.89%)
instructions in affected programs: 83794 -> 80807 (-3.56%)
Gallium core just changed to start setting MSAA enabled in the rasterizer
state even with samples==1 buffers. This caused disagreements in our
driver between binning and rasterization state, which the simulator threw
assertion failures about. Keep the single-sampled samples==1 behavior for
now.
I dropped the first hunk of this change last minute when I decided it
wasn't actually needed, and apparently failed to piglit it in simulation.
The simulator threw an an assertion in gl-1.0-drawpixels-color-index,
which queued up 5 coordinates (3 before a switch, two after) before
loading the result.
This seems like it would conform better with the spec.
noticed while digging into fast clears.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It turns out that the flushing required around resolves is a bit more
extensive than I first thought. You actually need render cache flush
and a CS stall both before *and* after the resolve.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Otherwise, some pipe flushes may just never happen. This is unlikely to
cause problems depending on how the kernel schedules batches, but we
shouldn't count on it.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
At vkCmdNextSubpass time, we have the actual framebuffer so we can use
regular blorp_clear for subpass clears. For fast clears, there is no
attachment version, so this will make fast clears a bit easier.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This commit adds the last remaining bits to support input attachments in
the Intel Vulkan driver. For color and depth attachments, we allocate an
input attachment surface state during vkCmdBeginRenderPass like we do for
the render target surface states. This is so that we can incorporate the
clear color and aux information as used in rendering. For stencil, we just
treat it like a regular texture because we don't there is no aux. Also,
only having to worry about at most one input attachment surface for each
attachment makes some of the vkCmdBeginRenderPass code simpler.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Input and resolve attachments can cause an implicit dependency in the
pipeline. It's our job to insert the needed flushes. Fortunately, we can
easily reuse the usage tracking that we use for CCS resolves.
This fixes 159 Vulkan CTS tests on Haswell because we're now flushing in
between drawing and MSAA resolves. I have no idea how they were passing
before on newer hardware.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We were using VK_IMAGE_ACCESS_COLOR_ATTACHMENT_READ_BIT to detect an input
attachment read. We should use VK_IMAGE_ACCESS_INPUT_ATTACHMENT_READ_BIT
instead.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The != VK_SUCCESS case is really only capable of handling the one error.
This assert makes things a bit safer if something else goes wrong.
Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This can happen even if the binding table isn't changed. For instance, you
could have dynamic offsets with your descriptor set. This fixes the new
stress.lots-of-surface-state.cs.dynamic cricible test.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
If we try to allocate a binding table and fail, we have to get a new
binding table block, re-emit STATE_BASE_ADDRESS, and then try again. We
already handle this correctly for 3D and blorp but it never got handled for
CS. This fixes the new stress.lots-of-surface-state.cs.static crucible test.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
The precision of our trig instructions appears to have been fixed on Kaby
Lake. Neither Ben nor I can find any documentation for this. However, the
dEQP precision tests now pass with INTEL_PRECISE_TRIG=0 where they fail on
Sky Lake.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Most of the 3-D engine Kaby Lake is identical to Sky Lake. However, there
are a few small differences that we need to be able to detect.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Since both pCreateInfo->strideInBytes and pCreateInfo->extent.height
are of uint32_t type 32-bit arithmetic will be used.
Fix unintentional integer overflow by casting to uint64_t before
multifying.
CID 1394321
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
[Emil Velikov: cast only of the arguments]
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Mention the script - why/how to use alongside a useful trick to make it
work interactively (thanks Rob!).
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Elie Tournier <tournier.elie@gmail.com>
v2: [Emil Velikov]
- Add the shorthand git send-email -vX
- Move to submittingpatches.html
- Add to the TOC.
v3: [Emil Velikov]
- Use @~8 instead of HEAD~8 (Nicolai)
Cc: Timothy Arceri <t_arceri@yahoo.com.au>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com> (v1)
Just fetch and store it once, rather than doing the
xcb_setup_roots_iterator + get_xcb_screen dance five times.
v2: Call xcb_disconnect() on error (Eric)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Identical throughout dri2, dri3 and drisw. Next patch will add more
common code, so rather than duplicating it factor out the function.
Note: this also sets eglError on failure. Something that's quite
inconsistent throughout the codebase.
v2: Call xcb_disconnect() on error (Eric)
Note: use xcb_disconnect() even in the xcb_connection_has_error() case
as per the manual:
... memory will not be freed until xcb_disconnect...
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
The old approach works fine, and this approach isn't necessarily better.
But it at least has the advantage that Vulkan and GL use the same
approach. I originally wrote it to gain additional testing for the
new paths.
shader-db statistics show 0 instruction count changes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Everything is now in place, and we appear to pass the tests on Gen7+.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
ARB_enhanced_layouts only requires component qualifier support for
generic varyings, so this is all the vec4 backend knew how to handle.
This patch extends the backend to handle it for all varyings, so we
can use store_output intrinsics with a component set for things like
clip/cull distances. We may want to use that for other VUE header
fields in the future as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
v2: Use nir_is_per_vertex_io() rather than is_arrays_of_arrays().
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Certain built-in arrays, such as gl_ClipDistance[], gl_CullDistance[],
gl_TessLevelInner[], and gl_TessLevelOuter[] are specified as scalar
arrays. Normal scalar arrays are sparse - each array element usually
occupies a whole vec4 slot. However, most hardware assumes these
built-in arrays are tightly packed.
The new var->data.compact flag indicates that a scalar array should
be tightly packed, so a float[4] array would take up a single vec4
slot, and a float[8] array would take up two slots.
They are still arrays, not vec4s, however. nir_lower_io will generate
intrinsics using ARB_enhanced_layouts style component qualifiers.
v2: Add nir_validate code to enforce type restrictions.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I've started working on a shader-db alike for Vulkan,
it's based on vktrace and it records pipelines, this
adds support to dump the shader stats exactly like
radeonsi does, so I can reuse the shader-db scripts it
uses.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The sample id is packed into bits 8-12, so adjust
things properly.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes a bunch of crashes in CTS tests looking for this.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This cleans up the ddxy emission along the same lines as
radeonsi. It also means we don't use LDS on VI chips we
use the dspermute interface, it also removes some duplicated
code.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For the hw resolve there is no need to emit any sort
of texture coordinates, so drop them all in the meta path.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We want to also invalidate the cache when LLVM gets changed. As the
specific LLVM revision is not fixed at build time, we will need to
check at runtime. Computing a checksum for LLVM is going to be very
expensive, so just use the mtime.
Tested on my computer that the returned DSO for the LLVM symbol is
actually the LLVM DSO.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
No sense in repeatedly determining it. Also, it might be dependent
on the device as shaders get compiled differently for SI/CIK/VI etc.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
The former calculations were for min/max y. The width/height don't take
translate into account.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
This may ultimately be possible to support, but for now it's not hooked
up and the swr core only supports this output from GS.
This normally wouldn't matter, but we lie about supporting GL 3.2, and
also the blitter and st/mesa will make use of this functionality if
claimed.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Multiple buffers may reference client arrays. When this happens, we
might reach for scratch space multiple times, which could cause later
arrays to invalidate the pointers allocated for the earlier ones.
This fixes copyteximage 2D_ARRAY.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Currently a sequence like draw/map/draw/map will cause the second map to
not wait for the second draw. This is because the first map will clear
the resource business bit, and the second draw won't reset it since no
state has changed.
swr_update_derived does a tiny bit of extra work, including updating the
SWR_BACKEND_STATE as well as waiting for prending fences. If that's a
problem, we could call swr_update_resource_status directly from
draw/clear handlers.
Fixes clearbuffer-stencil, clearbuffer-depth, clearbuffer-depth-stencil,
and clearbuffer-display-lists.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
The minification should happen before alignment, not after. See similar
logic on ComputeLODOffsetY. The current logic requires unnecessarily
large textures when there's an initial NPOT size.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
There's no guarantee that mip width/height will be a multiple of the
compressed block size. Doing a divide by the block size first yields
different results than GL expects, so we do the divide at the end.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
A past commit added the ability to compile "optimized" shader variants
asynchronously (not stalling the app).
This commit builds upon that and adds what is basically a runtime shader
linker. If a VS output isn't used by the currently-bound PS, a new VS
compilation is started without that output. The new shader variant
is used when it's ready.
All apps using separate shader objects I've seen had unused VS outputs.
Eliminating unused/useless VS outputs also eliminates the corresponding
vertex attribute loads.
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This is the first user of optimized monolithic shader variants.
Cull distances can't be disabled by states.
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
key->part.*: prolog and epilog flags only
key->as_{ls,es}: special flags
key->mono.*: flags for monolithic compilation only
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
When the uploading of shader fails on si_shader_binary_upload(),
it returns -ENOMEM. We should handle si_shader_binary_upload() failure path
on si_create_compute_state().
CID 1394027
v2: Fixes from Edward O'Callaghan's review
a) Update explicitly return value check with "si_shader_binary_upload() < 0"
b) Update commit message.
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
It turns out that noone actually cares if the address computations overflow,
be it the stride mul or the offset adds.
Wrap around seems to be explicitly permitted even by some other API (which
is a _very_ surprising result, as these overflow computations were added just
for that and made some tests pass at that time - I suspect some later fixes
fixed the actual root cause...). So the requirements in that other api were
actually sane there all along after all...
Still need to make sure the computed buffer size needed is valid, of course.
This ditches the shiny new widening mul from these codepaths, ah well...
And now that I really understand this, change the fishy min limiting
indices to what it really should have done. Which is simply to prevent
fetching more values than valid for the last loop iteration. (This makes
the code path in the loop minimally more complex for the non-indexed case
as we have to skip the optimization combining two adds. I think it should
be safe to skip this actually there, but I don't care much about this
especially since skipping that optimization actually makes the code easier
to read elsewhere.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Don't keep the ofbit. This is just a minor simplification, just adjust
the buffer size so that there will always be an overflow if buffers aren't
valid to fetch from.
Also, get rid of control flow from the instanced path too. Not worried about
performance, but it's simpler and keeps the code more similar to ordinary
fetch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The code for elts and linear paths was nearly 100% identical by now - with
the elts path simply having some additional gather for the elements in the
main loop (with some additional small differences before the main loop).
Hence nuke the separate functions and decide this at jit shader execution
time (simply based on the presence of the elts pointer).
Some analysis shows that the generated vs jit functions seem to be just very
minimally more complex than the former elts functions, and almost none of the
additional complexity is in the main loop (basically just the branch logic
for the branch fetching the actual indices).
Compared to linear, the codesize of the function is of course a bit larger,
however the actual executed code in the main loop appears to be near 100%
identical (the additional code looking up indices is skipped as expected).
So, I would not expect a (meaningful) performance difference with the
generated code, neither with elts nor linear, this does however roughly
half the compilation time (the compiled shaders should also use only half
the memory of course).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This was kind of strange, since it replaced indices which were only
overflowing due to bias with MAX_UINT. This would cause an overflow later
in the shader, except if stride was 0, however the vertex id would be
essentially random then (-1 + eltBias). No test cared about it, though.
So, drop this and just use ordinary int arithmetic wraparound as usual.
This is much simpler to understand and the results are "more correct" or
at least more consistent (vertex id as well as actual fetch results just
correspond to wrapped around arithmetic).
There's only one catch, it is now possible to hit the cache initialization
value also with ushort and ubyte elts path (this wouldn't be an issue if
we'd simply handle the eltBias itself later in the shader). Hence, we need
to make sure the cache logic doesn't think this element has already been
emitted when it has not (I believe some seriously bad things could happen
otherwise). So, borrow the logic which handled this from the uint case, but
not before fixing it up...
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
vsplit_get_base_idx explicitly returned idx 0 and set the ofbit
in case of overflow. We'd then check the ofbit and use idx 0 instead of
looking it up. This was necessary because DRAW_GET_IDX used to return
DRAW_MAX_FETCH_IDX and not 0 in case of overflows.
However, this is all unnecessary, we can just let DRAW_GET_IDX return 0
in case of overflow. In fact before bbd1e60198
the code already did that, not sure why this particular bit was changed
(might have been one half of an attempt to get these indices to actual draw
shader execution - in fact I think this would make things less awkward, it
would require moving the eltBias handling to the shader as well).
Note there's other callers of DRAW_GET_IDX - those code paths however
explicitly do not handle index buffer overflows, therefore the overflow
value doesn't matter for them.
Also do some trivial simplification - for (unsigned) a + b, checking res < a
is sufficient for overflow detection, we don't need to check for res < b too
(similar for signed).
And an index buffer overflow check looked bogus - eltMax is the number of
elements in the index buffer, not the maximum element which can be fetched.
(Drop the start check against the idx buffer though, this is already covered
by end check and end < start).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
v4: Add windows-specific gen_knobs.{cpp|h} changes
v5: remove aggresive squashing of gen_knobs.py to this commit; added
SConscript to EXTRA_DIST in Makefile.am
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Modify gen_knobs.py so that each invocation creates a single generated
file. This is more similar to how the other generators behave.
v5: remove Scoscript edits from this commit; moved to commit that first
adds SConscript
Acked-by: Emil Velikov <emil.velikov@collabora.com>
To buils The SWR driver (currently optional, not compiled by default)
v3: add option as opposed to target
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
- Handle dynamic library loading for windows
- Implement swap for gdi
- fix prototypes
- update include paths on configure-based build for swr_loader.cpp
v2: split to multiple patches
v3: split and reshuffle some more; renamed title
v4: move Makefile.am changes to other commit. Modify header files
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
There are 2 swr_create_screen() functions. One in swr_loader.cpp, which
is used during driver init, and the other is hiding in swr_screen.cpp,
which ends up in the arch-specific .dll/.so.
Rename the second one to swr_create_screen_internal(), to avoid confusion
in header files.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reorder header files so that we have a chance to defined NOMINMAX before
mesa include files include windows.h
v3: split from bigger patch
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Added hooks for screen creation and swap. Still keep llvmpipe the default
software renderer.
v2: split from bigger patch
v3: reword commit message
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Drivers that contain C++ .hpp files need to ignore them too, along
with .h files, when building source file lists.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Still far from perfect, but a few small steps in the right direction.
- Split build systems, compilers, third party tools
- Mention building mesa for Android (part of AOSP)
- Drop explicit "other" dependencies. Reference to disto methods to
get them.
- HTML 4.01 Traditional compliance fixes - mixed ul and br tags.
- nuke dead links README.{CYGWIN,VMS}
v2: Squash typos, add note about buggy flex 2.6.2 (Eric), add Suse
zipper command (Tobias).
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
A mixed bag of updates/fixes - mostly aiming at removing no longer
applicable directories.
Add a few more state-trackers, drivers, etc. alongside "XXX more" where
applicable. Attribute for the GLSL/NIR movement and nukage of
src/egl/docs.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Properly document the whole process:
- Brief on what, when, where
- Picking, testing, branchpoints, pre-release announcement
- Releasing, announcement, website and bugzilla updates
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Currently they are buried within the text, making it hard to find.
Move them to the top and be clear what is _not_ a good idea.
v2: Minor commit polish, use only "resending" as suggested by Matt.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
With earlier commit we folded all the xlib handling in --enable-glx, but
we forgot to update the documentation.
Elaborate on --enable-debug and drop mentions about depenencies.
v2: Grammar - s|haven't|hasn't| (Eric)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
... and point people to use/honour the EditorConfig/Emacs files, where
applicable.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
As seen a couple of lines above - there's no way for the assert to
trigger.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is an interface that can be used to query YUV buffers for their
internal format. Specifically, if gralloc:lock_ycbcr() is given no SW
usage flags, it's supposed to return plane offsets instead of pointers.
Let's use this interface to implement support for YUV formats in Android
EGL backend.
v2: Fixes from Emil's review:
a) Added comments for parts that might be not clear,
b) Changed get_fourcc_yuv() to return -1 on failure,
c) Changed is_yuv() to use bool.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Currently droid_open_device() gets a reference to the gralloc module
only for its own use and does not store it anywhere. To make it possible
to call gralloc methods from code added in further patches, let's
refactor current code to get gralloc module in dri2_initialize_android()
and store it in dri2_dpy.
v2: fixes from Emil's review:
a) remove duplicate initialization of 'err'.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
It is currently completely broken, as it ends up using RGBX_8888 on
hardware side, due to no way of distinguishing between these two in the
DRI API, while HAL_PIXEL_FORMAT_RGB_888 is clearly defined to be the
3-byte per pixel RGB format.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Consider a geometry shader that contains code like this:
some_out = expr;
if (cond) {
...
EmitVertex();
} else {
...
EmitVertex();
}
Both branches should see the correct value of some_out.
Since this is a rather subtle and rare case, I'm submitting a piglit test
for this as well.
GLSL says that the values of output variables are undefined after
EmitVertex(). With this change, the values will now be defined and
unmodified. This may reduce optimization opportunities in the probably
quite rare case where subsequent compiler passes cannot prove that the
value of the output variable is overwritten.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For compute shaders, we free the selector after the shader has been
compiled, so we need to save this bit somewhere else. Also, make sure that
this type of bug cannot re-appear, by NULL-ing the selector pointer after
we're done with it.
This bug has been there since the feature was added, but was only exposed
in piglit arb_compute_variable_group_size-local-size by commit
9bfee7047b (which is totally unrelated).
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This fixes the regression of radeonsi in
glsl-1.10/execution/variable-indexing/vs-output-array-vec3-index-wr
caused by commit 74e39de932.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch improves pass rate of dEQP-VK.texture.explicit_lod.2d.sizes.*
from 68.0% (98/144) to 83.3% (120/144) by enabling sampler address
rounding mode when the selected filter is not nearest, which is the same
thing we do for OpenGL.
These tests check texture filtering for various texture sizes and mipmap
levels. The failures (without this patch) affect cases where the target
texture has odd dimensions (like 57x35) and either the Min or the Mag filter
is not nearest.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This fixes the image view for sampling just the depth.
It removes some pointless swizzle code, and adds
a missing case for the x8_d24 format.
Fixes:
dEQP-VK.renderpass.formats.d32_sfloat_s8_uint.input.*
dEQP-VK.renderpass.formats.d24_unorm_s8_uint.input.*
dEQP-VK.renderpass.formats.x8_d24_unorm_pack32.input.*
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This isn't useful for legacy GL, but will be used in Vulkan.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This also allows us to move it from a GL specific location to a
part of the compiler shared by both GL and Vulkan.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We switched from a boolean to array lengths in gl_program a while back.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We weren't taking first_component into account when handling GS push
inputs. We hardly ever push GS inputs, so this was not caught by
existing tests. When I started using component qualifiers for the
gl_ClipDistance arrays, glsl-1.50-transform-feedback-type-and-size
started catching this.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This code is far too complicated to cut and paste.
v2: Update the newly added genX_gpu_memcpy.c; const a few things.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
So much of this code was cut and pasted per stage. We can accomplish
much of it by looping over shader stages.
Improves performance of OglBatch7 (version 6) by 1.50783% +/- 0.287049%
(n = 71) at 1024x768 on Cherryview.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The context fields are for Gen4-5; setting them has always been useless.
There's no point in spending the cost in the hottest path in the driver.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Matt intentionally switched the VS calculation to be float-based in
commit c1da15709a. Tessellation support
was written before this and rebased forward, and missed the change.
Now it's consistent.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
If geometry/tessellation shaders are disabled, prog_data will be NULL
(see brw_state_upload.c). This consolidates dirty bits a little.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This will be used to share data between gl_program and gl_shader_program
allowing for greater code simplification as we can remove a number of
awkward uses of gl_shader_program.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This fixes a regression with the standalone compiler caused by
9d96d3803a
Note that we change standalone_compiler_cleanup() to no longer
explicitly free the linked shaders as the will be freed when
we free the parent ctx whole_program.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98774
There's no point in performing depth writes when the depth test
comparison function is set to GL_EQUAL - it would just write out
the same value that's already there (if it is written at all). While
this is harmless from a functional perspective, it hurts performance.
Obviously, writing to memory is not free, but there's another more
subtle impact as well: it can prevent early depth optimizations.
Depth writes aren't supposed to happen for pixels that are killed
by fragment shader discard statements or the alpha test. So, with
depth writes enabled and either of those, the pixel shader must be
invoked to determine whether or not to perform the write. This is
fairly stupid in the EQUAL case - we're running a shader to decide
whether to replace the existing depth value with itself.
By disabling these pointless writes, we allow early depth even with
discards and alpha testing, allowing the hardware to skip the pixel
shader altogether if the depth test fails.
Improves performance of Unigine Valley:
- Skylake GT2: +17.8%
- Broadwell GT3e: +11.5%
- Cherrytrail: +19.4%
Huge thanks to Mark Janes for building frameretrace [1], the performance
analysis tool that helped us find this issue, and to Robert Bragg for
providing us performance metrics on Linux. Mark also spent the time to
analyze Valley performance on Windows vs. Linux and discovered a
discrepancy in early depth test metrics. Once he had isolated a draw
call and drawn attention to the problem, fixing it was pretty simple.
[1] https://github.com/janesma/apitrace/wiki/frameretrace-branch
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Here we just move initialisation of entries to where it is needed i.e.
outside the loop and after the continue checks.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This will allow us to directly store metadata we want to retain in
gl_program this metadata is currently stored in gl_linked_shader and
will be lost if relinking fails even though the program will remain
in use and is still valid according to the spec.
"If a program object that is active for any shader stage is re-linked
unsuccessfully, the link status will be set to FALSE, but any existing
executables and associated state will remain part of the current
rendering state until a subsequent call to UseProgram,
UseProgramStages, or BindProgramPipeline removes them from use."
This change will also help avoid the double handing that happens in
_mesa_copy_linked_program_data().
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In i965 we were calling _mesa_reference_program() after creating
gl_program and then later calling it again with NULL as a param
to get the refcount back down to 1. This changes things to not
use _mesa_reference_program() at all and just have gl_linked_shader
take ownership of gl_program since refcount starts at 1.
The st and ir_to_mesa linkers were worse as they were both getting
in a state were the refcount would never get to 0 and we would leak
the program.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The HZ sequence modifies less state than the blorp path and requires
less CPU time to generate the necessary packets.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This behavior differs from what's described in the PRMs and was
observed by analyzing CTS test results.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Framebuffer attachments can be specified through FramebufferTexture*
calls. Upon specifying a depth (or stencil) framebuffer attachment that
internally reuses a texture, the cube map face of the new attachment
would not be updated (defaulting to TEXTURE_CUBE_MAP_POSITIVE_X).
Fix this issue by actually updating the CubeMapFace field.
This bug manifested itself in BindFramebuffer calls performed on
framebuffers whose stencil attachments internally reused a depth
texture. When binding a framebuffer, we walk through the framebuffer's
attachments and update each one's corresponding gl_renderbuffer. Since
the framebuffer's depth and stencil attachments may share a
gl_renderbuffer and the walk visits the stencil attachment after
the depth attachment, the uninitialized CubeMapFace forced rendering
to TEXTURE_CUBE_MAP_POSITIVE_X.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77662
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This extension can be enabled automatically as it is a subset of
ARB_shader_image_load_store.
v2: Replace helper function by qualifier struct field (Ilia)
Enable NV_image_formats using ARB_shader_image_load_store (Ilia)
v3: Drop extension field from gl_extensions (Ilia)
Release notes (Ilia)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98480
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Since the state tracker now enables MSAA in the hardware for the case
nr_samples == 1 as well, we need to set sample locations correctly for
this case.
The Polaris override is still needed for the non-MSAA case (when
nr_samples == 0).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
There are some differences between how non-multisampled framebuffers (i.e.
samples == 0) and multisampled framebuffers with a single sample should be
treated. For example, alpha to coverage and writing to gl_SampleMask has an
effect with single-sample multisample framebuffers, but not on
non-multisample framebuffers.
This fixes GL45-CTS.sample_variables.mask.*.samples_1.* at least for
Gallium drivers (and possibly others, though at least radeonsi needs an
additional fix).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
In case we have empty log (""), we should return 0. This fixes
Khronos WebGL conformance test 'program-infolog'.
From OpenGL ES 3.1 (and OpenGL 4.5 Core) spec:
"If pname is INFO_LOG_LENGTH , the length of the info log, including
a null terminator, is returned. If there is no info log, zero is
returned."
v2: apply same fix for get_shaderiv and _mesa_GetProgramPipelineiv (Ian)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> (v1)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97321
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
lp_build_any_true_range is just what we need, though it will only produce
optimal code with sse41 (ptest + set) - but even without it on 64bit x86
the code is still better (1 unpack, 2 movq + or + set), on 32bit x86 it's
going to be roughly the same as before.
While here also make it a "real" 8bit boolean - cuts one instruction but
more importantly similar to ordinary booleans.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Instead of doing all the math with scalars, use vectors. This means the
overflow math needs to be done manually, albeit that's only really
problematic for the stride/index mul, the rest has been pretty much
moved outside the shader loop (albeit the mul could actually be optimized
away too), where things are still scalar.
To eliminate control flow in the main shader loop fetch, provide fake
buffers (so index 0 is always valid to fetch).
Still uses aos fetch though in the end - mostly because some more code
would be needed to handle unaligned fetches in that path, and because for
most formats it won't make a difference anyway (we generate some truly
horrendous code for things like R16G16_something for instance).
Instanced fetch however stays roughly the same as before, except that
no longer the same element is fetched multiple times (I've seen a reduction
of ~3 times in main shader loop size due to llvm not recognizing it's all
the same fetch, since it would have been possible some of the fetches
getting replaced with zeros in case vector size exceeds remaining fetch
count - the values of such fetches don't matter at all though).
Also, for elts gathering, use vectorized code as well.
The generated shaders are smaller and faster to compile (not entirely sure
about execution speed, but generally unless there's just single vertices
to handle I would expect it to be faster - there's more opportunities
for future improvements by using soa fetch).
v3: skip the fake index buffer, not needed due to the jit code never seeing
the real index buffer in the first place.
Fix a bug with mask expansion (needs SExt, not ZExt).
Also, be really really careful to keep the behavior the same, even in cases
where it looks wrong, and add comments why the code is doing the seemingly
wrong stuff... Fortunately it's not actually more complex in the end...
Also change function order slightly just to make the diff more readable.
No piglit change. Passes some internal testing with another api too...
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Found by the piglit 'fbo-depth-array stencil-clear' test when
implementing blorp blit splitting for gen7.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
GNU/Hurd does not define PATH_MAX since it doesn't have such arbitrary
limitation, so this failed to compile. Apparently glibc does not
enforce PATH_MAX restrictions anyway, so it's kind of a hoax:
https://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html
MSVC uses a different name (_MAX_PATH) as well, which is annoying.
We don't really need it. We can simply asprintf() the filenames.
If the filename exceeds an OS path limit, presumably fopen() will
fail, and we already check that. (We actually use ralloc_asprintf
because Mesa provides that everywhere, and it doesn't look like we've
provided an implementation of GNU's asprintf() for all platforms.)
Fixes the build on GNU/Hurd.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98632
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This commit extends our support of color compression to surfaces without
the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT set. These images will never have
an image view created with a different format then the one set at image
creation time so it's safe to always use compression. We still bail if the
image is used as a storage image because that sometimes ends up using a
different format.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Previously, blorp copy operations were CCS-unaware so you had to perform
resolves on the source and destination before performing the copy. This
commit makes blorp_copy capable of handling CCS-compressed images without
any resolves.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Many of these UINT formats aren't available prior to Sky Lake so we used
UNORM formats. Using UINT formats is a bit nicer because it guarantees we
don't run into rounding issues. Also, we will need it in the next commit
for handling copies with CCS enabled.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This commit moves the handling of resolves into blorp_surf_for_miptree().
Instead of each helper doing resolves and checks itself, it simply tells
blorp_surf_for_miptree which aux modes are supported by the given blorp
operation and blorp_surf_for_miptree will resolve as-needed.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Initially, the field is set to ISL_AUX_USAGE_NONE so this commit shouldn't
bring any functional changes. Setting this field to something else will
cause all sampled and storage image views to be created with AUX and blorp
will start trying to respect it so set with care.
This commit adds basic support for color compression. For the moment,
color compression is only enabled within a render pass and a full resolve
is done before the render pass finishes. All texturing operations still
happen with CCS disabled.
Otherwise, we'll try to clear it the first time it's used as a draw so if
you do some multisampled rendering, resolve to an attachment, and then draw
on top of the single-sampled attachment, we might accidentally clear it.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Eventually, we may want to just have a single blorp_ccs_op function that
does both clears and resolves. For now we'll stick to just making the
ccs_resolve function we have now a bit more configurable.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The CCS calculations in ISL are already correct for 1-D and 3-D CCS
surfaces since they have exactly the same layout as 2-D array surfaces (at
least on Sky Lake). The only problem was that we weren't passing in the
right dimensionality and we weren't passing in the depth.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
There are some invariants such as number of samples on which we should
assert. However, most other things should silently return false since
they're much easier for isl_surf_get_ccs to check than the caller. We also
update the checking to be a bit more complete.
Auxiliary surfaces have to be created manually anyway so force-disabling it
does nothing whatsoever at the moment.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
cd724208d3 added a call to
_mesa_lock_debug_state(ctx) but wasn't unlocking the debug state.
This fixes a hang in glsl-fs-loop piglit test with MESA_DEBUG=context.
v2:
- Remove unrelated changes.
Reviewed-by: Brian Paul <brianp@vmware.com>
I introduced this code last month, but didn't follow the naming
convention. Fix this.
Fixes: 0a606a400f ("egl: add eglSwapBuffersWithDamageKHR")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Before, we were always treating it as an output which bogus. The only
stage in which this it can be an output is the geometry stage. In all
other stages, it's an input which, in the back-end, we actually want to be
a system value.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This fixes a bunch of new CTS tests which look for exactly this. Even in
the cases where we just call vk_free to free a CPU data structure, we still
handle NULL explicitly. This way we're less likely to forget to handle
NULL later should we actually do something less trivial.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Multithreaded fragment shaders let us hide texturing latency by a
hyperthreading-style switch to another fragment shader. This gets us up
to 20% framerate improvements on glmark2 tests.
It's common for games to compile 2000 programs or more so at
32bits x 2000 programs x 22 fields x 2 (at least) stages
This should give us something like 352 kilobytes in savings
once we add some more glsl only fields.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This will allow us to move the ARB asm fields in gl_program into
a union as we will be able call ralloc_free() on the entire struct
when destroying the context.
In this change we switch over to using ralloc for the Instructions,
String and LocalParams fields of gl_program.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We should be able to free gl_linked_shader after linking in order to
do so we need to switch to getting values from gl_program instead.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We should be able to free gl_linked_shader after linking in order to
do so we need to switch to getting values from gl_program instead.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Since we started releasing GLSL IR after linking the only time we can
print GLSL IR is during linking. When regenerating variants only NIR
will be available.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
When Kristian reworked descriptor set allocation, somehow he forgot to
actually store the offset in the free list. Somehow, this completely
missed CTS testing until now... This fixes all 2744 of the new
'dEQP-VK.texture.filtering.* tests in the latest CTS.
Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This partially reverts commit 0d241085f7.
HiZ buffer cannot do this properly now, and it's not required, so remove
it.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When 1 BO is used for aux data, it needs to point to the correct offset,
which will not be the BOs offset but instead an offset from the BOs
offset. Since today there are always multiple BOs for aux, this doesn't
actually change anything.
Cc: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
From the Vulkan 1.0.29 spec for vkCmdClearAttachments:
"If the subpass’s depth/stencil attachment is VK_ATTACHMENT_UNUSED,
then the clear has no effect."
and
"If colorAttachment is VK_ATTACHMENT_UNUSED then the clear has no
effect."
I have no idea why it's spec'd this way; it seems very anti-Vulkan to me,
but that's what it says and it's really not much work to support.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Nothing that is allowed to be called within a secondary now relies on the
framebuffer.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
This allows us to re-use the surface states emitted from the Vulkan driver
instead of blorp creating its own.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
When a pre-baked binding table is requested, no binding table is created,
instead the binding table offset (relative to surface state base address)
provided by the user is used verbatim.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We're about to start passing other things in as a sort of "VS header" for
vertex shaders and we need a place to put them. Since we want the instance
id to be one of them, it makes sense to have one vec4 that's either VUE
header or VS header. Always uploading some handy zeros makes the code a
bit simpler.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Some things may not be floats and intel CPUs are known for mangling bits
when a float type is used for copying integers.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
By using offsetof() we can ensure that adding fiels to wm_inputs is always
safe as long as we maintain alignment.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Depending on how the driver using blorp implements its shader caching,
there is a small chance of shader collisions due to identical keys between
blit and clear programs. Adding a small shader type at the top of the key
alleviates this problem.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Previously, we always inferred it from params->dst which meant that
references to params->dst were scattered all throughout the state upload
code.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This commit moves the allocation and filling out of surface state from
CreateImageView time to BeginRenderPass time. Instead of allocating the
render target surface state as part of the image view, we allocate it in
the command buffer state at the same time that we set up clears. For
secondary command buffers, we allocate memory for the surface states in
BeginCommandBuffer but don't fill them out; instead, we use our new
SOL-based memcpy function to copy the surface states from the primary
command buffer. This allows us to handle secondary command buffers without
the user specifying the framebuffer ahead-of-time.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This method of doing copies has the advantage of touching very little of
the GPU state. While it does disable all the shader stages, it doesn't
have to blow away binding tables, viewports, scissors, or any other bits of
dynamic state other than VBO 32 which is already reserved. All of the
state that it does touch is contained within a pipeline anyway so that's
the only thing that has to be dirtied.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
There are a few dynamic bits, namely binding table and sampler addresses,
but most of it is static and really belongs in the pipeline. It certainly
doesn't belong in flush_compute_descriptor_set. We'll use the same state
merging trick we use for gen7 DEPTH_STENCIL.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This commit makes both gen7 and gen8 pipeline setup emit state packets
in exactly the same order.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
With this commit, a few fields are now specified on gen7 which weren't
before. However, the values specified are zero which is the default so the
final hardware packet remains the same.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
From the Vulkan spec version 1.0.32 docs for vkCreateGraphicsPipelines:
The stage member of one element of pStages must be
VK_SHADER_STAGE_VERTEX_BIT
Since a vertex shader is always required, this hasn't been used since we
deleted meta. Let's get rid of the complexity.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Now that we have anv_shader_bin, they're completely redundant with other
information we have in the pipeline. For vertex shaders, we also go
through way too much work to put the offset in one or the other field and
then look at which one we put it in later.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
A number of drivers report useful debug/perf information accessible
through GL_ARB_debug_output and with debug contexts (i.e. setting the
GLX_CONTEXT_DEBUG_BIT_ARB flag). But few applications actually use
the GL_ARB_debug_output extension.
This change lets one set the MESA_DEBUG env var to "context" to force-set
a debug context and report debug/perf messages to stderr (or whatever
file MESA_LOG_FILE is set to). This is a useful debugging tool.
The small change in st_api_create_context() is needed so that
st_update_debug_callback() gets called to hook up the driver debug
callbacks when ST_CONTEXT_FLAG_DEBUG was not set, but MESA_DEBUG=context.
v2: use %.*s format string instead of allocating temporary buffer.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
I'm also sending out a piglit test, gl-2.0/vertexattribpointer-size-3,
which exposes this corner case.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Fixes parts of GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
By using _mesa_image_address, the code becomes simpler _and_ fixes the bug
that GL_PACK_SKIP_IMAGES was applied even on non-3D textures.
Also, converting a whole slice at a time simplifies the format translation
fallback path.
Fixes parts of GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore.
v2: fix a silly mistake during code movement
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
This fixes use cases like glReadPixels from an RGBA8I framebuffer into
a PBO with type GL_INT by clamping values appropriately when they fall
outside the range of the destination format.
Fixes parts of GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pbo.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
When using the GPU download path, we bind the PBO as a buffer texture,
so call is_format_supported accordingly. On radeonsi, this means that
GPU downloads aren't used for UNSIGNED_SHORT_5_6_5 destinations, for
example.
Fixes parts of GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pbo.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Even though glBlitFramebuffer cannot be used for SINT <-> UINT blits, we
still need to handle this type of blit here because it can happen as part
of texture uploads / downloads, e.g. uploading a GL_RGBA8I texture from
GL_UNSIGNED_INT data.
Fixes parts of GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
If the mcs buffer allocation fails we might get a NULL pointer. This
was reported by Coverity and should only happen if we run out of
memory.
v2: return failure at the point of allocation (Chris)
CID: 1394290
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Android path didn't support pbuffer, so add pbuffer support to fix
most failing dEQP and CTS pbuffer test cases.
Patch adds a single buffer config to support pbuffer, and creates
image in getBuffers for pbuffer when surface type is front surface.
The EGL 1.5 spec states that pbuffers have a back buffer but no front
buffer, single-buffered surfaces with no front buffer confuse Mesa;
so we deviate from the spec, following the precedent of Mesa's EGL
X11 platform.
V3: update commit message and code review changes.
Signed-off-by: Liu Zhiquan <zhiquan.liu@intel.com>
Signed-off-by: Kalyan Kondapally <kalyan.kondapally@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
There is no functionality in swr to clamp either vertex or frag colors.
This could be added in swr_shader, at which point these could be
re-enabled.
Fixes arb_color_buffer_float-render
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Rendering could still be ongoing (or have yet to start) when the shader
is deleted. There's no refcounting on the shader text, so insert a
pipeline stall unconditionally when this happens.
[Note, we should instead introduce a way to attach work to
fences, so that the freeing can be done in the current fence.]
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
The EXT_texture_integer test says that blending and alphatest should
all be disabled. st/mesa takes care of alphatest already.
Fixes the ext_texture_integer-fbo-blending piglit test.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
The support in swr requires shaders to output the components as UINTs.
This is not how GL or Gallium work, and since this is not a
required-renderable format, just leave it out.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Fixes the texsubimage piglit and lets the copyteximage one get further.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
In a BGR10X2 or BGR5X1 situation, there's no need to try to quantize the
X channel - the default will have the proper quantization required.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This is the format used for the primary surface of a
PIPE_FORMAT_Z32_FLOAT_S8X24_UINT resource.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This fixes a number of CTS tests like:
dEQP-VK.glsl.texture_gather.basic.2d.rgba8ui.size_npot.clamp_to_edge_repeat
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Autotools goes smart on us warning that foo_SOURCES variable is present
yet a target with name foo is missing. Rename things (like we do
throughout the build) to silence the warnings.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This pulls amd/common build rules into upper level makefile,
along with amd/addlib which is already there.
v2: [Emil Velikov]
- Move NEED_RADEON_LLVM conditional, drop amd/common from SUBDIRS
- Drop AM_ from common_libamd_common_la*
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
It's not dependent on GLSL and it can be useful for shader caches that don't
deal with GLSL.
v2: address review comments
v3: keep the other 3 lines in configure.ac
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Changes since v1:
- removed not needed includes
- use the loader version of the helper
v2 [Emil Velikov]
- Keep the includes - they are required.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This makes it possible to 'use' the imx-drm driver. Remeber that it
is not possible to have sysmbol names in C/C++ with a '-' in it.
Changes since v1:
- move the fix to loader.c
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Changes since v1:
- renamed function to loader_get_extensions_name
- moved function into loader
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
V2: [Emil Velikov]
- Use local define.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
It's possible to build Mesa for Android using the traditional
autotools workflow [1]. ChromiumOS fetches Android prebuilts and
puts them in a sysroot. We now want to use pkg-config to specify
the location of system headers and libraries [2].
To enable this, let's add the required pkg-config checks and link
against them.
[1] https://developer.android.com/ndk/guides/standalone_toolchain.html
[2] https://chromium-review.googlesource.com/#/c/403237/
v2: Bundle pkg-config checks together (Emil)
v3: Provide further context on standalone NDK Mesa build (Emil)
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In Android, the pthreads libs are in bionic. When building
Mesa for Android with the autotools workflow, we shouldn't
set -lpthread or -pthread.
[Emil Velikov]
Other platforms could use a similar fix, although that is left as
separate exercise.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This option was being ignored when packing compressed 3D and cube textures.
Fixes CTS test (on gen8+):
* GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
v2: Drop API checks.
v3 (Ken): Just apply the existing code in more cases.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
OpenGL ES 3.2 says in section 8.10. "TEXTURE PARAMETERS", at the end of
the section:
"An INVALID_ENUM error is generated if target is TEXTURE_2D_-
MULTISAMPLE or TEXTURE_2D_MULTISAMPLE_ARRAY , and pname is any
sampler state from table 21.12."
GL_TEXTURE_BORDER_COLOR is present in that table.
v2:
- Add check to _mesa_texture_parameteriv() (Kenneth)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98250
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
A commit from the CTS suite on the 1.0-dev branch started using
VK_REMAINING_MIP_LEVELS, we're not dealing with it properly for clears.
Fixes:
dEQP-VK.api.image_clearing.clear_color_image.*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Trailing white spaces will be now always highlighted, not just in
prog-mode.
Also, the White Space package, which is available since GNU Emacs 22,
is loaded and activated locally in prog-mode.
Additionally, using White Space variables, we set highlighting through
faces on wrong indentation and the maximum length of a coding line.
Notice that:
- The highlighting for the characters beyond the set length of a
coding line is not activated by default, only for wrong
indentations.
- If the White Space package is not available, errors on loading or
activation are ignored.
- If the White Space mode is not activated the set variables would
not have any effect.
v2: Removed too long lines trail highlighting, as suggested by Ilia
Mirkin.
Signed-off-by: Andres Gomez <agomez@igalia.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
According to the spec for vkGetPhysicalDeviceImageFormatProperties:
"If format is not a supported image format, or if the combination of format,
type, tiling, usage, and flags is not supported for images, then
vkGetPhysicalDeviceImageFormatProperties returns VK_ERROR_FORMAT_NOT_SUPPORTED."
Makes the following Vulkan CTS tests report 'Not Supported' instead of crashing:
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_unorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_snorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_uscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_sscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_uint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_sint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_unorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_snorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_uscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_sscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_uint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_sint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r4g4_unorm_pack8
dEQP-VK.api.image_clearing.clear_color_image.1d_r8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r8g8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r8g8b8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_b5g5r5a1_unorm_pack16
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Move to pass by value since most events are very small in size.
We can look at pass by reference but will need to create multiple
versions to handle temp objects.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Added events for tracking early/late Depth and stencil events,
TE patch info, GS prim info, and FrontEnd/BackEnd DrawEnd events.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
- Do proper culling of wireframe triangles (including non-culling of
degenerates)
- Fix degenerate culling of CCW front-facing triangles in wireframe and
conservative rast
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Alpha from render target 0 should always be used for alpha test for all
render targets, according to GL and DX9 specs. Previously we were using
alpha from the current render target.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Buffer events ourselves and then when that's full or we're destroying
the context then write the contents to file. Previously, we're relying
ofstream to buffer for us.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
* All format combinations coded
* Fully emulated on AVX2 and AVX
* Known issue: the MSAA sample locations need to be adjusted for 8x2
Set ENABLE_AVX512_SIMD16 and USD_8x2_TILE_BACKEND to 1 in knobs.h to enable
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Karol Herbst's fuzzing efforts discovered that we would hit the
following assert:
assert(dummy_instructions.is_empty());
when processing an illegal array size expression of
float[(1=1)?1:1] t;
In do_assignment, we realized we needed an rvalue for (1 = 1), and
generated a temporary variable and assignment from the RHS. We've
already flagged an error (non-lvalue in assignment), and return a bogus
value as the rvalue. But process_array_size sees the bogus value, which
happened to be a constant expression, and rightly assumes that
processing a constant expression shouldn't have generated any code.
instructions.
To handle this, make do_assignment not generate any temps or assignments
when it's already raised an error - just return an error value directly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98694
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We don't allow the last thread switch to be inside control flow, to be
sure that we hit the last state exactly once. If the last texturing was
in control flow, fall back to single threaded.
We have two major requirements: Make sure that only the bottom half of the
physical reg space is used, and make sure that none of our values are live
in an accumulator across a switch.
We have had no reason to separate ability to store in an accumulator from
ability to store in B, but with FS threading, we need to be able to force
values to be stored only in the physical regfiles.
This will eventually be generated at the QIR level, so that
vc4_qir_schedule.c can arrange the separation of tex_strb from tex_result
correctly. It will also be important so that register allocation set the
register classes appropriately for values that are live across the switch.
This is a port of commit a4a5917248:
Add guards to prevent dereferencing NULL dynamic pipeline state. Asserts
of pCreateInfo members are moved to the earliest points at which they
should not be NULL.
This fixes a segfault, related to pColorBlendState, seen in Talos Principle
which I've observed after startup is completed and when exiting the menus,
depending on when Vulkan rendering is selected.
v2: moved the NULL check in radv_pipeline_init_blend_state to after the
declarations.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Fixes fallout from acc23b04 ("ralloc: remove memset from ralloc_size").
We were still depending on zero'd allocations in a couple of places.
Signed-off-by: Rob Clark <robdclark@gmail.com>
There is currently no protection against walking a hash (using
_mesa_HashWalk()) and modifying it at the same time, for instance by inserting
or deleting elements. This leads to segfaults in multithreaded code if e.g.
someone calls glTexImage2D (which may have to walk the list of FBOs) while
another thread is calling glDeleteFramebuffers on another thread with the two
contexts sharing lists.
The reason for this is that _mesa_HashWalk() doesn't actually take the mutex
that normally protects the hash; it takes an entirely different mutex.
Thus, walks are only protected against other walks, and there is also no
outer lock taking this. There is an old comment saying that this is to fix
problems with deadlock if the callback needs to take a mutex; we solve this
by changing the mutex to be recursive.
A demonstration Helgrind hit from a real application:
==13412== Possible data race during write of size 8 at 0x3498C6A8 by thread #1
==13412== Locks held: 2, at addresses 0x1AF09530 0x2B3DF400
==13412== at 0x1F040C99: _mesa_hash_table_remove (hash_table.c:395)
==13412== by 0x1EE98174: _mesa_HashRemove_unlocked (hash.c:350)
==13412== by 0x1EE98174: _mesa_HashRemove (hash.c:365)
==13412== by 0x1EE2372D: _mesa_DeleteFramebuffers (fbobject.c:2669)
==13412== by 0x6105AA4: movit::ResourcePool::cleanup_unlinked_fbos(void*) (resource_pool.cpp:473)
==13412== by 0x610615B: movit::ResourcePool::release_fbo(unsigned int) (resource_pool.cpp:442)
[...]
==13412== This conflicts with a previous read of size 8 by thread #20
==13412== Locks held: 2, at addresses 0x1AF09558 0x1AF73318
==13412== at 0x1F040CD9: _mesa_hash_table_next_entry (hash_table.c:415)
==13412== by 0x1EE982A8: _mesa_HashWalk (hash.c:426)
==13412== by 0x1EED6DFD: _mesa_update_fbo_texture.part.33 (teximage.c:2683)
==13412== by 0x1EED9410: _mesa_update_fbo_texture (teximage.c:3043)
==13412== by 0x1EED9410: teximage (teximage.c:3073)
==13412== by 0x1EEDA28F: _mesa_TexImage2D (teximage.c:3105)
==13412== by 0x166A68: operator() (mixer.cpp:454)
There are many more interactions than just these two possible.
Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Steinar H. Gunderson <steinar+mesa@gunderson.no>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This fixes a NULL pointer dereference for intrinsics with more than
one function attribute introduced in commit 2fdaf38.
The fix is ported from the lp_build_intrinsic changes in commit 8bdd52c.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
The function returns "void" rather than int. We could rework that, yet
again there will be no benefit since all the callers have no use of it.
Fixes: 9ca6711faa ("Revert "wayland: Block for the frame callback in
get_back_bo not dri2_swap_buffers"")
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Now that we have switched to using nir_shader_gather_info() we
can remove the hacks and just use the system variable.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This takes us one step closer to being able to drop the GLSL IR
optimisation passes during linking in favour of the NIR passes.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This allows for gl_PrimitiveId to come in as a system value rather than as
an input. This is the way it will come in from SPIR-V. We keeps the input
path working for now so we don't break GL.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
From the Vulkan spec 1.0.32 section 29.6 docs for vkAcquireNextImageKHR:
"Let n be the total number of images in the swapchain, m be the value of
VkSurfaceCapabilitiesKHR::minImageCount, and a be the number of
presentable images that the application has currently acquired (i.e.
images acquired with vkAcquireNextImageKHR, but not yet presented with
vkQueuePresentKHR). vkAcquireNextImageKHR can always succeed if a ≤ n -
m at the time vkAcquireNextImageKHR is called. vkAcquireNextImageKHR
should not be called if a > n - m with a timeout of UINT64_MAX; in such
a case, vkAcquireNextImageKHR may block indefinitely."
With minImageCount == 2 (as it was previously, the client is allowed to
acquire all but one image withoutblocking. If we really need 4 images for
mailbox mode + pageflipping, then we need to request a minimum of 4 images
up-front. This is a bit unfortunate because it means we will always
consume 4 images. In the future, we may be able to optimize this a bit by
waiting until the server starts to flip and returning OUT_OF_DATE to get
the client to re-allocate with more images or something like that.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
In order to support FIFO mode without blocking the application on calls
to vkQueuePresentKHR it is necessary to enqueue the request and defer
calling the server until the next vblank period. The xcb present api
doesn't offer a way to register a callback, so we will have to spawn a
worker thread that will wait for a request to be added to the queue, call
to the server, and then make the image available for reuse. This commit
introduces the queue data structure needed to implement this.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
fixes following compilation warnings on Android build:
"warning: implicit declaration of function 'static_assert' is invalid in
C99 [-Wimplicit-function-declaration]"
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
fixes following compilation warnings on Android build:
"warning: implicit declaration of function 'static_assert' is invalid in
C99 [-Wimplicit-function-declaration]"
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I just noticed the new vulkan headers changed a prototype,
so I've decided to import them and fix the drivers to use the
new API.
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We can only read the valid samples if this is an MSAA
texture, which means the type field must be 0x14 or 0x15.
This fixes:
dEQP-VK.glsl.texture_functions.query.texturesamples.*
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is only in libstandalone currently because it will only be used in
the stand-alone compiler.
v2: Change the signature of the generated function. The ir_factory is
created in the generator, and an availability predicate is taken as a
parameter.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
For many expressions, this is different from the printable name. The
printable name for ir_binop_add is "+", but we want "add". This is
needed for ir_builder_print_visitor.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
If the user did not request full linking, link the shader with the
built-in functions, inline them, and eliminate them. Previous to this
you'd see all these calls to "dot" and "max" in the output. This
prevented a lot of expected optimizations and cluttered the output.
This gives it some chance of being useful.
v2: Rebase on top of Ken's "built-ins now" work.
v3: Don't do_common_optimizations if par-linking fails. Update expected
output of warnings tests to prevent 'make check' regressions.
v4: Optimize harder. Most important, do function inlining. Otherwise
it's quite impractical for one function in a file to call another
function in the same file.
v5: Add some code simplifications and an assertion suggested by Iago.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
We didn't bother with this in the regular compiler because it doesn't
change the generated code. In the stand-alone compiler, this can
clutter the output with useless variables. It's especially bad after
functions are inlined but the foo_retval declarations remain.
v2: Use set_foreach. Suggested by Tapani.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This just makes the output of the standalone compiler a little more
compact.
v2: Fix indexing typo noticed by Iago. Move the add_neg_to_sub_visitor
to it's own header file. Add a unit test that exercises the visitor.
Both the neg_a_plus_b and neg_a_plus_neg_b tests reproduced the bug that
Iago discovered.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This enables a sort of par-linking. The primary use for this feature is
resolving built-in functions in the stand-alone compiler.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This is based on the code from the GLSL IR pass however unlike the GLSL IR
pass it also supports arrays of arrays.
As well as implementing the logic from the GLSL IR pass we add some
additional intrinsic cases to catch more system values.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I want this function for nir_gather_info(), and realized it's basically
the same as the ones in nir_lower_io().
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The #version directive can only handle decimal constants. Enforce that
the value is a decimal constant.
Section 3.3 (Preprocessor) of the GLSL 4.50 spec says:
The language version a shader is written to is specified by
#version number profile opt
where number must be a version of the language, following the same
convention as __VERSION__ above.
The same section also says:
__VERSION__ will substitute a decimal integer reflecting the version
number of the OpenGL shading language.
Use a separate flag to track whether or not the #version line has been
encountered. Any possible sentinel (0 is currently used) could be
specified in a #version directive. This would lead to trying to
(internally) redefine __VERSION__. Since there is no parser location
for this addition, NULL is passed. This eventually results in a NULL
dereference and a segfault.
Attempts to use -1 as the sentinel would also fail if '#version
4294967295' or '#version 18446744073709551615' were used. We should
have piglit tests for both of these.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97420
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: mesa-stable@lists.freedesktop.org
Cc: Juan A. Suarez Romero <jasuarez@igalia.com>
Cc: Karol Herbst <karolherbst@gmail.com>
It looks like I added this version as a short-hand for users that didn't
need the fuller version. I don't think there's any real utility in
that. I'm not sure what my thinking was there. Maybe if those users
overloaded the recursion function could just call the compact version to
avoid passing some parameters? None of the users do that.
Either way, having this extra overload is not useful. Delete it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Earlier commit renamed the file radeon_icd.json{,.in} but missed one
reference of the file - in EXTRA_DIST.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Fixes: 0f434a68a ("radv: Suffix the radeon_icd file with the host CPU")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This reverts commit a39ad18593.
The commit aims to address "missing" -L/foo/bar during linking stage. At
the same time it doesn't add the -L and yet the LLVM_LDFLAGS [which
provide -L/foo/bar] are already used throughout.
Seems like something pretty unique (broken?) on my end. Since the commit
introduces issues (due to the missing -L) revert until we get to the
root of it (PEBKAC or a genuine issue).
I'm leaving num_out_sgpr around since it's not in a fast path, and besides
the compiler should be able to optimize it away easily. The alternative
with #if/#endif would be extremely ugly.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The fix in commit 88f791db75 was insufficient
for radeonsi because the vector case was not handled properly. It seems
piglit only covers the scalar case, unfortunately.
Fixes GL45-CTS.shader_bitfield_operation.[iu]mulExtended.*
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This reverts commit 25cc889004, though
since the code has changed, it was applied manually.
The intent of moving blocking from SwapBuffers to get_back_bo, was to
avoid unnecessary triple-buffering by ensuring that the compositor had
fully processed the previous frame before we started rendering. This
means that the only time we would have to resort to triple-buffering
would be when the buffer is directly scanned out, thus saving an extra
buffer for composition anyway.
The 'repaint window' changes introduced in Weston since then, however,
have narrowed the window of time between the frame event being sent and
the repaint loop needing to conclude, to 7ms by default, in order to
reduce latency. This means however that blocking in get_back_bo gives a
maximum of 7ms for the entire GL submission to begin and complete.
Not only this, but if a client is using buffer_age to avoid full
repaints, the buffer-age request will stall in get_back_bo until the
frame callback completes, meaning that the client cannot even calculate
the repaint area before the 7ms window.
The combination of the two meant that WebKit-GTK+ was failing to
achieve full framerate on a Minnowboard, due to spending a great deal of
its time attempting to query the age of the next buffer before redraw.
Revert to the previous behaviour of allowing rendering to begin but
delaying SwapBuffers, unless and until we can find a more gentle
behaviour.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Tested-by: Derek Foreman <derekf@osg.samsung.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Until now were validating in/out blocks by listing the inputs in the
consumer stage and then, for each output of the producer, we checked that
it was a match if it was consumed. This method does not catch the case
where the consumer has an input that is not present as an output in the
producer stage, because it only generates link errors for outputs present
in the producer stage that don't match the inputs in the consumer stage.
The current method does catch the case were an output from the producer
stage is not consumed, which is irrelevant and is ignored.
By reversing the way we do this, we can detect this situation, so this
patch lists the outputs of the producer stage and then validates inputs
of the consumer stage against them. If we see an input in the consumer
for which there is no associated output in the producer, we produce a
link error.
The only exception to this is the special built-in input block gl_in[],
since this is implicitly generated for geometry and tessellation stages,
but we don't generate it if the producer stage does not write to any of
the pre-defined outputs (for example, if the vertex shader does not write
to gl_Position, etc). Since writing to these is not mandatory, do not
produce a link error in that case. There is a CTS tessellation test
(GL45-CTS.tessellation_shader.program_object_properties) that has an
empty vertex shader (so it does not produce gl_in[]) and would fail to
link if we don't do this.
This fixes the following dEQP test:
dEQP-GLES31.functional.shaders.linkage.io_block.missing_output_block
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98245
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
From the Vulkan spec version 1.0.32 docs for vkFreeMemory:
"If a memory object is mapped at the time it is freed, it is implicitly
unmapped."
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org>
Our previous fence implementation was very simple. Fences had two states:
signaled and unsignaled. However, this didn't properly handle all of the
edge-cases that we need to handle. In order to handle the case where the
client calls vkGetFenceStatus on a fence that has not yet been submitted
via vkQueueSubmit, we need a three-status system. In order to handle the
case where the client calls vkWaitForFences on fences which have not yet
been submitted, we need more complex logic and a condition variable. It's
rather annoying but, so long as the client doesn't do that, we should still
hit the fast path and use i915_gem_wait to do all our waiting.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Instead of packing varyings into vec4's, keep track of how many
components each slot uses and create varyings with matching types. This
ensures that we don't end up using more components than the orginal
shader, which is especially important for geometry shader output limits.
This comes up for NVIDIA hw, where the limit is 1024 output components
for a GS, and the hardware complains *loudly* if you even think about
going over.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The previous code was confused about whether slot_end was inclusive or
exclusive. Make it so that it is inclusive consistently, and use it for
setting the new location. This also avoids discrepancies in how
num_components is calculated vs the more manual approach taken for the
former reserved_slots check.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This setting is for whether color and alpha have different blend
settings, not for whether blending is enabled on a per-RT basis.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
With ARB_clip_control, GL may also do 0..1 depth clipping, not just
-1..1. This removes clip's reliance on driver type. DX users will need
to be updated to set the new clipHalfZ flag to get proper clipping
functionality.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Most logic op usage is probably going to end up with normalized
textures. Scale the floating point values and convert to integer before
performing the logic operations.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Jonas Pfeil noticed that we were putting passthrough tlb_z writes early in
the shader, despite QIR and QPU scheduling both trying to delay scoreboard
locking for as long as possible.
The problem was that when trying to pair up QPU instructions, at some
point the passthrough tlb_z would be the last one available and it would
get paired, even if the other half would open up other instructions to be
scheduled and we could have paired tlb_z with something later in the
program. Also, since passthrough z is just a mov, it pairs up really
easily.
The proper fix would probably be to flip the order of scheduling
instructions so we went from bottom to top (also relevant for branch delay
slot scheduling).
However, we can do a quick fix here to just not schedule a TLB lock until
there's nothing but TLB left in the program, at a slight instruction cost
(est .61% cycle count in shader-db) but a major fragment shader
parallelism win.
glmark2 results:
texture:texture-filter=linear: +1.24481% +/- 0.626117% (n=15)
bump:bump-render=height: 1.24991% +/- 0.154793% (n=136,133 -- screensaver
outliers removed)
It's much better to just skip the draw call entirely. Getting this
information out of register allocation will also be useful for
implementing threaded fragment shaders, which will need to retry
non-threaded if RA fails.
Cc: <mesa-stable@lists.freedesktop.org>
We had missed a bit of errata - PS scratch needs to be computed as if
there were 4 subslices per slice, rather than 3.
Skylake Broxton Kabylake
GT1 GT2 GT3 GT4 2x6 3x6 GT1 GT1.5 GT2 GT3 GT4
Actual Slices 1 1 2 3 1 1 1 1 1 2 3
Total Subslices 3 3 6 9 2 3 2 3 3 6 9
Subsl. for PS Scratch 4 4 8 12 4 4 4 4 4 8 12
Note that Skylake GT1-3 already worked because we allocated 64 * 9
(trying to use a value that would work on GT4, with 9 subslices),
and the actual required values were 64 * 4 or 64 * 8. However, all
others (Skylake GT4, Broxton, and Kabylake GT1-4) underallocated,
which can lead to scratch writes trashing random process memory,
and rendering corruption or GPU hangs.
Fixes GPU hangs and rendering corruption on Skylake GT4 in shaders that
spill. Particularly, dEQP-GLES31.functional.ubo.all_per_block_buffers.*
now runs successfully with no hangs and renders correctly. This may
fix problems on Broxton and Kabylake as well.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Half float support already exists for desktop GL. Reuse the
ARB_half_float_vertex enable bit and account for the different enum to
enable the extension for ES2.
Signed-off-by: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reverts commit 3652d1d594.
Self nack/reject on this one. The base.ConfigID is overwritten
immediately after we store the current value, thus one memcpy [further
down] the wrong value will be copied.
Vulkan has introduced the consept of .specVersion which can be used to
attribute changes of the said extension.
The current loader does not check the value, thus it have gone unnoticed
that the driver exposes an old version of the following extensions:
VK_KHR_xcb_surface (Rev 6)
VK_KHR_xlib_surface (Rev 6)
VK_KHR_wayland_surface (Rev 5)
- Updated the surface create function to take a pCreateInfo structure
VK_KHR_swapchain (Rev 68)
- Moved the "validity" include for vkAcquireNextImage to be in its proper
place, after the prototype and list of parameters.
...
According to the documentation:
* pname:specVersion is the version of this extension.
It is an integer, incremented with backward compatible changes.
Based on the history of vk.xml the above (latest) revision has been
available since Vulkan 1.0 so even if they were any backwards
incompatible change(s) [as hinted by the revision log] those should be
safe.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Currently if one uses a non-default prefix, the path won't get
propagated and we'll fail at link-time.
A very quick and easy example is to install to /usr/local.
At this point, llvm-config will be picked even without the
--with-llvm-prefix, but regardless of the latter linking will fail.
Currently people can workaround that via LD_LIBRARY_PATH.
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Cc: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Currently we only saved the id to memcpy the whole _EGLConfig to write
back the exact same id value.
Remove the unneeded and confusing/misleading code.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
As the linked per-stage shaders are processed, mark any block that has a
field that is accessed as referenced. When combining all the linked
shaders, combine the per-stage stageref masks.
This fixes a number of GLES CTS tests:
ES31-CTS.core.geometry_shader.program_resource.program_resource
ES32-CTS.core.geometry_shader.program_resource.program_resource
ESEXT-CTS.geometry_shader.program_resource.program_resource
piglit.gl45-cts.geometry_shader.program_resource.program_resource
However, it makes quite a few more fail:
ES31-CTS.functional.program_interface_query.buffer_variable.random.6
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.compute.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.separable_fragment.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_fragment_only_fragment.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_fragment.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_geo_fragment_only_fragment.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_geo_fragment.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_tess_fragment_only_fragment.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_tess_fragment.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_tess_geo_fragment_only_fragment.unnamed_block.float
ES31-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_tess_geo_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.random.6
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.compute.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.separable_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_fragment_only_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_geo_fragment_only_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_geo_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_tess_fragment_only_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_tess_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_tess_geo_fragment_only_fragment.unnamed_block.float
ES32-CTS.functional.program_interface_query.buffer_variable.referenced_by.vertex_tess_geo_fragment.unnamed_block.float
I have diagnosed the failures, but I'm not sure whether we or the
tests are wrong. After optimizations are applied, all of the tests
are of the form:
buffer X {
float f;
} x;
void main()
{
x.f = x.f;
}
The test then queries that x is referenced by that shader stage. We
eliminate the assignment of x.f to itself, and that removes the last
reference to x. We report that x is not referenced, and the test fails.
I do not know whether or not we are allowed to eliminate that assignment
of x.f to itself.
After discussions with the OpenGL ES group in Khronos, we believe that
Mesa's behavior is correct. I will provide patches to the CTS tests
to Khronos.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It was not obvious from the just the .h file what the hash table
contained. It was also not obvious that get_variable_entry would create
a new entry in the hash table.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes a bunch of GPU hangs introduced in some CTS
tests like
dEQP-VK.memory.pipeline_barrier.host_write_uniform_buffer.65536
It works around an issue seen in the LLVM backend, but
also makes the radv code work more like the radeonsi stack.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is ported from GLSL and converts
if (cond)
discard;
into
discard_if(cond);
This removes a block, but also is needed by radv
to workaround a bug in the LLVM backend.
v2: handle if (a) discard_if(b) (nha)
cleanup and drop pointless loop (Matt)
make sure there are no dependent phis (Eric)
v3: make sure only one instruction in the then block.
v4: remove sneaky tabs, add cursor init (Eric)
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We are going to start lowering to this in NIR code,
so prepare radv for it.
v2: handle conversion to kilp properly (nha)
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since our surface state buffer is shared by all batches, the kernel does a
full stall and sync with the CPU between batches every time we call
execbuf2 because it refuses to do relocations on an active buffer. Doing
them in userspace and passing the NO_RELOC flag to the kernel allows us to
perform the relocations without stalling.
This improves the performance of Dota 2 by around 30% on a Sky Lake GT2.
v2 (Jason Ekstrand):
- Better comments (Chris Wilson)
- Fixed write_reloc for correct canonical form (Chris Wilson)
v3 (Jason Ekstrand):
- Skip relocations which aren't needed
- Provide an environment variable to always use the kernel
- More comments about correctness (Chris Wilson)
v4 (Jason Ekstrand):
- More comments (Chris Wilson)
v5 (Jason Ekstrand):
- Rebase on top of moving execbuf2 setup go QueueSubmit
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Ever since the early days of the Vulkan driver, we've been setting up the
lists of relocations at EndCommandBuffer time. The idea behind this was to
move some of the CPU load out of QueueSubmit which the client is required
to lock around and into command buffer building which could be done in
parallel. Then QueueSubmit basically just becomes a bunch of execbuf2
calls.
Technically, this works. However, when you start to do more in QueueSubmit
than just execbuf2, you start to run into problems. In particular, if a
block pool is resized between EndCommandBuffer and QueueSubmit, the list of
anv_bo's and the execbuf2 object list can get out of sync. This can cause
problems if, for instance, you wanted to do relocations in userspace.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
The original reason for putting it in the batch_bo was to allow primaries
to share it across secondaries or something like that. However, the
relocation lists in secondary command buffers are are always left alone and
copied into the primary command buffer's relocation list. This means that
the offset really applies at the command buffer level and putting it in the
batch_bo doesn't make sense. This fixes a couple of potential bugs around
re-submission of command buffers that are not likely to be hit but are bugs
none the less.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
This commit adds a little helper struct for storing everything we use to
build an execbuf2 call. Since the add_bo function really has nothing to do
with a command buffer, it makes sense to break it out a bit. This also
reduces some of the churn in the next commit.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
The old version wasn't properly handling large addresses where we have to
sign-extend to get it into the "canonical form" expected by the hardware.
Also, the new version is capable of doing a clflush of the newly written
reloc if requested.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Since -1 is an invalid GPU address, this lets us know whether or not we
have a valid address for a buffer. We don't get a valid address until the
first time that buffer is used in an execbuf2 ioctl.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
The previous implementation was being overly clever and using the
anv_bo::size field as its mutex. Scratch pool allocations don't happen
often, will happen at most a fixed number of times, and never happen in the
critical path (they only happen in shader compilation). We can make this
much simpler by just using the device mutex. This also means that we can
start using anv_bo_init_new directly on the bo and avoid setting fields
one-at-a-time.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Because our relocation processing happens at EndCommandBuffer time and
because RENDER_SURFACE_STATE objects may be shared by batches, we really
have no clue whatsoever what address is actually written to the relocation
offset in the BO. We need to stop making such claims to the kernel and
just let it relocate for us.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
When you fire up Dota2 on Haswell you get spammed with thousands of
"Implement Gen7 HZ ops" finishme's. The point of anv_finishme is to act as
a reminder that there is something left to implement. Printing it once
should be sufficient.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Trivial. There's some regressions internally, related to overflow
behavior. I'll have to look at it at another time, some interactions
with vsplit/vcache are actually mind-blowing.
This reverts commit 3fa10ffb49.
This patch should have been the part of commit e592f7df.
In a situation when there are multiple render targets with alpha testing
enabled, if fragment shader doesn't write to draw buffer zero, it causes
the GPU hang on SKL. No GPU hang is seen on HSW. Simulator gives a
warning for all gen6+ h/w:
"Illegal render target write message length 0xa expected 0xc"
This patch fixes the GPU hang as well as the simulator warning with
new piglit test fbo-mrt-alphatest-no-buffer-zero-write:
https://patchwork.freedesktop.org/patch/118212
No regressions in Jenkins CI system.
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
I was getting a random GPU hang in the renderpass simple tests,
it turns out sometimes radv emitted the wrong thing "last".
This fixes the logic to emit Z/stencil last if they occur,
and not mark a color output as last. Also this relies on the
Z/STENCIL being the first two fragment outputs, which they are
so yay.
Fixes: dEQP-VK.renderpass.simple.color_depth (random hangs)
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some of the details of this function are very confusing and have a long
history. We should document that history and this seems like the best
place to do it.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
At least on Sky Lake, after emitting 3DSTATE_CONSTANT_*, you are required
to re-emit the 3DSTATE_BINDING_TABLE_POINTERS packet for the corresponding
stage. If you don't, double-buffering may fail and you may get the wrong
constants. It turns out that you need to do this even if you have no push
constants to speak of or else the next 3DSTATE_CONSTANT packet you emit for
that stage may not work correctly.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
For gen9+ this will indicate when we should allow hiz based sampling
during rendering.
Improves performance in :
- Synmark's OglDeferred by 2.2% (n=20)
- Synmark's OglShMapPcf by 0.44% (n=20)
v2 by Ben: Add spec reference, and make it fix with some of the changes made on
the previous patches
Change the check from mt->aux_buf to mt->num_samples. The presence of an aux_buf
isn't enough to determine there isn't a HiZ buffer to use.
v3: It seems all depth surface end up with num_samples = 0 by default,
so allow sampling from depth HiZ if num_samples <= 1. (Lionel)
Allow sampling from HiZ only if all LOD are available from the HiZ
buffer. (Lionel)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v2)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v3)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The original functionality this patch introduces was authored by a patch from
Ken (the commit subject was the same). Since I ended up changing so many patches
in the code before this one, I had some non-trivial decisions to make, and I
didn't feel it was appropriate to keeps Ken's name as author (mostly because he
might not like what I've done). Ken's original patch was like 2 LOC :-)
In either case, some credit needs to go to Ken, and to Jordan for a few small
other changes in that original patch.
v2: Back to a smaller diff now that ISL handles most of the actual
programming (Lionel)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Currently it indicates that this is never supported, but soon it will
be supported for gen8+^w gen9+
v2 by Ben:
- Explicitly disable aux_hiz for gen < 9 (with comment)
- squashed in next patch to avoid unused and useless functions
i965: Support sampling with hiz during rendering
For gen8, we can sample from depth while using the hiz buffer. This
allows us to sample depth without resolving from hiz to the depth
texture.
To do this we must resolve to hiz before drawing so we can use the hiz
buffer to sample while rendering. Hopefully the hiz buffer will
already be resolved in most cases because it was previously rendered,
meaning the hiz resolve is a no-op.
Note that this is still controlled by the
intel_miptree_sample_with_hiz function, and we will enable hiz
sampling for gen8 in a separate patch.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This seems counter to the goal of consolidating hiz, mcs, and later ccs buffers.
Unfortunately, hiz on gen6 is a thing the code supports, and this wart will be
helpful to achieve that. Overall, I believe it does help unify AUX buffers on
gen7+.
I updated the size field which I introduced in the previous patch, even though
we have no use for it.
XXX: As I mentioned in the last patch, the height given to the MCS buffer
allocation in intel_miptree_alloc_mcs() looks wrong, but I don't claim to fully
understand how the MCS buffer is laid out.
v2: rebase on master (Lionel)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This patch will preserve the BO & offset, and not the miptree for the
aux_mcs buffer. Eventually it might make sense to pull put the sizing
function in miptree creation, but for now this should be sufficient
and not too hideous.
v2: Save BO's offset too (Lionel)
v3: Squash previous patch storing the size of the allocated aux buffer
(Lionel)
Fix memory leak with mcs_buf->bo (Lionel)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The next patch will change the map type, and this will make sure there are no
regressions as a result of the other stuff. Since the miptree is newly created,
I believe it is always safe to just map.
It is possible to CPU map this buffer on LLC platforms (it additionally requires
rounding up to tile size). I did experiment with that patch, and found no
performance gains to be had.
I've added in error handling while here. Generally GTT mapping is an operation
which is highly unlikely to fail, but we may as well handle it when it does.
v2: rebase on master (Lionel)
v3: print out error if gtt mapping fails (Topi)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This will allow us to treat HiZ and MCS the same when using as an
auxiliary surface buffer.
v2: (Ben) Minor rebase conflict resolution.
Rename mcs_buf to aux_buf to address upcoming change for hiz specific buffers.
That second thing is essentially a squash of:
i965/gen8: Use intel_miptree_aux_buffer for auxiliary buffer - which didn't need
to be separate in my opinion.
v3: rebase on master (Lionel)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>a (v2)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v3)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This patch does two things:
1. It separates the host-CPU code generation from the generic code
generation. This guards against accidently breaking things for
radeonsi in the future.
2. It makes sure we actually use both arguments and don't just compute
a square :-p
Fixes a regression introduced by commit 29279f44b3
Cc: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Instead of doing all the math with scalars, use vectors. This means the
overflow math needs to be done manually, albeit that's only really
problematic for the stride/index mul, the rest has been pretty much
moved outside the shader loop (albeit the mul could actually be optimized
away too), where things are still scalar. Because llvm is complete fail
with the zero-extend widening mul, roll our own even...
To eliminate control flow in the main shader loop fetch, provide fake
buffers (so index 0 is always valid to fetch).
Still uses aos fetch though in the end - mostly because some more code
would be needed to handle unaligned fetches in that path, and because for
most formats it won't make a difference anyway (we generate some truly
horrendous code for things like R16G16_something for instance).
Instanced fetch however stays roughly the same as before, except that
no longer the same element is fetched multiple times (I've seen a reduction
of ~3 times in main shader loop size due to apparently llvm not being able
to deduce it's really all the same with a couple instanced elements).
Also, for elts gathering, use vectorized code as well - provide a fake
elt buffer if there's no valid one bound.
The generated shaders are smaller and faster to compile (not entirely sure
about execution speed, but generally unless there's just single vertices
to handle I would expect it to be faster - there's more opportunities
for future improvements by using soa fetch).
No piglit change.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This is used by shader umul_hi/imul_hi functions (and soon by draw).
It's actually useful separating this out on its own, however the real
reason for doing it is because we're using an optimized sse2 version,
since the code llvm generates is atrocious (since there's no widening
mul in llvm, and it does not recognize the widening mul pattern, so
it generates code for real 64x64->64bit mul, which the cpu can't do
natively, in contrast to 32x32->64bit mul which it could do).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
In the event that multiple threads attempt to install a graph
concurrently, protect the shared list.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Instead of trying to maintain a reference counted list of valid HUD
objects, and freeing them accordingly, creating race conditions
between unanticipated multiple threads, simply accept they're
allocated once and never released until the process terminates.
They're a shared resource between multiple threads, so accept
they're always available for use.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes a problem seen with gallium drivers vs android wallpaper.
Basically, what happens is:
EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay, mEglConfig, attribs);
mEgl.eglMakeCurrent(mEglDisplay, tmpSurface, tmpSurface, mEglContext);
int[] maxSize = new int[1];
Rect frame = surfaceHolder.getSurfaceFrame();
glGetIntegerv(GL_MAX_TEXTURE_SIZE, maxSize, 0);
mEgl.eglMakeCurrent(mEglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
mEgl.eglDestroySurface(mEglDisplay, tmpSurface);
... check maxSize vs frame size and bail if needed ...
mEglSurface = mEgl.eglCreateWindowSurface(mEglDisplay, mEglConfig, surfaceHolder, null);
... error checking ...
mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface, mEglContext);
When the window-surface is created, it ends up with the same ptr address
as the recently freed tmpSurface pbuffer surface. Which after many
levels of indirection, results in st_framebuffer_validate() ending up with
the same/old framebuffer object, and in the end never calling the
DRIimageLoaderExtension::getBuffers(). Then in droid_swap_buffers(), the
dri2_surf is still the old pbuffer surface (with dri2_surf->buffer being
NULL, obviously, so when wallpaper app calls eglSwapBuffers() nothing
gets enqueued to the compositor). Resulting in a black/blank background
layer.
Note that at the EGL layer, when the context is unbound, EGL drops it's
references to the draw and read buffer as well.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Robert Foss <robert.foss@collabora.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
v3 [Francisco Jerez]: Loosely based on Serge's v1 of this patch in
order to avoid CL-specific enums in the clover module binary
format. In addition to other changes made in v2: Represent the CL
program binary type as the section type instead of adding a CL
API-specific enum, check that the binary types of the input objects
are valid during clLinkProgram(), pass section type as argument to
build_module_library() instead of using separate function.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Instead, hardcode group sigsel because there are a bunch of unknown
groups, especially on SM50/SM52.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This is similar to NVC0 and GK110 emitters where we emit
reduction operations instead of atomic operations when the
destination is not used.
Found after writing some tests which check if performance counters
return the expected value. In that case, gred_count returned 0
on gm107 while at least gk106 returned the correct value.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This fixes random crashes with MSVC release builds. It seems the
members are implicitly initialized to zero with gcc, but not MSVC.
In particular, the tex_offset_num_offset field was non-zero causing
a loop over the NULL tex_offsets array to crash.
Zero-init those fields and a few others to be safe.
The regression began with acc23b04cf "ralloc: remove memset from
ralloc_size".
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes the following building error introduced with commit 7115e56
and related amd/common dependencies:
external/mesa/src/gallium/drivers/radeonsi/si_shader.c:6861: error: undefined reference to 'ac_is_sgpr_param'
external/mesa/src/gallium/drivers/radeonsi/si_shader.c:6951: error: undefined reference to 'ac_is_sgpr_param'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
build/core/ninja.mk:148: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
GL_ARB_ES3_compatibility brings ETC2/EAC formats to desktop GL.
The meaning of the GL compressed format list is pretty vague - it's
supposed to return formats for "general-purpose usage". (GL 4.2
deprecates the list because of this.) Basically everyone interprets
this as "linear RGB/RGBA".
ETC2/EAC meets that criteria, so while we shouldn't be required to add
it to the list, there's also little harm in doing so, at least on
platforms with native support. I doubt anyone is using this list for
much anyway, so even on platforms without native support, it's probably
not a big deal.
Makes the following GL45-CTS.gtf43 tests pass:
* GL3Tests.eac_compression_r11.gl_compressed_r11_eac
* GL3Tests.eac_compression_rg11.gl_compressed_rg11_eac
* GL3Tests.eac_compression_signed_r11.gl_compressed_signed_r11_eac
* GL3Tests.eac_compression_signed_rg11.gl_compressed_signed_rg11_eac
* GL3Tests.etc2_compression_rgb8.gl_compressed_rgb8_etc2
* GL3Tests.etc2_compression_rgb8_pt_alpha1.gl_compressed_rgb8_pt_alpha1_etc2
* GL3Tests.etc2_compression_rgba8.gl_compressed_rgba8_etc2
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
The 1/W was apparently not accurate enough, and we were getting sparklies
in the distance. The closed driver also did a N-R step here.
Cc: <mesa-stable@lists.freedesktop.org>
The hardware always treats the alpha channel as unsigned, so add a shader
workaround. This is rare enough that we'll just build a monolithic vertex
shader.
The SINT case cannot actually happen in OpenGL, but I've included it for
completeness since it's just a mix of the other cases.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
A (latent) bug in VDPAU interop was exposed by commit
e5cc84dd43.
Before that commit, the st_vdpau code created samplers with
first_layer == last_layer == 1 that the general texture handling code
would immediately delete and re-create, because the layer does not match
the information in the GL texture object.
This was correct behavior at least in the DMABUF case, because the imported
resource is supposed to have the correct offset already applied. In the
non-DMABUF case, this was just plain wrong but apparently nobody noticed.
After that commit, the state tracker assumes that an existing sampler is
correct at all times. Existing samplers are supposed to be deleted when
they may become invalid, and they will be created on-demand. This meant
that the sampler with first_layer == last_layer == 1 stuck around, leading
to rendering artefacts (on radeonsi), command stream failures (on r600), and
assertions (in debug builds everywhere).
This patch fixes the problem by simply not creating a sampler at all in
st_vdpau_map_surface. We rely on the generic texture code to do the right
thing, adding the layer_override to make the non-DMABUF case work.
v2: add the layer_override
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98512
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Cc: Christian König <deathsimple@vodafone.de>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Reviewed-by: Christian König <christian.koenig@amd.com>
This reverts commit d180de3532.
This is a radeon specific hack that causes problems on nouveau
when combined with the SHARED flag later. If radeonsi needs a fix
for this, please fix it in the driver.
[chk]
Using linear surfaces for this makes sense because tilling isn't
beneficial and the surfaces can potentially be shared with other GPUs
using the VDPAU OpenGL interop.
[airlied]
I think we need a flag that isn't SHARED/LINEAR that is more
SHARED_OTHER_GPU.
[mareko]
Does radeonsi need PIPE_BIND_VIDEO_DECODE_OUTPUT that it would translate
into linear ?
[mareko]
My only concern is decoding performance. If the decoder works in 64x1
blocks, tiling will hurt. That's the theory. I don't know how the
decoder works.
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Nayan Deshmukh <nayan26deshmukh@gmail.com> (I+A)
When splitting up loads, we have to add 16 bytes to the offset for
the high components, just like already happens for stores.
Fixes arb_gpu_shader_fp64@shader_storage@layout-std140-fp64-shader.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
From the manpage of asprintf:
"If memory allocation wasn't possible, or some other error occurs,
these functions will return -1, and the contents of strp are
undefined."
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Fixes valgrind warnings about using uninitialized memory when starting X.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes spurious assertion failure in surf_level_drm_to_winsys when
starting X, due to processing a miplevel which was never initialized.
Fixes: e9c76eeeaa ("gallium/radeon: remove radeon_surf_level::pitch_bytes")
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Mesa uses limits.h elsewhere, and this makes is possible to
compile anv_allocator.c on Android.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
We were leaving an undefined value since the ralloc zeroing changes.
Fixes nir_validate() failures on vc4.
v2: Fix the color-index case of drawpixels as well.
Reviewed-by: Rob Clark <robdclark@gmail.com> (v1)
Previous fixes were incomplete - some code still iterated through the number
of elements provided by velem layout instead of the number stored in the key
(which is the same as the number defined by the vs). And also actually
accessed the elements from the layout directly instead of those in the key.
This mismatch could still cause crashes.
(Besides, it is a very good idea to only use data stored in the key anyway.)
v2: move null format check, remove now unnecessary function parameter,
some minor prettify
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Invalidate a "new" surface before it is bound to a render target view or
depth stencil view in order to avoid the unnecessary host side copy
of the surface data before it is rendered to.
Note that, recycled surface is already invalidated before it is reused.
Reviewed-by: Brian Paul <brianp@vmware.com>
Using untyped surface formats causes huge performance degradation on Fusion.
This reverts commit eb0ced74f6 until
the backend has a better solution to address typeless surface formats.
Currently blitter will fail if the blit format is different and
view-incompatible to the resource format. Instead of punting
to software blit which will stall the pipeline, we will
create temporary resource to allow blitter to work.
Fixes piglit test arb_copy_image-formats.
Also tested with MTT piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
Currently we adjust the view format when we are asked to create a
BGRA render target view for BGRX surface. But we only look for
SVGA3D_B8G8R8X8_TYPELESS surface format.
With this patch, we will also check for SVGA3D_B8G8R8X8_UNORM surface format,
and use SVGA3D_B8G8R8X8_UNORM as the view format for that case.
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch adds a helper function svga_format_is_typeless() which
returns TRUE if the specified format is typeless.
Reviewed-by: Brian Paul <brianp@vmware.com>
We may need to re-emit texture bindings when the framebuffer state
changes. In particular, emitting the texture binding can also involve
updating a texture from its backing copy during sampler view validation.
The backing copy is made during framebuffer validation.
This helps to fix an issue with Photoshop on VGPU9 (VMware bug 1723971).
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
With this patch, we will allow blit with copy_region if the
source and destination textures have the same sample counts.
Fixes failures with piglit tests
spec@arb_texture_float@multisample-formats 2 gl_arb_texture_float
spec@arb_texture_rg@multisample-formats 2 gl_arb_texture_rg-float
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch sets the rendered-to flag for the subresource after it is
updated using the PredCopyRegion command. This is to ensure that the GB surface
will be sync up properly before it will be directly mapped to.
Tested with MTT piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch adds a flag "can_use_upload" to svga_texture structure
to avoid some checking of the upload availability at each transfer map time.
Tested with Lightsmark2008, Tropics, MTT glretrace, piglit.
Reviewed-by: Brian Paul <brianp@vmware.com>
As Thomas suggested, we'll first try to map directly to a GB surface.
If it is blocked, then we'll use texture upload buffer.
Also if a texture is already "rendered to", that is, the GB surface
is already out of sync, then we'll use the texture upload buffer
to avoid syncing the GB surface.
Tested with Lightsmark2008, Tropics, MTT piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch sets the rendered_to flag for the texture subresource that
is uploaded using the TransferFromBuffer command. This is to ensure that
the subresource will be read back or invalidated before it will be
directly mapped to. This makes sure that the content of the GB surface
will not be accidentally overwritten by the device at suspend/resume time.
Reviewed-by: Brian Paul <brianp@vmware.com>
set render_condition flag when driver performs conditional rendering.
Blit using DXPredCopyRegion command gets affected by conditional rendering so
We should check this flag while performing blit operation
Tested with piglit tests.
v2: As per Charmaine's comment, setting render_condition flag if svga_query is valid.
Tested with pigit tests.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
DXPredCopyRegion supports copy between src and dst for depth_and_stencil
formats if src and dst have same formats.
tested ith piglit
v2: As per Brian's comment, allow DXPredCopyRegion for depth+stencil buffers
if the blit mask is PIPE_MASK_ZS.
Tested with piglit tests and added new piglit test
arb_framebuffer_object-depth-stencil-blit to test this particular testcase.
Reviewed-by: Brian Paul <brianp@vmware.com>
Piglit tests which uses arb_clear_texture extension, have memory leak issue.
pipe_surface created in svga_clear_texture() was not deleted which happens to be
the cause for memory leak.
tested all arb_clear_texture-* piglit tests with valgrid.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
v2: Accounted for the fact that svga_try_clear_render_target also
honors conditional rendering.
Testing done: Excercised all functions in a separate feature branch. Forced
emission of conditional rendering commands when necessary.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Assuming the hardware is set up to use a screen coordinate system
flipped vertically with respect to the GL's window coordinate system,
the SYSTEM_VALUE_SAMPLE_POS vector will also be flipped vertically
with respect to the value expected by the GL, so we need to give it
the same treatment as gl_FragCoord. Fixes the following CTS tests on
i965:
ES31-CTS.functional.shaders.multisample_interpolation.interpolate_at_offset.at_sample_position.default_framebuffer
ES31-CTS.functional.shaders.sample_variables.sample_pos.correctness.default_framebuffer
when run with any multisample configuration, e.g. rgba8888d24s8ms4.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Such a surface is not possible on our hardware. Without this change, ISL
surface creation would fail with the next patch.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Valgrind reports that we use cfg.cycle_count uninitialised, so zero the
cfg_t on construction.
Fixes: 52d2b28f7f ("ralloc: use rzalloc where it's necessary")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes GL45-CTS.geometry_shader.adjacency.adjacency_indiced_triangle_strip and
others.
This leaves the case of triangle strips with adjacency and primitive restarts
open. It seems that the only thing that cares about that is a piglit test.
Fixing this efficiently would be really involved, and I don't want to use the
hammer of degrading to software handling of indices because there may well
be software that uses this draw mode (without caring about the precise
rotation of triangles).
v2:
- skip the GS prolog entirely if workaround is not needed
- only check for TES (TES is always non-null when tessellation is used)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The copy shader only depends on the selector. This change avoids creating
separate code paths for monolithic vs. non-monolithic geometry shaders.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For fixed function TCS, we keep the copying of VS outputs to TES inputs inside
the main function; the call to si_copy_tcs_inputs is moved accordingly.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This helps to achieve a gradual transition towards building monolithic shaders
via inlining.
no_prolog and no_epilog will be removed by the end of the series,
separate_prolog remains in use to control the PS input mapping.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Change the pass manager as well, since this is a module-level pass. No
noticeable run-time difference on shader-db.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The incompatible signature becomes an issue when the VS epilog gets merged
with the main vertex shader at the IR level.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
At least when LLVM is used, which is basically always (unless you're only
building r600 without OpenCL).
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When a UBO reference has the form block_name.foo where block_name refers
to a block where the first member has a non-zero offset, the base offset
was incorrectly added to the reference.
Fixes an assertion triggered in debug builds by
GL45-CTS.enhanced_layouts.uniform_block_layout_qualifier_conflict. That test
doesn't properly check for correct execution in this case, so I am also
going to send out a piglit test.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
At link time, we resolve the size of implicitly sized arrays.
When doing so, we update the type of the ir_variables. However,
we neglected to update the type of ir_dereference nodes which
reference those variables.
It turns out array_resize_visitor (for GS/TCS/TES interface array
handling) already did 2/3 of the cases for this, so we can simply
refactor the code and reuse it.
This fixes:
GL45-CTS.shader_storage_buffer_object.basic-syntax
GL45-CTS.shader_storage_buffer_object.basic-syntaxSSO
which have an SSBO containing an implicitly sized array, followed
by some other members. setup_buffer_access uses the dereference
types to compute offsets to fields, and it had a stale type where
the implicitly sized array's length was still 0 instead of the
actual length.
While we're here, we can also fix update_array_sizes to properly
update deref types as well, fixing a FINISHME from 2010.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This moves the delete linked shaders call to
_mesa_clear_shader_program_data() which makes sure we delete them
before returning due to any validation problems.
It also reduces some code duplication.
From the OpenGL 4.5 Core spec:
"If LinkProgram failed, any information about a previous link of
that program object is lost. Thus, a failed link does not restore
the old state of program.
...
If one of these commands is called with a program for which
LinkProgram failed, no error is generated unless otherwise noted.
Implementations may return information on variables and interface
blocks that would have been active had the program been linked
successfully. In cases where the link failed because the program
required too many resources, these commands may help applications
determine why limits were exceeded."
Therefore it's expected that we shouldn't be able to query the
program that failed to link and retrieve information about a
previously successful link.
Before this change the linker was doing validation before freeing
the previously linked shaders and therefore could exit on failure
before they were freed.
This change also fixes an issue in compat profile where a program
with no shaders attached is expect to fall back to fixed function
but was instead trying to relink IR from a previous link.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97715
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
These were broken in e1af20f18a when the info field in nir_shader was
turned into a pointer.
Clone was copying the pointer rather than the data and nir_sweep was
cleaning up shader_info rather than claiming it.
Reviewed-by: Eric Anholt <eric@anholt.net>
This will allow use to use ralloc_parent() on the info field and fix
a regression in nir_sweep() caused by e1af20f18a.
This is intended to be a temporary requirement that will be removed
when we finish separating shader_info from nir_shader.
Reviewed-by: Eric Anholt <eric@anholt.net>
This allows us to use ralloc_parent() to see which data structure owns
shader_info which allows us to fix a regression in nir_sweep().
This will also allow us to move some fields from gl_linked_shader to
gl_program, which will allow us to do some clean-ups like storing
gl_program directly in the CurrentProgram array in gl_pipeline_object
enabling some small validation optimisations at draw time.
Also it is error prone to depend on the gl_linked_shader for
programs in current use because a failed linking attempt will free
infomation about the current program. In i965 we could be trying
to recompile a shader variant but may have lost some required fields.
Reviewed-by: Eric Anholt <eric@anholt.net>
This limitation was initially here because AMD_performance_monitor
doesn't allow to expose the real number of hardware counters. But
this actually really annoying when profiling with qapitrace.
Anyways, performance counters are mostly for developers and
failures are expected if you try to monitor more queries than
supported.
This breaks amd_performance_monitor_measure but it's expected.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Dolphin tried to use this, but we hadn't had any tests for it properly.
All that is required is the shader output format needs to be set
for 0 and 1 exports.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The case where we just want the loop to continue is INCOMPATIBLE_DRIVER
because that simply means that whatever FD we opened isn't a supported
Intel chip. Other error codes such as OUT_OF_HOST_MEMORY are actual errors
and we should be returning early in that case.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Note LOCAL_CFLAGS and LOCAL_SHARED_LIBRARIES in Android.common.mk
are used by both host and target modules. However, commit 112e988
moved libdrm related flags to common. It causes the errors like:
error: 'out/host/linux-x86/obj32/SHARED_LIBRARIES/libdrm_intermediates/export_includes',
needed by 'out/host/linux-x86/obj32/EXECUTABLES/mesa_gen_matypes_intermediates/import_includes',
missing and no known rule to make it
No reason to use libdrm with host modules.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Fixes: 112e988329 ("Android: move libdrm settings to top-level
Android.common.mk")
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This is required when an out argument involves an array index that is either
a global variable modified by the function or another out argument in the
same function call.
Fixes the shaders/out-parameter-indexing/vs-inout-index-inout-* tests.
v2:
- modify the ir_dereference_array nodes in place
- use ir_hierarchical_visitor
v3: use base_ir (Ian Romanick)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
As previously written, these opcodes use the SM5 semantics which is
incompatible with GLSL when bits == 0, offset == 32.
At some point we may want to add BFI_SM5 etc. opcodes, but all users
currently either want (and expect!) the GLSL semantics or don't care.
Bitfield inserts are generated by the GLSL lower_instructions and
lower_packing_builtins passes with constant bits and offset arguments,
so any workaround code that drivers may have to emit to follow GLSL
semantics should be optimized away easily for those uses.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This makes more sense than OUT_OF_HOST_MEMORY. Technically, you can
recover from a failed execbuf2 but the batch you just submitted didn't
fully execute so things are in an ill-defined state. The app doesn't want
to continue from that point anyway.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The emission of vertex attributes corresponding to dvec3 and dvec4
vertex shader input variables was not correct when the <size> passed
to the VertexAttribL* commands was <= 2.
This was because we were using the vertex array size when emitting vertices
to decide if we uploaded a 64-bit floating point attribute as 1 slot (128-bits)
for sizes 1 and 2, or 2 slots (256-bits) for sizes 3 and 4. This caused problems
when mapping the input variables to registers because, for deciding which
registers contain the values uploaded for a certain variable, we use the size
and type given to the variable in the shader, so we will be assigning 256-bits
to dvec3/4 variables, even if we only uploaded 128-bits for them, which happened
when the vertex array size was <= 2.
The patch uses the shader information to only emit as 128-bits those 64-bit floating
point variables that were declared as double or dvec2 in the vertex shader. Dvec3 and
dvec4 variables will be always uploaded as 256-bits, independently of the <size> given
to the VertexAttribL* command.
From the ARB_vertex_attrib_64bit specification:
"For the 64-bit double precision types listed in Table X.1, no default
attribute values are provided if the values of the vertex attribute variable
are specified with fewer components than required for the attribute
variable. For example, the fourth component of a variable of type dvec4
will be undefined if specified using VertexAttribL3dv or using a vertex
array specified with VertexAttribLPointer and a size of three."
We are filling these unspecified components with zeros, which coincidentally is
also what the GL44-CTS.vertex_attrib_binding.basic-inputL-case1 expects.
v2: Do not use bitcount (Kenneth Graunke)
Fixes: GL44-CTS.vertex_attrib_binding.basic-inputL-case1 test
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97287
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
3DSTATE_WM_CHROMAKEY isn't programmed anywhere else.
3DSTATE_WM_HZ_OP is programmed, then cleared by blorp during a
HZ op, so repeatedly clearing it after every blorp execution is
redundant.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
When the video coded size is different from frame size, we need the result
buffers are same as coded size, which are not size compatible with encode
required size, so that simply use no tunnel for this case instead of frame
by frame converting.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Add frontend dependency concept in the DRAW_CONTEXT, which
allows serialization of frontend work if necessary.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This allows the post-processor to easily detect the API thread and to
process frame information. The frame information is needed to
optimized how data is processed from worker threads.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
No change in behavior. ralloc_size is equivalent to rzalloc_size.
That will change though.
Calls not switched to rzalloc_size:
- ralloc_vasprintf
- glsl_type::name allocation (it's filled with snprintf)
- C++ classes where valgrind didn't show uninitialized values
I switched most of non-glsl stuff to rzalloc without checking whether
it's really needed.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
this fixes some of the regressions with
"ralloc: remove memset from ralloc_size"
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Switch to use memory allocations which zero memory for places
where needed.
v2: modify and rebase on top of Marek's series (Tapani)
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
time GALLIUM_NOOP=1 ./run shaders/private/alien_isolation/ >/dev/null
Before (2 takes):
real 0m8.734s 0m8.773s
user 0m34.232s 0m34.348s
sys 0m0.084s 0m0.056s
After (2 takes):
real 0m8.448s 0m8.463s
user 0m33.104s 0m33.160s
sys 0m0.088s 0m0.076s
Average change in "real" time spent: -3.4%
calloc should only do 2 things compared to malloc:
- check for overflow of "n * size"
- call memset
I'm not sure if that explains the difference.
v2: clear "parent" and "next" in the caller of add_child.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> (v1)
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> (v1)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
The options specified in the CLOVER_EXTRA_BUILD_OPTIONS shell
variable are appended to the options specified by the OpenCL program
in the clBuildProgram function call, if any.
Analogously, the options specified in the CLOVER_EXTRA_COMPILE_OPTIONS
and CLOVER_EXTRA_LINK_OPTIONS variables are appended to the options
specified in clCompileProgram and clLinkProgram function calls,
respectively.
v2:
* rename to CLOVER_EXTRA_COMPILER_OPTIONS
* use debug_get_option
* append to linker options as well
v3: code cleanups
v4: separate CLOVER_EXTRA_LINKER_OPTIONS options
v5:
* fix documentation typo
* use CLOVER_EXTRA_COMPILER_OPTIONS in link stage
v6:
* separate in CLOVER_EXTRA_{BUILD,COMPILE,LINK}_OPTIONS
* append options in cl{Build,Compile,Link}Program
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by[v1]: Edward O'Callaghan <funfunctor@folklore1984.net>
v7 [Francisco Jerez]: Slight simplification.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
OpenCL apps can quote arguments they pass to the OpenCL compiler, most
commonly include paths containing spaces.
If the Clang OpenCL compiler was called via a shell, the shell would
split the arguments with respect to to quotes and then remove quotes
before passing the arguments to the compiler. Since we call Clang as a
library, we have to split the argument with respect to quotes and then
remove quotes before passing the arguments.
v2: move to tokenize(), remove throwing of CL_INVALID_COMPILER_OPTIONS
v3: simplify parsing logic, use more C++11
v4: restore error throwing, clarify a comment
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The address immediate field is only 9 bits and, since the value is in
bytes, the highest GRF we can point to with it is g15. This makes it
pretty close to useless for MOV_INDIRECT. There were already piles of
restrictions preventing us from using it prior to Broadwell, so let's get
rid of the gen8+ code path entirely.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97779
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Commit 66fcfa6894 changed the vec4 version of offset() to have 3
parameters instead of 2 but the vec4_cmod_propagation test was never
updated.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
When blending with GL_COLORBURN_KHR and these colors:
dst = <0.372549027, 0.372549027, 0.372549027, 0.372549027>
src = <0.09375, 0.046875, 0.0, 0.375>
the normalized dst value became 0.99999994 (due to precision problems
in the floating point divide of rgb by alpha). This caused the color
burn equation to fail the dst >= 1.0 comparison. The blue channel would
then fall through to the dst < 1.0 && src >= 0 comparison, which was
true, since src.b == 0. This produced a factor of 0.0 instead of 1.0.
This is an inherent numerical instability in the color burn and dodge
equations - depending on the precision of alpha scaling, the value can
be either 0.0 or 1.0. Technically, GLSL floating point division doesn't
even guarantee that 0.372549027 / 0.372549027 = 1.0. So arguably, the
CTS should allow either value. I've filed a bug at Khronos for further
discussion (linked below).
In the meantime, this patch improves the precision of alpha scaling by
replacing the division with (rgb == alpha ? 1.0 : rgb / alpha). We may
not need this long term, but for now, it fixes the following CTS tests:
ES31-CTS.blend_equation_advanced.blend_specific.GL_COLORBURN_KHR
ES31-CTS.blend_equation_advanced.blend_all.GL_COLORBURN_KHR_all_qualifier
Cc: currojerez@riseup.net
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16042
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The term "client array" is a legacy thing dating back to the pre-VBO
era when _all_ vertex arrays lived in client memory.
Nowadays, it only contains vertex array state which is derived from
gl_array_attributes and gl_vertex_buffer_binding. It's used by the
VBO module and some drivers.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This patch simplifies x11_surface_get_formats(). It is actually just a
readability improvement over the patch I provided earlier this week
(750d8cad72).
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
x11_surface_get_present_modes() is currently asserting that the number of
elements in pPresentModeCount must be greater than or equal to the number
of present modes available. This is buggy because pPresentModeCount
elements are later copied from the internal modes' array, so if
pPresentModeCount is greater, it will overflow it.
On top of that, this assertion violates the spec. From the Vulkan 1.0
(revision 32, with KHR extensions), page 581 of the PDF:
"If the value of pPresentModeCount is less than the number of
presentation modes supported, at most pPresentModeCount values will be
written. If pPresentModeCount is smaller than the number of
presentation modes supported for the given surface, VK_INCOMPLETE
will be returned instead of VK_SUCCESS to indicate that not all the
available values were returned."
So, the correct behavior is: if pPresentModeCount is greater than the
internal number of formats, it is clamped to that many present modes. But
if it is lesser than that, then pPresentModeCount elements are copied,
and the call returns VK_INCOMPLETE.
This fix is similar (but simpler and more readable) than the one I provided
in 750d8cad72 for vkGetPhysicalDeviceSurfaceFormatsKHR, which was suffering
from the same problem.
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
An assert is currently raised, preventing decompression of a texture image into
a GL_TEXTURE_3D target. I have not found any spec wording that would explain
this, or implementation detail that would prevent it. And in any case, the
driver should not cause a crash upon user input arguments.
Fixes most failing subcases in CTS tests:
* GL44-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
* GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
These tests were crashing the driver before. Now they just fail, but due
to an unrelated issue affecting 2 out of the 45 test subcases.
No regressions observed against piglit or CTS-GL.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we were creating the shader with a NULL ralloc context and then
trusting in blorp_compile_fs to clean it up. The only problem was that
blorp_compile_fs didn't clean up its context properly so we were leaking.
When I went to fix that, I realized that it couldn't because it has to
return the shader binary which is allocated off of that context and used by
the caller. The solution is to make blorp_compile_fs take a ralloc
context, allocate the nir_shaders directly off that context, and clean it
all up in whatever function creates the shader and calls blorp_compile_fs.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "12.0, 13.0" <mesa-stable@lists.freedesktop.org>
Advertise two device local memory heaps; one that is host visible
and one that is not.
This makes it possible for clients to tell how much host visible
vs. non-host visible memory is available.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add the new memory type between the two device-local types. This makes
the list of supported memory types look like this:
1) DEVICE_LOCAL | | |
2) | HOST_VISIBLE | HOST_COHERENT |
3) DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT |
4) | HOST_VISIBLE | HOST_COHERENT | HOST_CACHED
With this order a client that searches for a HOST_VISIBLE and
HOST_COHERENT memory type using the algorithm described in section
10.2 of the Vulkan specification (revision 32) will find the host-
local memory type first.
A client that requires the memory type to be HOST_VISIBLE and
HOST_COHERENT, but not DEVICE_LOCAL is most likely searching for
a memory type suitable for staging buffers / images.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These restrictions existed because intel_miptree_blit couldn't handle
surfaces bigger than 32k. How that we're chopping blits up into chunks, it
can handle any size we throw at it so we can get rid of this restriction.
This improves the terrain tests in synmark by 25-30% on my Sky Lake gt3.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reported-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This allows us to blit much larger images than if we use the blitter
directly. In particular, it gives us an almost infinite image height
compared to the fairly limiting 32k. We do, however, still have a
restriction on stride of the image because handling larger strides, while
possible, is fairly difficult.
v2: Properly handle linear blit alignment restrictions
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This assertion, while valid for linear buffers, doesn't work properly for
tiled memory. It used to work most of the time because the offset provided
was always to the left-hand edge of the image. However, if you use a byte
offset to get to the inside of the image, the height * stride calculation
may actually end up being too large.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The only actual user of this parameter was blorp and, since the conversion
to ISL, it no longer uses this function.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
With dealing with rectangles in compressed images, you can have a width or
height that isn't a multiple of the corresponding compression block
dimension but only if that edge of your rectangle is on the edge of the
image. When we call convert_to_single_slice, it creates an 2-D image and a
set of tile offsets into that image. When detecting the right-edge and
bottom-edge cases, we weren't including the tile offsets so the assert
would misfire. This caused crashes in a few UE4 demos
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reported-by: "Eero Tamminen" <eero.t.tamminen@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98431
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Tested-by: "Eero Tamminen" <eero.t.tamminen@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
When checking if a type contains doubles, integers, samples, etc. we
check if the current type is a record or array, but not if it is an
interface.
This commit also inspects if the type is an interface.
It fixes spec/arb_enhanced_layouts/compiler/transform-feedback-layout-qualifiers/xfb_offset/invalid-block-with-double.vert
piglit test.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
So that it has the same semantics as the scalar backend implementation. The
helper will now take a simd width (which is always 8 in vec4 mode) and step
as many scalar components as specified by that width, respecting the size of
the scalar channels.
v2 (Curro):
- Remove the assertion in offset(), byte_offset() has the same checks.
- Use byte_offset() directly instead of add_byte_offset().
- Make things more clear by explicitly including the vertical stride
in the byte offset expression.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
In a later patch we want to change the semantics of offset() to be in terms
of SIMD width and scalar channels so it is consistent with the definition
of the same helper in the scalar backend. However, some uses of offset()
in the vec4 backend do not operate naturally in terms of these
semantics. In these cases it is more natural to use the byte_offset() helper
instead.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
v2: wrap the helper in a namespace to make clear that it is an
implementation detail of byte_offset() and is not intended
to be used independently (Curro).
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
SSO validation and other program interface queries want to see that
unsized (non-patch) TCS output/TES input arrays are implicitly sized
to gl_MaxPatchVertices.
By the time we create the program resource lists, we've sized the arrays
to their actual size. (We try to create TCS output arrays to match the
output patch size right away, and at this point, we should have shrunk
TES input arrays.) One option would be to keep them sized to
gl_MaxPatchVertices, and defer shrinking them. But that's a big change,
and I don't think it's a good idea.
Instead, this patch introduces a new ir_variable flag which indicates
the variable is implicitly to gl_MaxPatchVertices. Then, the linker
munges the types when creating the resource list, ignoring the size
in the IR's types. Basically, lie about it for resource queries.
It's ugly, but I think it ought to work.
We probably could use var->data.implicit_sized_array for this, but
I opted for a separate bit to try and avoid convoluting the existing
SSBO handling. They're similar in concept, but share none of the
same code...
Fixes:
ES31-CTS.core.tessellation_shader.single.xfb_captures_data_from_correct_stage
and the ES32-CTS and ESEXT-CTS variants.
v2: Add a comment (requested by Timothy, written by me).
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
We shouldn't be using ASYNC here, that would be used
for immediate mode, so let's implement that.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just moves this up a level as x11 will need it to
implement things properly.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For 0 timeout, just poll for an event, and if none, return
For UINT64_MAX timeout, just wait for special event blocked
For other timeouts get the xcb fd and block on it, decreasing
the timeout if we get woken up for non-special events.
v1.1: return VK_TIMEOUT for poll timeouts.
handle timeout going negative.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes the following compile error, present when the SHA1 library is libgcrypt:
CCLD glsl/tests/cache-test
glsl/.libs/libglsl.a(libmesautil_la-mesa-sha1.o): In function `call_once':
/mesa/src/util/../../include/c11/threads_posix.h:96: undefined reference to `pthread_once'
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This affects GF100:GK110 chipsets, but not GM107+ where the
logic is a bit different. The emitters tried to emit sub
instead of subr when src0 has a NEG modifier.
This fixes the following piglit tests glsl-fs-loop-nested
and glsl-vs-loop-nested.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
PYTHON_GEN is defined to the exact same thing in both
Makefile.glsl.am and Makefile.nir.am. This makes automake complain,
so let's lift the definition up to Makefile.am, the same way as
MKDIR_GEN.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Tested-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Since commit 0a606a400f ("egl: add eglSwapBuffersWithDamageKHR"),
Android has been broken because the function eglSwapBuffersWithDamageKHR
is provided regardless of the extension being present. Also, the Android
meta-EGL always advertises the extension regardless of the underlying
EGL implementation. As there doesn't seem to be a simple way
conditionally make the EGL function ptr NULL, just implement a brain
dead version of eglSwapBuffersWithDamage{KHR,EXT}.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
CC: Rob Clark <robdclark@gmail.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Rob Herring <robh@kernel.org>
[Emil Velikov: copy the original commit message from Rob's patch]
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Otherwise it'll be missing from the tarball.
Fixes: 094fe3a959 ("nir: move nir_shader_info to a common compiler header")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
GCN can use a completely different tile mode for FMASK.
FMASK allocation now skips one unrelated amdgpu_surface_init codepath as
hinted by the assertion.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
I expect no change in behavior, because r600_texture.c forces the same
tile mode as the base texture has.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
These just say whether libdrm can assume that the latest radeon_surface
definition is used by Mesa.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This removes input-only parameters from the radeon_surf structure.
Some of the translation logic from pipe_resource to radeon_surf is moved to
winsys/radeon.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
npix_y will be removed. level[0].npix_y will be removed too. nblk_y should
be the same as npix_y if the block height == 1. However, nblk_y is aligned
to the tile size, so it can be greater than npix_y.
If that's a problem, we'll have to save the input height of surface_init
and use that.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Maybe this is why SDMA has been broken for many amdgpu users?
SDMA is the only block which is used with imported textures and relies
on this variable. DB also uses it, but it doesn't get imported textures,
so it's unaffected.
I do get SDMA failures on Tonga before this patch if R600_DEBUG=testdma
is changed to use imported textures.
Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Default precision qualifier for a data type could be set several times
inside a shader. This patch allows to update the default precision
qualifier for the given type that is saved in the symbol table.
If it is not in the symbol table, just add it.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97804
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This function allows to modify an existing symbol.
v2:
- Remove namespace usage now that it was deleted.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
As of 59864e8e02 we just use the location assigned by the front-end and
no longer need this for i965.
Since there were some issues in the logic with assigning arrays the same
driver location if they didn't start at the same location just remove it
and let other drivers implement a solution if needed when they add
ARB_enhanced_layouts support.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This temporary helper is no longer needed now that we have finished
refactoring common shader metadata.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And set system values read directly in shader_info.
st/mesa changes where:
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And set outputs written directly in shader_info.
st/mesa changes where:
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And set set inputs_read directly in shader_info.
To avoid regressions between changes this change is a squashed
version of the following patches.
st/mesa changes where:
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Here we move OriginUpperLeft and PixelCenterInteger into gl_program
all other fields have been replace by shader_info.
V2: Don't use anonymous union/structs to hold vertex/fragment fields
suggested by Ian.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Note we access shader_info from the program struct rather than the
nir_shader pointer because shader cache won't create a nir_shader.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Rather then messing around creating bitfields and arrays to store
the interpolation location just translate it on the fly.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This was accidently disabled in 832bcc3613 not long after it was added.
Since it's only for gen5 and lower we might as well just remove it rather
than fixing it.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Here brw_setup_vue_interpolation() is rewritten not to use the InterpQualifier
array in gl_fragment_program which will allow us to remove it.
This change also makes the code which is only used by gen4/5 more self contained
as it now has its own gen5_fragment_program struct rather than storing the map
in brw_context. This means the interpolation map will only get processed once
and will get stored in the in memory cache rather than being processed everytime
the fs changes.
Also by calling this from the fs compile code rather than from the upload code
and using the interpolation assigned there we can get rid of the
BRW_NEW_INTERPOLATION_MAP flag.
It might not seem ideal to add a gen5_fragment_program struct however by the end
of this series we will have gotten rid of all the brw_{shader_stage}_program
structs and replaced them with a generic brw_program struct so there will only
be two program structs which is better than what we have now.
V2: Don't remove BRW_NEW_INTERPOLATION_MAP from dirty_bit_map until the following
patch to fix build error.
V3 - Suggestions by Jason:
- name struct gen4_fragment_program rather than gen5_fragment_program
- don't use enum with memset()
- create interp mode set helper and simplify logic to call it
- add assert when calling function to show prog will never be NULL for
gen4/5 i.e. no Vulkan
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
A following patch is going to merge the gl_fragment_program struct into
a common gl_program and we want to avoid all stages having this array.
V2: use TGSI_INTERPOLATE_COUNT as the temporary placeholder. Suggested by
Marek.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Note we access shader_info from the program struct rather than the
nir_shader pointer because shader cache won't create a nir_shader.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Note we access shader_info from the program struct rather than the
nir_shader pointer because shader cache won't create a nir_shader.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Note we access shader_info from the program struct rather than the
nir_shader pointer because shader cache won't create a nir_shader.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Note we access shader_info from the program struct rather than the
nir_shader pointer because shader cache won't create a nir_shader.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This function is added here to ease refactoring towards using the new shared
shader_info. Once refactoring is complete and values are set directly it
will be removed.
We call it from _mesa_copy_linked_program_data() rather than glsl_to_nir()
so that the values will be set for all drivers. In order to do this some
calls need to be moved around so that we make sure to call
do_set_program_inouts() before _mesa_copy_linked_program_data()
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And use this field as the source for shader info in the nir_shader
this will allow us to set some of these fields from GLSL directly.
It will also simplify restoring from shader cache and allow the
removal of duplicate fields from GLSL.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When restoring something from shader cache we won't have and don't
want to create a nir_shader this change detaches the two.
There are other advantages such as being able to reuse the
shader info populated by GLSL IR.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This will allow use to stop copying values between structs and
will also simplify handling handling these values in the shader cache.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This allows us to do some small tidy ups, but will also allow us to call
a new function that copies values to a shared shader info from here.
In order to make this change this function now requires
_mesa_reference_program() to have previously been called.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Use an ARGB format for the DRM buffer when the compositeAlpha field
in VkSwapchainCreateInfoKHR is set to
VK_COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pass the correct depth to xcb_dri3_pixmap_from_buffer_checked().
Otherwise xcb_present_pixmap() fails with a BadMatch error.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
configure.ac already requires 2.4.66.
Fix SCons build. drmDevicePtr is not available until libdrm 2.4.65.
Compiling src/loader/loader.c ...
src/loader/loader.c:111:40: error: unknown type name ‘drmDevicePtr’
static char *drm_construct_id_path_tag(drmDevicePtr device)
^
Fixes: 4a183f4d06 ("scons: loader: use libdrm when available")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98421
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Vedran Miletić <vedran@miletic.net>
total instructions in shared programs : 3499888 -> 3499445 (-0.01%)
total gprs used in shared programs : 453866 -> 453803 (-0.01%)
total local used in shared programs : 21621 -> 21621 (0.00%)
total bytes used in shared programs : 32078952 -> 32074936 (-0.01%)
local gpr inst bytes
helped 0 39 119 119
hurt 0 0 0 0
Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
x11_surface_get_formats() is currently asserting that the number of
elements in pSurfaceFormats must be greater than or equal to the number
of formats available. This is buggy because pSurfaceFormatsCount
elements are later copied from the internal formats' array, so if
pSurfaceFormatCount is greater, it will overflow it.
On top of that, this assertion violates the spec. From the Vulkan 1.0
(revision 32, with KHR extensions), page 579 of the PDF:
"If pSurfaceFormats is NULL, then the number of format pairs supported
for the given surface is returned in pSurfaceFormatCount. Otherwise,
pSurfaceFormatCount must point to a variable set by the user to the
number of elements in the pSurfaceFormats array, and on return the
variable is overwritten with the number of structures actually written
to pSurfaceFormats. If the value of pSurfaceFormatCount is less than
the number of format pairs supported, at most pSurfaceFormatCount
structures will be written. If pSurfaceFormatCount is smaller than
the number of format pairs supported for the given surface,
VK_INCOMPLETE will be returned instead of VK_SUCCESS to indicate that
not all the available values were returned."
So, the correct behavior is: if pSurfaceFormatCount is greater than the
internal number of formats, it is clamped to that many formats. But
if it is lesser than that, then pSurfaceFormatCount elements are copied,
and the call returns VK_INCOMPLETE.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Patch rearranges error checking so that enum checking provided via
destmask happens before other checks. It needs to be done in this
order because other error checks do not work properly if there were
invalid enums passed.
Patch also refines one existing check and it's documentation to match
GLES 3.0 spec (also in later specs). This was somewhat mysteriously
referring to desktop GL but had a check for gles3.
Fixes following dEQP tests:
dEQP-GLES31.functional.debug.negative_coverage.get_error.buffer.draw_buffers
no CI regressions observed.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98134
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
EGL spec defines EGL_BAD_MATCH for windows, pixmaps and pbuffers in
case where user creates a surface but config does not support rendering
to such surface type.
Following quotes are from EGL 1.5 spec 3.5 "Rendering Surfaces" :
for eglCreatePlatformWindowSurface, eglCreateWindowSurface:
"If config does not support rendering to windows (the EGL_SURFACE_TYPE
attribute does not contain EGL_WINDOW_BIT ), an EGL_BAD_MATCH error is
generated."
for eglCreatePbufferSurface:
"If config does not support pbuffers, an EGL_BAD_MATCH error is
generated."
for eglCreatePlatformPixmapSurface, eglCreatePixmapSurface:
"If config does not support rendering to pixmaps (the EGL_SURFACE_TYPE
attribute does not contain EGL_PIXMAP_BIT ), an EGL_BAD_MATCH error is
generated."
Fixes following dEQP test:
dEQP-EGL.functional.negative_api.create_pbuffer_surface
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
While these max values were previously fixed for pbuffer creation, this
change makes also eglGetConfigAttrib() return correct values.
Fixes following dEQP tests:
dEQP-EGL.functional.create_surface.pbuffer.rgb888_no_depth_no_stencil
dEQP-EGL.functional.create_surface.pbuffer.rgb888_depth_stencil
dEQP-EGL.functional.create_surface.pbuffer.rgba8888_no_depth_no_stencil
dEQP-EGL.functional.create_surface.pbuffer.rgba8888_depth_stencil
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98326
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Post-splitting, VGRFs have a maximum size (MAX_VGRF_SIZE). This is
required by the register allocator, as we have to create classes for
each size of VGRF.
We can (and do) allocate virtual registers larger than MAX_VGRF_SIZE,
but we must ensure that they are splittable. split_virtual_grfs()
asserts that the post-splitting register size is in range.
Unfortunately, these trip for completely dead registers which are too
large - we only set split points for live registers. So dead ones are
never split, and if they happened to be too large, they'd trip asserts.
To fix this, call compact_virtual_grfs() to eliminate dead registers
before splitting.
v2: Add a comment written by Iago.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Shared memory is local to CTA, thus we should only wait for
prior memory writes which are visible to other threads in
the same CTA, and not at global level. This should speedup
compute shaders which use shared memory.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
We are not sure exactly what needs to be 0 initialized,
but we are missing some cases. 0 initialize all our current
aligned allocation.
Fixes Tree of Savior visual issues.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Add implementation for align_calloc,
which is align_malloc + memset.
v2: add if (ptr) before memset.
Fix indentation.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Leak introduced by:
a83dce0128
The patch also moves the part to
release changed.vs_const_i and changed.vs_const_b
before the if (!cb.buffer_size) check,
to avoid reuploading every draw call if
integer or boolean constants are dirty, but the shaders
use no constants.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
CC: "13.0" <mesa-stable@lists.freedesktop.org>
We follow this rule at multiple places in i965 driver. This patch
doesn't fix any testcase.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
So far we have been checking that interface block definitions had matching
matrix layouts by comparing the definitions of their fields, however, this
does not cover the case where the interface blocks are defined with
mismatching matrix layouts but don't define any field with a matrix type.
In this case Mesa will not fail to link because none of the fields will
inherit the mismatching layout qualifier.
This patch fixes the problem in the same way we fixed it for packing layout
information: we add the the layout information to the interface type and then
we check it matches during the uniform block linking process.
v2: Fix unit tests so they pass the new parameter to
glsl_type::get_interface_instance()
Fixes:
dEQP-GLES31.functional.shaders.linkage.uniform.block.layout_qualifier_mismatch_3
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98245
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
There are three intended functional changes here:
1. OpenGL 4.5 clarifies that primitive restart should only apply with index
buffers, so make that change explicit in the indirect draw path.
2. Make PrimitiveRestartFixedIndex work with indirect draws.
3. The change where primitive_restart is only set when the restart index can
actually have an effect (based on the size of indices) is also applied for
indirect draws.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Namespace support seems to have been unused for a very long time.
Previously the hash table entry was never removed and the symbol name
wasn't freed until the symbol table was destroyed.
In theory this could reduced the number of times we need to copy a string
as duplicate names are reused. However in practice there is likely only a
limited number of symbols that are the same and this is likely to cause
other less than optimal behaviour such as the hash_table continuously
growing.
Along with dropping namespace support this change removes entries from
the hash table as they become unused.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
shared glapi was previously built without setting CFLAGS for
AM_CFLAGS and VISIBILITY_CFLAGS.
This resulted in symbols being exported that shouldn't be.
The x86 and sparc assembly versions of the dispatch table partially
mitigated this by using .hidden. Otherwise shared_dispatch_stub_*
were being exported.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: "11.2 12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
The original patch by Joanna added the function pointer and callback yet
things got only partially applied - the infra was added, but the
implementation was missing.
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Fixes: 690ead4a13 ("egl/wayland-egl: Fix for segfault in
dri2_wl_destroy_surface.")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Earlier commit reworked the header install rules, to ensure that the
correct ones are installed only as needed.
By doing so it dropped a wildcard which was effectively including the
wglext.h header in the tarball.
Add the header to the top-level noinst_HEADERS, since the it is not
meant to be installed (autoconf is not used on Windows plaforms).
Fixes: a89faa2022 ("autoconf: Make header install distinct for various
APIs (v2)")
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Cc: Chuck Atkins <chuck.atkins@kitware.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
It is specific only to GLSL ES 3.1. From the spec, section 4.3.9
"Interface Blocks":
"Matched block names within a shader interface (as defined above) must
match in terms of having the same number of declarations with the same
sequence of types and the same sequence of member names, as well as
having the same qualification as specified in section 9.2 (“Matching
of Qualifiers“)."
But in GLSL ES 3.0 and 3.2, it is the opposite:
"Matched block names within a shader interface (as defined above) must
match in terms of having the same number of declarations with the same
sequence of types, precisions and the same sequence of member names,
as well as having the matching member-wise layout qualification as
defined in section 9.2 (“Matching of Qualifiers”)."
Fixes:
dEQP-GLES31.functional.shaders.linkage.uniform.block.differing_precision
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98243
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
This fixes
dEQP-VK.pipeline.multisample.sampled_image*
These all render to multisampled image, and then
sample from it, so we must transition it correctly,
since we have a cmask and fmask this will cause
the correct transition.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeonsi also does the same thing. I suspect that this is likely to be a
no-op in reality, but it brings nouveau code closer to what the blob
produces. Plus it makes sense to not try to do auto-derivatives on this.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This allows the driver to signal that it can't handle random
interleaving of attributes across buffers. This is required for
ARB_transform_feedback3, and it's initialized to whatever the previous
value of PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME was except for nv50 where
it is disabled. Note that the proprietary drivers never expose
ARB_transform_feedback3 on any GT21x's (where nouveau previously did),
and after some effort I was unable to get it to work.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Getting stores to NIR regs to not generate new MOVs is tricky, since the
result we're trying to store into the NIR reg may have been from a
conditional update of a temp, or a series of packed writes. The easiest
solution seems to be to require that nir_store_dest()'s arg comes from an
SSA temp.
This causes us to put in a few more temporary MOVs in the NIR SSA dest
case, but copy propagation successfully cleans those up.
The shader-db change is modest:
total instructions in shared programs: 93774 -> 93598 (-0.19%)
instructions in affected programs: 14760 -> 14584 (-1.19%)
total estimated cycles in shared programs: 212135 -> 211946 (-0.09%)
estimated cycles in affected programs: 27005 -> 26816 (-0.70%)
but I was seeing patterns in some register-allocation failures in DEQP
tests that looked like the extra MOVs would increase maximum register
pressure in loops. Some debug code indicates that that's not the case,
though I'm still a bit confused by that result.
Now we aren't limited to 256MB total allocated across a driver instance,
just 256MB at one time. We're still copying in and out, which should get
fixed.
Rather than having simulator mode changes scattered around vc4_bufmgr.c
and vc4_screen.c, make vc4_bufmgr.c just call a vc4_simulator_ioctl, which
then dispatches to a corresponding implementation.
This will give the simulator support a centralized place to do tricks like
storing most BOs directly in simulator memory rather than copying in and
out.
This leaves special casing of mmaping BOs and execution, because of the
winsys mapping.
The loop is scanning until the original max_ip (size of the BO), but we
want to not examine any code after the PROG_END's delay slots. There was
a block trying to do that, except that we had some early continue
statements if the signal wasn't a PROG_END or a BRANCH.
The failure mode would be that a valid shader is rejected because some
undefined memory after the PROG_END slots is parsed as a branch and the
rest of its setup is illegal. I haven't seen this in the wild, but
valgrind was complaining and the new userland simulator code started
triggering it.
Vulkan has a multi-arch problem... The idea behind the Vulkan loader is
that you have a little json file on your disk that tells the loader where
to find drivers. The loader looks for these json files in standard
locations, and then goes and loads the my_driver.so's that they specify.
This allows you as a driver implementer to put their driver wherever on the
disk they want so long as the ICD points in the right place.
For a multi-arch system, however, you may have multiple libvulkan_intel.so
files installed that the loader needs to pick depending on architecture.
Since the ICD file format does not specify any architecture information,
you can't tell the loader where to find the 32-bit version vs. the 64-bit
version. The way that packagers have been dealing with this is to place
libvulkan_intel.so in the top level lib directory and provide just a name
(and no path) to the loader. It will then use the regular system search
paths and find the correct driver. While this solution works fine for
distro-installed Vulkan drivers, it doesn't work so well for user-installed
drivers because they may put it in /opt or $HOME/.local or some other more
exotic location. In this case, you can't use an ICD json file with just a
library name because it doesn't know where to find it; you also have to add
that to your library lookup path via LD_LIBRARY_PATH or similar.
This patch handles both use-cases by taking advantage of the fact that the
loader dlopen()s each of the drivers and, if one dlopen() calls fails, it
silently continues on to open other drivers. By suffixing the icd file, we
can provide two different json files: intel_icd.x86_64.json and
intel_icd.i686.json with different paths. Since dlopen() will only succeed
on the libvulkan_intel.so of the right arch, the loader will happily ignore
the others and load that one. This allows us to properly handle multi-arch
while still providing a full path so user installs will work fine.
I tested this on my Fedora 25 machine with 32 and 64-bit builds of our
Vulkan driver installed and 32 and 64-bit builds of crucible. It seems to
work just fine.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
A constant value of float type is not necessarily a ConstantFP: it could also
be a constant expression that for some reason hasn't been folded.
This fixes a regression in GL45-CTS.arrays_of_arrays_gl.InteractionFunctionCalls2
that was introduced by commit 3ec9975555.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
These two GLES 3.2 entry points were being defined in the category of
the ARB_ES3_2_compatibility and KHR_blend_equation_advanced extensions
respectively instead of in the ES3.2 category. Defining them in the
ES3.2 category makes sure that the gl_procs.py generator emits
declarations in the glprocs.h header file for the unsuffixed GLES-only
entry points that PrimitiveBoundingBoxARB and BlendBarrierKHR
respectively alias. This should avoid a compilation failure during
scons builds in combination with "mapi: export all GLES 3.2 functions
in libGLESv2.so".
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Fix build error with clang.
Compiling src/compiler/glsl/link_varyings.cpp ...
In file included from src/compiler/glsl/link_varyings.cpp:33:
In file included from src/compiler/glsl/glsl_symbol_table.h:34:
In file included from src/compiler/glsl/ir.h:33:
In file included from src/compiler/glsl_types.h:29:
/usr/include/string.h:518:12: error: exception specification in declaration does not match previous declaration
extern int ffs (int __i) __THROW __attribute__ ((__const__));
^
src/util/bitscan.h:51:13: note: expanded from macro 'ffs'
^
src/util/bitscan.h:96:18: note: previous declaration is here
const int i = ffs(*mask) - 1;
^
src/util/bitscan.h:51:13: note: expanded from macro 'ffs'
^
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97952
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Long story short, 3D and CP are aliased on Fermi and initializing
compute after pushing the MS sample coordinate offsets seems to
corrupt 3D state for weird reasons.
I still don't have the faintest clue what is going on, but
this seems to only affect Fermi generation. A possible fix
could be to use two different channels, one for 3D and one
for CP.
This fixes a bunch of regressions pinpointed by piglit.
Fixes: "nvc0: fix up image support for allowing multiple samples"
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
If the attribute type is changing, we would have found that earlier in
the ATTR_UNION() macro and would have called vbo_exec_fixup_vertex().
So move the assignment into that function so we don't do it every time.
No Piglit regressions.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Even when enabled, primitive restart has no effect when the restart index
is larger than the representable values in the index buffer.
Fixes GL45-CTS.gtf31.GL3Tests.primitive_restart.primitive_restart_upconvert
for radeonsi VI.
v2: add an explanatory comment
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Use a full writemask in this case. This is relevant e.g. when a function
has an inout argument which is an array of structs.
v2: use C-style comment (Timothy Arceri)
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Set the type of the left-hand side to the same as the right-hand side,
so that when the base type is double, the writemask of the MOV instruction
is properly fixed up.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
After the changes in comit 5b2675093e, we moved this check to the
linker, but the spec expects this to be checked at compile-time. There are
dEQP tests that expect an error at compile time and the spec seems to confirm
that expectation:
"Except for the last declared member of a shader storage block (section 4.3.9
“Interface Blocks”), the size of an array must be declared (explicitly sized)
before it is indexed with anything other than an integral constant expression.
The size of any array must be declared before passing it as an argument to a
function. Violation of any of these rules result in compile-time errors. It
is legal to declare an array without a size (unsized) and then later
redeclare the same name as an array of the same type and specify a size, or
index it only with integral constant expressions (implicitly sized)."
Commit 5b2675093e tries to take care of the case where we have implicitly
sized arrays in SSBOs and it does so by checking the max_array_access field
in ir_variable during linking. In this patch we change the approach: we look
for indirect access on SSBO arrays, and when we find one, we emit a
compile-time error if the accessed member is not the last in the SSBO
definition.
There is a corner case that the specs do not address directly though and that
dEQP checks for: the case of an unsized array in an SSBO definition that is
not defined last but is never used in the shader code either. The following
dEQP tests expect a compile-time error in this scenario:
dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader
However, since the unsized array is never used it is never indexed with a
non-constant expression, so by the spec quotation above, it should be valid and
the tests are probably incorrect.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
With ARB_gpu_shader5, texture offsets can be any source, including TEMPs
and IN's. Make sure to process them as regular sources so that we pick
up masks, etc.
This should fix some CTS tests that feed offsets directly to
textureGatherOffset, and we were not picking up the input use, thus not
advertising it in the shader header.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Dave Airlie <airlied@redhat.com>
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
On a debug llvm build we'd assert on the next compare
when the return from samples_identical was i1 instead
of i32.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When the local group size is 8 or less, we will execute the program at
most 1 time. Therefore, the local channel ID will always be 0. By
using a constant 0 in this case we can prevent using push constant
data.
This is not expected to be common a occurance in real applications,
but it has been seen in tests.
We could extend this optimization to 16 and 32 for SIMD16 and SIMD32,
but it gets a bit more complicated, because this optimization is
currently being done early on, before we have decided the SIMD size.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The predicate is always CC_NOT_P as defined in
processSurfaceCoordsNVE4(), so we only want to emit OR.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The previous power-of-two rules didn't catch idiv (because i965 doesn't
set lower_idiv) and imod cases. The udiv and umod cases should have
been caught, but I included them for orthogonality.
This fixes silly code observed from compute shaders with local_size_[xy]
= 1.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98299
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
since GBM is enabled by default, this is also enabled by default
the whitespace changes remove tabs
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
These constant value VS PARAM exports:
- 0,0,0,0
- 0,0,0,1
- 1,1,1,0
- 1,1,1,1
can be loaded into PS inputs using the DEFAULT_VAL field, and the VS exports
can be removed from the IR to save export & parameter memory.
After LLVM optimizations, analyze the IR to see which exports are equal to
the ones listed above (or undef) and remove them if they are.
Targeted use cases:
- All DX9 eON ports always clear 10 VS outputs to 0.0 even if most of them
are unused by PS (such as Witcher 2 below).
- VS output arrays with unused elements that the GLSL compiler can't
eliminate (such as Batman below).
The shader-db deltas are quite interesting:
(not from upstream si-report.py, it won't be upstreamed)
PERCENTAGE DELTAS Shaders PARAM exports (affected only)
batman_arkham_origins 589 -67.17 %
bioshock-infinite 1769 -0.47 %
dirt-showdown 548 -2.68 %
dota2 1747 -3.36 %
f1-2015 776 -4.94 %
left_4_dead_2 1762 -0.07 %
metro_2033_redux 2670 -0.43 %
portal 474 -0.22 %
talos_principle 324 -3.63 %
warsow 176 -2.20 %
witcher2 1040 -73.78 %
----------------------------------------
All affected 991 -65.37 % ... 9681 -> 3353
----------------------------------------
Total 26725 -10.82 % ... 58490 -> 52162
v2: treat Undef as both 0 and 1
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> (v1)
Found that information message while replaying a trace from
Metro 2033 Redux. Mark that property as useless for now.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Never used. The GLSL compiler doesn't even look at EmitNoFunctions.
v2: add back "return" support in "main"
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
I noticed that glsl_to_tgsi_instruction is too huge.
sizeof(glsl_to_tgsi_instruction): 752 -> 464 (-38%)
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Earlier commit replaced the default platform specific libglapi.so name
with an #error.
This may have been overzealous since the name is the correct for the BSD
platforms, at least. Reinstate the hunk - bringing back OpenBSD, et al.
to a successful build state.
Fixes: 7a9c92d071 ("egl/dri2: non-shared glapi cleanups")
[Emil Velikov: format the patch from Eric, add commit message and tag.]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Before we can read the fmask using the compute shader, we need
to decompress the fmask in place.
This fixes a bunch of remaining failure and hopefully multisampling
in Talos.
This adds some comments and adds defines for the user sgprs,
so that we can move them around easier later and not have
to change/revalidate every one of these.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This drops all the radv WSI code in favour of using
the new shared code that was ported from anv
This regresses Talos for now, Jason has pointed out
the bug is in Talos and we should wait for them to fix it.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This moves the shared code to a common subdirectory
and makes anv linked to that code instead of the copy
it was using.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The per-element fetch has quite some calculations which are constant,
these can be moved outside both the per-element as well as the main
shader loop (llvm can figure out it's constant mostly on its own, however
this can have a significant compile time cost).
Similarly, it looks easier swapping the fetch loops (outer loop per attrib,
inner loop filling up the per vertex elements - this way the aos->soa
conversion also can be done per attrib and not just at the end though again
this doesn't really make much of a difference in the generated code). (This
would also make it possible to vectorize the calculations leading to the
fetches.)
There's also some minimal change simplifying the overflow math slightly.
All in all, the generated code seems to look slightly simpler (depending
on the actual vs), but more importantly I've seen a significant reduction
in compile times for some vs (albeit with old (3.3) llvm version, and the
time reduction is only really for the optimizations run on the IR).
v2: adapt to other draw change.
No changes with piglit.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Previous attempts to zero initialize all inputs were not really optimal
(though no performance impact was measurable). In fact this is not really
necessary, since we know the max number of inputs used.
Instead, just generate fetch for up to max inputs used by the shader,
directly replacing inputs for which there was no vertex element by zero.
This also cleans up key generation, which previously would have stored
some garbage for these elements.
And also drop the assertion which indicates such bogus usage by a
debug_printf (the whole point of initializing the undefined inputs was to
make this case safe to handle).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Compilation to actual machine code can easily take as much time as the
optimization passes on the IR if not more, so print this out too.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
For the texturing packs, things looked pretty terrible. For every
lerp, we were repacking the values, and while those look sort of cheap
with 128bit, with 256bit we end up with 2 of them instead of just 1 but
worse, plus 2 extracts too (the unpack, however, works fine with a
single instruction, albeit only with llvm 3.8 - the vpmovzxbw).
Ideally we'd use more clever pack for llvmpipe backend conversion too
since we actually use the "wrong" shuffle (which is more work) when doing
the fs twiddle just so we end up with the wrong order for being able to
do native pack when converting from 2x8f -> 1x16b. But this requires some
refactoring, since the untwiddle is separate from conversion.
This is only used for avx2 256bit pack/unpack for now.
Improves openarena scores by 8% or so, though overall it's still pretty
disappointing how much faster 256bit vectors are even with avx2 (or
rather, aren't...). And, of course, eliminating the needless
packs/unpacks in the first place would eliminate most of that advantage
(not quite all) from this patch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This moves to the shared vk_alloc inlines for vulkan
memory allocations.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This moves all the alloc/free in anv to the generic helpers.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
vulkan allocation allows for overriding the allocator used,
add some macros for anv/radv to share for this.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This removes the vector code from radv in favour of sharing
code with anv.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just removes the anv vector code and uses the new helper.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
During dual instance encoding submission, if the second encode task and first
encode task have no reference dependency, e.g. p following with idr-frame,
there is a chance the second task will use for its reconstructed picture
buffer the same buffer used by first task for its reference/reconstructed
picture. In this case, buffer corruption may occur depending on encoding
speed. Fix is to force flush these two tasks separately to avoid race condition
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98005
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Since commit 63c5d5c6c4, the surfaceless
platform has allowed creation of pbuffer surfaces. But the vtable entry
for eglSwapBuffers has remained NULL.
Discovered by running a little pbuffer test.
Cc: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Add mesa_glinterop.h to the list of headers that will get included
in the distfile as it is required to build Mesa itself.
Corrects a regression introduced in a89faa2022.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
% pattern rules are a GNU extension. Convert the use of one to a
inference rule to allow this to build on OpenBSD.
This is a related change to the one made in
e3d43dc5ea
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Rather than having 4-5 places which do the explicit check/message just
polish the gallium helper and use it everywhere.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Previously it was used to differentiate between the different codepaths
in the loader. Although strictly speaking the (core) of the loader is
only used when a hardware device is available. The latter of which in
itself requires libdrm (one of the codepaths available).
That said, all the configure toggles which relate to enabling/using hw
device should attribute and require libdrm, so there's no need to keep
this code around.
With this gallium_require_drm_loader becomes an empty stub, so nuke that
one as well.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
With previous patches nearly all the original code (as seen in the
various loaders) is gone.
Update the copyright/license section to reflect that.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reminiscent from the pre-loader days, were we had multiple instances of
the loader logic in separate places and one could build a "GALLIUM_ONLY"
version.
Since that is no longer the case and the loaders (glx/egl/gbm) do not
(and should not) require to know any classic/gallium specific we can
drop the argument and the related code.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Effectively everyone with actual hardware and/or requesting the
"device_name" requires a working libdrm. Thus they could/should already
be using the (now only) codepath.
Apart from the code simplification, we can slim down our configure.ac
even further. But that will be done in separate patch(es).
Cc: Gary Wong <gtw@gnu.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The gbm_device_get_backend_name() provides an (somewhat) internal name
of the implementation/backend used. Is has nothing to do with the udev,
one cannot and should not attempt to derive the name from it.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Currently not everyone has libudev and with follow-up patches we'll
completely remove the divergent codepaths.
Use the libdrm drm device API to construct the required ID_PATH_TAG-like
string, to preserve the current functionality for libudev users and
allow others to benefit from it as well.
v2: Drop ranty comments, pick the correct device
v3: \n -> \0 in PCI_ID_PATH_TAG_LENGTH comment (Axel).
v4: Use snprintf (Nicolai)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Currently mesa has three code paths in the loader - libudev, manual
sysfs and drm ioctl one.
Considering the issues we had with libudev - strip those down in favour
of the libdrm drm device API. The latter can be implemented in any way
depending on the platform and can be reused by others.
v2: Use correct message on drmGetDevice failure. (Nicolai)
Cc: Jonathan Gray <jsg@jsg.id.au>
Cc: Jean-Sébastien Pédron <dumbbell@FreeBSD.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
With follow on work, we'll untangle and simplify all the different
codepaths in loader. Then again, we forget to set have_pci_id when
libdrm is present (one of the codepaths available).
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The indirect handle has to come right after the coordinates, so if there
was a sample/bias/depth compare/offset, everything would end up being
shifted by one argument position.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
As specified in va.h, default value should be set on attributes
not present in the input list.
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
dEQP-GLES31.functional.geometry_shading.instanced.geometry_1_invocations
draws using a geometry shader that specifies
layout(points, invocations = 1) in;
and then uses gl_InvocationID. According to the Haswell PRM, the
"GS Instance ID 0" (and 1) thread payload fields are undefined in
dual object mode:
"If 'dispatch mode' is DUAL_OBJECT this field is not valid."
But there's no point in using them - if there's only one invocation,
the ID will be 0. So just load a constant.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
All code that would have once called this can now call the gen-specific
version. The switching version is no longer needed.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
It really should have gone here all along. We were trying a bit too hard
to make it gen-agnostic just because it didn't have any #if's.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
With one small genxml change, the two versions were basically identical.
The only differences were one #define for HSW+ and a field that is missing
on Haswell but exists everywhere else.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
vkBeginCommandBuffer and vkCmdExecuteCommands both call into the
gen-specific emit_state_base_address function and vkEndCommandBuffer
belongs with begin.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This has two primary advantages. First, it means that the batch_chain code
knows less about the actual command buffer contents which is good because
improves separation. Second, it means that it only gets re-emitted once
after all of the secondaries instead of once after each secondary which is
just wasteful. It also has the advantage of cleaning the code up a bit.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
V2. add i965/hsw+ to list
V3. rebased on master.
V4. 'DONE' -> 'DONE ()'.
V5. remove i965/hsw+ from list :/
Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Once upon a time, this was used to extract prototypes from the shader
containing GLSL built-in functions. This was removed by f5692f45 in
November 2010 for Mesa 7.10.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
This makes the stream of commands a bit easier to read.
v2 (Ken): Use bold text on green headers for easier readability;
swap the green and blue headers so the majority stay blue.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
The corresponding opcodes for integers need to be treated the same as F2D.
Fixes GL45-CTS.gpu_shader_fp64.conversions.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When more than one atomic counter buffer is in use, UniformStorage[n].opaque
is set up to contain indices that are contiguous across all used buffers.
This appears to be used by i965 via NIR, but for TGSI we do not treat atomic
counter buffers as opaque, so using the data in the opaque array is incorrect.
Fixes GL45-CTS.compute_shader.resource-atomic-counter.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Properly handle the case where there is a gap in the assigned output locations,
e.g. a fragment shader writes to color buffer 2 but not to color buffers 0 & 1.
Fixes GL45-CTS.gtf33.GL3Tests.explicit_attrib_location.explicit_attrib_location_pipeline.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Generally, we only check for the presence of compute shaders during
parsing when we find any language (like layout qualifiers) that are
specific to compute shaders, however, it is possible to define an
empty compute shader does not use any language specific to compute
shaders at all and we should fail the compilation anyway. dEQP checks
this.
This patch adds a check for compute shader availability after we have
parsed the source code. At this point we know the effective GLSL version
and also extensions enabled in the shader.
Fixes a subcase of the following dEQP tests:
dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader
The tests still fail because there is one more subcase that fails that needs
another fix.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This was some kind of leftover in commit acd35c8 and format_count
array variable (declared in outer scope) should be used instead.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Fixes: acd35c8758 ("egl/android: tweak droid_add_configs_for_visuals()")
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Vulkan doesn't set these fields even though it doesn't use HiS.
HiS is disabled by programming DB_SRESULTS_COMPARE_STATEn to 0.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This has apparently never existed in GLSL ES.
Fixes dEQP-GLES3.functional.shaders.texture_functions.invalid
.textureoffset_sampler2darrayshadow_vec4_ivec2_vertex and
.textureoffset_sampler2darrayshadow_vec4_ivec2_fragment
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98244
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
DEQP's clear tests like to give us x + w < 0 or y + h < 0. Since we
were comparing to an unsigned, it would get promoted to unsigned and come
out as bignum >= width or height and we would clear the whole fb instead
of none of the fb.
Fixes 10 tests under deqp-gles2/functional/color_clear.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When !use_ib_bos, we can't easily chain ibs one to another. If the
required cs size grows over 1Mi - 8 dwords just fail the cs so that we
won't assert-fail in radv_amdgpu_winsys_cs_submit later on.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Several conformance tests violate this requirement:
ES31-CTS.core.tessellation_shader.max_patch_vertices
ES31-CTS.core.tessellation_shader.tessellation_control_to_tessellation_evaluation.data_pass_through
I submitted a merge request to fix the conformance tests, but Khronos
opted to drop this GLSL ES specific requirement in favor of making flat
qualification of VS outputs optional, matching modern desktop GL.
Note that there were 7 Piglit tests which enforce this rule:
tests/spec/glsl-es-3.00/compiler/interpolation/qualifiers/*nonflat*
but these were deleted in Piglit commit acc0a2fabbd714bc704c16f1675e7c0.
Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=15465#c7
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We also remove the redundant zero defaults since everything without an
explicit default gets zeroed automatically.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Split the source immediate value into new values and move them into the
original defs set by the split. Since we can only have up to 64-bit
immediates, this is largely beneficial for F64 (and, in the future, U64)
operations.
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
[imirkin: always use U32, set newi for foldCount tracking]
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Everything is in place. There are still conformance issues to sort out,
but we may as well turn it on in master.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Without meta, we no longer need the _init helpers and the ability to back
an image view with surface states allocated out of the command buffer.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Now that meta is gone and we're using blorp, we don't need all of the usage
hacks. Instead, the usage provided by the app is exactly the usage that we
want because the app is the only thing creating image views.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Now that we don't have meta, we have no need for a gen-agnostic pipeline
create path. We can, instead, just generate one Create*Pipelines function
per gen and be done with it.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
In order for things such as the ANV_CALL and the ifuncs to work, we used to
have a singleton gen_device_info structure that got assigned the first time
you create a device. Given that the driver will never be used
simultaneously on two different generations of hardware, this was fairly
safe to do. However, it has caused a few hickups and isn't, in general, a
good plan. Now that the two primary reasons for this singleton are gone,
we can get rid of it and make things quite a bit safer.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This macro was needed by meta in order to make gen-specific calls from
gen-agnostic code. Now that we don't have meta, the remaining two uses are
fairly trivial to get rid of.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Now that we no longer have meta, all pipelines get created via the normal
Vulkan pipeline creation mechanics. There is no more need for this bit of
extra magic data that we've been passing around.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
If we don't, we can end up with corruption in the portion of the depth
buffer that lies outside the render area when we do a HiZ resolve at the
end. The only reason we weren't seeing this before was that all of the
meta-based clears such as VkCmdClearDepthStencilImage were internally using
HiZ so the HiZ buffer never truly got out-of-sync. If the CTS ever tested
a depth upload (which doesn't care about HiZ) and then a partial render we
would have seen problems. Soon, we will be using blorp to do depth clears
and it won't bother with HiZ so we would get CTS regressions without this.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
When I initially brought up Vulkan blorp, I completely missed that this
was already factored out. There's no good reason for us to hand-roll it.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
In Vulkan, we want to be able to use blorp to perform clears inside of a
render pass. If blorp stomps the depth/stencil buffers packets then we'll
have to re-emit them. This gets tricky when secondary command buffers get
involved. Instead, we'll simply guarantee that the depth and stencil
buffers we pass to blorp (if any) match those already set in the hardware.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This never mattered before because the only time we used blorp
depth/stencil only was to do HiZ operations on gen6-7. It may have worked
in that case (and maybe it didn't) but slow depth clears actually do depth
rendering so they need a valid render target.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This gives a slightly smarter way to check whether or not a particular
surface exists than looking at the address.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This should now set the pipeline up properly for doing depth and/or stencil
clears by plumbing through depth/stencil test values. We are now also
emitting color calculator state for blorp operations without an actual
shader because that is where the stencil reference value goes pre-SKL.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The newly reworked depth/stencil config code can properly handle having
depth, stencil, both, or neither. We no longer need to predicate it on
having depth or stencil.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
While we're here, we also make depth without HiZ work.
v2:
- Use the correct surface type for 1-D on SKL+
- Set QPitch on BDW+
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We want to be able to start doing slow depth clears with blorp. This
allows us to adjust the depth we're clearing to.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Due to conflicting symbol names (between i915 and i965) in the
megadriver, we use a set of defines in i915/intel_screen.h.
With a recent commit we've introduced a symbol intelFenceExtension which
has different implementation for each driver, yet we forgot to add the
define.
Fixes: d11515ff1b ("i915/sync: Implement DRI2_Fence extension")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98264
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Document the EGL enum ranges for Mesa and those values allocated by the
following extensions:
EGL_MESA_drm_image
EGL_MESA_platform_gbm
EGL_MESA_platform_surfaceless
EGL_WL_bind_wayland_display
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Years ago Khronos replaced the registry's spec files with newfangled XML
files. Update the reference in doc/specs/enum.txt accordingly.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
It was the lone file in src/egl/docs. Move it to where the other specs
live, in $MESA_TOP/docs/specs.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Mesa's set of supported platform extensions depends on the autoconf
option --with-egl-platforms=foo,bar,baz. If --with-egl-platforms lacks
foo, then eglGetPlatformDisplay(EGL_PLATFORM_FOO, ...) unconditonally
fails.
So, if --with-egl-platforms lacks foo, then remove
EGL_VENDOR_platform_foo from the EGL client extension string.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
modulefinder wasn't searching for dependencies in the script dir.
It's not capable of detecting the sys.path manipulations scripts do
internally neither.
This change fixes the first issue, and hacks around the second.
Honestly, I've come to the conclusion that automatic Python dependency it will always be
too brittle. I think we should start manually typing the dependencies
like we do in automake. At very least it will enable any person to
eyeball and spot/fix missing dependencies, without dig into SCons internals.
Porting of the corresponding patch for i965.
Here follows the original commit message by Tomasz Figa:
"As the spec allows for {server,client}_wait_sync to be called without
currently bound context, while our implementation requires context
pointer.
v2: Add a mutex and acquire it for the duration of
brw_fence_client_wait() and brw_fence_is_completed() as suggested
by Chad."
NOTE: in i915 all references to 'brw' are replaced by 'intel'
Marshmallow-x86 boots ok with the following results of Android CTS.
Android CTS 6.0_r7 build:2906653
Session Pass Fail Not Executed
0(EGL) 1410 24 0
1(GLES2) 13832 82 0
I get the same results as per i965GM.
[Emil Velikov: Include Mauro's test results]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Here is the porting of corresponding patch for i965,
i.e. commit c636284 i965/sync: Implement DRI2_Fence extension
Here follows part of original commit message by Chad Versace:
"This enables EGL_KHR_fence_sync and EGL_KHR_wait_sync."
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This is the porting of corresponding patch for i965,
i.e. commit 2516d83 i965/sync: Replace prefix 'intel_sync' -> 'intel_gl_sync'
The only difference compared to i965 one is that intel_check_sync() was renamed
to intel_gl_check_sync() here, as it is more appropriate.
Here follows original commit message by Chad Versace:
"I'm about to implement DRI2_Fenc in intel_syncobj.c. To prevent
madness, we need to prefix functions for GL_ARB_sync with 'gl' and
functions for DRI2_Fence with 'dri'. Otherwise, the file will become
a jumble of similiarly named functions.
For example:
old-name: intel_client_wait_sync()
new-name: intel_gl_client_wait_sync()
soon-to-come: intel_dri_client_wait_sync()
I wrote this renaming commit separately from the commit that implements
DRI2_Fence because I wanted the latter diff to be reviewable."
[Emil Velikov: rename the outstanding intel_sync instances]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
... in dri2_x11_add_configs_for_visuals().
Currently the latter does not consider that, thus in such cases it adds
"empty" configs in the list.
Properly account for things and as we do that we can reuse count,
instead of calling _eglGetArraySize to determine if we've added any
configs.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Analogous to previous commits - with an extra bonus.
Current code, apart from not attributing the lack of 'per visual'
and overall configs also overwrites the newly added config.
Namely if the dpy supports two or more of the supported formats
(XRGB8888, ARGB8888 and RGB565) earlier configs will be overwritten
and the the final one will be stored, since the we use the same index
for all three in our dri2_add_config call.
v2: Use correct comparison in loop conditional (Eric)
Use valid C initializer (Gurchetan)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Analogous to previous commit.
v2: Use correct comparison in loop conditional (Eric)
Use valid C initializer (Gurchetan)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Iterate over the driver_configs first in order to cut down the number of
getConfigAttrib() calls by a factor of 5.
While we're here, also drop the sentinel of the visuals array. We
already know its size so we can use that and save a few bytes.
v2: Use correct comparison in loop conditional (Eric)
Use valid C initializer (Gurchetan)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Factor out and rework the existing code so that it prints a debug
message if we have zero configs for any visual.
As a nice side effect we now provide a correct (sequential ID) when
creating a config (via dri2_add_config).
v2: Use correct comparison in loop conditional (Eric)
Use valid C initializer (Gurchetan)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Currently we print a debug message if the total configs is non-zero only
to do the same (at an error level) as we return from the function.
Rework the message to print if we're missing a config for the given
format.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Introduce a helper and use it throughout the platform code. This allows
us to reduce the amount of ifdef(s) and (potentially) use
kms_swrast_dri.so for !drm platforms (namely wayland and x11).
Note: in the future as other platforms (android, surfaceless) support
the extension they can reuse the helper.
v2: Rebase, check for device_name.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
The core egl/dri2 already sets the extension bit _only_ when possible -
which in Android's case is always.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Will allow us to reuse the function for optional extensions and fold a
bit of code.
v2: Make dri2_bind_extensions::optional flag an argument to
dri2_bind_extensions (Kristian).
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Consistently indent with space rather than a mix of tab and
spaces.
v2: Keep the structs properly aligned (Eric).
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Remove the error prone fixed size array.
While we're here also rename to loader_extensions like in the GLX code.
v2: Rebase. Keep image_loader_extension within the wayland_drm
dri2_loader_extensions list.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Analogous to earlier commits.
Note: the actual version of the extension is 1, since it does not
implement .putImage2.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Similar to the dri2 one - the extension stored in struct
dri2_egl_display is unused.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Analogous to the earlier android and wayland patches. As we're here we
can drop exposing the old version of the extension.
Any dri loader/driver interface use lower bound checking thus exposing
dri2 loader v3 to a v2 capable driver is perfectly normal.
v2: Preserve compat with dri2_minor < 1. The driver does not know if
there is a protocol to manage getBuffersWithFormat(). It's up-to the
loader to expose the vfunc if there is one. (Kristian)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Earlier commit introduced support for image_loader and left the
dri2_loader code dangling/unused. Let's remove it.
Fixes: 63c5d5c6c4 ("Added pbuffer hooks for surfaceless platform")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The extension stored in struct dri2_egl_display isn't used, thus we can
create a static const instance of the extension and point extensions[]
to it.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Fold duplicate conditional blocks and add a few extra comments ;-)
v2: Bring back the explicit "unbind" logic (Eric), remove NULL derefs.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The indirection is meant to be used by the core EGL implementation in
main. Not in the drivers themselves.
Move the dri2_destroy_surface definition to avoid forward declaration of
the static function.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Currently all callers are careful enough not to do that, yet that will
not be the case in the future.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
All the platforms are duplicating what should be a driver/dri2 thing -
refcounting. Just fold it accordingly.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
For a while now we require shared glapi for EGL, thus we can drop a
few bits from the olden days. Namely - dlopen(NULL...) is not possible,
error out at build stage if so and drop the guard around dlclose().
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
The documentation is clear - one must glFlush the old context on
eglMakeCurrent. Thus keeping it optional is not something we should be
doing. Furthermore if we cannot get the entry point we're likely having
a broken setup/stack.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Update the comment to reflect the correct filename and add a guard to
catch incorrect inclusion of the header.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
The function gen7_format_needs_valign2 has two callers - the gen7 only
gen7_choose_valign_el() and isl_gen6_filter_tiling(). The latter of
which already guarding the invocation appropriately.
To be extra cautious add a couple of asserts alongside the removal of the
runtime check.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
The rest of ISL already follows this approach. Be consistent and resolve
the final references.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Will allow us to catch issues (as fixed with previous patches) rather
than release a broken tarball.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
The letter C was missing, thus in turn all the internal symbols were
exported.
As a result we hide ~150 symbols and cut ~36K from libvulkan_radeon.so.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Private/internal symbols should not be exported. Using the CXXFLAGS cuts
~300 exported symbols and ~23K from libvulkan_radeon.so.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Historically we use "device name" for the name of the kernel module and
"driver name" for the dri/other driver.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Likely unused since day 1, although I've only checked back until the
st/dri unification with commit 29ca7d2c94 ("st/dri: merge dri/drm and
dri/sw backends")
Based on the comment, referencing drmOpenByName it's not something we
want to bring back.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This commit effectively reverts c10dcb2ce8
and fixes the typedef redefinition which inspired it.
In order to prevent requiring X packages at build time earlier commit
forward declared the required X/GLX typedefs. Since that approach
introduced typedef redefinition (a C11 feature) it was reverted.
To avoid the redefinition while _not_ mandating X and related headers
forward declare the structs and use those through the header.
As anyone uses the mesa interop header they ensure that the X (or others
in terms of EGL) headers are included, which ensures that everything is
resolved within the compilation unit.
Cc: Vinson Lee <vlee@freedesktop.org>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Cc: Tapani Pälli <tapani.palli@intel.com>
Cc: Chih-Wei Huang <cwhuang@android-x86.org>
Fixes: c10dcb2ce8 ("Revert "mesa_glinterop: remove inclusion of GLX
header"")
Fixes: 8472045b16 ("mesa_glinterop: remove inclusion of GLX header")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96770
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Constrained baseline profile is supported, so use that instead. This
matches what the encoder already does (constraint_set1_flag is always
set in the output bitstream).
Reviewed-by: Christian König <christian.koenig@amd.com>
This makes the supported format actually match the configuration, and
allows the user to observe that NV12 is supported for video processing
where previously they couldn't (though it did always work if they
blindly tried to use it anyway).
Reviewed-by: Christian König <christian.koenig@amd.com>
Both YUV420 and RGB32 configurations are supported, so we need to be
able to distinguish which is being used.
Reviewed-by: Christian König <christian.koenig@amd.com>
The encoder attributes are needed for a user of the encoder to be
able to configure it sensibly without internal knowledge.
Reviewed-by: Christian König <christian.koenig@amd.com>
Commit cf804b4455
('glx: fix crash with bad fbconfig') introduced a check
in glXCreateNewContext() if the given config is a valid
fbconfig.
Unfortunately the check always checks the given config against
the fbconfigs of the DefaultScreen(dpy), instead of the
actual X-Screen specified in the config config->screen.
This leads to failure whenever a GL context is created
on a non-DefaultScreen(dpy), e.g., on X-Screen 1 of
a multi-x-screen setup, where the default screen is
typically 0.
Fix this by using config->screen instead of DefaultScreen(dpy).
Tested to fix context creation failure on a dual-x-screen setup.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Work in progress (disabled).
USE_8x2_TILE_BACKEND define in knobs.h enables AVX512 code paths
(emulated on non-AVX512 HW).
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
src2 was being given the wrong modifier, and we were not properly
managing the modifier on the SHL source either.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Rename to gl_vertex_attrib_array::BufferBindingIndex because this field
is an index into the array of buffer binding points. This makes some
code a little easier to follow since there's also a "VertexBinding" field
in gl_vertex_array_object.
Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
Use a bitmask to indicate which color buffers are integer-valued, rather
than a bool. Also, the old field was mis-computed. If an integer buffer
was followed by a non-integer buffer, the _IntegerColor field was wrongly
set to false.
This fixes the new piglit gl-3.1-mixed-int-float-fbo test.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
None of the drivers which implement this hook do anything with the
texture parameter value. Drivers just look at the pname and set a
dirty flag if needed.
We were doing some ugly casting and type conversion to setup the
argument so that all goes away.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Previously, the plan was "if the width/height we have to load/store isn't
the size the user is planning on writing, then we need to load the old
contents out beforehand to prevent writing back undefined".
However, when we're doing glTexImage() we often end up aligning the
width/height into the padding of the texture, and we don't actually
need to read out that padding.
Improves x11perf -aatrapezoid100 performance from ~460/sec to
~700/sec.
Regression introduced by
ba0274c7d6
Check the resource exists before assigning it
a flag (and use This->base.resource instead
of pResource, since the former may have a newly
allocate resource, while the latter would be
NULL).
This should reintroduce the behaviour of previous
code.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Since 1604efa6fd,
lconsti and lconstb don't need to be initialized.
Remove some leftovers from the previous code (which
has now invalid use of ARRAY_SIZE on a pointer instead
of an array).
Reported by Coverity.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Use uint64_t instead of int64_t in the calculation,
as the result is uint64_t.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
All ARB_enhanced_layouts piglit tests pass without any changes
in our compiler.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
These were changed in LLVM r284024.
v2:
- Only use float types for vdata of llvm.amdgcn.image.store. LLVM doesn't
support integer types for this intrinsic.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The identity swizzle should operate exactly
like an .r = R, .g = G, .b = B, .a = A swizzle.
This fixes a bunch of the 16-bit BGRA blit tests
dEQP-VK.api.copy_and_blit.blit_image.all_formats.b4g4r4a4*
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fix was found in the radv codebase when running dota2,
no idea if anyone has reported it on anv, but the same problem
occurs.
Once an image is acquired we need to mark it busy.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
dota2 does multiple acquires followed by multiple queues,
this bug manifested itself as a hang in the xshmfence code
randomly when dota2 was doing it's menus. It also occured
when running dota2 under phoronix-test-suite.
The fix is once the image is acquired to mark it busy then
so nobody else can acquire. We have to trust vulkan apps
that they will eventually submit it.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The table was copied from the Vulkan driver. The comment lines are as long
as the table for cosmetic reasons.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
so that decompress blits aren't needed and depth texturing needs less
memory bandwidth.
Z16 and Z24 are promoted to Z32_FLOAT by the driver, because TC-compatible
HTILE only supports Z32_FLOAT. This doubles memory footprint for Z16.
The format promotion is not visible to state trackers.
This is part of TC-compatible renderbuffer compression, which has 3 parts:
DCC, HTILE, FMASK. Only TC-compatible FMASK compression is missing now.
I don't see a measurable increase in performance though.
(I tested Talos Principle and DiRT: Showdown, the latter is improved by
0.5%, which is almost noise, and it originally used layered Z16,
so at least we know that Z16 promoted to Z32F isn't slower now)
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
For performance tuning in drivers. It filters out window system
framebuffers and OpenGL renderbuffers.
radeonsi will use this to guess whether a depth buffer will be read
by a shader. There is no guarantee about what will actually happen.
This is a departure from PIPE_BIND flags which are defined to be strict
but they are useless in practice.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Whether one or two slots are taken up by one API array depends on the
vertex shader, not on how the array is configured. When an array is
set up with fewer components than the shader expects, the high components
are undefined.
Fixes GL45-CTS.vertex_attrib_binding.basic-inputL-case1.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Dave Airlie <airlied@redhat.com>
This fixes a bug with offsets from uniforms which seems to have only been
noticed as a crash in piglit's
arb_gpu_shader5/compiler/builtin-functions/fs-gatherOffset-uniform-offset.frag
on radeonsi.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Fixes GL45-CTS.shader_image_load_store.basic-allTargets-atomic*
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
If pPhysicalDevices is too small for all physical devices,
the driver must return VK_INCOMPLETE. Since only a single
physical device is supported, this is only the case when
pPhysicalDeviceCount == 0 && pPhysicalDevices != NULL.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Gallium is completely oblivious to whether the fbo is flipped or not.
Only flip the stipple pattern when the fbo is flipped as well. Otherwise
the driver has no idea when to unflip the pattern.
Fixes bin/gl-2.1-polygon-stipple-fs -fbo
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Recent fix for non-const offsets broke the case of a single offset (vs 4
offsets). The later code relies on the offs array to contain null values
to tell whether they should be added onto the srcs list.
Fixes: 5239bd592 ("nvc0/ir: fix overwriting of value backing non-constant gather offset")
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
In order to be able to emit overlapping input and output array
declarations, we flip the logic of emitting those declarations on its
head: rather than iterating over slots and emitting the corresponding
declarations, we iterate over the declarations from GLSL and emit those.
v2: fix some regressions related to structs
v3: fix a regression in geometry and tessellation shader array handling
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net> (v2)
Reviewed-by: Dave Airlie <airlied@redhat.com> (v2)
In some cases, a shader may have an input/output array but not use some
entries in the middle. This happens with eON games, for example.
We emit declarations that cover the entire array range even if there are
some unused gaps. This patch now reflects that in the InputsRead etc.
fields to ensure the various input/outputMapping arrays are actually
correct, which will be important when we re-jiggle the way declarations
are emitted.
v2: fix a typo (Edward O'Callaghan)
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This optimization is incorrect with 64-bit operations, because the
channel-splitting logic in emit_asm ends up being applied twice to
the source operands.
A lucky coincidence of how the writemask test works resulted in this
optimization basically never being applied anyway. As far as I can tell,
the only case where it would (incorrectly) have been applied is something
like
dvec2 d;
float x = (float)d.y;
which nobody seems to have ever done. But the moral equivalent does occur
in one of the component layout piglit test.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Empty writemasks mean "copy everything", so we can always just use the number
of vector elements (which uses the GLSL meaning here, i.e. each double is a
single element/writemask bit).
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
For specifying an exact location/component.
v2: change the order of parameters (Dave)
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> (v1)
Reviewed-by: Dave Airlie <airlied@redhat.com> (v1)
This is a screen cap because drivers are expected to support it either
for all shader types or for none of them.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
radeonsi no longer supports pixel shaders without interpolation optimizations,
which led to assertion failures in si_shader_ps when running shader-db.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
total instructions in shared programs :2286901 -> 2284473 (-0.11%)
total gprs used in shared programs :335256 -> 335273 (0.01%)
total local used in shared programs :31968 -> 31968 (0.00%)
local gpr inst bytes
helped 0 41 852 852
hurt 0 44 23 23
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
We shouldn't be using wildcard here in the first place, but changing that
is some effort. As it stands, make -p confirms that glapi_gen_mapi_deps only
contains mapi_abi.py when building outside the Mesa tree.
As a result, only some of the tables were updated when XML files change, but
not the tables for shared glapi. This change ensures that we pick up the
XML files and scripts from the source tree as dependencies also for shared
glapi.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This should make the code more robust if a shader tries to use inputs which
aren't defined by the vertex element layout (which usually shouldn't happen).
No piglit change.
Reviewed-by: Brian Paul <brianp@vmware.com>
If pPhysicalDevices is too small for all physical devices,
the driver must return VK_INCOMPLETE.
Since only a single physical device is supported, this is only the case
when pPhysicalDeviceCount == 0 && pPhysicalDevices != NULL.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Many of these can be "NULL if the pipeline has rasterization disabled."
Also, we should assert that pMultisampleState exists.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
It's supposed to be how much at least we want to grow the cs, not the
minimum size of the cs after growth.
v2: Unbreak use_ib_bos.
Don't mask the ib_size when !use_ib_bos, since it's not needed.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This checks the kernel driver name is amdgpu before calling
libdrm_amdgpu.
This avoids the following error:
amdgpu_device_initialize: DRM version is 1.6.0 but this driver is only compatible with 3.x.x
when run on a machine with i915 graphics as well as amdgpu.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Probably unlikely however ensure we don't leak a heap allocation
on the fail path.
V.2:
also fix missing 'amdgpu_device_deinitialize()' calls (Emil Velikov).
Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Drop/add a few newlines where appropriate and drop a couple of
unnessary braces.
Signed-off-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
SwrStoreTiles now takes a mask of surfaces to store. Reduces
overhead when storing multiple render targets.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
Align and use streaming store instructions for BE fifo queues.
Provides slightly faster enqueue and doesn't pollute the caches.
Add appropriate memory fences to ensure streaming writes are
globally visible.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
EGL_KHR_swap_buffers_with_damage is actually already supported, as it is
technically nothing but a rename of EGL_EXT_swap_buffers_with_damage.
To that effect, both extension are advertised depending on the same
condition, and the new entrypoint simply redirects to the previous one.
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
New generated headers were introduced by commit 63a366a
"intel: aubinator: generate a standalone binary"
Android does not need aubinator yet, so in order to avoid building error,
aubinator required new genxml headers are defined in a separate list.
If required, building rules for Android will be added later.
[Emil Velikov: don't use a _HEADERS variable name (causes warnings)]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The static library is analogous to the intel ISL, which is required for
both hardware and (to be added) testing library.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Patch changes function to use _mesa_lookup_shader_program_err both
in TransformFeedbackVaryings and GetTransformFeedbackVarying that
handles errors correctly for invalid values of shader program.
Fixes following dEQP test:
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.transform_feedback_varyings
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98135
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Add the miptree level/slice x/y_offset when count the surface offset
in brw_emit_surface_state. The surface offset has two parts, one is
from mt->offset, which should be 32 aligned in width/height for tiled
buffer; another is from mt->level[current_level].slice[current_slice].
x/y_offset.
This fix will solve 12 deqp failure
dEQP-EGL.functional.image.create.gles2_cubemap_negative_*_texture
Signed-off-by: Xu,Randy <randy.xu@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
On Intel Pineview M hardware, the i915 gallium driver doesn't output
the correct gl_FragCoord. It seems to always have an X coord of 0.0
and a Y coord of the window's height in pixels, e.g. 600.0f or such.
I believe this is a regression caused in part by this commit:
afa035031f
The old behavior used the output at index zero, while the new behavior
uses actual zeroes. In the case of gl_FragCoord the output at index
zero happened to be the correct one, so the behavior appeared correct
although the code already had a bug.
Fixed by checking for I915_SEMANTIC_POS when setting up texCoords. If
the generic_mapping is I915_SEMANTIC_POS, look for the
TGSI_SEMANTIC_POSITION instead of a TGSI_SEMANTIC_GENERIC output.
https://bugs.freedesktop.org/show_bug.cgi?id=97477
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
This reverts commit 8472045b16.
Conflicts:
include/GL/mesa_glinterop.h
This patch fixes this build error with GCC 4.4.
Compiling src/glx/dri_common_interop.c ...
In file included from src/glx/dri_common_interop.c:33:
include/GL/mesa_glinterop.h:62: error: redefinition of typedef ‘GLXContext’
include/GL/glx.h:165: note: previous declaration of ‘GLXContext’ was here
Fixes: 8472045b16 ("mesa_glinterop: remove inclusion of GLX header")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96770
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Return error instead of crashing on source surfaces
with format D3DFMT_NULL.
Fix for issue #236.
Tested on Windows 7.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Wine tests show that cubetextures always use
PIPE_TEX_WRAP_CLAMP_TO_EDGE regardless of set
sampler states.
Fixes failing d3d9 wine test test_cube_wrap.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Add an assert to make sure buffer creation doesn't fail.
Add error handling in calling functions.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
The removed code was there for two reasons:
1) Allow DF16, DF24, INTZ to be used as depth buffer
for swapchain, if the driver doesn't support
PIPE_BIND_SAMPLER_VIEW for the underlying format
2) Set PIPE_BIND_SAMPLER_VIEW if possible, such that
if StretchRect is called on the depth texture, it is happy.
1) The reason these formats needed a workaround is because
the check flags for them in CheckDeviceFormat were incorrect,
which led applications to think the formats were valid for
swapchains, even if they weren't supported.
2) StretchRect limitations for depth buffers force
the resource_copy_region path, which should be fine without
PIPE_BIND_SAMPLER_VIEW.
Thus fix the check for 1), and remove the code.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Advertise quality levels:
Each supported multisample count matches to one quality level.
The application doesn't know how much samples each quality level has.
For that reason it's not possible to set the multisample mask.
Return errors on quality level missmatch.
Fixes several old games not having multisample support until now.
Fix for issue #73.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Compare resource's nr_samples instead of D3D multisample level.
Required for multisample quality levels to work correct.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Use strict aliasing in SetPrivateData and struct pheader.
Casting char[1] to IUnknown** isn't allowed in strict aliasing.
Compute pointer to body by adding size of header to header pointer.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Remove {Set/Get/Free}PrivateData in resource9.
Functionality has been implement in IUnknown interface.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Remove {Set/Get/Free}PrivateData in volume9.
Functionality has been implement in IUnknown interface.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Switch {Set/Get/Free}PrivateData function to introduced IUnknown functions.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Implement {Set/Get/Free}PrivateData in iunknown to get rid
of duplicated code in resource9 and volume9.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
According to MSDN the device is returned for surfaces that do
not have a regular container.
Such surfaces are:
OffscreenPlainSurface, DepthStencilSurface and RenderTarget
Tested and verified on Windows.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Allocate resources in surface ctor.
Allows to use statetracker internal memory accounting.
Fix for issue #231.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
D3DFMT_NULL is mapped to PIPE_FORMAT_NONE.
Instead of relying on PIPE_FORMAT_NONE to
return a size, pick one.
The one picked is the same than Wine.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Add DBG calls to NineTexture9_GetLevelDesc and
NineTexture9_GetSurfaceLevel to ease debugging.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Tests showed that is allowed to call this method on
object that have a zero refcount.
Required for issue #230.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Same change than for vs ff.
This makes it easier to not introduce mistakes
reusing temporaries whose result shouldn't be
erased.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Error found with wine tests.
nine_shader was expecting another order
than the one device9 was using.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Thanks to wine tests.
Apparently 4x4 inverse is to be used, and
if the inverse can't be calculated, the
input matrix is to be used.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Wine tests for the passthrough feature are for positiont.
Nothing seems to indicate passthrough happens when positiont
it not used. However having passthrough with positiont makes
sense (to be used with ProcessVertices outputs).
Signed-off-by: Axel Davy <axel.davy@ens.fr>
We were (wrongly) adding specular to diffuse
in vertex shaders when SPECULARENABLE was set.
However the spec says specular has to be added
after texture processing (which is in ps).
Besides SPECULARENABLE is flagged as a pixel state.
There was unused support for SPECULARENABLE
in the ps ff code.
Remove the vs code, and use the ps code.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
There are several holes. This patch reduces
the holes a bit, which reduces the size of
the constant buffer uploaded.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
This has been a real mess up to now: the temporaries
were allocated once, and shared after that between
the different parts of the code.
To help maintaining the code, the temporaries are now
allocated and released on need.
As surprising as it could be, this patch, which was
supposed to introduce no behaviour change, actually
solved a visual bug observed on a sample program.
This was due to ureg_normalize3 polluting a temporary
variable.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
When this state is set, the normals computed
in the vs ff shader should be normalized.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Software Vertex Processing allows:
. Less limitations for shaders (more loops, etc)
. Less limitations for ff (more enabled lights, 255
matrices for VertexBlend)
In particular shaders can get more constants.
This patch implements support for this (not using software
rendering, but hardware rendering, as llvmpipe and dx10+ hw
have the same limits...)
This is considered a second class path. Even apps asking for
"Mixed Vertex processing" (ie the ability to switch to swvp
on demand) do not use the feature much. Some just initialize
more constants than the normal limit at the start of the
application, but never use more than the normal limit.
When the apps do not need the software vertex processing
features, they do not seem to turn it on. This means it is
ok if that path is slow.
Thus no care has been made to make the path optimized.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
This path has been disabled for some time because
of some bugs with it. It hasn't been updated to the
new features, and is not faster.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
In mixed vertex processing, the user can enable or disable
software vertex processing. It is on hardware by default.
This feature is not a state, and thus the setting doesn't
need to be recorded by stateblocks.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Buffers with this flag must be usable with both software
and hardware vertex processing. Use Staging for fast cpu access.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
ATIx are "unknown" formats that do not follow block format conventions.
Tests showed that pitch*height bytes are allocated.
apitrace used to depend on this behaviour.
It used to copy more bytes than it has to for the ATI1 block format,
but it didn't crash on Windows.
Increase buffersize for ATI1 to fix this crash.
The same issue was present in WINE but a patch has been sent by me.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
To implement the feature we copy the ps inputs to a temp array.
This is not optimal for performance, but it is the simplest solution.
This is a feature that is very very rarely used.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
On 32 bits system, application memory is quite limited.
softpipe uses application memory. To help prevent memory
exhaustion, limit reported memory availability to 2GB.
Some gallium nine apps do check reported memory by allocating
resources until memory is full. Gallium nine refuses allocations
when 80% of the reported memory limit is used. This change
helps some apps to start.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
On 32 bits system, application memory is quite limited.
llvmpipe uses application memory. To help prevent memory
exhaustion, limit reported memory availability to 2GB.
Some gallium nine apps do check reported memory by allocating
resources until memory is full. Gallium nine refuses allocations
when 80% of the reported memory limit is used. This change
helps some apps to start.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Fixes regression introduced by
ecd6fce261
and is more future proof than just clearing the next
field.
Other nine usages did already zero out the templates.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
When offset != 0, the valid range was wrong because the second
argument of util_range_add() is end, not size.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Normally the value is an immediate, which is moved to some temporary, so
there's no problem. In the case of a non-constant offset (as allowed by
ARB_gpu_shader5), we have to take care to copy it first before using it
to build up the bits.
This fixes a compilation error observed in F1 2015.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
CC glsl/tests/cache_test.o
glsl/tests/cache_test.c: In function ‘test_cache_create’:
glsl/tests/cache_test.c:160:4: error: implicit declaration of function ‘cache_destroy’ [-Werror=implicit-function-declaration]
cache_destroy(cache);
^
Fixes: 87ab26b2ab ("glsl: Add initial functions to implement an on-disk cache")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Pre-patch, there were two code paths for parsing EGLSync attribute
lists: one path for old-style EGLint lists, used by eglCreateSyncKHR,
and another for new-style EGLAttrib lists, used by eglCreateSync (1.5)
and eglCreateSync64 (EGL_KHR_cl_event2).
There were two attrib_list parsing functions,
_eglParseSyncAttribList(_EGLSync *sync, const EGLint *attrib_list)
_eglParseSyncAttribList64(_EGLSync *sync, const EGLattrib *attrib_list)
This patch unifies the two attrib_list parsing functions into one,
_eglParseSyncAttribList(_EGLSync *sync, const EGLattrib *attrib_list)
Many internal EGLSync function signatures had *two* attrib_list
parameters to accomodate both code paths: one parameter was an EGLint
list and other an EGLAttrib list. At most one of the parameters was
allowed to be non-null. This patch removes the `EGLint *attrib_list`
parameter, leaving only the `EGLAttrib *attrib_list` parameter, for all
internal EGLSync functions.
v2:
- Consistently use condition (sizeof(int_list[0]) ==
sizeof(attrib_list[0])). [for emil]
v3:
- Don't double-unlock the display in eglCreateSyncKHR.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (v2)
A function with multiple returns would have had multiple preret settings
at the top of the function. While this is unlikely to have caused issues
since we don't use functions in earnest, it could have in some cases
overflowed the call stack, in case a function had a lot of early
returns.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Not sure if it's possible to avoid programming the block size twice (once for
the userdata and once for the dispatch).
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
According to the Vulkan spec 5.63.4 :
samplerAnisotropy indicates whether anisotropic filtering is supported. If
this feature is not enabled, the maxAnisotropy member of the
VkSamplerCreateInfo structure must be 1.0.
Since we already set maxAnisotropy to 16 and program the hardware according
to the VkSamplerCreateInfo.maxAnisotropy, it seems we can turn this on.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Changes make copy_propagation_elements pass faster, reducing link
time spent in test case of bug 94477. Does not fix the actual issue
but brings down the total time. No regressions seen in CI.
v2 (idr): Formatting / whitespace fixes. Embed the acp_ref in the
acp_entry.
v3 (idr): Delete unused copy constructor. Use while(pop_head) instead
of foreach() { remove }.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In conjuction with an intel_aubdump change, you can now look at your
application's output like this :
$ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app
v2: Add print_help() comment about standard input handling (Eero)
Remove shrinked gtt space debug workaround (Eero)
v3: Use realloc rather than memcpy/free (Ben)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Embed the xml files into the binary, so aubinator can be used from any
location.
v2: Split generation packing into another patch (Jason)
Check for xxd (Jason)
v3: Fix out of tree builds (Jason)
Generate custom variable name rather than names generated by xxd
(Lionel)
v4: Move generated _xml.h files to genxml/ (Sirisha)
v5: Remove newline from makefile (Jason)
v6: Add comment on gen*_xml.h creation (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Nanley Chery:
(rebase)
- Resolve conflicts with new anv_batch_emit macro
(amend)
- Handle a QPitch TODO
- Emit 3DSTATE_HIER_DEPTH_BUFFER on pre-BDW systems
- Only use HiZ for single-subpass renderpasses
- Emit the HiZ instruction before the stencil instruction to follow the
optimized clear sequence specified in the PRMs
- Don't modify clear params
- Enable resolves when a HiZ buffer is used to ensure depth buffer validity
Provides an FPS increase of ~15% on the Sascha triangle and multisampling
demos.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Create a function that performs one of three HiZ operations -
depth/stencil clears, HiZ resolve, and depth resolves.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Nanley Chery:
(rebase)
- Use isl_surf_get_hiz_surf()
(amend)
- Only add a HiZ surface onto a depth/stencil attachment
- Add comment above HiZ surface addition
- Hide HiZ behind INTEL_VK_HIZ prior to BDW
- Disable HiZ for untested cases
- Remove DISABLE_AUX_BIT instead of preventing it from being added
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
We will only hit this with multi-planar YUV external images, so we would
probably never hit this code path in the first place. But if we did, it
wouldn't do the right thing so just bail.
Signed-off-by: Rob Clark <robdclark@gmail.com>
According to the spec - 9.6. Pipeline Cache :
If pDataSize is less than the maximum size that can be retrieved by the
pipeline cache, at most pDataSize bytes will be written to pData, and
vkGetPipelineCacheData will return VK_INCOMPLETE.
Fixes the following test from Vulkan CTS :
dEQP-VK.pipeline.cache.pipeline_from_incomplete_get_data.vertex_stage_fragment_stage
dEQP-VK.pipeline.cache.pipeline_from_incomplete_get_data.vertex_stage_geometry_stage_fragment_stage
dEQP-VK.pipeline.cache.misc_tests.invalid_size_test
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Since the gen_device_info structs are no longer just constant memory, a
pointer to one is not a pointer to something in the .data section so we
shouldn't be storing it in a static variable. Instead, we should just
store the entire device_info structure.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
We have to be careful to not smash the value they're clearing to, but
other than that we're fine. Avoids quad clears in Processing, which likes
to do glClear(Z|S); glClear(Z).
Improves performance of Processing's QuadRendering demo at 5000 quads by
5.46507% +/- 1.35576% (n=15 before, 32 after)
We were incrementing the count at the end of vc4_start_draw(), except that
that function returns immediately if we've already started drawing on this
batch. It also failed to count the statechanges from the GFXH-515
workaround.
This incidentally allows repeated glClear() to be coalesced, because the
fast clears aren't counted in draw_calls_queued any more. Fixes most of
the extra flushes in Processing, which emits glClear(Z|S); glClear(Z);
glClear(C) during its frame setup.
Improves performance of Processing's QuadRendering demo at 5000 quads by
3.33538% +/- 2.05846% (n=21 before, 15 after)
This slightly reduces instructions on shader-db, but I think it's just
perturbing register allocation -- the allocator should have always
trivially colored these nodes, before. This commit is just to make QIR
code failing more intelligible when register allocation fails.
If a conditional assignment is only conditioned on the exec mask, that's
still screening off the value in the executed channels (and, since we're
not storing to the unexcuted channels, we don't care what's in there).
Fixes a bunch of extra register pressure on Processing's Ribbons demo,
which is failing to allocate.
We would assertion fail in setting up the simulator the second time
around. This at least postpones the assertion failure until we've closed
all of the first set of screens and started opening a new set.
Initially, we had intended set_subpass to be an interesting function that
did whatever (presumably a lot) setup we needed for a subpass. In reality,
it just sets a pointer and a dirty bit and then emits depth and stencil
state. When we call BeginCommandBuffer on a secondary, there's no point in
setting depth and stencil state since it will already be set by the
primary. Instead, the only thing we need to do at the start of a secondary
is set the subpass pointer and the dirty bit.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
We have a DIRTY_RENDER_TARGETS flag and that makes a lot more sense than
just dirtying fragment descriptors. We're checking for it in some of the
gen7 code but unfortunately, nothing was setting it and it didn't do what
it was supposed to do in cmd_buffer_flush_state.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Because WSI images are created with VkImageCreateInfo::flags explicitly set
to 0, they don't ever have the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT set.
This means that you can't create an image view of it with a different
format so applications can't render directly in sRGB (without automatic
encoding) unless we actually advertise UNORM formats. There are a lot of
applications that want to do their own sRGB conversion, so we should allow
for that. We do, however, make UNORM come after sRGB in the list so that
the default for dumb apps that just grab the first thing is to render in
linear and let the sRGB conversion happen automatically.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
If the user created a fence with VK_FENCE_CREATE_SIGNALED_BIT set, we
shouldn't fail to wait for a fence if it was not submitted since that is
not necessary.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This squashes all the radv development up until now into
one for merging.
History can be found:
https://github.com/airlied/mesa/tree/semi-interesting
This requires llvm 3.9 and is in no way considered
a conformant vulkan implementation. It can run a number
of vulkan applications, and supports all GPUs using
the amdgpu kernel driver.
Thanks to Intel for providing anv and spirv->nir,
and Emil Velikov for reviewing build integration.
Parts of this are:
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Authors: Bas Nieuwenhuizen and Dave Airlie
Signed-off-by: Dave Airlie <airlied@redhat.com>
Checking if MAD is supported is definitely wrong, and it's
more likely a typo I introduced few days ago which breaks
NV50 because SHLADD is not supported there.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
When the chipset is forced with NV50_PROG_CHIPSET, we actually
only want to output the binary if NV50_PROG_DEBUG is also
enabled. Otherwise, this pollutes the shader-db output.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Only expose 512 threads/block on Fermi to not be limited by
32 GPRs/thread.
v4: - use 512 threads on Fermi, 1024 on Kepler+
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
When a variable local size is defined as specified by
ARB_compute_variable_group_size, the fixed local size is set to 0
and a SIGFPE occurs when we compute the maximum number of regs.
This allows to use 64 GPRs/thread.
v4: - use 512 threads on Fermi, 1024 on Kepler+
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This extension is only exposed if the underlying driver supports
ARB_compute_shader and if PIPE_COMPUTE_MAX_VARIABLE_THREADS_PER_BLOCK
is set.
v3: - initialize max_variable_threads_per_block to 0
v2: - expose the ext based on that new cap
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
gl_LocalGroupSizeARB can be translated into TGSI_SEMANTIC_BLOCK_SIZE
which represents the block size in threads.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Compute shaders can now include a fixed local size as defined by
ARB_compute_shader or a variable size as defined by
ARB_compute_variable_group_size.
v2: - update formatting spec quotations (Ian)
- various cosmetic changes (Ian)
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The ARB_compute_variable_group_size specification explains that
when a compute shader includes both a fixed and a variable local
size, a compile-time error occurs.
v2: - update formatting spec quotations (Ian)
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This is the new layout qualifier introduced by
ARB_compute_variable_group_size which allows to use a variable work
group size.
v4: - add missing '%s' in the monster format string
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
v5: - replace fixed_local_size by !LocalSizeVariable (Nicolai)
v4: - slightly indent spec quotes (Nicolai)
- drop useless _mesa_has_compute_shaders() check (Nicolai)
- move the fixed local size outside of the loop (Nicolai)
- add missing check for invalid use of work group count
v2: - update formatting spec quotations (Ian)
- move the total_invocations check outside of the loop (Ian)
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
helped some ue4 demos and divinity OS shaders
total instructions in shared programs : 2818674 -> 2818606 (-0.00%)
total gprs used in shared programs : 379273 -> 379273 (0.00%)
total local used in shared programs : 9505 -> 9505 (0.00%)
total bytes used in shared programs : 25837792 -> 25837192 (-0.00%)
local gpr inst bytes
helped 0 0 33 33
hurt 0 0 0 0
Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Pierre Moreau <pierre.morrow@free.fr>
Previously, the sampler view code was scattered across several different
files.
Note, the previous REALLOC(), FREE() for st_texture_object::sampler_views
are replaced by realloc(), free() to avoid conflicting macros in Mesa vs.
Gallium.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Before, st_get_texture_sampler_view_from_stobj() did a lot of work to
check if the texture parameters matched the sampler view (format,
swizzle, min/max lod, first/last layer, etc). We did this every time
we validated the texture state.
Now, we use a ctx->Driver.TexParameter() callback and a couple other
checks to proactively release texture views when we know that
view-related parameters have changed. Then, the validation step is
simplified:
- Search the texture's list of sampler views (just match the context).
- If found, we're done.
- Else, create a new sampler view.
There will never be old, out-of-date sampler views attached to texture
objects that we have to test.
Most apps create textures and set the texture parameters once. This
make sampler view validation much cheaper for that case.
Note that the old texture/sampler comparison code has been converted
into a set of assertions to verify that the sampler view is in fact
consistent with the texture parameters. This should help to spot any
potential regressions.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
To inform drivers of texture buffer offset/size changes, as we do for
other texture object parameters.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Before, we had code to compute the sampler view's format spread across two
different functions: in update_single_texture() and
st_get_texture_sampler_view_from_stobj(). Now it's all in one new function.
Also, use _mesa_texture_base_format() to simplify the code.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Now that the NIR casting functions have type assertions, we have a bunch of
assertions that aren't needed anymore.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
One of NIR's invariants is that control flow lists always start and end
with blocks. There's no good reason why we should return a cf_node from
these functions since we know that it's always a block. Making it a block
lets us remove a bunch of code.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
This makes calling nir_foo_as_bar a bit safer because we're no longer 100%
trusting in the caller to ensure that it's safe. The caller still needs to
do the right thing but this ensures that we catch invalid casts with an
assert rather than by reading garbage data. The one downside is that we do
use the casts a bit in nir_validate and it's not a validate_assert.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Otherwise it won't be picked in the tarball and the build will fail.
Fixes: 91ec6e5664 ("radeonsi/compute: Use the HSA abi for non-TGSI
compute shaders v3")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Otherwise it won't be picked in the tarball and the build will fail.
Fixes: 0035f7f136 ("svga: add guest statistic gathering interface")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The function deals with fb (style) configs, thus using "visual"
in the name is misleading. Which in itself had led to the use of
fbconfig_style_tags argument.
Rename the function to reflect what it does and drop the unneeded
argument.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Return GL_FALSE if we fail to find any fb/visual configs, otherwise we
end up with all sorts of chaos further down the GLX stack.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The comment/spec says - only for pbuffer drawables, while the code
clears the window/pixmap bit. Practise what you preach and apply the
trivial tweak. In practise this should not cause functional change.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This fixes a problem where GL headers would only get installed if
glx was enabled. So if osmesa was enabled but not glx, then the
GL headers required by osmesa would be missing from the install.
v2: Dropped unneeded mesa_glinterop.h redundant osmesa.h install
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Similar to earlier commit - symbol was never part of the public API so
we're safe to remove it.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
The symbol is a no-op since, the EXTRA_DEBUG macro is not set in the
build. Unused by !Haiku people/platforms since 2010 (commit
a73c6540d9) while the Haiku C++ wrapper
has no obvious users.
Cc: Alexander von Gluck IV <kallisti5@unixzen.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Similar to the other 'tests', enable assertions in xvmc_bench.
This silences the GCC warnings about unused-variable(s), makes the
program actually useful, as the XvMC API called. Atm the function
calls are omitted, since they're called within the assert.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The header was renamed with earlier commit, so update the
Makefile.sources respectively.
{vulkan/genX_multisample.h => common/gen_sample_positions.h}
Fixes: c779ad3e661("intel: Move Vulkan sample positions to common code")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
glsl_print_type() prints arrays of arrays incorrectly. For example,
a type with name float[3][7] would be printed as float[7][3]. (This
is an array of length 3 containing arrays of 7 floats.) cdecl says
that the type name is correct.
glsl_print_type() doesn't really do anything above and beyond printing
type->name, and glsl_print_struct() wasn't used at all. So, drop them.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
According to chapters 16.5. (Timestamp Queries) and 30.2 (Limits) of the
Vulkan Specification 1.0.29, the .limits.timestampPeriod field returned
by vkGetPhysicalDeviceProperties is measured in nanoseconds, not in
seconds.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a step towards dropping the GLSL IR version of
do_set_program_inouts() in i965 and moving towards native nir support.
This is important because we want to eventually convert to nir and
use its optimisations passes before we can call this GLSL IR pass.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a step towards dropping the GLSL IR version of
do_set_program_inouts() in i965 and moving towards native nir support.
This is important because we want to eventually convert to nir and
use its optimisations passes before we can call this GLSL IR pass.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a step towards dropping the GLSL IR version of
do_set_program_inouts() in i965 and moving towards native nir support.
This is important because we want to eventually convert to nir and
use its optimisations passes before we can call this GLSL IR pass.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a step towards dropping the GLSL IR version of
do_set_program_inouts() in i965 and moving towards native nir support.
This is important because we want to eventually convert to nir and
use its optimisations passes before we can call this GLSL IR pass.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a step towards dropping the GLSL IR version of
do_set_program_inouts() in i965 and moving towards native nir support.
This is important because we want to eventually convert to nir and
use its optimisations passes before we can call this GLSL IR pass.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Just say no to:
- brw->cs.base.prog_data = &brw->cs.prog_data->base.base;
We'll just use the brw_stage_prog_data pointer in brw_stage_state
and downcast it to brw_cs_prog_data as needed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arcero@collabora.com>
Just say no to:
- brw->wm.base.prog_data = &brw->wm.prog_data->base.base;
We'll just use the brw_stage_prog_data pointer in brw_stage_state
and downcast it to brw_wm_prog_data as needed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arcero@collabora.com>
Just say no to:
- brw->gs.base.prog_data = &brw->gs.prog_data->base.base;
We'll just use the brw_stage_prog_data pointer in brw_stage_state
and downcast it to brw_gs_prog_data as needed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arcero@collabora.com>
Just say no to:
- brw->tes.base.prog_data = &brw->tes.prog_data->base.base;
We'll just use the brw_stage_prog_data pointer in brw_stage_state
and downcast it to brw_tes_prog_data as needed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arcero@collabora.com>
Just say no to:
- brw->tcs.base.prog_data = &brw->tcs.prog_data->base.base;
We'll just use the brw_stage_prog_data pointer in brw_stage_state
and downcast it to brw_tcs_prog_data as needed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arcero@collabora.com>
Just say no to:
- brw->vs.base.prog_data = &brw->vs.prog_data->base.base;
We'll just use the brw_stage_prog_data pointer in brw_stage_state
and downcast it to brw_vs_prog_data as needed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arcero@collabora.com>
What is the difference between a 'driver_fence' and a 'fence'? Do the
characters 'driver_' add anything helpful? Nope. They do, though, add an
extra 7 chars and pull your eyeballs away to ask "huh? what's that?" one
microsecond too many.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is yet another patch for the great renaming begun long ago.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We locked an unitialized mutex in the callstack
glClientWaitSync
intel_gl_client_wait_sync
brw_fence_client_wait_sync
because we forgot to initialize it in intel_gl_fence_sync.
(The EGLSync codepath didn't have this bug. It initialized the mutex in
intel_dri_create_sync).
We also forgot to tear down (mtx_destroy) the mutex when destroying
the sync object.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Currently, program binaries are only dumped at upload time, but
when the chipset has been forced via NV50_PROG_CHIPSET we might
want to show the generated code, especially with shaderdb.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
which is returned for GL_MAX_TEXTURE_BUFFER_SIZE.
It doesn't have any other use at the moment.
Bigger allocations are not rejected.
This fixes GL45-CTS.texture_buffer.texture_buffer_max_size on Bonaire.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
(v1 pushed, then reverted)
This fixes 9 randomly failing tests on radeonsi:
GL45-CTS.shader_multisample_interpolation.render.interpolate_at_centroid.*
v2: use input_interpolate[input] (correct) instead of
input_interpolate[index] (incorrect)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Use the vertex positions described in the PRMs. This has no effect on
rendering but quiets the simulator warnings seen when the vertices
appear out of order.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
It is now the only caller so there's no sense in keeping things split out.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Wire up the debug entrypoints to EGL dispatch, and add the extension
string to the client extension list.
v2:
- Lots of style fixes
- Fix missing EGLAPIENTRYs
- Factor out valid attribute check
- Lock display in eglLabelObjectKHR as needed, and use RETURN_EGL_*
- Move "EGL_KHR_debug" into asciibetical order in client extension
string
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.veliko@collabora.com>
This decorates every EGL entrypoint with _EGL_FUNC_START, which records
the function name and primary dispatch object label in the current
thread state. It also adds debug report functions and calls them when
appropriate.
This would be useful enough for debugging on its own, if the user set a
breakpoint when the report function was called. We will also need this
state tracked in order to expose EGL_KHR_debug.
v2:
- Clear the object label in more cases in _eglSetFuncName
- Pass draw surface (if any) to _EGL_FUNC_START in eglSwapInterval
v3:
- Set dummy thread's CurrentAPI to EGL_OPENGL_ES_API not zero
- Less ?: in _eglSetFuncName
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.veliko@collabora.com>
There should be no functional change here because Broxton and CHV are
both gt1. Without this code however, it might seem like broxton support
is missing.
While here, put the gt1 check in front to hopefully short-circuit the
condition for the mobile cases.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The difference to the virtually identical ARB_robustness (which is already
enabled unconditionally) is miniscule and handled elsewhere, but this cap
seems like the right thing to require for this extension.
v2: drop the device reset cap requirement (Ilia)
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Check for device reset on flush. It would be nicer if the kernel just
reported this as an error on the submit ioctl (and similarly for fences),
but this will do for now.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is basically a re-write of the slab allocator into a design where
multiple child pools are linked to a parent pool. The intention is that
every (GL, pipe) context has its own child pool, while the corresponding
parent pool is held by the winsys or screen, or possibly the GL share group.
The fast path is still used when objects are freed by the same child pool
that allocated them. However, it is now also possible to free an object in a
different pool, as long as they belong to the same parent. Objects also
survive the destruction of the (child) pool from which they were allocated.
The slow path will return freed objects to the child pool from which they
were originally allocated. If that child pool was destroyed, the corresponding
page is considered an orphan and will be freed once all objects in it have
been freed.
This allocation pattern is required for pipe_transfers that correspond to
(GL) buffer object mappings when the mapping is created in one context
which is later destroyed while other contexts of the same share group live
on -- see the bug report referenced below.
Note that individual drivers do need to migrate to the new interface in
order to benefit and fix the bug.
v2: use singly-linked lists everywhere
v3: use p_atomic_set for page->u.num_remaining
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97894
This is motivated by the fact that p_atomic_read and p_atomic_set may
somewhat surprisingly not do the right thing in the old version: while
stores and loads are de facto atomic at least on x86, the compiler may
apply re-ordering and speculation quite liberally. Basically, the old
version uses the "relaxed" memory ordering.
The new ordering always uses acquire/release ordering. This is the
strongest possible memory ordering that doesn't require additional
fence instructions on x86. (And the only stronger ordering is
"sequentially consistent", which is usually more than you need anyway.)
I would feel more comfortable if p_atomic_set/read in the old
implementation were at least using volatile loads and stores, but I
don't see a way to get there without typeof (which we cannot use here
since the code is compiled with -std=c99).
Eventually, we should really just move to something that is based on
the atomics in C11 / C++11.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Anv programs the hardware to use L3 data cache if we use either SSBOs or
images in the shaders, we can program i965 the same way.
gl_shader_program has a bit of a confusing named field with
'NumAtomicBuffers'. It doesn't tell how many buffers are accessed by the
shader in an atomic way but instead the number of atomic counters
manipulated by the shader.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
ES3-CTS.functional.negative_api.buffer.framebuffer_texture2d expects
glFramebufferTexture[123]D to raise GL_INVALID_ENUM when
supplied a completely bogus textarget parameter (i.e. 0xffffffff).
This is at odds with the spec. GLES 3.1 says:
"An INVALID_OPERATION error is generated if texture is not zero and
textarget is not one of TEXTURE_2D, TEXTURE_2D_MULTISAMPLE, or one
of the cube map face targets from table 8.21."
(and GLES 3.0 and GL 4.5 both have similar text). However, GL has a
general guideline that says:
"If a command that requires an enumerated value is passed a symbolic
constant that is not one of those specified as allowable for that
command, an INVALID_ENUM error is generated."
Apparently other vendors reconcile these two rules as follows: GL should
raise INVALID_OPERATION for actual texture target enumeration values
which are not allowed for this particular glFramebufferTexture*D call.
Any value that is not a texture target should result in GL_INVALID_ENUM.
For example, glFramebufferTexture2D with GL_TEXTURE_1D would result in
INVALID_OPERATION because it is a real texture target, but not allowed
for the 2D version of the function. But calling it with GL_FRONT would
result in INVALID_ENUM, as that isn't even a texture target.
Fixes:
- {ES3-CTS,dEQP-GLES3}.functional.negative_api.buffer.framebuffer_texture2d
- {ES31-CTS,ES32-CTS,dEQP-GLES31}.functional.debug.negative_coverage.get_error.buffer.framebuffer_texture2d
References: https://gitlab.khronos.org/opengl/cts/merge_requests/387
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Having one top-level switch statement covering all known texture targets
will make the next change easier to implement.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
From the less man page:
"Warning: when the -r option is used, less cannot keep track of the
actual appearance of the screen (since this depends on how the
screen responds to each type of control character). Thus, various
display problems may result, such as long lines being split in the
wrong place."
Lines which are too long to fit in the terminal would be word wrapped,
but unfortunately less would get confused about which line it was on,
and text would be drawn on top of other text. The most noticable case
was shader assembly, which is frequently too wide for an 80 character
terminal, and thus would be drawn on top of the following state packets,
making them completely unreadable.
Using -R instead of -r fixes this problem by only allowing color escape
sequences. (Notably, Git's implicit pager invocation uses -R.)
Unfortunately, it means our "clear to the end of the line" hack for
extending the blue bar headers won't work anymore.
Word wrapping usually isn't terribly readable, anyway, so we also add
the -S option (chop long lines) to restrict it to the terminal width.
(You can hit the left and right arrow keys to scroll sideways.)
Then, for a new blue bar hack, we can use a printf specifier to pad
the command packet names to be 80 characters long (arbitrarily), which
extends them "far enough" to look good, and doesn't require us to use
ioctls to determine the terminal width.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Sirisha Gandikota <sirisha.gandikota@intel.com>
The atom that uploads push constants listens to _NEW_TRANSFORM for
legacy clip plane handling. On Sandybridge, the gen6_vs_state atom
emits 3DSTATE_CONSTANT_VS as well as 3DSTATE_VS, so it needs to listen
to the same set of conditions.
However, it looks like Gen7 doesn't need this. The push constant atom
emits 3DSTATE_CONSTANT_VS directly, and the gen7_vs_state atom that
emits 3DSTATE_VS doesn't have a dependency on ctx->Transform.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v2: Delete some stray debug code notice by Iago.
v3: Massive rebase on new ir_function_signature::intrinsic_id mechanism.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> [v1]
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Otherwise grepping for where atomic_counter_inc and friends are defined
is a very frustrating experience.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Just generate an __intrinsic_atomic_add with a negated parameter.
Some background on the non-obvious reasons for the the big change to
builtin_builder::call()... this is cribbed from some discussion with
Ilia on mesa-dev.
Why change builtin_builder::call() to allow taking dereferences and
create them here rather than just feeding in the ir_variables directly?
The problem is the neg_data ir_variable node would have to be in two
lists at the same time: the instruction stream and parameters. The
ir_variable node is automatically added to the instruction stream by the
call to make_temp. Restructuring the code so that the ir_variables
could be in parameters then move them to the instruction stream would
have been pretty terrible.
ir_call in the instruction stream has an exec_list that contains
ir_dereference_variable nodes.
The builtin_builder::call method previously took an exec_list of
ir_variables and created a list of ir_dereference_variable. All of the
original users of that method wanted to make a function call using
exactly the set of parameters passed to the built-in function (i.e.,
call __intrinsic_atomic_add using the parameters to atomicAdd). For
these users, the list of ir_variables already existed: the list of
parameters in the built-in function signature.
This new caller doesn't do that. It wants to call a function with a
parameter from the function and a value calculated in the function. So,
I changed builtin_builder::call to take a list that could either be a
list of ir_variable or a list of ir_dereference_variable. In the former
case it behaves just as it previously did. In the latter case, it uses
(and removes from the input list) the ir_dereference_variable nodes
instead of creating new ones.
text data bss dec hex filename
6036395 283160 28608 6348163 60dd83 lib64/i965_dri.so before
6036923 283160 28608 6348691 60df93 lib64/i965_dri.so after
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
text data bss dec hex filename
6036491 283160 28608 6348259 60dde3 lib64/i965_dri.so before
6036395 283160 28608 6348163 60dd83 lib64/i965_dri.so after
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
This necessetated renaming the is_intrinsic field to _is_intrinsic. The
next commit will remove the field.
text data bss dec hex filename
6036507 283160 28608 6348275 60ddf3 lib64/i965_dri.so before
6036491 283160 28608 6348259 60dde3 lib64/i965_dri.so after
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
text data bss dec hex filename
6038043 283160 28608 6349811 60e3f3 lib64/i965_dri.so before
6036507 283160 28608 6348275 60ddf3 lib64/i965_dri.so after
v2: s/ir_intrinsic_atomic_sub/ir_intrinsic_atomic_counter_sub/. Noticed
by Ilia.
v3: Silence unhandled enum in switch warnings in st_glsl_to_tgsi.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
text data bss dec hex filename
6037483 283160 28608 6349251 60e1c3 lib64/i965_dri.so before
6038043 283160 28608 6349811 60e3f3 lib64/i965_dri.so after
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
st_glsl_to_tgsi only calls lower_instructions once (instead of in a
loop), so the ir_binop_carry generated would not get lowered. Fixes
assertion failure
state_tracker/st_glsl_to_tgsi.cpp:2265: void glsl_to_tgsi_visitor::visit_expression(ir_expression*, st_src_reg*): Assertion `!"Invalid ir opcode in glsl_to_tgsi_visitor::visit()"' failed.
on softpipe in 16 piglit tests:
mesa_shader_integer_functions/execution/built-in-functions/fs-imulExtended-nonuniform.shader_test
mesa_shader_integer_functions/execution/built-in-functions/fs-imulExtended-only-msb-nonuniform.shader_test
mesa_shader_integer_functions/execution/built-in-functions/fs-imulExtended-only-msb.shader_test
mesa_shader_integer_functions/execution/built-in-functions/fs-imulExtended.shader_test
mesa_shader_integer_functions/execution/built-in-functions/fs-umulExtended-nonuniform.shader_test
mesa_shader_integer_functions/execution/built-in-functions/fs-umulExtended-only-msb-nonuniform.shader_test
mesa_shader_integer_functions/execution/built-in-functions/fs-umulExtended-only-msb.shader_test
mesa_shader_integer_functions/execution/built-in-functions/fs-umulExtended.shader_test
mesa_shader_integer_functions/execution/built-in-functions/vs-imulExtended-nonuniform.shader_test
mesa_shader_integer_functions/execution/built-in-functions/vs-imulExtended-only-msb-nonuniform.shader_test
mesa_shader_integer_functions/execution/built-in-functions/vs-imulExtended-only-msb.shader_test
mesa_shader_integer_functions/execution/built-in-functions/vs-imulExtended.shader_test
mesa_shader_integer_functions/execution/built-in-functions/vs-umulExtended-nonuniform.shader_test
mesa_shader_integer_functions/execution/built-in-functions/vs-umulExtended-only-msb-nonuniform.shader_test
mesa_shader_integer_functions/execution/built-in-functions/vs-umulExtended-only-msb.shader_test
mesa_shader_integer_functions/execution/built-in-functions/vs-umulExtended.shader_test
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This function is only ever used by an assert() this fixes an
unused function warning in release builds.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
v2: Make sure that with num_lods > 1 and min_filter != mag_filter we
still enter the splitting path. So this case would still use 4-wide aos
path (as a side note, the 4-wide aos sampling path could actually be
improved quite a bit if we have avx2, by just doing the filtering with
256bit vectors).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
_eglInitSync checked that the display supported the sync type (such as
EGL_SYNC_FENCE), and did it wrong. When the check failed it emitted
EGL_BAD_ATTRIBUTE, but sometimes EGL_BAD_PARAMETER is needed.
_eglCreateSync already does the error checking, and it does it right.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
When the function encountered an error, it effectively returned
immediately. However, it did so indirectly by breaking out of a loop.
Replace the loop breakout with a explicit 'return'.
Do the same for _eglParseSyncAttribList64 too.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This function converts an attribute list from EGLint[] to EGLAttrib[].
Will be used in following patches to cleanup EGLSync attribute parsing.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
When the user called eglCreateSync64KHR on a display without
EGL_KHR_cl_event2 (the only extension that exposes it), we returned
EGL_NO_SYNC but did not update the error code.
We also did the same for eglCreateSync on a display without EGL 1.5.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This patch causes 2 regressions in khronos' gles cts tests
on various intel platforms.
Failing tests:
ES3-CTS.functional.state_query.integers.viewport_getinteger
ES3-CTS.functional.state_query.integers.viewport_getfloat
Here is an explanation of what's causing the failures:
CTS tests are not clamping the x, y location of the viewport's
bottom-left corner as recommended by ARB_viewport_array and
OES_viewport_array:
"The location of the viewport's bottom-left corner, given by (x,y), are
clamped to be within the implementation-dependent viewport bounds range.
The viewport bounds range [min, max] tuple may be determined by
calling GetFloatv with the symbolic constant VIEWPORT_BOUNDS_RANGE_OES"
Khronos CTS merge request to fix the test case:
https://gitlab.khronos.org/opengl/cts/merge_requests/399
V2: Initialize the relevant variables for GL_OES_viewport_array on gen8+
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
For reference picture sets, there are cases that rps will not always
be used. Once detect the unused flag from encoded bitstream, we should
not add this rps to any list, otherwise pass the incorrect reference
and skip the correct rps.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
It will fix the corruption for frame, that only has one stort term ref
picture set, we set NULL rps for this case previously, causing taking
incorrect reference. Instead we should take that only short term set
as reference
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The video size from format container is not always compatible with
the size from codec bitstream, the HW decoder should take the size
information from bitstream, otherwise the corruption appears with clip
that has different size info between bitstream and format container
So we are passing width(height)_in_samples from sequence parameter
set to video decoder.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This reverts commit fc03ecfeaf.
Chad had already pushed the same change between me posting the patch and Jason
pushing it: 44bcf1ffcc (".gitignore: Ignore src/compiler/spirv2nir")
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This is enabled automatically if shader printing is enabled, or separately
by R600_DEBUG=checkir. Catch mal-formed IR before it crashes in a later
pass.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This changes the order of basic blocks to be equal to the order of code in the
original TGSI, which is nice for making sense of shader dumps.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Some of the existing code is needlessly complicated. The basic principle
should be: control-flow opcodes emit branches to properly terminate the
current block, _unless_ the current block already has a terminator (which
happens if and only if there was a BRK or CONT).
This also fixes a bug where multiple terminators were created in a block.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97887
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
si_llvm_emit_ddxy is called once per element, so we don't have to generate
code for 4 elements at once.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
do it at bind time, so that pipe_sampler_view is immutable with regard to
buffer reallocations and we don't have to remember all existing buffer
views.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
In core profile, we support up to 16 viewports. However, in the
majority of cases, only 1 of them is actually used - we only need
the others if the last shader stage prior to the rasterizer writes
gl_ViewportIndex.
Processing all 16 viewports adds additional CPU overhead, which hurts
CPU-intensive workloads such as Glamor. This meant that switching to
core profile actually penalized Glamor to an extent, which is
unfortunate.
This patch tracks the number of relevant viewports, switching between
1 and ctx->Const.MaxViewports if gl_ViewportIndex is written. A new
BRW_NEW_VIEWPORT_COUNT flag tracks this. This could mean re-emitting
viewport state when switching, but hopefully this is offset by doing
1/16th of the work in the common case. The new flag is also lighter
weight than BRW_NEW_VUE_MAP_GEOM_OUT, which we were using in one case.
According to Eric Anholt, x11perf -copypixwin10 performance improves by
11.5094% +/- 3.10841% (n=10) on his Skylake.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
Previously, we were saving off the last nir_block in a vtn_block before
moving on so that we could find the nir_block again when it came time to
handle phi sources. Unfortunately, NIR's control flow modification code is
inconsistent when it comes to how it splits blocks so the block pointer we
saved off may point to a block somewhere else in the shader by the time we
get around to handling phi sources. In order to get around this, we insert
a nop instruction and use that as the logical end of our block. Since the
control flow manipulation code respects instructions, the nop will keeps
its place like any other instruction and we can easily find the end of our
block when we need it.
This fixes a bug triggered by a couple of vkQuake shaders.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97233
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Tested-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This intrinsic has no destination, no sources, no variables, and can be
eliminated. In other words, it does nothing and will always get deleted by
dead code elimination. However, it does provide a quick-and-easy way to
temporarily tag a particular location in a NIR shader.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
We already do those checks in filter_tiling. There's no good reason to
repeat them in choose_msaa_layout. If anything they should have been
asserts and not "return false" checks. Also, this check was causing us to
outright reject multisampled HiZ surfaces which wasn't intended.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
The HiZ and CCS tiling formats are always used for HiZ and CCS surfaces
respectively. There's no reason why we should go through filter_tiling and
it's much easier to always get HiZ and CCS right if we just handle them
directly.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
HiZ buffers can be multisampled and, on Broadwell and earlier, simply using
interleaved multisampling with a compression block size of 8x4 samples
yields the correct HiZ surface size calculations. Unfortunately,
choose_msaa_layout was rejecting multisampled HiZ buffers because of format
checks. Now that we have a simple helper for determining if a format
supports multisampling, that's an easy enough issue to fix.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Compressed 1-D textures are not well-defined thing in either GL or Vulkan.
However, auxiliary surfaces are treated as compressed textures in ISL and
we can do HiZ and CCS with 1-D so we need to be able to create them. In
order to prevent actually using them (the docs say no), we assert in the
state setup code.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
The assertion that a format is uncompressed in the multisample layouts
isn't quite right. What we really want to assert is that the format
supports multisampling which is a bit more complicated query. We also want
to assert that it has a block size of 1x1 since we do nothing with the
block size in the phys_level0_sa assignment.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Previous fundamental change in stats gathering added a temporary
SwrWaitForIdle to begin_query and end_query. Code has been reworked to
remove stall.
Reviewed-by: George Kyriazis <george.kyriazis@intel.com>
Create worker pool now computes number of worker threads based on
things like topologies, etc. and creates the pool but doesn't actually
launch the threads. Instead there is a separate start thread pool
function. This allows thread resources to be constructed first before
threads start.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
- Immediately sleep threads until thread data is initialized
- Fix some compile bugs with AR enabled
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
- Move most jitter functionality into SwrJit namespace
- Avoid global "using namespace llvm" in headers
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
gcc-4 and earlier don't allow compound literals where a constant
is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
when populating the anv_formats[] array. There are a few ways around
it: First one would be -std=c89/gnu89, but the rest of the code
depends on c99 so it's not really an option. The second option
would be to upgrade to gcc-5+ where the compiler behaviour was relaxed
a bit [1]. And the third option is just to avoid using compound
literals. I chose the last option since it keeps gcc-4 and earlier
working.
[1] https://gcc.gnu.org/gcc-5/porting_to.html
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Topi Pohjolainen <topi.pohjolainen@intel.com>
Fixes: 7ddb21708c ("intel/isl: Add an isl_swizzle structure and use it for isl_view swizzles")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This fixes a crash in egl-create-msaa-pbuffer-surface Piglit test
and same crash in many dEQP EGL tests.
I also found that some Qt example did a workaround because of this
crash: https://bugreports.qt.io/browse/QTBUG-47509
v2: Ian pointed out that v1 removed support for all multisample
configs, including window ones. This one removes pbuffer bit
when adding configs, now only pbuffer+msaa gets rejected and
window+msaa continues to work. Fixed also comment (Emil)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
While the current CFG code is valid in the case where a switch break also
happens to be a loop continue, it's a bit suboptimal. Since hardware is
capable of handling the continue as a direct jump, it's better to use a
continue instruction when we can than to bother with all of the nasty
switch break lowering.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
It is possible that the break block of a switch is actually the continue of
the loop containing the switch. In this case, we need to identify the
break block as a continue and break out of current level of CFG handling.
If we don't, the continue portion of the loop will get handled twice, once
by following after the break and a second time by the loop handling code
handling it explicitly.
This fixes 6 of the new Vulkan CTS tests:
- dEQP-VK.spirv_assembly.instruction.graphics.opphi.out_of_order*
- dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order*
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
These structs will be written to disk as part of the shader cache
so use uint32_t just to be safe.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Almost all of the other drawing validation code is in api_validate.c
so put this function there as well.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Detect all of the CPUs in the system. Expose metrics
for min, max and current frequency in Hz.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Regression introduced by "gallium/radeon: zero all query buffers".
Cc: Michel Dänzer <michel@daenzer.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is only needed for r600 which doesn't have ARB_query_buffer_object and
therefore wouldn't really need the fences, but let's be optimistic about
filling in this feature gap eventually.
Cc: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We don't plan to use sub-allocated buffers with UVD, but just in case one
slips through, this increases the chances of things working out anyway.
Reviewed-by: Christian König <christian.koenig@amd.com>
We don't plan to use sub-allocated buffers with VCE, but just in case one
slips through, this increases the chances of things working out anyway.
Reviewed-by: Christian König <christian.koenig@amd.com>
Implement support for power based sensors, reporting units in
milli-watts and watts.
Also, minor cleanup - change the related if block to a switch.
Tested with two different power sensors, including the nouveau
'power1' sensors on a GTX950 card.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Commutativity is not allowed with SHLADD, but src2 can accept
loads. To allow the load propagation pass to do its job, add a
special case like for SUCLAMP because src1 is always an immediate.
This IMAD to SHLADD optimization helps a bunch of shaders from Tomb
Raider, Victor Vran, UE4 demos (+15% perf with Elemental) and Shadow
Warrior.
GF100/GK104:
total instructions in shared programs :2838045 -> 2834712 (-0.12%)
total gprs used in shared programs :396684 -> 396386 (-0.08%)
total local used in shared programs :34416 -> 34416 (0.00%)
local gpr inst bytes
helped 0 326 1105 1105
hurt 0 55 3 3
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Unfortunately, we can't use the emit helpers for GF100/GK110
because src1 and src2 are swapped.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This instruction is available since SM20 (Fermi) and allow to do
(a << b) + c in one shot. In some situations, IMAD should be
replaced by SHLADD when b is a power of 2, and ADD+SHL should be
replaced by SHLADD as well.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
envyas now uses a much better representation for those control
codes and it displays the different flags instead of an
unreadable hex number.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Most of the time, even the 512 bytes that we now get is more than sufficient
(pipeline stats queries are the largest at 184 bytes per shot).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We will support the waiting option in ARB_query_buffer_object using
WAIT_REG_MEM on an appropriate fence-like dword. Some queries conveniently
write their results with the highest bit set, and we can just use that;
for others, we have to write a fence explicitly.
ZPASS_DONE for occlusion queries writes its results with the high bit
set, but it writes up to 8 pairs of results (one for each DB). We have
to wait for all of these results, so let's just add an explicit fence.
The new function provides summary information to be used by subsequent
patches.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Save compute shader state that will be used for the ARB_query_buffer_object
implementation.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
These functions extract the pipe state structure from the current
descriptors, for state saving.
v2: correctly dereference *buf (Bas)
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
There are driver-specific context flags for barriers that are not covered
by the Gallium barrier interfaces.
The R600 settings of these flags may not be optimal, but we're not going
to use them yet anyway.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
V8: Feedback based on peer review
convert if block into a switch
Constify some func args
V7: Increase precision when measuring lmsensors volts
Flatten patch series.
V6: Feedback based on peer review
Simplify sensor initialization (arg passing).
Constify some func args
V5: Feedback based on peer review
Convert sprintf to snprintf
Convert char * to const char *
int arg converted to bool
Func changes to take a filename vs a larger struct.
Omit the space between '*' and the param name.
V4: Merged with master as of 2016/9/27 6pm
V3: Flatten the entire patchset ready for the ML
V2: Additional seperate patches based on feedback
a) configure.ac: Add a comment related to libsensors
b) HUD: Disable Block/NIC I/O stats by default.
Implement configuration option --enable-gallium-extra-hud=yes
and enable both statistics when this option is enabled.
c) Configure.ac: Minor cleanup to user visible configuration settings
d) Configure.ac: HUD stats - build system improvements
Move the -lsensors out of a deeper Makefile, bring it into the configure.ac.
Also, rename a compiler directive to more closely follow the standard.
V1: Initial release to the ML
Three new features:
1. Disk/block I/O device read/write stats MB/ps.
2. Network Interface RX/TX transfer statistics as a percentage
of the overall NIC speed.
3. lmsensor power, voltage and temperature sensors.
The lmsensor changes makes a dependency on libsensors so support
for the change is opt out by default.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The code already skips doing the depth stall on gen >= 8, and as we
enable new platforms this assertion will fail needlessly. Instead of
changing the caller, make this simple change.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
I found this in a shader that was doing an alpha test when alpha is fixed
at 1.0.
v2: Rebase on master (now the const value is "u32" not "u").
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (v1)
Fixes lots of piglit tests crashing due to using uninitialized memory.
Fixes: ecd6fce261 ("mesa/st: support lowering multi-planar YUV")
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This code provides for an on-disk cache of objects. Objects are stored
and retrieved via names that are arbitrary 20-byte sequences,
(intended to be SHA-1 hashes of something identifying for the
content). The directory used for the cache can be specified by means
of environment variables in the following priority order:
$MESA_GLSL_CACHE_DIR
$XDG_CACHE_HOME/mesa
<user-home-directory>/.cache/mesa
By default the cache will be limited to a maximum size of 1GB. The
environment variable:
$MESA_GLSL_CACHE_MAX_SIZE
can be set (at the time of GL context creation) to choose some other
size. This variable is a number that can optionally be followed by
'K', 'M', or 'G' to select a size in kilobytes, megabytes, or
gigabytes. By default, an unadorned value will be interpreted as
gigabytes.
The cache will be entirely disabled at runtime if the variable
MESA_GLSL_CACHE_DISABLE is set at the time of GL context creation.
Many thanks to Kristian Høgsberg <krh@bitplanet.net> for the initial
implementation of code that led to this patch. In particular, the idea
of using an mmapped file, (indexed by a portion of the SHA-1), for the
efficent implementation of cache_has_key was entirely his
idea. Kristian also provided some very helpful advice in discussions
regarding various race conditions to be avoided in this code.
Signed-off-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Needed to successfully link llvmpipe or swr when using shared llvm libs
built with inteljitevents enabled.
v2: Make adding inteljitevents component global rather than just
llvmpipe/swr, since libgallium will have a symbol dependency.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Small buffers are now handled via the slabs code, so separate buckets in
pb_cache have become redundant.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Only enable for chips with GPUVM, because older driver paths do not take the
required offset into account.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Note the logic for adding fences is somewhat different than for amdgpu,
because radeon has no scheduler and we therefore have no guarantee about
the order in which submissions from multiple threads are processed.
(Ironically, this is only an issue when "multi-threaded submission" is
disabled, because "multi-threaded submission" actually means that all
submissions happen from a single thread that happens to be separate from
the application's threads. If we only supported "multi-threaded
submission", the fence handling could be simplified by adding the fences
in that thread where everything is serialized.)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When a buffer is added to a CS without the SYNCHRONIZED usage flag, we now
no longer add a dependency on the buffer's fence(s).
However, we still need to add a fence to the buffer during flush, so that
cache reclaim works correctly (and in the hypothetical case that the buffer
is later added to a CS _with_ the SYNCHRONIZED flag).
It is now possible that the submissions refererring to a buffer are no longer
linearly ordered, and so we may have to keep multiple fences around. We keep
the fences in a FIFO. It should usually stay quite short (# of contexts * 2,
for gfx + dma rings).
While we're at it, extract amdgpu_add_fence_dependency for a single buffer,
which will make adding the distinction between real buffer and slab cases
easier.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When passed to winsys->buffer_create, this flag will indicate that we require
a buffer that maps 1:1 with a kernel buffer handle.
This is currently set for all textures, since textures can potentially be
exported to other processes. This is not a huge loss, since the main purpose
of this patch series is to deal with applications that allocate many small
buffers.
A hypothetical application with tons of tiny textures might still benefit
from not setting this flag, but that's not a use case I'm worried about
just now.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is really the behavior we want most of the time, but having a
SYNCHRONIZED flag instead of an UNSYNCHRONIZED one has the advantage that
OR'ing different flags together always results in stronger guarantees.
The parent BOs of sub-allocated buffers will be added unsynchronized.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is a simple framework for slab allocation from buffers that fits into
the buffer management scheme of the radeon and amdgpu winsyses where bufmgrs
aren't used.
The utility knows about different sized allocations and explicitly manages
reclaim of allocations that have pending fences. It manages all the free lists
but does not actually touch buffer objects directly, relying on callbacks for
that.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The implementation of i915_drm_buffer_get_handle now handles
DRM_API_HANDLE_TYPE_FD in the same way that intel_winsys_import_handle
does, by calling drm_intel_bo_gem_create_from_prime.
Tested by successfully running Chrome's ozone_demo [1] with the
ozone-gbm backend on an Intel Pineview M machine. Without this change
it fails while trying to create a DMA-BUF.
[1] https://chromium.googlesource.com/chromium/src.git/+/master/ui/ozone/demo/ozone_demo.cc
Signed-off-by: Nicholas Bishop <nbishop@neverware.com>
[Emil Velikov: Fix coding style]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Change dri2_query_image to check the return value of resource_get_handle
and return GL_FALSE if an error occurs.
For reference this is an example callstack that should propagate the
error back to the user:
i915_drm_buffer_get_handle
i915_texture_get_handle
u_resource_get_handle_vtbl
dri2_query_image
gbm_dri_bo_get_fd
gbm_bo_get_fd
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Nicholas Bishop <nbishop@neverware.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
[Emil Velikov: Split from larger patch, polish coding style, cc stable]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Change gbm_dri_bo_get_fd to check the return value of queryImage and
return -1 (an invalid file descriptor) if an error occurs.
Update the comment for gbm_bo_get_fd to return -1, since (apart from the
above) we've already return -1 on error.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Nicholas Bishop <nbishop@neverware.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
[Emil Velikov: Split from larger patch, polish coding style, cc stable]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
For now that's never since advanced blend hasn't been piped through.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Marek Olšák <marek.olsak@amd.com>
As part of the shader-cache work an upcoming change will add new
references to _mesa_add_parameter and _mesa_new_parameter_list from
the glsl code. To prepare for that, and to allow the standalone
glsl_compiler to still link, here we add mesa/program/prog_parameter.c
to the libglsl_util sources.
Then, in order to get *that* to work, we also add to stubs to
standalone_scaffolding:
_mesa_program_state_flags
_mesa_program_state_string
These functions aren't actually used by the two functions in
prog_parameter.c that we are actually calling. They are used in other
functions in the same file. So we don't care what the implementation
of these stubs is, (they won't be called by glsl_compiler). We just
need the stubs present so that it can link.
Signed-off-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Support multi-planar YUV for external EGLImage's (currently just in the
dma-buf import path) by lowering to multiple texture fetch's for each
plane and CSC in shader.
There was some discussion of alternative approaches for tracking the
additional UV or U/V planes:
https://lists.freedesktop.org/archives/mesa-dev/2016-September/127832.html
They all seemed worse than pipe_resource::next
Signed-off-by: Rob Clark <robdclark@gmail.com>
Fixed the way the values that span two Dwords are decoded.
Based on the start and end indices of the field, the Dwords
are fetched and decoded accordingly.
v2: rename dw to qw in gen_field_iterator_next
and remove extra white space (Anuj)
v3: change all instances of dw to qw (Anuj)
Earlier, 64-bit fields (such as most pointers on Gen8+)
weren't decoded correctly. gen_field_iterator_next seemed
to walk one DWord at a time, sets v.dw, and then passes it
to field(). So, even though field() takes a uint64_t, we're
passing it a uint32_t (which gets promoted, so the top 32
bits will always be zero). This seems pretty bogus... (Ken)
Signed-off-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This adds a new envvar called NV50_PROG_CHIPSET which allows to
compile shaders with a different target, especially useful for
shader-db.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Based off of Ilia's original patch, but with output values replicated so
that it matches the TGSI semantics.
Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
This is needed to be consistent with other drivers.
Signed-off-by: Emilio Cobos Álvarez <me@emiliocobos.me>
Reviewed-by: Brian Paul <brianp@vmware.com>
Usually, there's no user-specified texture swizzle so we can optimize
the swizzle_swizzle() function and skip the loop/switch.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Some demos, like Heaven, were creating and destroying a large number
of sampler views because of a swizzle issue.
Basically, we compute the sampler view's swizzle by examining the
texture format, user swizzle, depth mode, etc. Later, during validation
we recompute that swizzle (in case something like depth mode changes)
and see if it matches the view's swizzle.
In the case of PIPE_FORMAT_RGTC2_UNORM, get_texture_format_swizzle
returned SWIZZLE_XYZW but the u_sampler_view_default_template() function
was setting the sampler view's swizzle to SWIZZLE_XY01. This mismatch
caused the validation step to always "fail" so we'd destroy the old
sampler view and create a new one.
By removing the conditional, the sampler view's swizzle and the computed
texture swizzle match and validation "passes". When creating a new sampler
view, we always want to use the texture swizzle which we just computed.
Fixes VMware issue 1733389.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
When we create a depth/stencil texture, also check if we can render to
it and set the PIPE_BIND_DEPTH_STENCIL flag. We were previously doing
this for color textures (PIPE_BIND_RENDER_TARGET).
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
This may have been needed years ago during development, but not now.
Prevents some regressions after introducing the next patch.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
To handle z/layer fix-ups for blitting and copying. Note that we weren't
doing this properly in svga_blit() before.
Also, remove redundant stex, dtex assignments.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
The util_is_format_compatible() function didn't quite do what we wanted
for vgpu10. This check is more flexible and allows copies between
formats such as R32G32B32A32_FLOAT and R32G32B32A32_INT.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
With latest mesa and latest piglit tests srgb<->linear conversion
is not required as per GL4.4 rules
See commit b662c70aea.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
This reverts commit f5a6aab403.
This broke some tests. It seems gl_transform_feedback_info gets memset
to 0 so we were losing the values in BufferStride before we used them.
Now that we generate built-in functions inline, there's no need to link
against the built-in shader, and no built-in prototypes to consider.
This lets us delete a bunch of code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by; Ian Romanick <ian.d.romanick@intel.com>
In the past, we imported the prototypes of built-in functions, generated
calls to those, and waited until link time to resolve the calls and
import the actual code for the built-in functions.
This severely limited our compile-time optimization opportunities: even
trivial functions like dot() were represented as function calls. We
also had no way of reasoning about those calls; they could have been
1,000 line functions with side-effects for all we knew.
Practically all built-in functions are trivial translations to
ir_expression opcodes, so it makes sense to just generate those inline.
Since we eventually inline all functions anyway, we may as well just do
it for all built-in functions.
There's only one snag: built-in functions that refer to built-in global
variables need those remapped to the variables in the shader being
compiled, rather than the ones in the built-in shader. Currently,
ftransform() is the only function matching those criteria, so it seemed
easier to just make it a special case.
On Skylake:
total instructions in shared programs: 12023491 -> 12024010 (0.00%)
instructions in affected programs: 77595 -> 78114 (0.67%)
helped: 97
HURT: 309
total cycles in shared programs: 137239044 -> 137295498 (0.04%)
cycles in affected programs: 16714026 -> 16770480 (0.34%)
helped: 4663
HURT: 4923
while these statistics are in the wrong direction, the number of
hurt programs is small (309 / 41282 = 0.75%), and I don't think
anything can be done about it. A change like this significantly
alters the order in which optimizations are performed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by; Ian Romanick <ian.d.romanick@intel.com>
We want to check prior to optimization - otherwise we might fail to
detect cases where barrier() is in control flow which is always taken
(and therefore gets optimized away).
We don't currently loop unroll if there are function calls inside;
otherwise we might have a problem detecting barrier() in loops that
get unrolled as well.
Tapani's switch handling code adds a loop around switch statements, so
even with the mess of if ladders, we'll properly reject it.
Enforcing these rules at compile time makes more sense more sense than
link time. Doing it at ast-to-hir time (rather than as an IR pass)
allows us to emit an error message with proper line numbers.
(Otherwise, I would have preferred the IR pass...)
Fixes spec/arb_tessellation_shader/compiler/barrier-switch-always.tesc.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by; Ian Romanick <ian.d.romanick@intel.com>
It makes more sense to have this here where we store the other values
from xfb qualifiers. The struct it was previously part of is now only
used to store values that come from the api.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
This reverts commit e66a2b879b.
Which breaks the scons build in an interesting way, particularly when
BlendBarrier and PrimitiveBoundingBox are added to static_data.py's
functions list. This seems to be related to the fact that the unsuffixed
names are only in GLES3.2, but Desktop GL only has suffixed versions.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
From the Vulkan spec:
Size is the number of bytes to fill, and must be either a multiple of 4,
or VK_WHOLE_SIZE to fill the range from offset to the end of the buffer.
If VK_WHOLE_SIZE is used and the remaining size of the buffer is not a
multiple of 4, then the nearest smaller multiple is used.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Now that we have gen_device_info mutable, we can update its values and drop
all copies we had in brw_context.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Make gen_device_info a mutable structure so we can update the fields that
can be refined by querying the kernel (like subslices and EU numbers).
This patch does not make any functional change, it just makes
gen_get_device_info() fill a structure rather than returning a const
pointer.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This just up-converts them to doubles. Not great, but this is what all
the other variants also do.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The expectation is that drivers will set this based on
OES_geometry_shader and ARB_viewport_array support. This is a separate
enable on the same reasoning as for OES_texture_cube_map_array.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This file currently uses a mixture of 3 and 4 space indent. I have
changed it all to 4 space indent, matching the settings in
$ROOT/.editorconfig.
This was generated with sed:
sed -i -e 's@^ "@ "@g'
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
OpAtomicLoad/Store should have pointer to images just like the rest of the
atomic operators. These couple of lines were poorly copied from the
ssbo/shared_vars cases (the only ones currently tests by the CTS).
Fixes 2afb950161 ("spirv/nir: Add support for OpAtomicLoad/Store")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
VC4 was running into a major performance regression from enabling control
flow in the glmark2 conditionals test, because of short if statements
containing an ffract.
This pass seems like it was was trying to ensure that we only flattened
IFs that should be entirely a win by guaranteeing that there would be
fewer bcsels than there were MOVs otherwise. However, if the number of
ALU ops is small, we can avoid the overhead of branching (which itself
costs cycles) and still get a win, even if it means moving real
instructions out of the THEN/ELSE blocks.
For now, just turn on aggressive flattening on vc4. i965 will need some
tuning to avoid regressions. It does looks like this may be useful to
replace freedreno code.
Improves glmark2 -b conditionals:fragment-steps=5:vertex-steps=0 from 47
fps to 95 fps on vc4.
vc4 shader-db:
total instructions in shared programs: 101282 -> 99543 (-1.72%)
instructions in affected programs: 17365 -> 15626 (-10.01%)
total uniforms in shared programs: 31295 -> 31172 (-0.39%)
uniforms in affected programs: 3580 -> 3457 (-3.44%)
total estimated cycles in shared programs: 225182 -> 223746 (-0.64%)
estimated cycles in affected programs: 26085 -> 24649 (-5.51%)
v2: Update shader-db output.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
From reading the code, it's not obvious what is src/dest compatible.
The list of a->b copy-compatible formats comes from Jose's original
check-in message, with some format name updates.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
It's already advertised because the version.c extension checks are
fulfilled, but we didn't actually claim support, so trying to create
a ES 3.2 context would fail.
It's all done, and the CTS results look good, so let's turn it on.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We already support all of the decorations that require this capability.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This was something that I wrote in the early days of the spirv_to_nir code
but deleted once we had a real driver. However, in the absence of a
shader_runner equivalent, it's extremely useful for debugging the
spirv_to_nir code so let's bring it back.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
The offset should not always be 0. For example, if EGLImage is
created from a 2D texture with EGL_GL_TEXTURE_LEVEL=1, then the
offset should be the actual start of miplevel 1 in bo.
v2: Add version check of __DRIimageExtension implementation
(Suggested by Axel Davy).
v3: Don't add version check of __DRIimageExtension implementation.
Set the offset only when queryImage() succeeds. (Suggested by Emil
Velikov)
Signed-off-by: Chuanbo Weng <chuanbo.weng@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
[Emil Velikov: coding style fixes]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Not [originally] intended for upstream. Should cause a GPU hang if
some thread is executed with a non-contiguous dispatch mask breaking
assumptions of brw_stage_has_packed_dispatch(). Doesn't cause any
CTS, DEQP or Piglit regressions, while replacing
brw_stage_has_packed_dispatch() with a dummy implementation that
unconditionally returns true on top of this patch causes multiple GPU
hangs.
v2: Refactor into a separate function instead of emitting the test
code directly from emit_nir_code(), drop VEC4 test and clean up
slightly for upstream. (Jason)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This avoids emitting a few extra instructions required to take the
dispatch mask into account when it's known to be tightly packed.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The eliminate_find_live_channel optimization eliminates
FIND_LIVE_CHANNEL instructions in cases where control flow is known to
be uniform, and replaces them with 'MOV 0', which in turn unblocks
subsequent elimination of the BROADCAST instruction frequently used on
the result of FIND_LIVE_CHANNEL. This is however not correct in
per-sample fragment shader dispatch because the PSD can dispatch a
fully unlit sample under certain conditions. Disable the optimization
in that case.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v2: Add devinfo argument to brw_stage_has_packed_dispatch() to
implement hardware generation check.
On at least Sky Lake, ce0 does not contain the full story as far as enabled
channels goes. It is possible to have completely disabled channels where
the corresponding bits in ce0 are 1. In order to get the correct execution
mask, you have to mask off those channels which were disabled from the
beginning by taking the AND of ce0 with either sr0.2 or sr0.3 depending on
the shader stage. Failure to do so can result in FIND_LIVE_CHANNEL
returning a completely dead channel.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Francisco Jerez <currojerez@riseup.net>
[ Francisco Jerez: Fix a couple of typos, add mask register type
assertion, clarify reason why ce0 can have bits set for disabled
channels, clarify that this may only be a problem when thread
dispatch doesn't pack channels tightly in the SIMD thread. Apply
same treatment to Align16 path. ]
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The state register sr0 is really a collection of dwords not a SIMD8
anything. It's much more convenient for brw_sr0_reg to return the
particular dword you're looking for rather than a giant blob you have to
massage into what you want.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
[ Francisco Jerez: Trivial simplification of brw_ud1_reg(). ]
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This enables 64-bit integer support in gallivm and
llvmpipe.
v2: add conversion opcodes.
v3:
- PIPE_CAP_INT64 is not there yet
- restrict DIV/MOD defaults to the CPU, as for 32 bits
- TGSI_OPCODE_I2U64 becomes TGSI_OPCODE_U2I64
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This adds all the opcodes to tgsi_exec for softpipe to use.
v2: add conversion opcodes.
v3:
- no PIPE_CAP_INT64 yet
- change TGSI_OPCODE_I2U64 to TGSI_OPCODE_U2I64
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This just adds the basic support for 64-bit opcodes,
and the new types.
v2: add conversion opcodes.
add documentation.
v3:
- make docs more consistent
- change TGSI_OPCODE_I2U64 to TGSI_OPCODE_U2I64
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v2)
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
"intelScreen" is wordy and also doesn't fit our style guidelines.
"screen" is shorter, which is nice, because we use it fairly often.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
I want to use "screen" as the variable name for a struct intel_screen
pointer. This means that we can't use it for __DRIscreen pointers.
Sometimes we called it "screen", sometimes "sPriv", sometimes
"driScrnPriv", and sometimes "psp" (Pointer to Screen Private?).
The last one is particularly confusing because we use "psp" to refer to
the Gen4 PIPELINED_STATE_POINTERS packet as well.
Let's be consistent. "dri_screen" is clear, and it's not used often
enough that I'm worried about the verbosity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This extension is a combination of AMD_vertex_shader_viewport_index and
AMD_vertex_shader_layer, making it rather trivial to implement.
For gallium I *think* this needs a new cap because of the addition of
support in tessellation evaluation shaders, and since I don't have any
hardware to test it on, I've left that for someone else to wire up.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
so that the texture is rendered to back buffer before calling
flush_frontbuffer and can be copied to a different buffer in
the function
v2: change comment style
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
so that the texture is rendered to back buffer before calling
flush_frontbuffer and can be copied to a different buffer in
the function
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
In case of prime when rendering is done on GPU other then the
server GPU, use a seprate linear buffer for each back buffer
which will be displayed using present extension.
v2: Use a seprate linear buffer for each back buffer (Michel)
v3: Change variable names and fix coding style (Leo and Emil)
v4: Use PIPE_BIND_SAMPLER_VIEW for back buffer in case when
a seprate linear buffer is used (Michel)
v4.1: remove empty line
v4.2: destroy the context and handle the case when
create_context fails (Emil)
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
This function was quite similar to nvc0_stage_set_sampler_views()
and I don't see any reasons to not remove it.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This helps shaders in UE4 demos, especially with Elemental
(+1% perf). This optimization reduces spilling usage in one
shader which explains the little gain.
GF100/GK104:
total instructions in shared programs :2838551 -> 2838045 (-0.02%)
total gprs used in shared programs :396706 -> 396684 (-0.01%)
total local used in shared programs :34432 -> 34416 (-0.05%)
local gpr inst bytes
helped 1 19 112 112
hurt 0 0 0 0
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
A couple of forward-declarations were causing warnings in clang:
'value' defined as a class here but previously declared as a struct
[-Wmismatched-tags]
Signed-off-by: Martina Kollarova <martina.kollarova@intel.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Given robust access, we should just be returning zeroes if the user gives
us a base pointer that's too big, which is what was happens on a release
build. This was caught by a webgl conformance test for out-of-bounds
draws on servo.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes the following piglit test (for softpipe):
/spec/glsl-1.10/execution/fs-loop-return
Signed-off-by: Lars Hamre <chemecse@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch relaxes the restriction of compressed formats for texture
upload buffer. For now, 3D texture with compressed format
is still not supported in the texture upload buffer path.
As Brian noted, ETQW does many texture updates with glCompressedTexSubImage.
This patch greatly improves the performance of the ETQW trace.
Tested with ETQW, MTT piglit, glretrace, conform, viewperf
v2: Per Brian's suggestion, removed the subregion boundary check.
Reviewed-by: Brian Paul <brianp@vmware.com>
This reduces the number of times we flush in some situations (the
arbocclude demo is one trivial example).
Tested with Piglit, ETQW, Sauerbraten, arbocclude.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Since commit 99d8fe20ab we don't have to flush the command buffer when
we end a query.
Tested with Piglit, Sauerbraten, arbocclude, ETQW (noticably faster now).
Reviewed-by: José Fonseca <jfonseca@vmware.com>
With this patch, when running with vgpu10, instead of mapping directly to the
guest backed memory for texture update, we'll use the texture upload buffer
and use the transfer from buffer command to update the host side texture memory.
This optimization yields about 20% performance improvement with
Lightsmark2008 and about 40% with Tropics.
Tested with Lightsmark2008, Tropics, Heaven, MTT piglit, glretrace, conform.
Reviewed-by: Brian Paul <brianp@vmware.com>
Split the functions into separate functions for dma and direct map to make
the code more readable.
Tested with MTT piglit, glretrace, viewperf, conform, various OpenGL apps
Reviewed-by: Brian Paul <brianp@vmware.com>
With this patch, single sample surface will be created as non-multisamples
surface.
Tested with piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch fixes a memory leak with sampler state when piglit
is run with HW version 11. Sampler state clean up was incorrectly skipped
in svga_cleanup_sampler_state() for vgpu9.
Tested with piglit.
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Left over test code spotted by Sinclair.
Tested with piglit, Google Earth, Lightsmark, Heaven4, glretraces, etc.
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Use SVGA3D_QUERYTYPE_MAX instead of SVGA_QUERY_MAX for
svga query type check.
Tested with various OpenGL apps with GALLIUM_HUD set.
Reviewed-by: Brian Paul <brianp@vmware.com>
Replace the num-resources-mapped hud with
num-textures-mapped and num-buffers-mapped, so we can
differentiate the map counts for these two different resources.
Reviewed-by: Brian Paul <brianp@vmware.com>
Some OpenGL apps, like Cinebench R15, have many glDrawElements(GL_QUADS)
calls. Since we don't directly support quads we have to convert these
calls into GL_TRIANGLES which involves generating a new index buffer.
This patch saves the new/translated index buffer in the hope that it
can be reused for a later draw call.
Cinebench R15 increases by about 20% with this change.
The NobelClinician Viewer app also hits this code.
Tested with full piglit run.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
If a consecutive sequence of drawing commands references the same
vertex/index buffers, there should be no need to rebind the surfaces
for the second and subsequent drawing commands.
Apps that use multiple display lists benefit from this since the vertex
data for several display lists is often stored in one buffer.
In the case of the legacy E&S Glaze demo, this reduces the size of our
command buffers from 91KB to 44KB. One WSI Fusion trace shows a 33%
reduction in command buffer sizes.
Tested with full piglit run.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Previously, every time we put shader constants into the default constant
buffer we called u_upload_alloc(), which mapped the buffer, and
u_upload_unmap(). We had to unmap the buffer before calling
svga_buffer_handle() to get the winsys handle for the buffer. But we
really only need to do that the first time we reference the const buffer.
Now we try to keep the upload manager's buffer mapped until we fill it or
flush the command buffer.
v2: add additional comment on the buffer unmapping code in
svga_context_flush(), per Charmaine.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
When we migrate a buffer from sw/malloc storage to a hardware buffer,
don't memcpy the whole buffer, just copy the part we've written to.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
PredCopyRegion support copy between same type of textures.
Instead of comparing src and dst pipe texture type, compare svga texture
type which can avoid some software fallback.
for example, it avoids a software blit with the Redway3D Aston demo.
Tested piglit tests on VGPU9 and VGPU10 on GL/DX11Renderer, Redway3D Aston demo
v2: some nit pick suggested by Charmaine.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This function returns svga texture type for corresponding pipe texture.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The comment for the commutative flags was wrong because OP_MUL is
before OP_MAD. While we are at it add missing opcodes, and fix
the comment about the short forms.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
This needs to be above the switch on API, as that can return true
(valid to render) before this error check even had a chance to run.
Fixes ESEXT-CTS.draw_elements_base_vertex_tests.invalid_mapped_bos,
which worked before commit 72f1566f90.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
This patch switches non-TGSI compute shaders over to using the HSA
ABI described here:
https://github.com/RadeonOpenCompute/ROCm-Docs/blob/master/AMDGPU-ABI.md
The HSA ABI provides a much cleaner interface for compute shaders and allows
us to share more code in the compiler with the HSA stack.
The main changes in this patch are:
- We now pass the scratch buffer resource into the shader via user sgprs
rather than using relocations.
- Grid/Block sizes are now passed to the shader via the dispatch packet
rather than at the beginning of the kernel arguments.
Typically for HSA, the CP firmware will create the dispatch packet and set
up the user sgprs automatically. However, in Mesa we let the driver do
this work. The main reason for this is that I haven't researched how to
get the CP to do all these things, and I'm not sure if it is supported
for all GPUs.
v2:
- Add comments explaining why we are setting certain bits of the scratch
resource descriptor.
v3:
- Use amdgcn-mesa-mesa3d triple instead of amdgcn--mesa3d.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes 8 fs-interpolateat* piglit crashes on radeonsi, because it can't
handle non-input operands in interpolateAt*.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fix getting the size of a struct arg. vec3 types still work ok.
Only buit-in args need to have power of two alignment, getTypeAllocSize
reports the correct size in all cases.
Acked-by: Francisco Jerez <currojerez@riseup.net>
The gallium interface defines these like DX10. Note that OpenGL ignores
these options if MSAA is disabled or the dest buffer doesn't support
MSAA.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Regardless of whether GL_MULTISAMPLE is enabled (it's enabled by default)
we should not set the alpha_to_coverage or alpha_to_one flags if the
current drawing buffer does not do MSAA.
This fixes the new piglit gl-1.3-alpha_to_coverage_nop test.
ETQW is a game that enables GL_SAMPLE_ALPHA_TO_COVERAGE without MSAA.
Shrubs along the side of roads were invisible because fragments with
alpha < 0.5 were being discarded (zero coverage).
v2: remove ctx->DrawBuffer != NULL check.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This adds support for the input attachments subpass type
to the SPIRV->NIR pass.
v1.1: drop handling from vtn_handle_texture
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
SPIR-V/Vulkan have a special image type for input attachments
called the subpass type. It has different characteristics than
other images types.
The main one being it can only be an input image to fragment
shaders and loads from it are relative to the frag coord.
This adds support for it to the GLSL types. Unfortunately
we've run out of space in the sampler dim in types, so we
need to use another bit.
v2: Fixup subpass input name (Jason)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Gen6 only has one additional restriction over Gen7+, so we just add it
to the existing gen7 function (which actually covers later gens too).
This should stop FINISHME spew when running GL on Sandybridge.
v2: Fix bytes per block vs. bits per block confusion (Jason) and
rename function to gen6_filter_tiling (Jason and Chad).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Note that ASTC support is not actually mandated for this extension to be
exposed.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
From the ARB_gpu_shader5 spec:
The built-in functions interpolateAtCentroid() and interpolateAtSample()
will sample variables as though they were declared with the "centroid"
or "sample" qualifiers, respectively.
When running with persample dispatch forced by the API, we interpolate
anything that isn't flat as if it's qualified by "sample". In order to
keep interpolateAtCentroid() consistent with the "centroid" qualifier, we
need to make interpolateAtCentroid() do sample interpolation instead.
Nothing in the GLSL spec guarantees that the result of
interpolateAtCentroid is uniform across samples in any way, so this is a
perfectly fine thing to do.
Fixes 8 of the new dEQP-VK.pipeline.multisample_interpolation.* Vulkan CTS
tests that specifically validate consistency between the "sample" qualifier
and interpolateAtSample()
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Some apps issue redundant glLoadMatrixf() calls with the same matrix.
Try to avoid setting dirty state in that situation.
This reduces the number of constant buffer updates by about half in
ET Quake Wars.
Tested with Piglit, ETQW, Sauerbraten, Google Earth, etc.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Structurally, this is very similar to the existing Apple-DRI code, except I
have chosen to implement this using the __GLXDRIdisplay, etc. vtables (as
suggested originally in [1]), rather than a maze of ifdefs. This also means
that LIBGL_ALWAYS_SOFTWARE and LIBGL_ALWAYS_INDIRECT work as expected.
[1] https://lists.freedesktop.org/archives/mesa-dev/2010-May/000756.html
This adds:
* the Windows-DRI extension protocol headers and the windowsdriproto.pc
file, for use in building the Windows-DRI extension for the X server
* a Windows-DRI extension helper client library
* a Windows-specific DRI implementation for GLX clients
The server is queried for Windows-DRI extension support on the screen before
using it (to detect the case where WGL is disabled or can't be activated).
The server is queried for fbconfigID to pixelformatindex mapping, which is
used to augment glx_config.
The server is queried for a native handle for the drawable (which is of a
different type for windows, pixmaps and pbuffers), which is used to augment
__GLXDRIdrawable.
Various GLX extensions are enabled depending on if the equivalent WGL
extension is available.
This is supposed to be exposed with the GL_KHR_robustness extension,
which we support on ES 2.0 and later. On desktop GL, it's also exposed
by GL_ARB_robustness, which is supported by all drivers ("dummy_true").
so we also allow desktop GL.
Fixes:
- ES32-CTS.robust.robustness.noResetNotification
- ES32-CTS.robust.robustness.loseContextOnReset
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Without this bit set, the value in "L3 Atomic Disable" won't get applied by
the hardware so we won't properly get L3 atomic caching.
Fixes dEQP-VK.spirv_assembly.instruction.compute.opatomic.compex and 198 of
the dEQP-VK.image.atomic_operations.* tests on HSW
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The Vulkan driver sets 3DSTATE_DRAWING_RECTANGLE once to MAX_INT x MAX_INT
at the GPU initialization time and never sets it again. The GL driver sets
it every time the framebuffer changes. Originally, blorp set it to the
size of the drawing area but meant we had to set it back in the Vulkan
driver. Instead, we can easily just do that in the GL driver's blorp_exec
implementation and not set it in blorp core.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Previously, we relied on a driver hook for 3DSTATE_MULTISAMPLE. However,
now that Vulkan and GL use the same sample positions, we can set up
3DSTATE_MULTISAMPLE directly in blorp and delete the driver hook.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Non-16B-aligned pull constant loads are unlikely to be particularly
useful given that you can get roughly the same effect by using
swizzles on the result.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
It might be useful to actually handle this once copy propagation
becomes smarter about register-misaligned offsets.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
A better fix would be to do something along the lines of the FS
back-end spilling code and emit a scratch read before any instruction
that overwrites the register to spill partially due to a non-zero
sub-register offset. In the meantime mark registers used with a
non-zero sub-register offset as no-spill to prevent the spilling code
from miscompiling the program.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This prevents it from trying to propagate a copy through a
register-misaligned region. MOV instructions with a misaligned
destination shouldn't be treated as a direct GRF copy, because they
only define the destination GRFs partially. Also fix the interference
check implemented with is_channel_updated() to consider overlapping
regions with different register offset to interfere, since the
writemask check implemented in the function is only valid under the
assumption that the source and destination regions are aligned
component by component.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cmod propagation would misoptimize the program if the destination
offset of the generating instruction wasn't exactly the same as the
source region offset of the copy instruction. In preparation for
adding support for sub-GRF offsets to the VEC4 IR.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Because the pass already checks that the destination offset of each
'scan_inst' that needs to be rewritten matches 'inst->src[0].offset'
exactly, the final offset of the rewritten instruction is just the
original destination offset of the copy. This is in preparation for
adding support for sub-GRF offsets to the VEC4 IR.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
For simplicity just assume that two writes to the same GRF with
different sub-GRF offsets will potentially interfere and break the
dependency control chain. This is in preparation for adding sub-GRF
offset support to the VEC4 IR.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This should also have the side effect of fixing convert_to_hw_regs()
to handle sub-GRF register offsets.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The offset printing code in fs_visitor::dump_instruction() was doing
things differently for sources and destinations and for each register
file -- In some cases it would be added to the base register number
fs_reg::nr, in other cases it would follow the base register separated
with a plus sign, in other cases (uniforms) it would do both (!). The
sub-register offset was also being printed or not rather
inconsistently. Fix it.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Get rid of some leftover redundant arithmetic introduced during the
conversion to byte offsets and sizes that can be simplified easily.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
component() was generally a better alternative because of several
issues set_smear() had:
- It wouldn't take the original stride and offset of the register
into account, which means that set_smear() on the result of
e.g. another set_smear() call or an offset() call would give a
bogus region as result.
- It was an inherently destructive operation. See the
'nir_intrinsic_shader_clock' hunk below for how this could lead to
subtle bugs in cases where set_smear() was called multiple times on
the same register like 'r.set_smear(0), r.set_smear(1)' with the
expectation that each call would return a separate value instead of
a reference to the same subsequently mutated object.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Also changed the argument names since 'src' and 'dst' don't make that
much sense outside of the context of copy propagation.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This makes the function less annoying to use and more accurate -- We
shouldn't propagate a copy into a register region that wasn't fully
contained in the destination of the copy (IOW, a source region that
wasn't fully defined by the copy) just because the number of registers
written and read by each instruction happened to get rounded up to the
same GRF multiple.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Using component_size() is easier and generally more correct because it
takes into account the register type and stride for you.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
These were bashing the 'offset' and 'stride' values of several
registers without taking the previous value into account, which
probably didn't matter in practice for optimize_frontfacing_ternary()
because the 'tmp' register already had a known region, but it would
have given the wrong region as result in the other cases in
lower_integer_multiplication(). subscript(..., i) is a more
straightforward way to take the i-th field of a given type from each
channel of a register which should give the right answer as result
regardless of the original 'offset' and 'stride' parameters of the
register region.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
In the most common case this can now be implemented as a simple
addition because the offset is already encoded as a single scalar
value in bytes.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The 'scan_inst->dst.offset % REG_SIZE' term in the final
'scan_inst->dst.offset' calculation is obviously bogus. The offset
from the start of the copy destination register 'inst->dst' where the
destination of the generating instruction 'scan_inst' would be written
to (before compute-to-mrf runs) is just the offset of 'scan_inst->dst'
relative to the source of the copy instruction (AKA rel_offset in the
code below).
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This was dropping 'inst->dst.offset' on the floor. Nothing in the
code above seems to guarantee that it's zero and in that case the
offset of the register being coalesced into wouldn't be taken into
account while rewriting the generating instruction.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This makes sure that overlap checks are done correctly throughout the
back-end when the '*this' register starts before the register/size
pair provided as argument, and is actually less annoying to use than
in_range() at this point since regions_overlap() takes its size
arguments in bytes.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This is copy-pasted almost line by line from the FS back-end. The
only reason it cannot be implemented in terms of backend_reg is that
the backend_reg::nr field doesn't have the same meaning for uniforms
on both back-ends. It could be easily deduplicated by using a
template function.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Its only use left in the FS back-end should be using regions_overlap()
instead to avoid getting a false negative result in cases where source
and destination overlap but the former starts before the latter in the
VGRF file.
v2: Put back lost components factor (Iago).
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
fs_inst::overwrites_reg is rather easy to misuse because it cannot
tell how large the register region starting at 'reg' is, so in cases
where the destination region starts after 'reg' it may give a
misleading result. regions_overlap() is somewhat more verbose to use
but handles arbitrary overlap correctly so it should generally be used
instead.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
is_nop_mov() was broken for LOAD_PAYLOAD instructions in two ways: On
the one hand the original destination register offset wasn't being
taken into account which would give incorrect results if it was
already non-zero, and on the other hand all source registers were
being treated as if they had a size of 32B, which is almost never the
case in SIMD16 programs for non-header sources.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The previous overlap condition only made sure that the VGRF numbers or
GRF-aligned offsets were different without taking the amount of data
written and read by the instruction into consideration. Use the
regions_overlap() helper instead.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This could potentially have misoptimized a program in cases where
inst->src[0] had a non-zero sub-GRF offset.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Unlike the FS counterpart of this commit this was likely not (yet) a
bug, but let's fix it already in preparation for implementing support
for sub-GRF offsets in the VEC4 back-end.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
There was a workaround for this in fs_inst::size_read() for the
SHADER_OPCODE_MOV_INDIRECT instruction and FIXED_GRF register file
*only*. We should take this possibility into account for the sources
and destinations of all instructions on all optimization passes that
need to quantize dataflow in 32B increments by adding the amount of
misalignment to the size read or written from the regs_read() and
regs_written() helpers respectively.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This fixes regs_written() and regs_read() to return a more accurate
value when the padding left between components due to a stride value
greater than one causes the region bounds given by size_written or
size_read to overflow into the next register. This could become a
problem in optimization passes that keep track of dataflow using
fixed-size arrays with register granularity, because the overflow
register (not actually accessed by the region) may not have been
allocated at all which could lead to undefined memory access.
An alternative to this would be to subtract the trailing padding
already during the calculation of fs_inst::size_read and
::size_written, but that would break code that currently assumes that
::size_read and _written are whole multiples of the component size,
and would be hard to maintain looking forward because size_written is
assigned from a bunch of different places.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The LINTERP virtual instruction only reads three scalar components
from the first 16B of the second source, we can now teach size_read()
about it since its return value is represented with byte granularity.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The previous regs_read value can be recovered by rewriting each
reference of regs_read() like 'x = i.regs_read(j)' to 'x =
DIV_ROUND_UP(i.size_read(j), reg_unit)'.
For the same reason as in the previous patches, this doesn't attempt
to be particularly clever about simplifying the result in the interest
of keeping the rather lengthy patch as obvious as possible. I'll come
back later to clean up any ugliness introduced here.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The previous regs_read value can be recovered by rewriting each
reference of regs_read() like 'x = i.regs_read(j)' to 'x =
DIV_ROUND_UP(i.size_read(j), reg_unit)'.
For the same reason as in the previous patches, this doesn't attempt
to be particularly clever about simplifying the result in the interest
of keeping the rather lengthy patch as obvious as possible. I'll come
back later to clean up any ugliness introduced here.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The previous regs_written field can be recovered by rewriting each
rvalue reference of regs_written like 'x = i.regs_written' to 'x =
DIV_ROUND_UP(i.size_written, reg_unit)', and each lvalue reference
like 'i.regs_written = x' to 'i.size_written = x * reg_unit'.
For the same reason as in the previous patches, this doesn't attempt
to be particularly clever about simplifying the result in the interest
of keeping the rather lengthy patch as obvious as possible. I'll come
back later to clean up any ugliness introduced here.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The previous regs_written field can be recovered by rewriting each
rvalue reference of regs_written like 'x = i.regs_written' to 'x =
DIV_ROUND_UP(i.size_written, reg_unit)', and each lvalue reference
like 'i.regs_written = x' to 'i.size_written = x * reg_unit'.
For the same reason as in the previous patches, this doesn't attempt
to be particularly clever about simplifying the result in the interest
of keeping the rather lengthy patch as obvious as possible. I'll come
back later to clean up any ugliness introduced here.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This is in preparation for dropping vec4_instruction::regs_read and
::regs_written in favor of more accurate alternatives expressed in
byte units. The main reason these wrappers are useful is that a
number of optimization passes implement dataflow analysis with
register granularity, so these helpers will come in handy once we've
switched register offsets and sizes to the byte representation. The
wrapper functions will also make sure that GRF misalignment (currently
neglected by most of the back-end) is taken into account correctly in
the calculation of regs_read and regs_written.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This is in preparation for dropping fs_inst::regs_read and
::regs_written in favor of more accurate alternatives expressed in
byte units. The main reason these wrappers are useful is that a
number of optimization passes implement dataflow analysis with
register granularity, so these helpers will come in handy once we've
switched register offsets and sizes to the byte representation. The
wrapper functions will also make sure that GRF misalignment (currently
neglected by most of the back-end) is taken into account correctly in
the calculation of regs_read and regs_written.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The fs_reg::subreg_offset and ::offset fields are now redundant, the
sub-GRF offset can just be added to the single ::offset field
expressed in byte units. The current subreg_offset value can be
recovered by applying the following rule: Replace each rvalue
reference of subreg_offset like 'x = r.subreg_offset' with 'x =
r.offset % reg_unit', and each lvalue reference like 'r.subreg_offset
= x' with 'r.offset = ROUND_DOWN_TO(r.offset, reg_unit) + x'.
For the same reason as in the previous patches, this doesn't attempt
to be particularly clever about simplifying the result in the interest
of keeping the rather lengthy patch as obvious as possible. I'll come
back later to clean up any ugliness introduced here.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The dst/src_reg::offset field in byte units introduced in the previous
patch is a more straightforward alternative to an offset
representation split between ::reg_offset and ::subreg_offset fields.
The split representation makes it too easy to forget about one of the
offsets while dealing with the other, which has led to multiple FS
back-end bugs in the past. To make the matter worse the unit
reg_offset was expressed in was rather inconsistent, for uniforms it
would be expressed in either 4B or 16B units depending on the
back-end, and for most other things it would be expressed in 32B
units.
This encodes reg_offset as a new offset field expressed consistently
in byte units. Each rvalue reference of reg_offset in existing code
like 'x = r.reg_offset' is rewritten to 'x = r.offset / reg_unit', and
each lvalue reference like 'r.reg_offset = x' is rewritten to
'r.offset = r.offset % reg_unit + x * reg_unit'.
Because the change affects a lot of places and is rather non-trivial
to verify due to the inconsistent value of reg_unit, I've tried to
avoid making any additional changes other than applying the rewrite
rule above in order to keep the patch as simple as possible, sometimes
at the cost of introducing obvious stupidity (e.g. algebraic
expressions that could be simplified given some knowledge of the
context) -- I'll clean those up later on in a second pass.
v2: Fix division by the wrong reg_unit in the UNIFORM case of
convert_to_hw_regs(). (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The fs_reg::offset field in byte units introduced in this patch is a
more straightforward alternative to the current register offset
representation split between fs_reg::reg_offset and ::subreg_offset.
The split representation makes it too easy to forget about one of the
offsets while dealing with the other, which has led to multiple
back-end bugs in the past. To make the matter worse the unit
reg_offset was expressed in was rather inconsistent, for uniforms it
would be expressed in either 4B or 16B units depending on the
back-end, and for most other things it would be expressed in 32B
units.
This encodes reg_offset as a new offset field expressed consistently
in byte units. Each rvalue reference of reg_offset in existing code
like 'x = r.reg_offset' is rewritten to 'x = r.offset / reg_unit', and
each lvalue reference like 'r.reg_offset = x' is rewritten to
'r.offset = r.offset % reg_unit + x * reg_unit'.
Because the change affects a lot of places and is rather non-trivial
to verify due to the inconsistent value of reg_unit, I've tried to
avoid making any additional changes other than applying the rewrite
rule above in order to keep the patch as simple as possible, sometimes
at the cost of introducing obvious stupidity (e.g. algebraic
expressions that could be simplified given some knowledge of the
context) -- I'll clean those up later on in a second pass.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
AEP requires ASTC, which is currently only enabled on Skylake and later.
(It may be possible to extend this to Cherryview/Braswell in the future,
but earlier hardware doesn't have ASTC support.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Numeric 2 is actually GLSL_SAMPLER_DIM_3D, which I don't think is what
was intended.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I want to re-use this in a different pass, so move to nir.h
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This moves the native pixmap fixup to a helper function so we don't
repeat ourselves.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This moves the native window fixup to a helper function so we don't
repeat ourselves.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Updated eglext.h to revision 33111 from the Khronos repository.
v2:
- Don't (re)move extension includes from eglext.h (Emil Velikov)
- Bump to revision 33111 (Adam Jackson)
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Track rendering to each FBO independently and flush rendering only when
necessary. This lets us avoid the overhead of storing and loading the
frame when an application momentarily switches to rendering to some other
texture in order to continue rendering the main scene.
Improves glmark -b desktop:effect=shadow:windows=4 by 27%
Improves glmark -b
desktop:blur-radius=5:effect=blur:passes=1:separable=true:windows=4
by 17%
While I haven't tested other apps, this should help X rendering a lot, and
I've heard GLBenchmark needed it too.
This is done in vc4_flush currently, but I'm going to make the job always
track the surfaces it might be rendering to instead of putting in the
destinations at flush time.
It's really just an upgrade to attempting WHOLE_RESOURCE. Pulling the
logic out caught two bugs in it: We would try to do so on cubemaps (even
though we're only mapping 1 of the 6 slices), and we would break
persistent coherent mappings by trying to reallocate when we shouldn't.
The clear of Z or stencil will end up clearing the other as well, instead
of masking. There's no way around this that I know of, so if we are
clearing just one then we need to draw a quad.
Fixes a regression in the job-shuffling code, where the clear values move
to the job and don't just have the last clear's value laying around when
you do glClear(DEPTH) and then glClear(STENCIL) separately
(ext_framebuffer_multisample-clear 4 depth)).
This causes regressions in ext_framebuffer_multisample/multisample-blit
depth and ext_framebuffer_multisample/no-color depth, but these were
formerly false positives due to the reference image also being black. Now
the reference and test images are both being drawn, and it looks like
there's an incorrect resolve of depth during blitting to an MSAA FBO.
This also exposes them for ARB_ES3_2_compatibility.
While both specs refer to the new MS line width parameters being
separate from the existing AA line widths, reality begs to differ. It's
the same on all hardware currently supported by mesa. Should hardware
come along that wants these to be different, they're easy enough to
separate out.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Earlier, the loop pretends to loop over instructions from "start" to "end",
but the callers always pass 8192 for end, which is some huge bogus
value. The real loop termination condition is send-with-EOT or 0. (Ken)
Signed-off-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Skylake adds new SENDS and SENDSC opcodes, which should be
handled in the send-with-EOT check. Make an is_send() helper
that checks if the opcode is SEND/SENDC/SENDS/SENDSC (Ken)
v2: Make is_send() much more crispier, Mix declaration and
code to make the code compact (Ken)
Signed-off-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Remove the float/dword union and use the iter->p[f->start / 32]
directly as printf formatter %08x expects uint32_t (Ken)
v2: Make the cleanup much more crispier (Ken)
Signed-off-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since Vulkan doesn't allow single-slice 3D storage images, we need to just
set the base_array_layer and array_len to the full size of the 3-D LOD.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This reverts commit 3943888c94. It turns out
that commit was pretty-much bogus since it breaks binding a 3-D texture as a
2-D storage image. The correct fix for the Vulkan CTS tests needs to be in
the Vulkan driver itself rather than ISL.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Everything that we were once using the blit2d framework for is now done
with blorp.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This is a lot cleaner and easier to read than the old piles of if
statements.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
The original blorp_alloc_binding_table helper was supposed to return the
binding table offset and map along with the surface state maps. This isn't
quite what we want, however. What we really want is the binding table
offsets, surface state offsets, and surface state maps. In the GL driver,
the binding table map *is* an array of surface state offsets. However, in
Vulkan, this isn't quite true as the entries in the binding table are
surface state offsets combined with another binding table block offset.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
radeonsi depends on the interp flags a little bit too much.
This fixes 9 randomly failing tests:
GL45-CTS.shader_multisample_interpolation.render.interpolate_at_centroid.*
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Unify the clear and copy paths, clean up the definitions.
It looks more like a rework. It's a preparation for GDS support,
which might or might not come.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
If si_sampler_view_add_buffer ends up flushing, then the code
in begin_new_cs would previously have added the buffer(s) for
whatever was previously bound to that slot. Now it would add only
the new buffer.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Heaven and Valley write gl_SampleMask and not Z.
Use 16_ABGR instead of 32_ABGR if Z isn't written.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Fixes segfaults in EG compute since:
commit 21de3be8e6
radeonsi: fix texture format reinterpretation with DCC
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fix VAAPI YV12/I420 convert to NV12 U/V reversal.
Input order is YVU when this is called.
Signed-off-by: Andy Furniss <adf.lists@gmail.com>
Reviewed-by: Boyuan Zhang <boyuan.zhang@amd.com>
Previously, we were relying on the fact that VALGRIND_MEMPOOL_FREE came
later on in the function to prevent "link->bo = bo" from causing an invalid
write. However, in the case where the size requested by the user is very
small (less than sizeof(struct anv_bo)), this isn't sufficient. Instead,
we should call VALGRIND_MEMPOOL_FREE early and then use VG_NOACCESS_WRITE.
We do, however, have to call VALGRIND_MEMPOOL_FREE after reading bo_in
because it may be stored in the bo itself.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The time we want to restrict the Z range of a 3-D surface is when rendering
to it. For storage surfaces, we always want he full range. However, we
still need to set MinimumArrayElement and RenderTargetViewExtent to
sensible values so we'll just set them to the reasonable defaults we used
before we started respecting the base_array_layer and array_len.
This fixes a bunch of Vulkan CTS regressions caused by 48f195d7c6.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97790
Reviewed-by: Chad Versace <chadversary@chromium.org>
Normally, using a non-linear tiling format helps improve cache locality by
ensuring that neighboring pixels are usually close-by in memory. For RGB
formats, this still sort-of holds, but it can also lead to rather terrible
memory access patterns where a single RGB pixel value crosses a tile
boundary and gets split into two pieces in different 4K pages. It also
makes for some rather awkward calculations because your tile size is no
longer an even multiple of surface element size. For these reasons, we
chose to simply never create tiled RGB images in the Vulkan driver.
The GL driver, however, is not so kind so we need to support it somehow. I
briefly toyed with a couple of different schemes but this is the best one I
could come up with. The fundamental problem is that a tile no longer
contains an integer number of surface elements. I briefly considered a
couple other options but found them wanting:
1) Using floats for the logical tile size. This leads to potential
rounding error problems.
2) When presented with a RGB format, just make the tile 3-times as wide.
This isn't so nice because now our tiles are no longer power-of-two
size. Also, it can force the row_pitch to be larger than needed which,
while not strictly a problem for ISL, causes incompatibility problems
with the way the GL driver chooses surface pitches.
The chosen method requires that you pay attention and not just assume that
your tile_info is in the units you think it is. However, it's nice because
it provides a nice "these are the units" declaration in isl_tile_info
itself. Previously, the tile_info wasn't usable as a stand-alone structure
because you had to also know the format. It also forces figuring out how
to deal with inconsistencies between tiling and format back to the caller
which is good because the two different consumers of isl_tile_info really
want to deal with it differently: Computation of the surface size wants
the fewest number of horizontal tiles possible while get_intratile_offset
is far more concerned with things aligning nicely.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Chad Versace <chadversary@chromium.org>
The restriction that Y-tiled surfaces must have valign == 4 only aplies to
render targets but we were applying it universally. This causes problems
if ISL_FORMAT_R32G32B32_FLOAT is used because it requires valign == 2; this
should be okay because you can't render to that format.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
When Ivy Bridge introduced array multisampling, someone made the decision
to do lots of stuff throughout the driver in terms of physical array layers
rather than logical array layers. In ISL, we use logical array layers most
of the time and it really makes no sense to use physical array layers in
the blorp API. Every time someone passes physical array layers into blorp
for an array multisampled surface, they're always divisible by the number
of samples and we divide right away.
Eventually, I'd like to rework most of the GL driver internals to use
logical array layers but that's going to be a big project and will probably
happen as part of the ISL conversion. For now, we'll do the conversion in
brw_blorp and let blorp just use the logical layers.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The result of this calculation goes into an fma() in the shader and we
would like it to be as precise as possible. The division in particular
was a source of imprecision whenever dst1 - dst0 was not a power of two.
This prevents regressions in some of the new Vulkan CTS tests for blitting
using a filtering of NEAREST.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
While we're here, we also re-arrange the parameters to better match the
parameter order of blorp_blit.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
While it can be useful, the field has substantial limtations. In
particular, the bittom 2 or 3 bits is missing so your offset always has to
be a multiple of 4 or 8. While surface alignments usually work out to make
this ok, when you start trying to fake compressed surfaces as uncompressed
(which we will want to do) this falls apart. The easiest solution is to
simply align all offsets to a tile boundary and munge the regions we're
copying to account for the intratile offset.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The convert_to_single_slice operation is *mostly* idempotent. The only
non-repeatable thing it does is that, when it sets the intratile offset
fields, it just overwrites them instead of doing a += operation. This is
supposed to be ok because we have an early return at the top that should
make it bail of the surface is already a single slice. Unfortunately, the
if condition has been broken ever since it was first added in 96fa98c18.
This commit fixes the condition and adds an assert to ensure we don't stomp
any non-zero intratile offsets.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
If we use the view format, it may be an uncompressed view of a compressed
image which throws things off. Since we're computing offsets of images, we
want the actual surface offset anyway.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This should be more compact than the enum isl_channel_select[4] that we
were using before. It's also very convenient because we already had such a
structure in the Vulkan driver we just needed to pull it over.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Similar to commit 49c24d8a24 ("i965: fix noop_scissor range issue on
width/height") - take the X/Y into account to determine whether the
scissor covers the whole area or not.
Fixes the recently-added gl-1.0-scissor-depth-clear-negative-xy piglit
test.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: <mesa-stable@lists.freedesktop.org>
Android porting of the following commits:
f1f1ba3 "radeonsi: move sid.h/r600d_common.h to a common place."
69fca64 "amd/addrlib: move addrlib from amdgpu winsys to common code"
This patch fixes android building errors
Reviewed-by: Dave Airlie <airlied@redhat.com>
This reverts commit 6ba88bce64. The commit
was erroneous because GL has a separate limit, GL_MAX_FRAMEBUFFER_LAYERS
which guards the number of layers you are allowed to render into.
The GL 4.5 spec says:
"The framebuffer attachment point attachment is said to be framebuffer
attachment complete if [...] all of the following conditions are true:
[...]
If image is a three-dimensional, one- or two-dimensional array, or
cube map array texture and the attachment is layered, the depth or
layer count of the texture is less than or equal to the value of the
implementation-dependent limit MAX_FRAMEBUFFER_LAYERS."
and goes on to say that "framebuffer complete" requires all attachments to
be "framebuffer attachment complete".
On Sandy Bridge, we set GL_MAX_FRAMEBUFFER_LAYERS to 512 so creating a 3D
texture bigger than 512 is fine; you just can't render into all of the
slices at once.
Fixes ES3-CTS.gtf.GL3Tests.npot_textures.npot_tex_image on Sandy Bridge
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chadversary@chromium.org>
In particular, this means that isl_view::base_array_layer and
isl_view::array_len get applied to 3-D textures but only when rendering.
We were already applying isl_view::base_array_layer for rendering into 3-D
textures so this isn't a huge deviation.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Copy the whole devinfo structure instead of just few fields (Ken)
Earlier, copied only couple of fields which added more code. So,
simplify code by copying the whole structure.
Signed-off-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes a crash when using the prefered video format with vaapisink
on Nvidia hardwares.
Also caught by the following assert:
nouveau_vp3_video.c:91: Assertion `templat->interlaced' failed.
TEST= gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! vaapisink
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Tested-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Tested-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Drivers which support ARB_tessellation_shader and ES 3.1 now will
expose OES_tessellation_shader and EXT_tessellation_shader as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
This provides a nice little place to share notes on what still needs to be
done and/or would be nice to have in BLORP.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Forgotten on commit "i965: Fix calculation of the image height at start level".
Thanks to Ilia Mirkin for point it.
Fixes the following regressions on Haswell and Broadwell:
ES2-CTS.gtf.GL2ExtensionTests.egl_image_external.TestSimpleUnassociated (crash back to pass)
ES2-CTS.gtf.GL2ExtensionTests.egl_image_external.TestSimple (crash back to fail)
ES2-CTS.gtf.GL2ExtensionTests.egl_image_external.TestVertexShader (crash back to fail)
https://bugs.freedesktop.org/show_bug.cgi?id=97761
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Rather than using platform specific methods to retrieve the program
name pass it explicitly. The function is called directly from main().
Similarly - basename comes in two versions POSIX (can modify string,
always pass a copy) and GNU (never modifies the string).
Just printout the complete program name, esp. since the program is not
meant to be installed. Thus using $basename is unlikely to work, not to
mention it is misleading.
Reported-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jonathan Gray <jsg@jsg.id.au>
Keep the old name in the extension string, but refer to the KHR
extension internally.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
MESA_configless_context does not specify the interaction with
QueryContext at all, and the code to generate an error in this case
predates the Mesa extension. Since EGL_NO_CONFIG_{KHR,MESA} are
numerically identical there's no way to distinguish which one the
application asked for, so use the KHR behaviour.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This patch enables variable bit-rate for vaapi encoding. According to va.h,
target bit-rate equals to maximum bit-rate multiplies by target_percentage.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The radeonsi driver doesn't and shouldn't care about the buffer index.
Only the virtual addresses matter.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The fence that is added to the BO during flush is guaranteed to be
signaled after all the fences that were in the fences array of the BO
before the flush, because those fences are added as dependencies for the
submission (and all this happens atomically under the bo_fence_lock).
Therefore, keeping only the last fence around is sufficient.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The idea is to have matching init/deinit functions so that deinit can be
re-used for cleanup in the error path of amdgpu_winsys_create.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Original commit added documentation explaining lossless compression
case:
commit 56f29911ec
Author: Topi Pohjolainen <topi.pohjolainen@intel.com>
Date: Tue Feb 2 10:00:41 2016 +0200
i965: Add a flag telling color resolve pass to ignore CCS_E
It, however, easily gives the impression that the sole purpose
of the intel_miptree_resolve_color() is to address lossless
compression. Original intention is to document the lack of
INTEL_MIPTREE_IGNORE_CCS_E flag given for the resolve call.
This patch fixes this along with a typo found spotted further
down.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This will indicate target layer (Render Target Array Index) needed
for layered clears.
v2: Use 3DSTATE_VF_SGVS for gen8+
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
such as we do for compressed msaa. In case of non-compressed simgle
sampled buffers the allocation of mcs is deferred until there is
actually a clear operation that needs the mcs.
In case of render buffer compression the mcs buffer always needed
and there is no real reason to defer the allocation. By doing it
directly allows to drop quite a bit unnecessary complexity.
Patch leaves brw_predraw_set_aux_buffers() a no-op. Subsequent
patches will re-use it and it seemed cleaner to leave it instead
of removing and re-introducing.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Otherwise once mcs buffer gets allocated without delay for lossless
compression (same as we do for msaa), assert starts to fire in
piglit case: tex3d. The test uses depth of one which is in fact
supported even now.
v2 (Jason): Allow also 1D case as there is nothing in the specs
constraining it either.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Once mcs buffer gets allocated without delay for lossless
compression (same as we do for msaa), one gets regression in:
GL45-CTS.texture_barrier_ARB.same-texel-rw
Setting the auxiliary surface for both sampling engine and data
port seems to fix this. I haven't found any hardware documentation
backing this though.
v2 (Jason): Prepare also for the case where surface is sampled with
non-compressible format forcing also rendering without
compression.
v3: Split asserts and decision making.
v4: Detailed comment provided by Jason explaining the need for using
auxiliary buffer for texturing when the same surface is also
used as render target.
Added check for existence of renderbuffer before considering if
underlying miptree matches.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v3:
- Actually set the flags when needed instead of falsely
overwriting them (Jason).
- Use more generic name for flag (dropped RENDERBUFFER)
- Consult also shader images
v4:
- Consult only lossless compressd shader images
v5:
- Check the existence of renderbuffer before considering
if it matches the given miptree
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And add plumbing to provide it all the way to surface state emitter.
This is not used yet but will be in subsequent patches to carry
additional constraints.
v2 (Jason): Use uint32_t instead of int as the type
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Blorp consults brw_is_color_fast_clear_compatible() to see if any
restrictions apply for fast clear in addition to the capablities
advertised in isl_format.c::format_info[]. On Gen8+ integer formats
are backlisted for plain old fast clear but there is no reason why
lossless compression shouldn't be supported. In fact, lossless
compression of integer formats is already supported for normal
render paths.
This patch prepares for dropping the delayed allocating of the mcs
buffer for lossless compression. Until now the skip of fast clear
also prevented the mcs being allocated and hence the lossless
compression being effectively turned off for integer formats.
Once the mcs buffer is allocated beforehand, the assertion addressed
here would start triggering.
v2: Drop the assert instead of relaxing it (Jason)
Fix typo while at it.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
After commit "i965: Fix calculation of the image height at start level", it is
not needed. This commit removes the "warning: unused variable ‘i’" warning.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This clears the last bits of the usecases of the hash table
located in mesa/program, allowing us to remove it.
V2: Rebase on top of changes to Makefile.sources
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We are getting the util hash table through the include in
program/hash_table.h for the moment until we migrate the
string_to_uint_map to a separate file.
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The "locals" hash table is used as a set, so use a set to
avoid confusion and also spare some minor memory.
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
V2: Fix incorrect ordering on hash table insert
V3: null check value returned by _mesa_hash_table_search()
(Timothy Arceri)
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
V2: Rebase to the adaption of new hashing functions
V3: move previous_label declaration to where it is used
(Timothy Arceri)
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
And remove the now unused hash_table_replace.
V2: Actually do the equivalent thing, and don't leak memory
V3: fix minor typo in comment (Timothy Arceri)
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
It is included through the util/hash_table include in
the program hash_table, so this should be safe.
This will be needed when we start converting each use of
the program_hash_table, as some places need this function.
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Here we make the prog_hash_table functionally equivalent to
the one in util by wrapping the remaing functions that differ.
We also move the functions to the header so we can remove the c
file.
This enables us to do a step-by-step replacement of the table.
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Looks like the GM107 IPA op does not allow a separate offset when
using an indirect register. Instead we must use AL2P like we do for
indirect vertex operations on Kepler+.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
We have to force it to write to predicate 7 (aka PT) in order for it not
to mess up another predicate. Unclear what would be returned in the
predicate, perhaps an error code for out-of-bounds requests. Blob
doesn't seem to check it.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
- Fixes CTS tests:
* GL44-CTS.shader_image_size.advanced-nonMS-cs-float
* GL44-CTS.shader_image_size.advanced-nonMS-cs-int
* GL44-CTS.shader_image_size.advanced-nonMS-cs-uint
* GL44-CTS.shader_image_size.advanced-nonMS-gs-float
* GL44-CTS.shader_image_size.advanced-nonMS-gs-int
* GL44-CTS.shader_image_size.advanced-nonMS-gs-uint
* GL44-CTS.shader_image_size.advanced-nonMS-tes-float
* GL44-CTS.shader_image_size.advanced-nonMS-tes-int
* GL44-CTS.shader_image_size.advanced-nonMS-tes-uint
* GL44-CTS.shader_image_size.advanced-nonMS-vs-float
* GL44-CTS.shader_image_size.advanced-nonMS-vs-int
* GL44-CTS.shader_image_size.advanced-nonMS-vs-uint
v1: (written by Dave Airlie) Always shift height images for levels.
Fixed the CTS test.
v2: Only shift height if the texture is not an 1D_ARRAY,
it fixes assertion in GL44-CTS.texture_view.gettexparameter
due to the original patch (Antia).
v3: Remove the loop. Do not shift height either for 1D textures.
Use an explicit switch and add an assertion (levels == 0) for
multisampled textures (Jason).
v4: Rectangle textures can not have levels either (Ilia Mirkin).
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Antia Puentes <apuentes@igalia.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to
hard-coded non-zero values. These two attributes are required on Android.
v2: use _EGL_MAX_PBUFFER_WIDTH/HEIGHT from egldefines.h
(based on discussion on the first version)
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Static library dependency is required to pull the generated
XML headers into the generated C file.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This change makes copy propagation pass faster. Complete link time
spent in test case attached to bug 94477 goes down to ~400 secs from
over 500 secs on my HSW machine. Does not fix the actual issue but
brings down the total. No regressions seen in CI.
v2: do not leak hash_table structure
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Blorp doesn't handle spilling so we set allow_spilling to false in that
case. The blorp 16x MSAA resolve shader spills in 16-wide but not 8-wide.
This commit makes it so that we fail the 16-wide compile and successfully
fall back to 8-wide instead of just assert-failing when trying to compile
the 16-wide shader.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Unlike the current CSE pass, global value numbering is capable of detecting
common values even if one does not dominate the other. For instance, in
you have
if (...) {
ssa_1 = ssa_0 + 7;
/* use ssa_1 */
} else {
ssa_2 = ssa_0 + 7;
/* use ssa_2 */
}
Global value numbering doesn't care about dominance relationships so it
figures out that ssa_1 and ssa_2 are the same and converts this to
if (...) {
ssa_1 = ssa_0 + 7;
/* use ssa_1 */
} else {
/* use ssa_1 */
}
Obviously, we just broke SSA form which is bad. Global code motion,
however, will repair this for us by turning this into
ssa_1 = ssa_0 + 7;
if (...) {
/* use ssa_1 */
} else {
/* use ssa_1 */
}
This intended to eventually mostly replace CSE. However, conventional CSE
may still be useful because it's less of a scorched-earth approach and
doesn't require GCM. This makes it a bit more appropriate for use as a
clean-up in a late optimization run.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
On the RSxxx chip series, HW TCL is missing and r300_emit_vs_state()
is never called.
However, if R300_VAP_CNTL is never set, the hardware (at least the
RS690 I tested this on) comes up with rendering artifacts, and
parts that are uploaded before this "fix" remain broken in VRAM.
This causes artifacts as in fdo#69076 ("triangle flickering").
It seems like this setup needs to happen at least once after power on
for 3D rendering to work properly. In the DDX with EXA, this happens in
RADEON_SWITCH_TO_3D() when processing an XRENDER Composite or an
Xv request. So playing back a video or starting a GTK+2 application
fixes 3D rendering for the rest of the session. However, this auto-fix
doesn't happen when EXA is not used, such as with GLAMOR or Wayland.
This patch ensures the register is configured even in absence of
the DDX's EXA module.
The register setting is taken from:
xf86-video-ati -- RADEONInit3DEngineInternal()
mesa/src/mesa/drivers/dri/r300 -- r300EmitClearState()
Tested on RS690.
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Max Staudt <mstaudt@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The problem is that TC-compatible DCC clear codes translate
into different clear values when you change the format.
I have a new piglit reproducing the issue.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
In the original commit message in 56a1c10 it was wrongly used too:
- env GALLIUM_HUD_SIGNAL_TOGGLE: toggle visibility via signal
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Previously, we dind't apply variable decorations to the members of a split
structure variable. This doesn't quite work, unfortunately, because things
such as the "flat" qualifier may get applied to an entire structure instead
of propagated to the members. This fixes 9 of the new CTS tests in the
dEQP-VK.glsl.linkage.varying.struct.* group.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
program_invocation_short_name is a gnu extension. Limit use of it
to glibc and cygwin and otherwise use getprogname() which is available
on BSD and OS X.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Include libgen.h for basename as required by posix.
The definition is not found on at least OpenBSD otherwise.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
error() is a gnu extension and is not present on OpenBSD
and likely other systems.
Convert use of error to fprintf/strerror/exit.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The Makefile unconditionally linked libX11-xcb into libvulkan_intel.so.
But it's needed only if HAVE_PLATFORM_X11.
Fixes build of libvulkan_intel.so on Chromium OS, which has no X11
libraries.
Fixes: 71258e9462 ("anv/x11: Add support for Xlib platform")
Cc: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Only keep track of a single current context, instead of separate
contexts for GL and GLES.
In EGL 1.4 (and 1.5), EGL_OPENGL_API and EGL_OPENGL_ES_API are supposed
to be interchangeable for all purposes except for eglCreateContext.
The _EGLThreadInfo::CurrentContexts array is now a single pointer to the
current context, which may be a GL or GLES context. In addition, it now
keeps track of the current API as an enum instead of an index.
eglMakeCurrent will now replace the current context, regardless of which
client API is used for for the current and new contexts. It no longer
checks for a conflicting context. In addition, calling eglMakeCurrent
with EGL_NO_CONTEXT will now release the current context regardless of
the current API.
v2: Rebased against master (Adam Jackson)
Reviewed-by: Adam Jackson <ajax@redhat.com>
v2: make fence extension optional to not break non-i965 classic
drivers, and move __DRI2_FENCE into core extensions, based
on comments from Emil
Signed-off-by: Rob Clark <robdclark@gmail.com>
First off, as late as ES 3.2, GetInternalformat only supports
RENDERBUFFER and 2DMS(_ARRAY) targets.
Secondly, the _mesa_has_ext helpers are very accurate... a little too
accurate, some might say. If we only show an extension in compat
profiles because core profiles have the functionality guaranteed, they
will return false. Fix these to either check for a core profile
explicitly, or to a different-but-identical extension available in core
profile.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matteo Bruni <matteo.mystral@gmail.com>
Tested-by: Matteo Bruni <matteo.mystral@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Add a separate extension check for that format. Prevents glTexImage from
trying to find a matching format, which fails on drivers without support
for this format.
Fixes: sized-texture-format-channels (on a3xx)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: mesa-stable@lists.freedesktop.org
We had two almost identical copies of this code and they were both broken
but in different ways. The previous two commits fixed both of them. This
one just unifies them so that it's easier to handle in the future.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
SPIR-V has the two arguments in the opposite order from GLSL. NIR uses the
GLSL order so we had them backwards.
Fixes dEQP-VK.spirv_assembly.instruction.compute.opatomic.compex
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Increases the performance of legacy geometry-heavy apps
still using display lists.
Performance increase for a targeted testcase is on the
order of 8x, and applications like ParaView 4.x (5.x uses
no longer used display lists) improve by about 10%-20%.
Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fix build with Python < 2.7.
File "./glsl/ir_expression_operation.py", line 360, in get_enum_name
return "ir_{}op_{}".format(("un", "bin", "tri", "quad")[self.num_operands-1], self.name)
ValueError: zero length field name in format
Fixes: e31c72a331 ("glsl: Convert tuple into a class")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Recent changes to generate ir_expression*.h header files broke Android
builds. This adds the generation rules. This change is complicated due to
creating a circular dependency between libmesa_glsl, libmesa_nir, and
libmesa_compiler. Normally, we add static libraries so that include paths
are added even if there's no linking dependency. That is the case here.
Instead, we explicitly add the include path using $(MESA_GEN_GLSL_H) to
libmesa_compiler. This in turn requires shuffling the order of make
includes. It also uncovered missing dependency tracking of glsl_parser.h.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
When creating interlaced video buffer, hegith set to "template.height =
align(tmpl->height/ array_size, VL_MACROBLOCK_HEIGHT);", and we use
"template.height *= array_size;" for the buffer height, so it actually
aligned with 32. With progressive video buffer it still aligned with 16,
thus causing different height between interlaced buffer and progressive
buffer for 4K (height=2160), and 720p (height=720).
When transcode the video, this will cause the 16 lines corruption
at the bottom of the encode video.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
As of commit d82f8d9772, we actually
parse and attempt to handle the 'patch' qualifier on interface blocks.
This patch fixes explicit locations for variables in such blocks.
Without it, many program interface query dEQP/CTS tests hit this
assertion in ir_set_program_inouts.cpp
if (is_patch_generic) {
assert(idx >= VARYING_SLOT_PATCH0 && idx < VARYING_SLOT_TESS_MAX);
bitfield = BITFIELD64_BIT(idx - VARYING_SLOT_PATCH0);
}
because the location was incorrectly based on VARYING_SLOT_VAR0.
Note that most of the tests affected currently fail before they hit
this, due to confusion about what the program interface query name
of those resources should be.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This just ports the simpler endian detection bits, addrlib
sharing wants this outside gallium.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Step one to merging radv would be to move some files around.
This only adds the include path to r600/radeonsi, because later
we want to avoid having to add it to the generic target paths.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Calculate depth ranges from viewport states and
pipe_rasterizer_state::clip_halfz.
The evergreend.h change is required to silence a warning.
This fixes this recently updated piglit: arb_depth_clamp/depth-clamp-range
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
DCC is limited in how texture formats can be reinterpreted using texture
views. If we get a view format that is incompatible with the initial
texture format with respect to DCC, disable DCC.
There is a new piglit which tests all format combinations.
What works and what doesn't was deduced by looking at the piglit failures.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Sometimes it was f32, other times it was i32. Now it's always i32.
This fixes:
GL45-CTS.texture_cube_map_array.image_texture_size.texture_size_compute_sh
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Invalidated buffers don't have to go through it.
Split r600_init_resource into r600_init_resource_fields and
r600_alloc_resource.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Currently, due to the inverse order, strcmp will produce negative result
when the needle is towards the start of the haystack. Thus on the next
iteration(s) we'll end up further towards the end and eventually fail to
locate the entry.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
We recently starting to always emit the NDV (== dall) bit for quadops.
However it was folded into the wrong code word.
Fixes: e0a067ed48 (nv50/ir: always emit the NDV bit for OP_QUADOP)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: <mesa-stable@lists.freedesktop.org>
Unfortunately a3xx does not have a separate disable for depth clipping,
so when depth clamp is enabled, we disable the whole 3d clipper logic.
This in turn also gets rid of the xy clip that it would normally do.
When we detect this would happen, instead we integrate the viewport into
the window scissor. This may have slightly different behavior around
wide points, but it's unlikely that anything depends on this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97231
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
The hw clipper only handles up to 6 UCPs. If there are more than 6 UCPs,
or a clip vertex, or clip distances are in use, then we must use the
fallback discard-based clipping from the frag shader.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
This is the only remaining part of genX_l3.c and there's really no good
reason for it to be in its own file.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Now that we're using gen_l3_config.c, we no longer have one set of l3
config functions per gen and we can simplify a bit. Also, we know that
only compute uses SLM so we don't need to look for it in all of the stages.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When Jordan first implement L3$ configuration for Vulkan, he copied+pasted
from the GL driver because we had no good place to share it. Now that we
have src/intel/common, we should be sharing these tables.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Generated by:
sed -i -e 's/brw_device_info/gen_device_info/g' src/intel/**/*.c
sed -i -e 's/brw_device_info/gen_device_info/g' src/intel/**/*.h
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.c
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.cpp
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.h
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In 144cbf8 ("nir: Make nir_opt_remove_phis see through moves."), Ken
made nir_opt_remove_phis able to coalesce phi nodes whose sources are
all moves with the same swizzle. However, he didn't add the logic
necessary for handling the fact that the phi may now have multiple
different sources, even though the sources point to the same thing. For
example, if we had something like:
if (...)
a1 = b.yx;
else
a2 = b.yx;
a = phi(a1, a2)
... = a
then we would rewrite it to
if (...)
a1 = b.yx;
else
a2 = b.yx;
... = a1
by picking a random phi source, which in this case is invalid because
the source doesn't dominate the phi. Instead, we need to change it to:
if (...)
a1 = b.yx;
else
a2 = b.yx;
a3 = b.yx;
... = a3;
Fixes 12 CTS tests:
ES31-CTS.functional.tessellation.invariance.outer_edge_symmetry.quads*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Curiously OES/EXT_tessellation_shader leave these out, while ES 3.2 adds
them in.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I left this out of my previous commit that went around enabling all of
the other ES 3.2 entrypoints.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is a newly added flag. We always pass false into it from
nv50_clear_texture, but other callers may want to respect the render
condition. (And the functions were originally spec'd to respect it.)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
When NIR was first introduced, Connor added this fake-edge hack to work
around issues related to unreachable blocks. Thanks to GLSL IR's jump
lowering code, the only unreachable code you can have is a block after an
infinite loop. With SPIR-V, we didn't have the jump lowering code so we
could also end up with the "if (...) { break; } else { continue; }" case
which generates an unreachable block after the if. Because of this, most
of NIR had to be fixed up for handling unreachable blocks. The only
remaining case of not handling unreachable blocks was specifically the
block-after-infinite-loop case in dead_cf which was fixed by the previous
commit. We can now delete the fake edge hack.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
When an application uses a ton of shaders, we need to evict them
when the code segment is full but this is not really a good solution
if monster shaders are used because code eviction will happen a lot.
To avoid this, it seems better to dynamically resize the code
segment area after each eviction. The maximum size is arbitrary
fixed to 8MB which should be enough.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
To avoid the bins list to grow up indefinitely when the code segment
size will be bumped, we need to separate that bin from the SCREEN
one because it contains other resources like the uniform bo.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This function will be helpful for resizing the code segment
area when we need to evict all shaders.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This fixes a very old issue which happens when the code segment
size is full. A bunch of real applications like Tomb Raider,
F1 2015, Elemental, hit that issue because they use a ton of shaders.
In this case, all shaders are evicted (for freeing space) but all
currently bound shaders also need to be re-uploaded and SP_START_ID
have to be updated accordingly.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This refactoring will help for fixing the "out of code space"
eviction issue because we will need to reupload the code for
all currently bound shaders but it's slightly different than
uploading a new fresh code.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
If scissor X or Y was set to a negative value then the previous
code might have indicated noop scissors when the scissor range
actually was masking a portion of the framebuffer.
Since fb->_Xmin, _Xmax, _Ymin and _Ymax take scissors into
account, we can use these to test for a noop scissor.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Varying packing would like to mark certain variables as flat.
This works as long as both sides of the interfaces are changed
accordingly. However, with SSO, we disable varying packing on
the outermost stages. We also disable varying packing for
certain tessellation stages.
With SSO, we operate on the producer and consumer separately.
Checks based on the consumer stage and variable are risky, and
can easily lead to altering one half of the interface between
stages, breaking SSO pipeline IO validation.
Just stop monkeying around with interpolation modes unless
required for varying packing. There's no point. This also
disables it in unsafe SSO cases.
Fixes CTS tests:
*.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_MaxPatchVertices_Position_PointSize
Also fixes Piglit's spec/oes_geometry_shader/sso_validation:
- user-defined-gs-input-not-in-block.shader_test
- user-defined-gs-input-in-block.shader_test
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We handled the unsized case, implicitly sizing arrays to the value
of gl_MaxPatchVertices. But if a size was present, we failed to
raise a compile error if it wasn't the value of gl_MaxPatchVertices.
Fixes CTS tests:
*.tessellation_shader.compilation_and_linking_errors.
{tc,te}_invalid_array_size_used_for_input_blocks
Piglit's tcs-input-read-nonconst-* tests have recently been fixed.
This patch will break older copies of those tests, but the latest
should continue working. Update to Piglit 75819c13af2ed5.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
When trying to get a device name for an fd using sysfs, it would always fail
as it was expecting key/value pairs to be delimited by '\0', which is not the
case.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The device name is only needed for WL_bind_wayland_display so make this clear
by only storing the device name when Wayland support is built.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
A few inline asserts in anv assume alignments are power of 2, but with
formats like R8G8B8 we have odd alignments.
v2: round up to power of 2 (Ilia)
v3: reuse util_next_power_of_two() from gallium/aux/util/u_math.h (Ilia)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The code was triggering asserts in DEBUG builds of the SVGA driver since
the reference count of the resource was never decremented before destroy.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Without this, we would pass over the instructions in the SIMD8 program
(which is located earlier in the buffer) when brw_set_uip_jip() is
called to handle the SIMD16 program.
The assertion about compacted control flow was bogus: halt, cont, break
cannot be compacted because they have both JIP and UIP. Instead, we
should never see a compacted instruction in this code at all.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The original motivation was that gen6_clip_state ignored _NEW_POLYGON
as it didn't care about early culling. The only other change was that
Gen6 ignored BRW_NEW_TES_PROG_DATA as it doesn't have tessellation
shaders, but listening to this is harmless as it'll never be signalled.
Now that we've added _NEW_POLYGON for is_drawing_lines/points, we can
merge the two as the distinction is meaningless.
This actually fixes a bug, though: Gen8+ was using the gen6_clip_state
atom because it doesn't care about early culling, but it also needs
BRW_NEW_TES_PROG_DATA, which was missing.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
State upload code should use prog_data rather than poking at core
Mesa shader data structures wherever possible.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
calculate_attr_overrides() uses is_drawing_points(), which depends
on tessellation and geometry program state, as well as polygon state.
v2: Add missing _NEW_POLYGON as well. Caught by Iago Toral.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This has never been used because info->immd.bufSize is always 0
and anyways this is an experimental code which has never been
completed.
This gets rid of some unused code in the program validation process.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The code a few lines below expects to migrate the bo in question to
VRAM. Since we're filling the initial data via CPU, it's more efficient
to create the temporary buffer in GART. There is no "push" method
implemented, otherwise we'd use that instead.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
To support WL_bind_wayland_display an authentication function needs to be
provided but this was not being done for this platform as it's not strictly
necessary. However, as this isn't an optional function there's the potential
for a segfault to occur if authentication is mistakenly performed. Protect
against this by providing a function that prints an error.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Up until now, DRI3 was only used for devices that have render nodes, unless
overridden via an environment variable, with it falling back to DRI2 otherwise.
This limitation was there in order to support WL_bind_wayland_display as it
requires client opened device node fds to be authenticated, which isn't possible
when using DRI3. This is an unfortunate compromise as DRI3 provides security
benefits over DRI2.
Instead, allow DRI3 to be used for devices without render nodes but don't
advertise WL_bind_wayland_display in this case. Applications that need this
extension can still be run by disabling DRI3 support via the LIBGL_DRI3_DISABLE
environment variable.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Until hardware appears (in a gallium driver) that can make use of the
TCS-outputted gl_BoundingBox, we just request that the variable gets
assigned as a regular patch variable.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Requested by Anuj during review of
4a87e4ade7, adding as follow-up since it
led to assertion failures due to various GLSL bugs that should be
fixed now.
In the fragment shader OutputsWritten is a bitset of FRAG_RESULT_*
enumerants, which represent the location of each color output written
by the shader. The secondary and primary color outputs of a given
render target using dual-source blending have the same location, so
the 'idx' computation below will give the wrong bit as result if the
'var->data.index' term is non-zero -- E.g. if the shader writes the
primary and secondary colors of the FRAG_RESULT_COLOR output,
ir_set_program_inouts will think that the shader writes both
FRAG_RESULT_COLOR and FRAG_RESULT_SAMPLE_MASK, which is just bogus.
That would cause the brw_wm_prog_key::nr_color_regions computation
done in the i965 driver during fragment shader precompilation to be
wrong, which currently leads to unnecessary recompilation of shaders
that use dual-source blending, and triggers an assertion failure in
fs_visitor::emit_fb_writes() on my i965-fb-fetch branch.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
gl_SecondaryFragColorEXT should have the same location as gl_FragColor
for the secondary fragment color to be replicated to all fragment
outputs. The incorrect location of gl_SecondaryFragColorEXT would
cause the linker to mark both FRAG_RESULT_COLOR and FRAG_RESULT_DATA0
as being written to, which isn't allowed by the spec and would
ultimately lead to an assertion failure in
fs_visitor::emit_fb_writes() on my i965-fb-fetch branch.
This should also fix the code below for multiple dual-source-blended
render targets, which no driver currently supports but we have plans
to enable eventually in the i965 driver (the comment saying that no
hardware will ever support it seems rather hilarious).
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Currently the mesa state tracker relies on there being two bits set
per dual-source output in the gl_program::OutputsWritten bitset, but
that only worked due to a GLSL front-end bug that caused it to set the
OutputsWritten bit for both location and location+1 even though at the
GLSL level the primary and secondary color outputs used for
dual-source blending have the same location. Fix it by extending
outputMapping[] to 2*FRAG_RESULT_MAX elements in order to represent a
mapping from a (location, index) pair to its TGSI output, which should
also make it slightly easier to add support for dual-source blending
in combination with multiple render targets in the long run.
No Piglit regressions on llvmpipe.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
text data bss dec hex filename
7669233 277176 28624 7975033 79b079 i965_dri.so before generated code
7647081 277176 28624 7952881 7959f1 i965_dri.so before this commit
7669289 277176 28624 7975089 79b0b1 i965_dri.so with this commit
Looking at the generated assembly, it appears that some of changes made
in the generated code prevent some loops from being unrolled. Removing
the default cases (via unreachable()) allows these loops to unroll again.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
constant_template_common can now handle the case where the result type
is different from the input type by using type_signature_iter. This
changes the "shape" of all the cast-style operators, but they should
function the same.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
constant_template_common can now handle the case where the result type
is different from the input type by using type_signature_iter.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This template is mostly an artefact of the development of the original
patch series and to minimize the differences between the original code
and the generated code.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The difference between these two templates were mostly an artefact of
the development of the original patch series and to minimize the
differences between the original code and the generated code.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
Immediately previous to this patch,
diff -wud src/glsl/ir_constant_expression.cpp \
src/glsl/ir_expression_operation_constant.h
should be "minimal."
v3: With much help from José Fonseca, fix the SCons build.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
ir_triop_bitfield_extract is a little weird because the second and third
operand and aways int, so they may differ in type from the first
operand.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
The code generated is quite different from what was previously used. I
believe that it is still correct by the GLSL spec, and I believe, due to
C rules about shifts, the behavior will be the same.
Section 5.9 (Expressions) of the GLSL 4.50 spec says:
The result is undefined if the right operand is negative, or greater
than or equal to the number of bits in the left expression's base
type.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
ldexp is weird because its two operands have different types. Add
support for directly specifying the exact signatures of all the possible
variations of an operation.
v2: Use tuple() instead of () for clarity. Suggested by Dylan.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
These are operations like the pack functions that have separate
functions that assign multiple outputs from a single input.
v2: Correct the source and destination types. They were previously
transposed.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
Only operations where the implementation is identical code regardless of
type. The only such operations are ir_binop_all_equal and
ir_binop_any_nequal.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
v2: Remove extra int() cast in find_lsb. Suggested by Matt. 'for (a,
b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
Unary operations where all of the supported types use the same C
expression to evaluate them.
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
(X & -X) calculates a value with only the least significant bit of X
set. Since there is only one bit set, the LSB is the MSB.
v2: Remove extra int() cast. Suggested by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The operator_string functions gave us some protection against a
malformed table. Now that the table is generated from the same data
that generates the enum, this is not a concern. Just cut out the middle
man.
text data bss dec hex filename
7531892 273992 28584 7834468 778b64 i965_dri-64bit-before.so
7531828 273992 28584 7834404 778b24 i965_dri-64bit-after.so
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
'diff -ud' is clean.
v2: Massive rebase.
v3: With much help from José Fonseca, fix the SCons build.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
No change except to the copyright symbol. The next patch will generate
this file with Python, and Unicode + Python = pure rage.
v2: Massive rebase.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This ensures that they remain correct if the list is rearranged or new
opcodes are added. I checked a diff of before and after to ensure that
each ir_last_ had the same value.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
There are differences in where end-of-line comments are placed, but
'diff -wud' is clean.
v2: Massive rebase.
v3: With much help from José Fonseca, fix SCons build.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
The original pipeline cache the Kristian wrote was based on a now-false
premise that the shaders can be stored in the pipeline cache. The Vulkan
1.0 spec explicitly states that the pipeline cache object is transiant and
you are allowed to delete it after using it to create a pipeline with no
ill effects. As nice as Kristian's design was, it doesn't jive with the
expectation provided by the Vulkan spec.
The new pipeline cache uses reference-counted anv_shader_bin objects that
are backed by a large state pool. The cache itself is just a hash table
mapping keys hashes to anv_shader_bin objects. This has the added
advantage of removing one more hand-rolled hash table from mesa.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97476
Acked-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>
This new anv_shader_bin struct stores the compiled kernel (as an anv_state)
as well as all of the metadata that is generated at shader compile time.
The struct is very similar to the old cache_entry struct except that it
is reference counted and stores the actual pipeline_bind_map. Similarly to
cache_entry, much of the actual data is floating-size and stored after the
main struct. Unlike cache_entry, which was storred in GPU-accessable
memory, the storage for anv_shader_bin kernels comes from a state pool.
The struct itself is reference-counted so that it can be used by multiple
pipelines at a time without fear of allocation issues.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Acked-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>
All of these worked before because they were depending on prog_data to be
null. Soon, we won't be able to depend on a nice prog_data pointer and
it's nice to be more explicit anyway.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
The range from ANV_MIN_STATE_SIZE_LOG2 to ANV_MAX_STATE_SIZE_LOG2 should
be inclusive and we have asserts that ensure that you never try to allocate
a state larger than (1 << ANV_MAX_STATE_SIZE_LOG2). However, without
adding 1 to the difference, we allocate 1 too few bucckts and so, even
though we have an assert, anything landing in the last bucket will fail to
allocate properly..
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This script was broken for the last few days and I couldn't figure out why.
Turns out it was checking for the existence of a file that got renamed,
so rename it in here too.
Fixes: f926cf5bd0 ("docs: Rename GL3.txt to features.txt")
CC: Ian Romanick <ian.d.romanick@intel.com>
CC: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Caught by Coverity. Likely fixes real issues if an output component
is not present.
CID: 1372278
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
While we are at it, make it static and change the return values
policy to be consistent.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This silences a divergent error found with F1 2015.
Basically, the NDV bit has to be set when a FSWZ instruction is
inside divergent code, but it's not needed otherwise. The correct
fix should be to set it only in divergent code situations.
GM107 emitter already sets that bit.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: <mesa-stable@lists.freedesktop.org>
Topi asked to have the prefix removed because there's nothing gen7 about
it. However, now that everything is in a single file, there is no good
reason to have it split out into a helper function anyway. Let's just put
the contents in emit_urb_config and call it a day.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
No longer needed as of last commit, since we no longer add OPENGL to the
ClientAPIs thus, RenderType and Conformant don't have the desktop GL
bit set.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
In the rather unlikely case that the API is considered invalid, don't
add it to the (supported) ClientAPIs bitmask.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
---
Strictly speaking we only need this in the Android case for OpenGL.
Adding it everywhere doesn't hurt us since the compiler will const
propagate and optimise/remove these.
At the moment one can use OpenGL in eglBindAPI() only to clear the
EGL_OPENGL_BIT from RenderableType and Conformant for _each_ config.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
This avoids generating fbconfigs whose winsys framebuffers will be
incomplete (see nouveau_check_framebuffer_complete).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Experimentally, this is required for glxgears and others to display the
proper colors. This is also what the code used to do before the
referenced commit.
Fixes: c703658b39 (mesa: Drop _EnabledUnits.)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
NV34 and possibly other NV3x hardware has the capability of exposing the
NV25 graph class. This allows forcing nouveau_vieux to be used instead
of the gallium driver, primarily for testing purposes. (Among other
things, NV2x only ever came as AGP or inside an Xbox, never PCI/PCIe).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Commit 7413625ad3 flipped a few functions too many to use
pipe_shader_type. These functions actually take an integer that does not
correspond 1:1 with the enum.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Backing views/surfaces are used to handle the case when a resource is
bound both as a render target and as a sampler source (such as when
doing auto mipmap generation).
This patch fixes a bug where mapping a resource (to do a glReadPixels)
was reading the stale data in the original surface rather than the
backing surface which was rendered to.
We need to propagate the backing resource (which we rendered to) back
to the original resource before we read from it. The problem was the
svga_propagate_rendertargets() function was examining the wrong surface
views.
This fixes the "poc9" test described in VMware bug 1686661.
Also tested with Piglit, Cinebench, Lightsmark, etc.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We need to set the need_convert flag with each loop iteration, not
just when the rgba pointer is null.
Bug reported by Markus Müller <mueller@imfusion.de> on mesa-users list.
Fixes new piglit arb_texture_float-get-tex3d test.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This should be all that is required for cull distances to work
on radeonsi.
v1.1: whitespace cleanup, add docs fix clipdist_mask usage.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This keeps invalid surface states from leaking through and potentially
hanging the GPU. We shouldn't actually be hitting this on a regular basis,
but a helpful assert is better than a hang.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This allows us to use the actual render format as opposed to the texture
format. I don't know that the hardware actually cares in the case of fast
clears, but it certainly seems more correct.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
At this point, blorp is completely driver agnostic and can be safely moved
into its own folder. Soon, we hope to start using it for doing blits in
the Vulkan driver.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This has been the only caller since we deleted the meta fast clear code.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This commit switches all of blorp from taking a brw_context to taking a
blorp_context and, where useful, a void *batch. In the GL driver, we only
have one active batch at a time so the brw_context *is* the batch but in
Vulkan, batch will point to the anv_cmd_buffer in which we are building
instructions.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This gets rid of brw_context throughout the core of the state setup code.
Instead, it is replaced with blorp_batch which contains a pointer to the
blorp_context and a void* that the driver can use for its own blorp data.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Previously, we passed the buffer address (as per the latest offset from the
kernel) to ISL to use when it filled out the surface state. We then called
drm_intel_bo_emit_reloc() to add the relocation to the list. The newly
added blorp_surface_reloc helper adds the relocation to the list and then
writes the buffer address directly into the surface state.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This pulls most of the brw-specific bits into helpers with generic names.
Later, those will become the driver hooks for generic code.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This sanitizes blorp's access to the i965 driver's shader cache by patching
it through the blorp_context. When we start using blorp in Vulkan, we will
simply have to implement such a caching interface in the Vulkan driver.
Note: In my first attempt at this, I simplified it down to a single
upload_shader entrypoint and implemented the caching inside of blorp. This
doesn't work, however, because the i965 driver will, on occation, dump its
entire cache and start over. When this happens, blorp needs to be able to
recompile its shaders and re-upload them. It's easiest to just expose the
caching interface.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Android porting of commit bebc1a1 "intel: Flatten the makefile structure"
Automake approach was followed, by moving makefiles a level up,
naming them Android.genxml.mk and Android.isl.mk,
performing the necessary adjustments to the paths,
adding src/intel/Android.mk and fixing mesa top level makefile.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Small code clean up that removes magic numbers where a TGSI
opcode has been defined.
No functional change expected as each opcode is unsupported on
the respective hardware.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: James Harvey <lothmordor@gmail.com>
As reported by Clang, TGSI_OPCODE_DFMA (defined magic number 118) is
currently initialized twice for Cayman and Evergreen.
When Jan Vesely added double precision FMA opcode it did make sense
to locate it immediately after TGSI_OPCODE_DMAD, although this is
out of order.
This change cleans up the prior magic number definition and ensures
any later reordering of this struct will not create problems.
Prior change was:
commit 015e2e0fce
Author: Jan Vesely <jan.vesely@rutgers.edu>
Date: Sat Jul 2 16:14:54 2016 -0400
r600g: Add double precision FMA ops
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96782
Fixes: 54c4d525da ("r600g: Enable FMA on chips that support it")
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Tested-by: James Harvey <lothmordor@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: James Harvey <lothmordor@gmail.com>
Implement SCATTERPS as a dynamic loop based on mask set bits
instead of a static compile time loop.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
- use per-primitive viewports throughout the pipeline.
- track whether all available scissor rects are tile aligned.
Causes failures, so not taken into account when choosing rasterizer yet.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
We were allocating global variables for the maximum LDS size
which made the compiler think we were using all of LDS, which
isn't the case.
Reviewed-By: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
v1 → v2:
- Fixed indentation (noted by Brian Paul)
- Removed second assert from nouveau's switch statements (suggested by
Brian Paul)
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Use temporary buffers so that we don't read and write to the
same surface at the same time. We don't need to use linear
layout now.
v2: rebase the patch against reverted change
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This reverts commit 09dff7ae2e.
Turned out this can cause some artifacts in the output. Let's revert
it for now until we have sorted out all issues.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
This hack was introduced in commit 03ac2c7223:
i965/gs: Fix up gl_PointSize input swizzling for DUAL_INSTANCED gs
Specifically to fixup the code we emitted to deal with gl_PointSize inputs
in dual instance mode, where we were emitting a MOV to copy the point
size from .w (where the hardware delivers it) to .x (because code will
expect this to be a float). This meant that we were emitting a MOV
to an ATTR destination that could have a width of 4 (in dual instanced
mode) so it was necessary to fix the execution size and regioning of the
instruction.
Fortunately, Ken fixed this in 67c5d00273:
i965/vec4/gs: Stop munging the ATTR containing gl_PointSize.
by using a WWWW swizzle instead of a MOV, and as the commit log in that
patch states, we no longer emit instructions with ATTR destinations, so
that makes the fixup code in the generator unnecessary.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
As retrieved from opengl.org and khronos.org. Maintained the APPLE hack
in GL/glext.h manually. Added gl32.h.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Dave Airlie <airlied@redhat.com>
This is identical to OES_texture_cube_map_array support. dEQP has tests
which use this extension. Also it is part of AEP.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This extension should just be available whenever ES 3.1 is available.
With the new extension verification infrastructure, it will only be
enable-able on a #version 310 es shader, rendering the original reason
for having a separate enable moot.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These are the only platforms that current expose OES_geometry_shader.
Once OpenGL ES 3.1 and OES_geometry_shader are enabled on Gen7, this
extension can be enabled there as well.
Gen6 will never get OpenGL ES 3.1, so it will never get this
extension... even though it has the desktop OpenGL extension. Alas.
NOTE: This causes a failure on Gen8+ platforms in
ES3-CTS.gtf.GL3Tests.texture_storage.texture_storage_texture_targets.
The test only fails because it doesn't know that 0x9009 is a valid
value when the extension exists.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This has a separate enable flag because this extension also requires
OES_geometry_shader. It is possible that some drivers may support
OpenGL ES 3.1 and ARB_texture_cube_map but not support
OES_geometry_shader.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Gen7 can get this extension (and GL_OES_shader_io_blocks) as soon as the
rest of OpenGL ES 3.1 is enabled.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When GL_OES_geometry_shader is enabled, this fixes
dEQP-GLES31.functional.shaders.linkage.geometry.uniform.rules.type_mismatch_1.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The checks in _mesa_has_shader_subroutine are slightly different than
_mesa_has_ARB_shader_subroutine, but they're not different in a way
that matters. The only way to have ctx->Version >= 40 is if
ctx->Extensions.ARB_shader_subroutine is set.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
GL_DOT3_RGB_EXT and GL_DOT3_RGBA_EXT. are nearly identical to
GL_DOT3_RGB and GL_DOT3_RGBA. The only difference is the _EXT
versions do not apply the post-scale. Just smash logscale to 0 so
that RC_OUT_SCALE_1 is always used.
NOTE: I have not actually tested this.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Fixes long standing bug on NV10 and NV20 where using a non-1x RGB or A
post-scale with GL_DOT3_RGB or GL_DOT3_RGBA texture environment would
not work.
The old combiner math uses HALF_BIAS_NORMAL and HALF_BIAS_NEGATE. The
GL_NV_register_combiners defines these as
HALF_BIAS_NORMAL_NV max(0.0, e) - 0.5
HALF_BIAS_NEGATE_NV -max(0.0, e) + 0.5
In order to get the correct result from the dot-product, the
intermediate dot-product must be multiplied by 4. This is a literal
implementation of the GL_ARB_texture_env_dot3 spec. It also requires
using the register combiner post-scale. As a result, the post-scale
cannot be used for the post-scale set by the application.
The new combiner math uses EXPAND_NORMAL and EXPAND_NEGATE. The
GL_NV_register_combiners defines these as
EXPAND_NORMAL_NV 2.0 * max(0.0, e) - 1.0
EXPAND_NEGATE_NV -2.0 * max(0.0, e) + 1.0
Since this fully expands the value to [-1, 1] range, the intermediate
dot-product result is the desired value. This leaves the register
combiner post-scale available for application use.
NOTE: I have not actually tested this.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
v2: Note that GL_KHR_blend_equation_advanced and
GL_KHR_blend_equation_advanced_coherent are done.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a direct port of Marek Olšáks patch
"radeonsi: increase performance for DRI PRIME
offloading if 2nd GPU is CIK or VI" to r600.
It uses SDMA for the detiling blit from renderoffload VRAM
to GTT, as SDMA is much faster for tiled->linear blits from
VRAM to GTT.
Testing on a dual Radeon HD-5770 setup reduced the time
for the render offload gpu to get its rendering into
system RAM from approximately 16 msecs for simple rendering
at 1920x1080 pixel 32 bpp to 5 msecs, a > 3x speedup!
This was measured using ftrace to trace the time the radeon kms
driver waited on the dmabuf fence of the renderoffload gpu to
complete.
All in all this brought the time for a flip down from 20 msecs
to 9 msecs, so the prime setup can display at full 60 fps instead
of barely 30 fps vsync'ed.
The current r600 implementation supports SDMA on Evergreen and
later, but not R600/R700 due to some bugs apparently present
in their SDMA implementation.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
For gen < 8, we can't sample from the stencil buffer, which is
required for the ARB_stencil_texturing extension. We'll make a copy of
the stencil data into a new texture that we can sample using the
R8_UINT surface type.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
thread_width_max in the GPGPU walker command limits us to a maximum of
64 threads.
This fixes a crash on Haswell in the OpenGLES 3.1 conformance test
suite which tests the advertised limits of the max invocation counts.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This file was supposed to be added with the previous "svga: add guest
statistic gathering interface" patch but went MIA for some reason.
Reviewed-by: Brian Paul <brianp@vmware.com>
SDMA is much faster for tiled->linear blits from VRAM to GTT.
I have Bonaire in my second PCIe slot.
$ glxinfo | grep OpenGL.renderer
OpenGL renderer string: Gallium 0.4 on AMD TONGA ...
$ DRI_PRIME=1 glxinfo | grep OpenGL.renderer
OpenGL renderer string: Gallium 0.4 on AMD BONAIRE ...
Without SDMA:
$ DRI_PRIME=1 glxgears
8796 frames in 5.0 seconds = 1759.074 FPS
8899 frames in 5.0 seconds = 1779.672 FPS
With SDMA:
$ DRI_PRIME=1 glxgears
12765 frames in 5.0 seconds = 2552.788 FPS
12888 frames in 5.0 seconds = 2577.495 FPS
The 1st GPU is irrelevant. The improvement should be much lower at 60 fps,
but definitely measurable.
SI will get this once we add SDMA blit support for it.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This regression is caused because of commit 3190c7ee97
Regression caused by following OpenGL 4.4 spec rules relates to
GL_FRAMEBUFFER_SRGB in Mesa.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Fixes piglit spec/ext_transform_feedback/overflow-edge-cases segfaults
because the query's fence pointer was null.
Tested with Piglit, Sauerbraten, ETQW.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We don't want to flush the command buffer or sync on the fence when ending
a query (that kind of defeats the whole purpose of async queries). Do that
instead in get_query_result().
Tested with Piglit, arbocclude, Sauerbraten game, Nobel Clinician Viewer,
ETQW.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
This patch avoid emitting redundant DXSetSamplers command.
Tested with Lightsmark2008, Heaven, MTT piglit, glretrace, viewperf.
Reviewed-by: Brian Paul <brianp@vmware.com>
Put all the clearing related functions in svga_init_clear_functions()
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
define svga_init_clear_functions()
and svga_clear_texture as svga->pipe.clear_texture. This is part of
ARB_clear_texture extension
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
To clear texture this function can be used. This is part of
ARB_clear_texture extension. Basically this extension allows you to
clear texture with given color values.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Saving all blitter states will be done in begin_blit() so that
begin_blit() can be used before performing any blit operation.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
With this patch, guest statistic gathering interface is added to
svga winsys interface that can be used to gather svga driver
statistic. The winsys module can then share the statistic info with
the VMX host via the mksstats interface.
The statistic enums used in the svga driver are defined in
svga_stats_count and svga_stats_time in svga_winsys.h
Reviewed-by: Brian Paul <brianp@vmware.com>
If the shader has indirect access to non-indexable temporaries,
convert these non-indexable temporaries to indexable temporary array.
This works around a bug in the GLSL->TGSI translator.
Fixes glsl-1.20/execution/fs-const-array-of-struct-of-array.shader_test
on DX11Renderer.
Reviewed-by: Brian Paul <brianp@vmware.com>
From about kernel 4.9, GTT mmaps are virtually unlimited. A new
parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the
feature so query it and use it to avoid limiting tiled allocations to
only fit within the mappable aperture.
A couple of caveats:
- fence support is still limited by stride to 262144 and the stride
needs to be a multiple of tile_width (as before, and same limitation as
the current 3D pipeline in hardware)
- the max_gtt_map_object_size forcing untiled may be hiding a few bugs
in handling of large objects, though none were spotted in piglits.
See kernel commit 4cc6907501ed ("drm/i915: Add I915_PARAM_MMAP_GTT_VERSION
to advertise unlimited mmaps").
v2: Include some commentary on mmap virtual space vs CPU addressable
space.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was found by obs:
I: Program returns random data in a function
E: Mesa no-return-in-nonvoid-function main/program_resource.c:109
v2: Remove the ! on the string (Ian Romanick)
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We always use a coherent read, and ignore the "opt out" enable flag.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This adds the extension enable (so drivers can advertise it) and the
extra boolean state flag, GL_BLEND_ADVANCED_COHERENT_KHR, which can
be set to request coherent blending.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
We'll do blending in the shader in this case, so just disable the
hardware blending.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Many GPUs cannot handle GL_KHR_blend_equation_advanced natively, and
need to emulate it in the pixel shader. This lowering pass implements
all the necessary math for advanced blending. It fetches the existing
framebuffer value using the MESA_shader_framebuffer_fetch built-in
variables, and the previous commit's state var uniform to select
which equation to use.
This is done at the GLSL IR level to make it easy for all drivers to
implement the GL_KHR_blend_equation_advanced extension and share code.
Drivers need to hook up MESA_shader_framebuffer_fetch functionality:
1. Hook up the fb_fetch_output variable
2. Implement BlendBarrier()
Then to get KHR_blend_equation_advanced, they simply need to:
3. Disable hardware blending based on ctx->Color._AdvancedBlendEnabled
4. Call this lowering pass.
Very little driver specific code should be required.
v2: Handle multiple output variables per render target (which may exist
due to ARB_enhanced_layouts), and array variables (even with one
render target, we might have out vec4 color[1]), and non-vec4
variables (it's easier than finding spec text to justify not
handling it). Thanks to Francisco Jerez for the feedback.
v3: Lower main returns so that we have a single exit point where we
can add our blending epilogue (caught by Francisco Jerez).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This will be used for emulating GL_KHR_advanced_blend_equation features
in shader code. We'll pass in the blending mode that's in use, and use
that in (effectively) a switch statement in the shader.
v2: Use the new _AdvancedBlendMode field.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
I'm about to add more error conditions to this function, so I wanted to
move the current spec citation above the code that checks it. Indenting
it required reformatting, so I tried to move it to our newer style.
While there, I also decided to drop some GL type usage, and drop the
unnecessary "_mesa_" prefix on a static function.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This will be useful for a number of things:
- Checking the current advanced blending mode against the shader's
blend_support_* qualifiers.
- Disabling hardware blending when emulating advanced blending.
- Uploading the current advanced blending mode as a state var.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Don't allow them in glBlendEquationSeparate[i], though, as required
by the spec.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Since each qualifier represents a blending mode the shader can be used
with, we take the union of all possible modes when linking.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
v2 (Ken): Add a BLEND_NONE enum value (no qualifiers in use).
v3 (Ken): Rename gl_blend_support_qualifier to gl_advanced_blend_mode.
v4 (Ken): Mark map[] as static const (Ilia).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
v2 (Ken): Fix enum values, drop _mesa_BlendBarrierKHR stub as Curro has
already implemented it.
v3 (Ken): Rework for _mesa_BlendBarrierKHR -> _mesa_BlendBarrier rename.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Note that _mesa_BlendBarrierMESA is not currently hooked up in the
glapi XML, so we can just rename it. We'll hook it up for the
KHR_blend_equation_advanced extension shortly.
We may as well use the ES 3.2 core name with no suffixes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
We want to insert code in each of the predecessors of the end block.
This code includes a nir_if, which would split the block, altering
the set. To avoid that, I emitted a dead constant at the end of each
block before splitting it, so that the set of predecessors remained
unchanged. This was admittedly ugly.
Connor suggested instead saving a copy of the set, so we can iterate
it safely. This is also a little ugly, but a much better plan.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
We want to insert the code at the end of the program. Looping over
all the functions (of which there was only one) was the old way of doing
this, but now we have nir_shader_get_entrypoint(), so let's use it.
Suggested by Connor Abbott.
v2: Update for nir_shader_get_entrypoint API change.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Jason suggested adding an assert(function->impl) here. All callers
of this function actually want ->impl, so I decided just to change
the API.
We also change the nir_lower_io_to_temporaries API here. All but one
caller passed nir_shader_get_entrypoint(), and with the previous commit,
it now uses a nir_function_impl internally. Folding this change in
avoids the need to change it and change it back.
v2: Fix one call I missed in ir3_compiler (caught by Eric).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
This changes the pass internals to work with a nir_function_impl
directly rather than a nir_function. The next patch will change
the API.
v2: Rebase after framebuffer fetch landed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
The reason why it was safe for the scheduler to ignore the side
effects of framebuffer write instructions was that its side effects
couldn't have had any influence on any other instruction in the
program, because we weren't doing framebuffer reads, and framebuffer
writes were always non-overlapping. We need actual memory dependency
analysis in order to determine whether a side-effectful instruction
can be reordered with respect to other instructions in the program.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We weren't checking the fs_inst::target field when comparing whether
two instructions are equal. For FB writes it doesn't matter because
they aren't CSE-able anyway, but this would have become a problem with
FB reads which are expression-like instructions.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
brw_set_dp_read_message() was setting the data cache as send message
SFID on Gen7+ hardware, ignoring the target cache specified by the
caller. Some of the callers were passing a bogus target cache value
as argument relying on brw_set_dp_read_message not to take it into
account. Fix them too.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is not enabled on the original Gen4 part because it lacks surface
state tile offsets so it may not be possible to sample from arbitrary
non-zero layers of the framebuffer depending on the miptree layout (it
should be possible to work around this by allocating a scratch surface
and doing the same hack currently used for render targets, but meh...).
On Gen9+ even though it should mostly work (feel free to force-enable
it in order to compare the coherent and non-coherent paths in terms of
performance), there are some corner cases like 1D array layered
framebuffers that cannot be handled easily by the non-coherent path
because of the incompatible layout in memory of 1D and 2D miptrees (it
should be possible to work around this too by doing state-dependent
recompiles, but it's hard to care enough since Gen9 has native support
for coherent render target reads...)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a no-op if the platform supports coherent framebuffer fetch,
-- If it doesn't we just need to flush the render cache and invalidate
the texture cache in order for previous rendering to be visible to
framebuffer fetch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This iterates over the list of attached render buffers and binds
appropriate surface state structures to the binding table block
allocated for shader framebuffer read.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This allows the caller to bind a miptree using a texture target other
than the one it it was created with. The code should work even if the
memory layouts of the specified and original targets don't match, as
long as the caller only intends to access a single slice of the
miptree structure.
This will be exploited by the next commit in order to support
non-coherent framebuffer fetch of a single layer of a 3D texture
(since some generations lack the minimum array element control for 3D
textures bound to the sampler unit), and multiple layers of a 1D array
texture (since binding it as an actual 1D array texture would require
state-dependent recompiles because the same shader couldn't
simultaneously work for 1D and 2D array textures due to the different
texel fetch coordinate ordering).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This commit does three different things in a single pass in order to
keep the amount of churn low: Remove the for_gather boolean argument
which was unused, pass the isl_view argument by value rather than by
reference since I'll have to modify it from within the function, and
add a target argument to allow callers to bind textures using a target
other than the original. The prototype of the function now looks
like:
void brw_emit_surface_state(struct brw_context *brw,
struct intel_mipmap_tree *mt,
GLenum target, struct isl_view view,
uint32_t mocs, uint32_t *surf_offset, int surf_index,
unsigned read_domains, unsigned write_domains);
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The logic to calculate the right layout and dimensionality for a given
GL texture target is going to be useful elsewhere, factor it out from
intel_miptree_get_isl_surf().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is required because the sampler unit used to fetch from the
framebuffer is unable to interpret non-color-compressed fast-cleared
single-sample texture data. Roughly the same limitation applies for
surfaces bound to texture or image units, but unlike texture sampling,
non-coherent framebuffer fetch is by definition non-coherent with
previous rendering, so the brw_render_cache_set_check_flush() call can
be omitted except after resolve.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This gets rid of the duplication of logic between nir_setup_outputs()
and get_frag_output() by allocating fragment output temporaries lazily
whenever get_frag_output() is called. This makes nir_setup_outputs()
a no-op for the fragment shader stage.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The problem with the current approach is that driver output locations
are represented as a linear offset within the nir_outputs array, which
makes it rather difficult for the back-end to figure out what color
output and index some nir_intrinsic_load/store_output was meant for,
because the offset of a given output within the nir_output array is
dependent on the type and size of all previously allocated outputs.
Instead this defines the driver location of an output to be the pair
formed by its GLSL-assigned location and index (I've borrowed the
bitfield macros from brw_defines.h in order to represent the pair of
integers as a single scalar value that can be assigned to
nir_variable_data::driver_location). nir_assign_var_locations is no
longer useful for fragment outputs.
Because fragment outputs are now allocated independently rather than
within the nir_outputs array, the get_frag_output() helper becomes
necessary in order to obtain the right temporary register for a given
location-index pair.
The type_size helper passed to nir_lower_io is now type_size_dvec4
rather than type_size_vec4_times_4 so that output array offsets are
provided in terms of whole array elements rather than in terms of
scalar components (dvec4 is the largest vector type supported by the
GLSL so this will cause all individual fragment outputs to have a size
of one regardless of the type).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Most likely we had only ever used this macro on bitfields of less than
31 bits -- That's going to change shortly.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I'm about to change how fragment shader output locations are
represented, so the generic nir_intrinsic_store_output implementation
that assumes that outputs are just contiguous elements in the big
nir_outputs array won't work anymore. This somewhat simplified
implementation of nir_intrinsic_store_output for fragment shaders
should be functionally equivalent to the current fall-back one.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will be required for the next commit since the non-coherent path
makes use of the fragment coordinates implicitly, so they need to be
calculated.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The result of a framebuffer fetch from a multisample FBO is inherently
per-sample, so the spec requires at least those sections of the shader
that depend on the framebuffer fetch result to be executed once per
sample.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Unfortunately due to the inconsistent meaning of some surface state
structure fields, we cannot re-use the same binding table entries for
sampling from and rendering into the same set of render buffers, so we
need to allocate a separate binding table block specifically for
render target reads if the non-coherent path is in use.
The slight noise is due to the change of
brw_assign_common_binding_table_offsets to return the next available
binding table index rather than void.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Some of the following changes in this series are specific to the
non-coherent path, so I need some way to tell whether the coherent or
non-coherent path is in use. The flag defaults to the value of the
gl_extensions::MESA_shader_framebuffer_fetch enable so that it can be
overridden easily on hardware that supports both framebuffer fetch
extensions in order to test the non-coherent path, like:
MESA_EXTENSION_OVERRIDE=-GL_EXT_shader_framebuffer_fetch
(Of course trying to force-enable the coherent framebuffer fetch
extension on hardware without native support won't work and lead to
assertion failures).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This boolean flag was being used for two different things:
- To set the brw_wm_prog_data::dual_src_blend flag. Instead we can
just set it based on whether the dual_src_output register is valid,
which will be the case if the shader writes the secondary blending
color.
- To decide whether to call emit_single_fb_write() once, or in a loop
that would iterate only once, which seems pretty useless.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This requires emitting a series of copies at the top of the program
from each output variable to the corresponding temporary. The initial
copy can be skipped for non-framebuffer fetch outputs whose initial
value is undefined, and the final copy needs to be skipped for
read-only outputs (i.e. gl_LastFragData), since it would be illegal to
emit a store output intrinsic for it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The NIR representation of framebuffer fetch is the same as the GLSL
IR's until interface variables are lowered away, at which point it
will be translated to load output intrinsics. The GLSL-to-NIR pass
just needs to copy the bits over to the NIR program.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We need the source to be in r0-r3, so make a new register class for it.
It will be up to the surrounding passes to make sure that the r0-r3
allocation of its source won't conflict with anything other class
requirements on that temp.
Respect intel_miptree_slice::x_offset,y_offset and
intel_mipmap_tree::offset. All three may be non-zero when glReadPixels
is called on an EGLImage created from the non-base slice of a miptree.
Patch 2/2 that fixes test
'dEQP-EGL.functional.image.create.gles2_cubemap_*'.
Reported-by: Haixia Shi <hshi@chromium.org>
Diagnosed-by: Haixia Shi <hshi@chromium.org>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Change-Id: I4b397b27e55a743a7094d29fb0a6a4b6b34352b0
When glEGLImageTargetRenderbufferStorageOES() was given an EGLImage
created from the non-base slice of a miptree,
intel_image_target_renderbuffer_storage() forgot to apply the intra-tile
offsets __DRIimage::tile_x,tile_y to the miptree layout.
This patch fixes the problem with a quick hack suitable for
cherry-picking. A proper fix requires more thorough plumbing in
intel_miptree_create_layout() and brw_tex_layout().
Patch 1/2 that fixes test
'dEQP-EGL.functional.image.create.gles2_cubemap_*'.
Reported-by: Haixia Shi <hshi@chromium.org>
Diagnosed-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Change-Id: I8a64b0048a1ee9e714ebb3f33fffd8334036450b
This pulls isl and genxml into a single make file so that they can properly
build in parallel. This isn't terribly important now as genxml just
generates sources which happens serially first anyway but it will be more
important as we add more stuff to src/intel.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The tests assumed that isl would be in the include path but that usually
isn't the case. Instead, we usually have src/intel and you need to add an
"isl/" prefix.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
If the surface has a layout of GEN4_2D then we need to compute a normal 2D
alignment and not use the magic linewar 1D alignment.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
The Sky Lake 1D layout is only used if the surface is linear. For tiled
surfaces such as depth and stencil the old gen4 2D layout is used.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
In some programs, we can have very deep dominance trees and the recursion
can cause us to risk stack overflows. Instead, we replace the recursion
with a pair of loops, one at the start and one at the end. This is
functionally equivalent to what we had before and it's actually a bit
easier to read in the new form without the recursion.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97225
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Prior to this commit rename_variables_block() is recursively called,
performing a depth-first traversal of the control flow graph. The
function uses a non-trivial amount of stack space for local variables,
which puts us in danger of smashing the stack, given a sufficiently deep
dominance tree.
XCOM: Enemy Within contains a shader with such a dominance tree (1574
nir_blocks in total, depth of at least 143).
Jason tells me that he believes that any walk over the nir_blocks that
respects dominance is sufficient (a DFS might have been necessary prior
to the introduction of nir_phi_builder).
In fact, the introduction of nir_phi_builder made the problem worse:
rename_variables_block(), walks to the bottom of the dominance tree
before calling nir_phi_builder_value_get_block_def() which walks back to
the top of the dominance tree...
In any case, this patch ensures we avoid that problem as well.
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97225
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
We can take advantage of the fact that multi_fence does the obvious thing
with NULL fences.
This fixes unflushed fences that can get stuck due to empty IBs.
Some front buffer rendering was in the wrong position. This included
scissored clears, glDrawPixels and glCopyPixels. The problem was the
y coordinate passed to putImage() didn't match the y coordinate passed
to getImage().
We fix this by setting xrb->map_y to the inverted coordinate in
swrast_map_renderbuffer() which is used later by the putImage() call.
Also pass xrb->map_y to getImage() to be symmetric.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97426
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
radeonsi needs to do some operations (DCC decompression) for OpenGL-OpenCL
interop and this is the only way to make it coherent with the current
context. It can optionally be set to NULL.
Reviewed-by: Brian Paul <brianp@vmware.com>
Always use 3 buffers when flipping. With only 2 buffers, we have to wait
for a flip to complete (which takes non-0 time even with asynchronous
flips) before we can start working on the next frame. We were previously
only using 2 buffers for flipping if the X server supports asynchronous
flips, even when we're not using asynchronous flips. This could result
in bad performance (the referenced bug report is an extreme case, where
the inter-frame stalls were preventing the GPU from reaching its maximum
clocks).
I couldn't measure any performance boost using 4 buffers with flipping.
Performance actually seemed to go down slightly, but that might have
been just noise.
Without flipping, a single back buffer is enough for swap interval 0,
but we need to use 2 back buffers when the swap interval is non-0,
otherwise we have to wait for the swap interval to pass before we can
start working on the next frame. This condition was previously reversed.
Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97260
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The pipeline layout affects shader compilation because it is what
determines binding table locations as well as whether or not a particular
buffer has dynamic offsets. Since this affects the generated shader, it
needs to be in the hash. This fixes a bunch of CTS tests now that the CTS
is using a pipeline cache.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This option makes installed Vulkan ICD files contain only a driver library
name and not a path. This is intended for distros to help them work around
multi-arch issues.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This would cause gl_FragStencilRef to be counted as a color output
incorrectly during the precompile phase, which leads to unnecessary
recompilation on master and could trigger an assertion failure in
fs_visitor::emit_fb_writes() on my i965-fb-fetch branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is the set of shader outputs whose initial value is provided to
the shader by some external means when the shader is executed, rather
than computed by the shader itself.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since they cannot be written. This prevents adding fragment outputs
to the OutputsWritten set that are only read from via the
gl_LastFragData array but never written to.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Apparently this pass can only handle elimination of a single built-in
fragment output array, so the presence of gl_LastFragData (which it
wouldn't split correctly anyway) could prevent it from splitting the
actual gl_FragData array. Just match gl_FragData by name since it's
the only built-in it can handle.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The EXT_shader_framebuffer_fetch extension defines alternative
language for GLES2 shaders where user-defined fragment outputs are not
allowed. Instead of using inout user-defined fragment outputs the
shader is expected to read from the gl_LastFragData built-in array.
In addition this allows using the same language on desktop GLSL
versions prior to 4.2 that support the deprecated gl_FragData built-in
in preparation for the MESA_shader_framebuffer_fetch desktop GL
extension.
Both legacy and user-defined inout outputs have a common
representation at the GLSL IR level, so it shouldn't make any
difference for optimization passes and back-ends whether the
application is using gl_LastFragData or user-defined outputs, all
they'll see is a variable dereference of a fragment output at a
certain interface location with the fb_fetch_output bit set to one.
v2: Don't define the built-in variable on GLSL versions for which
gl_FragData exists but is deprecated. (Ken)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
According to the EXT_shader_framebuffer_fetch extension the inout
qualifier can be used on ESSL 3.0+ shaders to declare a special kind
of fragment output that gets implicitly initialized with the previous
framebuffer contents at the current fragment coordinates. In addition
we allow using the same language to define FB fetch outputs in GLSL
1.3+ shaders in preparation for the desktop MESA_shader_framebuffer_fetch
extensions.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The GLSL IR representation of framebuffer fetch amounts to a single
bit in the ir_variable object applicable to fragment shader outputs.
The flag indicates that the variable will be implicitly initialized to
the previous contents of the render buffer at the same fragment
coordinates and sample index.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Both MESA_shader_framebuffer_fetch_non_coherent and the non-coherent
variant of KHR_blend_equation_advanced will use this driver hook to
request coherency between framebuffer reads and writes. This
intentionally doesn't hook up glBlendBarrierMESA to the dispatch layer
since the extension isn't exposed to applications yet, see [1]
for more details.
[1] https://lists.freedesktop.org/archives/mesa-dev/2016-July/124028.html
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This can currently only give true as result since the only way you can
expose EXT_shader_framebuffer_fetch right now is by flipping the
MESA_shader_framebuffer_fetch bit, but that could potentially change
in the future, see [1] for an explanation.
[1] https://lists.freedesktop.org/archives/mesa-dev/2016-July/124028.html
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This allows drivers to expose EXT_shader_framebuffer_fetch in GLES2+
contexts if desired. Note that this adds boolean flags for two MESA
extensions, but only the EXT GLES-only extension is exposed for the
moment, see the cover letter of this series [1] for the rationale.
[1] https://lists.freedesktop.org/archives/mesa-dev/2016-July/124028.html
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Like Fermi, textures and samplers are aliased between 3D and compute,
especially the TIC_FLUSH/TSC_FLUSH methods and we have to re-validate
these resources when switching between the two pipelines.
This fixes a GPU hang with Elemental (and most likely with other UE4 demos).
Tested on GK107 and GM107.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
CC: <mesa-stable@lists.freedesktop.org>
Duplicate line is currently on 1535.
Identified by Clang, when run through Eric Anholt's Travis harness.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This will hopefully fix wget from x.org (no real reason explained in
Travis CI bug reports), and may also mean that we can enable LLVM driver
builds.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Rhys Kidd <rhyskidd@gmail.com>
Travis has been broken a couple of times by configure.ac updates. To make
it useful, auto-update the version necessary.
This could potentially be used for other dependencies, too, but those get
bumped less frequently.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Rhys Kidd <rhyskidd@gmail.com>
This happens when three byte "00 00 03" is partly loaded to
vlc->buffer, thus at the bottom of buffer with valid bits is
"00" or "00 00" and left like "00 03" or "03" in the data,
so that it will not be detected by three byte emulation check.
The reason for that is the escaped bit was set to 0 from the
rbsp init.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
drmPrimeHandleToFD() will return the same GEM handle every time the same
buffer is imported, even from a different prime FD. Since GEM handles
are not reference counted, we need to make sure that each GEM handle is
referenced only by one display target struct, by looking it up in
kms_sw->bo_list first and bumping the refcount of the found dt on hit
and falling back to creating a new dt only on miss.
v2: Split into separate function.
Use helper function for lookup.
v3 [Emil Velikov]:
Rename kms_sw_displaytarget_{lookup,find_and_ref} (Jordan)
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com> (v2)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
As a preparation to use the lookup in more than once place, move the
code that looks up given KMS/GEM handle to a separate function. This
change should not introduce any functional changes.
v2: Split into separate patch.
Move lookup code into separate function.
v3 [Emil Velikov]:
Rename kms_sw_displaytarget_{lookup,find_and_ref} (Jordan)
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com> (v2)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Currently kms_sw_displaytarget_add_from_prime() allocates the struct and
fills in only some of the fields, resulting in a half-baked struct that
needs to be further completed by the caller. To make this a bit more
consistent, pass width, height and stride to this function and fill in
everything there, so that caller can take the returned struct as is.
v2: Split from one big patch into four fixing one thing at a time.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Currently the code creates a display target struct with refcount field
initialized to 1 and then the caller again increments it, leading to
a leaked reference. Let's remove the unnecessary increment.
v2: Split from one big patch into four fixing one thing at a time.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Both ARB_shader_subroutine and the GL core spec doesn't list any
error when the program is not linked.
We left a error generation for the uniform location, in order to be
consistent with other methods from the spec that generate them.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
The label `out:` calls `destroy()` which dereferences `ctx`.
This is unnecessary as there is nothing to destroy.
Immediately return instead.
CovID: 1258255
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Before this commit, GetProgramInterfaceiv for pname ACTIVE_RESOURCES
and all the <shader>_SUBROUTINE_UNIFORM programInterface were
returning the count of resources on the shader program using that
interface, instead of the num of uniform resources. This would get a
wrong value (for example) if the shader has an array of subroutine
uniforms.
Note that this means that in order to get a proper value, the shader
needs to be linked, something that is not explicitly mentioned on
ARB_program_interface_query spec, but comes from the general
definition of active uniform. If the program is not linked we
return 0.
v2: don't generate an error if the program is not linked, returning 0
active uniforms instead, plus extra spec references (Tapani Palli)
Fixes GL44-CTS.program_interface_query.subroutines-compute
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Removes the following GCC warning:
../../../../../src/gallium/state_trackers/va/picture.c:542:17: warning:
unused variable 'coded_size' [-Wunused-variable]
unsigned int coded_size;
^~~~~~~~~~
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Boyuan Zhang <boyuan.zhang@amd.com>
Several fixes have been added as part of this as listed below:
1) Fix the mask and add disassembler handling for STATE_DS, STATE_HS
as the mask returned wrong values of the fields.
2) Fix the GEN_TYPE_ADDRESS/GEN_TYPE_OFFSET decoding - the address/
offset were handled the same way as the other fields and that gives
the wrong values for the address/offset.
3) Decode nested/recurssive structures - Many packets contain nested
structures, ex: 3DSATE_SO_BUFFER, STATE_BASE_ADDRESS, etc contain MOC
structures. Previously, the aubinator printed 1 if there was a MOC
structure. Now we decode the entire structure and print out its fields.
4) Print out the DWord address along with its hex value - For a better
clarity of information, it is helpful to print both the address and
hex value of the DWord along with the DWord count. Since the DWord0
contains the instruction code and the instruction length, it is
unnecessary to print the decoded values for DWord0. This information
is already available from the DWord hex value.
5) Decode the <group> and the corresponding fields in the group- The
<group> tag can have fields of several types including structures. A
group can contain one or more number of fields and this has be correctly
decoded. Previously, aubinator did not decode the groups or the
fields/structures inside them. Now we decode the <group> in the
instructions and structures where the fields in it repeat for any number
of times specified.
v2: Fix the formatting (per Matt)
Make the start and end pos calculation to extract fields from a DWord
more appropriate by moving %32 away from mask() method
Signed-off-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
The Aubinator tool is designed to help the driver developers in debugging
the driver functionality by decoding the data in the .aub files.
Primary Authors of this tool are Damien Lespiau <damien.lespiau at intel.com>
and Kristian Høgsberg Kristensen <krh at bitplanet.net>.
v2: Review comments are incorporated by Sirisha Gandikota as below:
1) Make Makefile.am more crisp, reuse intel_aub.h from libdrm (per Emil)
2) Aubinator will use platform name instead of GEN number (per Matt)
3) Disassmebler gets created based on pciid rather then GEN number (per Matt)
4) Other formatting comments (per Ken, Matt and Emil)
Signed-off-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
In ca2a8e5628, we updated the format table to add more formats (most of
which are new on SKL) but accidentally marked some integer formats as
filterable. You can't filter an integer format.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Some hardware can't render to color/depth buffers of mixed bitness. When
that happens a fallback has to happen, but this allows the driver to
express that this isn't an optimal scenario. The purpose of this is to
remove such fbconfigs from the GLX/EGL config list.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Some GPUs, notably nv3x/nv4x can't render to mismatched color/zs
framebuffer depths. Fallbacks can be done by the driver, with shadow
surfaces, but no reason to encourage applications to select non-matching
glx visuals.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We can't actually clear these images normally because we can't render to
them. Instead, we have to manually unpack the rgb9e5 color value on the
CPU and clear it as R32_UINT. We still have a bit of work to do to clear
non-power-of-two images, but this should get all of the power-of-two clears
working on at least Haswell. This fixes three of the new Vulkan CTS tests
in the dEQP-VK.api.image_clearing.clear_color_image.* group.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
There were a lot of formats where support was added on Haswell or later but
we never updated the format table.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
We have implicitly been not advertising these formats since we had them
turned off in the format capabilities table. We are about to update that
table and this prevents a change in behavior. The only change in behavior
created by this patch is that we no longer advertise support for
R16G16B16_FLOAT which means that it's now renderable which seems like a
bonus. Maybe someday we'll want to change things to start supporting
16-bit RGB formats natively but, at the moment, there's no need.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
The whole point of using RGBX is so that we can render to it so if it isn't
renderable, that kind-of defeats the purpose. Some formats (one example is
R32G32B32X32_SFLOAT) exist in the format table but aren't actually
renderable. Eventually, we'd like to get away from RGBX entirely, but this
fixes hangs on BDW today.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
In the case where dri2_initialize is called with a TestOnly display,
the display is not actually initialized, so dri2_egl_display always
fails, and we cannot do any reference counting.
Fixes piglit spec@egl_khr_create_context@verify gl flavor (reproducible
with LIBGL_ALWAYS_SOFTWARE=1).
Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reported-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This removes unnecessary error checks on return result of mtx_lock
and cnd_wait calls as in all other places in MESA source since there
is no chance that any of these functions return any of error codes
in current implementation.
This patch also removes a redundent _eglError call that follows
EGL_FALSE check in the bottom of dri2_client_wait_sync.
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This seems to make sense, the image is bound to a subset of the buffer
so the image size should be from the bound size not the underlying
object.
This fixes:
GL44-CTS.shader_image_size.advanced-nonMS-fs-int
v2: get mininum of the two values, same as we write to the hw.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The only reason we should throw INITIALIZATION_FAILED is if we have found
useable intel hardware but have failed to bring it up for some reason.
Otherwise, we should just throw INCOMPATIBLE_DRIVER which will turn into
successfully advertising 0 physical devices
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Tested-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This needs to set the src swizzle so it doesn't access the .zw
members ever when we are just emitting a 0 constant here.
This fixes:
vert-conversion-explicit-dvec3-bvec3.shader_test
and a bunch of other fp64 tests on softpipe and radeonsi.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We used to upload the indices when they changed, now we rely
on the drivers calling the correct hook to have the values
updated from the context storage.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Andres Gomez <agomez@igalia.com>
This plugs the subroutine index updates into the i965 backend,
where it loads constants.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-by: Andres Gomez <agomez@igalia.com>
This writes the subroutine indicies to the program storage for
a stage. This API is intended to be used by drivers to update
the uniform storage before uploading to the hw.
This isn't the most thread safe effort, but it will be significantly
more multi-context safe.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Andres Gomez <agomez@igalia.com>
One piece of ARB_shader_subroutine I ignored was the fact that it
needs to store the subroutine index data per context and not per
shader program.
There is one CTS test that tests this:
GL45-CTS.shader_subroutine.multiple_contexts
However the test only does a write to context and readback,
it never renders using the values, so this is enough to fix the
test however not enough to do what the spec says.
So with this patch the info is now stored per context, but
it gets updated into the program at UseProgram and when the
values are inserted into the context, which won't help if
multiple contexts are in use in multiple threads.
v1.1: cleanups and nit-picks (Andres)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Andres Gomez <agomez@igalia.com>
Without this the following line will segfault and we don't get to
see the results of the validate_assert() above.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
If we're going to skip setting up vertex input data in them, we should
probably not leave them as vertex inputs with a driver_location that
happens to alias to something else.
Fixes a regression in glsl-mat-attribute on vc4 when enabling GTN.
v2: Change commit message shortlog, lower the new globals away before
handing off to the driver.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Generally you'd see the gl_Color reference first and get some cursor set.
However, in piglit draw-pixel-with-texture we're now seeing the TexCoord
dereferenced first.
Reviewed-by: Rob Clark <robdclark@gmail.com>
In the GLSL-to-NIR conversion of VC4, I had a bit of trouble with what I
was calling the "state uniforms" that I was putting into the NIR fighting
with its other lowering passes. Instead of using magic uniform base
numbers in the backend, follow the lead of load_user_clip_plane and just
define system values for them.
v2: Fix unintended change to channel_num, drop unspecified const_index
value on blend_const_color_r_float.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We let the user believe we support some transfer formats which we don't.
This can lead to crashes when actually trying to use those formats for
example on dEQP-VK.api.copy_and_blit.image_to_image.* tests.
Let all formats we can render to or sample from as meta implements transfers
using attachments.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Implementation previously used value itself as the key, however after
hash implementation change by ee02a5e we cannot use 0 as key.
v2: use constant pointer as the key and implement comparison
for contents (Eric Anholt)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97309
Needed to fix android build after commit 16a9fcb
which enabled genxml for gen{8,9} state setup
This is the last patch needed, android build tested successfully.
Needed to fix android build after commit e198983
which enabled genxml for gen{7,75} state setup
Android build fix for gen{8,9} will follow as incremental patch,
build tested successfully with all per-gen patches applied.
Needed to fix android build after commit c8bc1ae
where new per-gen genX_blorp.c source replaced gen6_blorp.c for gen6
Android build fixes for gen{7,75} and gen{8,9} will follow as incremental patches,
build tested successfully with all per-gen patches applied.
We're going to handle output qualifiers here too, and calling it "inout"
seems to be the going convention.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Not providing a path allows the ICD to work on multi-arch systems but
breaks it if you install anywhere other than /usr/lib. Given that users
may be installing locally in .local or similar, we probably do want to
provide a filename. Distros can carry a revert of this commit if they want
an intel_icd.json file without the path.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Chad Versace <chad@kiwitree.net>
We only did depth clamp when the value was written from the fs.
This is very wrong both for d3d10 and GL, and only passed the
corresponding piglit test due to pure luck (it no longer does
with the enhanced test).
Also, interpolation clamped values to 1.0 always, which can legitimately
happen if depth clip is disabled, so fix that as well (untested).
There is one unresolved issue left, d3d10 always does depth clamping,
whereas GL does not (but does [0,1] clamp instead for fs depth outputs)
- this information isn't in any gallium state object, leave it as-is
for now (though it looks like llvmpipe misses the [0,1] clamp as well).
This (with the previous patch) fixes piglit depth-clamp-range test.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This wasn't handled before (the result was that no matter what value got
clamped, it always ended up as the near value in this case) (if clamping
actually happened).
Fix this by using the util helper for that (the math is otherwise "mostly"
the same, mostly because there could actually be differences due to float
rounding, but I don't even know which one would be more correct).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Scheduling barriers are implemented by placing a dependence on every
node before and after the barrier. This is unnecessary as we can limit
the number of nodes we place dependencies on to those between us and the
next barrier in each direction.
Runtime of dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23
is reduced from ~25 minutes to a little more than three.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94681
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
var_range_end(v, n) loops over the n components of variable number v and
finds the maximum value, giving the last use of any component of v.
Therefore it expects v to correspond to the variable associated with the
.x channel of the VGRF.
var_from_reg() however returns the variable for the first channel of the
VGRF, post-swizzle.
So, if the last register had a swizzle with y, z, or w in the swizzle
component, we would read out of bounds. For any other register, we would
read liveness information from the next register.
The fix is to convert the src_reg to a dst_reg in order to call the
dst_reg version of var_from_reg() that doesn't consider the swizzle.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Allows shader-db to work on vec4 programs (has been broken since
shader-db commit 646df5ca98b2 from April!)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous bit disables the whole clipper, including the regular
viewport-related clipping that would go on. The two new bits disable
near and far clipping (separately, as verified with the
depth-clamp-range piglit).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
vc4 wants to have per-scalar IO load/stores so that dead code elimination
can happen on a more granular basis, which it has been doing in the
backend using a multiplication by 4 of the intrinsic's driver_location.
We can represent it properly in the NIR using the first_component field,
though.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous nir_load_system_value(b, nir_intrinsic_load_whatever), 0) was
rather verbose, when system values should be easy to generate.
The index is left out because only one system value had an index included
in it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reduces the diff between GLSL-to-NIR and TGSI-to-NIR, and gives NIR
more optimization to work on.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
GLSL-to-NIR generates system value usage, and vc4/freedreno would both
like the system value instead of the varying, so switch this pass over to
it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch improves the performance of Vaapi Encode by enabling dual
instances encoding. flush function is not called after each end_frame
call. radeon/vce will do flush whenever 2 frames are submitted for
encoding. Implement sync surface function to flush only if the frame
hasn't been flushed yet.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Now that we're using genxml for everything, we no longer need the
hand-rolled state emit helpers.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The new helper emits surface states and the binding table in one go. It's
nice to have it pulled out of the main blorp_exec function.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
At the moment, it's only used for gen6 but that will change soon. We use
the genX prefix for recompiled things in the Vulkan driver. It isn't
great, but it seems to have worked ok.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Blorp never uses points or lines and the default values of 0 are perfectly
fine. Explicitly setting them is just noise.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
All three go together on SNB so let's keep them together for gen7+ as well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We're about to start replacing blorp state setup code with packing structs
and we want to feel free to delete files as we go.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
More than half of the stuff in intel_reg.h had nothing whatsoever to do
with registers and really belongs in brw_defines.h anyway.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The actual data storred is in float, UNORM24, or UNORM16 depending on the
actual depth format.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This uses the unblocked time of the exit assigned to each available
node to attempt to unblock exit nodes as early as possible,
potentially reducing the runtime of the shader when an exit branch is
taken. There is a natural trade-off between terminating the program
as early as possible and reducing the worst-case latency of the
program as a whole (since this will typically move exit-unblocking
nodes closer to its dependencies potentially causing additional stalls
of the execution pipeline), but in practice the bandwidth and ALU
cycle savings from terminating the program earlier tend to outweigh
the slight increase in worst-case program execution latency, so it
makes sense to prefer nodes likely to unblock an earlier exit
regardless of the latency benefits of other available nodes.
I haven't observed any benchmark regressions from this change after
testing on VLV, HSW, BDW, BSW and SKL. The FPS of the GfxBench
Manhattan benchmark increases by 10%-20% and the FPS of Unigine Valley
improves by roughly 5% depending on the platform and settings.
The change to the register pressure-sensitive heuristic is rather
conservative and gives precedence to the existing heuristic in order
to avoid increasing register pressure and causing spill count and SIMD
width regressions in shader-db. It may make sense to revisit this
with additional performance data.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This adds a bit of metadata to schedule_node that will be used to
compare available nodes in the scheduling heuristic code based on
which of them unblocks the earliest successor exit node. Note that
assigning exit nodes wouldn't be necessary in a bottom-up scheduler
because we could achieve the same effect by scheduling the exit nodes
themselves appropriately.
No shader-db changes.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The critical path of each node is calculated by induction based on the
critical paths of its children, which can be done in a post-order
depth-first traversal of the dependency graph. The current code
implements graph traversal by iterating over all nodes of the graph
and then recursing into its children -- But it turns out that
recursion is unnecessary because the lexical order of instructions in
the block is already a good enough reverse post-order of the
dependency graph (if it weren't a reverse post-order some instruction
would have been located before one of its dependencies in the original
ordering of the basic block, which is impossible), so we just need to
walk the instruction list in reverse to achieve the same result more
efficiently.
No shader-db changes.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
ANY4H is more efficient than ANY8H and ANY16H because it makes sure
that whenever a whole subspan hits a discard statement it gets
disabled by the EU until the end of the program, regardless of whether
the discard condition is uniform across all channels of the SIMD8-16
thread. OTOH ANY8H/ANY16H would cause the rest of the program to be
executed for *all* channels if only one of the channels hadn't taken
the discard branch, potentially increasing the bandwidth and ALU usage
of the program unnecessarily.
This change increases the FPS by over 3x of a simple micro-benchmark
that discards a bunch of fragments and then does a single costly
texturing operation. I've just re-verified the FPS change on HSW and
SKL, but I expect all platforms from Gen6 up to get a similar benefit.
Note that we could potentially be more aggressive and use the NORMAL
predicate to discard individual channels, but that would need to
happen post-scheduling because the scheduler currently doesn't care to
reorder HALT instructions with respect to other instructions, and the
NORMAL predicate would cause the results of subsequent derivative
computations to become undefined -- If the scheduler didn't reorder
HALT instructions it would actually be safe to switch to NORMAL
because the behavior of derivative computations after a non-uniform
discard statement is undefined by the GLSL spec, but that would make
the optimization implemented by one of the following commits somewhat
more difficult.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This may have been the reason people ran into problems with
non-uniform HALT instructions and ended up using the inefficient
ANY16H/ANY8H predicates instead of ANY4H or NORMAL in order to prevent
non-uniform discard. The HALT instruction is able to handle
non-uniform execution masks just fine.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Valgrind complains with a "Conditional jump or move depends on
uninitialised value(s)" warning due to opaque being conditionally
initialized. However in the punchthrough_alpha == true case, it is
always initialized, so just flip the condition around to silence the
warning.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
The max basevertex is already computed and added into max_index by the
caller, _tnl_draw_prims.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The vkCmdDbgMarker{Begin,End} symbols are exported, yet the json does no
advertise that the driver supports the extension. Furthermore the
functions are empty stubs.
Remove those until we get a proper implementation and json notation.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
With version 1 of the Loader interface there is an internal/private symbol
(vk_icdGetInstanceProcAddr) which is used to retrieve all the API from the
Vulkan entrypoints from the ICD. Implying that exposing the Vulkan API is not
recommended.
Version 2 goes a step further explicitly forbiding the ICD from exposing Vulkan
symbols (and adding a negotiation API)
As a reference:
- Nvidia 367.35
Missing negotiation API - version 1.
Exposes only vk_icdGetInstanceProcAddr.
- AMD 16.30.3.306809
Have negotiation API - version 2,
Exposes vk_icdGetInstanceProcAddr.
Exposes a couple of Vulkan entry points - seems to be in violation with the spec.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Hide the internal symbols and annotate the vk_icdGetInstanceProcAddr as public
since the loader needs it (since v1 of the loader interface).
v2: Add VISIBILITY_CFLAGS to AM_CFLAGS (Ken)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (v1)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
I don't want src_is_bool() and src_is_type(x, nir_type_bool) to behave
differently. Having the logic spread out over three functions makes it
harder to decide where to put new logic, as well.
So, combine them all. It's a bit simpler because there's now only one
recursive function rather than a pair of mutually recursive functions.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Currently, 'a@type' can only match if 'a' is produced by an ALU
instruction. This is rather limited - there are other cases we
can easily detect which we should handle.
Extending the code in-place would be fairly messy, so we introduce
a new src_is_type() helper.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The "Barrier Count" field goes in 14:9 of m0.2. The vec4 backend
correctly shifts by 9, but the scalar backend only shifted by 8.
It's not like this changed - I think I just made a typo when writing
the original scalar TCS backend code.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
The first simply picks the bany_inequal[234] opcodes based on the SSA
def's number of components. The latter implicitly compares with zero
to achieve the same semantics of GLSL's any().
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
GL_EXT_packed_float, 2.1.B Unsigned 10-Bit Floating-Point Numbers:
0.0, if E == 0 and M == 0,
2^-14 * (M / 32), if E == 0 and M != 0,
2^(E-15) * (1 + M/32), if 0 < E < 31,
INF, if E == 31 and M == 0, or
NaN, if E == 31 and M != 0,
In the second case (E == 0 and M != 0), we were multiplying the mantissa
by 2^-20, when we should have been multiplying by 2^-19 (which is
2^(-14 + -5), or 2^-14 * 2^-5, or 2^-14 / 32).
The previous section defines the formula for 11-bit numbers, which is:
2^-14 * (M / 64), if E == 0 and M != 0,
In other words, we had accidentally copy and pasted the 11-bit code
to the 10-bit case, and neglected to change the exponent.
Fixes dEQP-GLES3.functional.pbo.renderbuffer.r11f_g11f_b10f_triangles
when run with surface dimensions of 1536x1152 or 1920x1080.
Cc: mesa-stable@lists.freedesktop.org
References: https://code.google.com/p/chrome-os-partner/issues/detail?id=56244
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Stephane Marchesin <stephane.marchesin@gmail.com>
Reviewed-by: Antia Puentes <apuentes@igalia.com>
When viewport transform is disabled (ie. screen space coords are passed
in directly), the W component should be interpreted as RHW.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
This mega-commit pulls most of the i965-specific bits of blorp into the
brw_blorp.c/h files which now contain nothing but i965 wrappers around
"core blorp" calls. The "core blorp" api is moved into blorp.h and the
internal blorp data structures are moved into blorp_priv.h. The new file
blorp.c is created to house "core blorp" internals which are pulled from
the old brw_blorp.c
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The helpers are completely miptree-unaware and each fairly cleanly do a
single thing. This does come at the downside of not doing proper debug
reporting on whether or not we're doing replicated clears.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This pulls the mcs allocation into the if statement where we initially
determine that we are doing a fast clear and moves the programming of
wm_inputs and figuring out the fast clear rect into it's own if statement.
The next commit will put code inbetween the two.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The blorp_surface_info_init call above should set the format for us and
stomping it later does nothing whatsoever.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We had another inline copy of brw_meta_get_buffer_rect embedded in
get_fast_clear_rect for no good reason. This lets us get rid of the
gl_frameuffer parameter to get_fast_clear_rect.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We already have an inlined version of the function slightly higher up in
do_single_blorp_clear and all calling it does is stomp the values with the
same thing. We might as well just get rid of it.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Now that we have the brw_blorp_surf struct, we can start to make bits of
blorp completely miptree-unaware. To start things off, we split the guts
of brw_blorp_blit_miptrees into a brw_blorp_blit function which knows
nothing about miptrees.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
At the moment, this seems to make all of the interfaces messier rather than
clener. However, it does provide a representation of a surface that
simultaneously contains everything and is completely unaware of miptrees.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The isl_surf munging doesn't happen until fairly late in the blorp_blit
function. We can use the isl_surf for the vast majority if not all of our
params setup.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This keeps all of the nastyness of gen6 stencil on the i965 side of the API
line and lets us delete that nasty hand-rolled ISL-based offset path that
we were using for ALL_SLICES_AT_EACH_LOD.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This commit also adds support for an offset for aux surfaces. In GL, this
only gets used for HiZ on SNB at the moment. However, in Vulkan, all aux
surfaces are at a non-zero offset and that is likely to happen in GL
eventually.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This commit movies us from a miptree model to a surf+bo+offset model. In
the GL driver, miptrees are almost always at the start of the bo so the
offset is zero but we don't want to always make that assumption. In the
sort term, gen6 stencil and HiZ will be at an offset but, in the long term,
any Vulkan surface is liable to be at a non-zero offset.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The previous HiZ support was bogus because all of get_aux_isl_surf looked
at mt->mcs_mt directly. For HiZ buffers, you need to look at either
mt->hiz_buf or mt->hiz_buf->mt.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Otherwise, the clear color will get ignored. This prevents assertion
errors if clear color is set to something invalid and aux is not used.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
In order for the calculations of things such as fast clear rectangles to
work, we need more details of the auxiliary surface to be correct. In
particular, we need to be able to trust the width and height fields.
(These are not necessarily what you want coming out of the miptree.) The
only values state setup really cares about are the row and array pitch and
those we can safely stomp from the miptree.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
At one point, we were doing this correctly. It must have gotten lost in
one of the many rebases.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The only reason why we need layer or level is that we need the z-offset for
3-D surfaces. Let's just have the one field for that.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The data comes in via ISL in a format that's almost directly usable by the
hardware so we can avoid some of the conversion headache.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Now that the generic blorp path uses base level/layer, there's no need to
make gen8 special.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Since the dawn of time, blorp has used offsets directly to get at different
mip levels and array slices of surfaces. This isn't really necessary since
we can just use the base level/layer provided in the surface state. While
it may have simplified blorp's original design, we haven't been using the
blorp path for surface state on gen8 thanks to render compression and
there's really no good need for it most of the time. This commit restricts
such surface munging to the cases of fake W-tiling and fake interleaved
multisampling.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The layer field is in terms of physical layers which isn't quite what the
sampler will want for 2-D MS array textures.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Multisample array surfaces on IVB don't support the minimum array element
surface attribute so it needs to come through the sampler message. We may
as well just pass it through everything.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
At the moment, the minify operation does nothing because
params.depth.view.base_level is always zero. However, as soon as we start
using actual base miplevels and array slices, we are going to need the
minification. Also, we only need to align the surface dimensions in the
case where we are operating on miplevel 0. Previously, it didn't matter
because it aligned on miplevel 0 and, for all other miplevels, the miptree
code guaranteed that the level was already aligned.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The sampling hardware can handle them ok. It just looks at the tiling to
determine whether it's the new gen9 1-D layout or the old one. The render
hardware isn't so smart.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
In all three cases, we start with width and height taken from
isl_surf::phys_slice0_extent_sa which is already in samples. There is no
need to do the conversion and doing so gives us an incorrect value.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
The helper does a full transformation on the surface to turn it into a new
2-D single-layer single-level surface representing the original layer and
level in memory.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
For the moment, we still call the old miptree function; we just assert that
the two are equal.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The function takes a logical array layer but was assuming it was a physical
array layer. While we'er here, we also make it not assert-fail on gen9 3-D
surfaces.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Eventually, this will be the actual view that gets passed into isl to
create the surface state. For now, we just use it for the format and the
swizzle.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Previously we multiplied full x/y offsets, resolved tile aligned buffer
offset and intra tile offset based on that. Now we let ISL to take into
account the msaa setting and we only multiply the resolved intra tile
offsets.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We put all of the code for fake IMS together. This requires moving a bit
of the program key setup code further down so that it gets the right values
out of the final surface.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Now that we're carrying around the isl_surf, we can just modify it
directly instead of passing an extra bit around.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The alignment we use doesn't matter (see the comment) but it should at
least be an alignment we can represent with the enums.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
It's only used to stomp the tiling to Y and it's only used by blorp so
there's no reason why blorp can't do it itself.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
It's been in elements for a while but, for whatever reason, the parameter
names in the header file never got updated.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The lrint() and lrintf() functions are pretty slow and make some
texture transfers very inefficient. This patch makes a better effort
at using those intrisics for 32-bit gcc and MSVC.
Note, this patch doesn't address the use of SSE4.1 with MSVC.
v2: get rid of the ROUND_WITH_SSE symbol, per Matt.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The function was always returning false because of this typo.
Retested with piglit. There's some sRGB-related blit failures, but
that seems unrelated.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Neha Bhende <bhenden@vmware.com>
No change except to the copyright symbol. The next patch will generate
this file with Python, and Unicode + Python = pure rage.
v2: Massive rebase... I guess a lot can change in a year.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is required by OpenGL. Our hardware supports this.
Example: Bind RGBA32F with offset = 4 bytes.
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Vulkan doesn't do this. The reason may be that CB_COLOR1_INFO.SOURCE_FORMAT
from NI was moved to SPI_SHADER_COL_FORMAT for SI.
I asked CB guys about this 2 days ago and they still haven't replied.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Avoid building all those store 0 / store undef instruction pairs that
end up getting removed anyway.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Also, prepare for using tgsi_array_info.
This also opens the door for properly handling allocation failures, but I'm
leaving that for a separate change.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Doing the write-back of the temporary vector in radeon_llvm_emit_store makes
no sense.
This also allows us to get rid of get_alloca_for_array.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
In the alloca'd array case, no longer create redundant and unused allocas
for the individual elements; create getelementptrs instead.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
ir_unop_fract already forbade integer types in ir_validate. ir_unop_rcp,
ir_unop_rsq, and ir_unop_sqrt should also forbid them in ir_validate.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Some shaders include code that looks like:
uniform int i;
uniform vec4 bones[...];
foo(bones[i * 3], bones[i * 3 + 1], bones[i * 3 + 2]);
CSE would do some work on this:
x = i * 3
foo(bones[x], bones[x + 1], bones[x + 2]);
The compiler may then add '<< 4 + base' to the index calculations.
This results in expressions like
x = i * 3
foo(bones[x << 4], bones[(x + 1) << 4], bones[(x + 2) << 4]);
Just rearranging the math to produce (i * 48) + 16 saves an
instruction, and it allows CSE to do more work.
x = i * 48;
foo(bones[x], bones[x + 16], bones[x + 32]);
So, ~6 instructions becomes ~3.
Some individual shader-db results look pretty bad. However, I have a
really, really hard time believing the change in estimated cycles in,
for example, 3dmmes-taiji/51.shader_test after looking that change in
the generated code.
G45
total instructions in shared programs: 4020840 -> 4010070 (-0.27%)
instructions in affected programs: 177460 -> 166690 (-6.07%)
helped: 894
HURT: 0
total cycles in shared programs: 98829000 -> 98784990 (-0.04%)
cycles in affected programs: 3936648 -> 3892638 (-1.12%)
helped: 894
HURT: 0
Ironlake
total instructions in shared programs: 6418887 -> 6408117 (-0.17%)
instructions in affected programs: 177460 -> 166690 (-6.07%)
helped: 894
HURT: 0
total cycles in shared programs: 143504542 -> 143460532 (-0.03%)
cycles in affected programs: 3936648 -> 3892638 (-1.12%)
helped: 894
HURT: 0
Sandy Bridge
total instructions in shared programs: 8357887 -> 8339251 (-0.22%)
instructions in affected programs: 432715 -> 414079 (-4.31%)
helped: 2795
HURT: 0
total cycles in shared programs: 118284184 -> 118207412 (-0.06%)
cycles in affected programs: 6114626 -> 6037854 (-1.26%)
helped: 2478
HURT: 317
Ivy Bridge
total instructions in shared programs: 7669390 -> 7653822 (-0.20%)
instructions in affected programs: 388234 -> 372666 (-4.01%)
helped: 2795
HURT: 0
total cycles in shared programs: 68381982 -> 68263684 (-0.17%)
cycles in affected programs: 1972658 -> 1854360 (-6.00%)
helped: 2458
HURT: 307
Haswell
total instructions in shared programs: 7082636 -> 7067068 (-0.22%)
instructions in affected programs: 388234 -> 372666 (-4.01%)
helped: 2795
HURT: 0
total cycles in shared programs: 68282020 -> 68164158 (-0.17%)
cycles in affected programs: 1891820 -> 1773958 (-6.23%)
helped: 2459
HURT: 261
Broadwell
total instructions in shared programs: 9002466 -> 8985875 (-0.18%)
instructions in affected programs: 658784 -> 642193 (-2.52%)
helped: 2795
HURT: 5
total cycles in shared programs: 78503092 -> 78450404 (-0.07%)
cycles in affected programs: 2873304 -> 2820616 (-1.83%)
helped: 2275
HURT: 415
Skylake
total instructions in shared programs: 9156978 -> 9140387 (-0.18%)
instructions in affected programs: 682625 -> 666034 (-2.43%)
helped: 2795
HURT: 5
total cycles in shared programs: 75591392 -> 75550574 (-0.05%)
cycles in affected programs: 3192120 -> 3151302 (-1.28%)
helped: 2271
HURT: 425
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
There's no guarantee that there is one, and we don't need one anyway.
Fixes piglit tests:
glx@glx-fbconfig-bad
glx@glx_ext_import_context@import context, multi process
glx@glx_ext_import_context@import context, single process
Fixes: 2e3f067458 ("glx: fix error code when there is no context bound")
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
It's fairly rare that the BB layout puts BBs after the exit block, which
is likely the reason these issues lingered for so long.
This fixes a fraction of issues with the giant pixmark piano shader.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
The current logic used to determine the execution size of sampler
messages was based on special-casing several argument and opcode
combinations, which unsurprisingly missed the possibility that some
messages could exceed the payload size limit or not depending on the
number of coordinate components present. In particular:
- The TXL, TXB and TEX messages (the latter on non-FS stages only)
would attempt to use SIMD16 on Gen7+ hardware even if a shadow
reference was present and the texture was a cubemap array, causing
it to overflow the maximum supported sampler payload size and
crash.
- The TG4_OFFSET message with shadow comparison was falling back to
SIMD8 regardless of the number of coordinate components, which is
unnecessary when two coordinates or less are present.
Both cases have been handled incorrectly ever since cubemap arrays and
texture gather were respectively enabled (the current logic used by
the SIMD lowering pass is almost unchanged from the previous no16
fall-back logic used pre-SIMD lowering times).
Fixes the following GL4.5 conformance test on Gen7-8 (the bug also
affects Gen9+ in principle, but SKL passes the test by luck because it
manages to use the TXL_LZ message instead of TXL):
GL45-CTS.texture_cube_map_array.sampling
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97267
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This makes it easier for the caller to find out how many scalar
components are actually read by the instruction. As a bonus we no
longer need to special-case BAD_FILE in the implementation of
fs_inst::regs_read.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This simplifies the code slightly and will allow the SIMD lowering
pass to find out easily what the actual texturing opcode is in order
to determine the maximum execution size of texturing instructions.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All three fields of the vbuffer_attrs[] array are assigned in the following
loop. The remaining elements of the array are not used.
Tested with full Piglit run, Heaven 4.0, etc.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We don't need to loop over the max number of color buffers, just the
current number (which is usually one).
Tested with full Piglit run, Heaven 4.0, etc.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Fixes regression with team_fortress_2 trace.
This change has been in our in-house tree for some time.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Since clears are more or less just normal draws, there isn't that much
benefit in having hand-rolled clear path. Add support to use u_blitter
instead if gen specific backend doesn't implement ctx->clear().
Signed-off-by: Rob Clark <robdclark@gmail.com>
Not (currently) state that is overwridden by u_blitter itself, but
drivers with custom blit/clear which are reusing part of the u_blitter
infrastructure will use it.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
eglMakeCurrent can also be used to change the active display. In that
case, we need to decrement ref_count of the previous display (possibly
destroying it), and increment it on the next display.
Also, old_dsurf/old_rsurf cannot be non-NULL if old_ctx is NULL, so
we only need to test if old_ctx is non-NULL.
v2: Save the old display before destroying the context.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97214
Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reported-by: Alexandr Zelinsky <mexahotabop@w1l.ru>
Tested-by: Alexandr Zelinsky <mexahotabop@w1l.ru>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Apply the median and matrix filter before the compostioning
we apply the deinterlacing first to avoid the extra overhead
in processing the past and the future surfaces in deinterlacing.
v2: apply the filters on all the surfaces (Christian)
v3: use get_sampler_view_planes() instead of
get_sampler_view_components() and iterate over
VL_MAX_SURFACES (Christian)
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Ian recently changed the preprocessor to allow this in most GLSL
versions, but not GLSL ES 3.00+. This patch converts the existing
test that expects a failure to a #version 300 es shader, and adds
a #version 110 shader to make sure that it's allowed.
Fixes 'make check'.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97307
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Tested-by: Vinson Lee <vlee@freedesktop.org>
Found with valgrind:
==4841== Invalid read of size 4
==4841== at 0x56BDC80: dri2_initialize (egl_dri2.c:783)
==4841== by 0x56BAFE5: _eglMatchAndInitialize (egldriver.c:261)
==4841== by 0x56BB15E: _eglMatchDriver (egldriver.c:295)
==4841== by 0x56B58C9: eglInitialize (eglapi.c:480)
==4841== by 0x4F537DC: _glfwInitEGL (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x4F4BEFB: _glfwPlatformInit (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x4F46F40: glfwInit (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x402E59: main
==4841== Address 0x6a05824 is 148 bytes inside a block of size 480 free'd
==4841== at 0x4C2B680: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4841== by 0x56C2AAE: dri2_initialize_x11_swrast (platform_x11.c:1233)
==4841== by 0x56C2AAE: dri2_initialize_x11 (platform_x11.c:1493)
==4841== by 0x56BDCEB: dri2_initialize (egl_dri2.c:805)
==4841== by 0x56BAFAF: _eglMatchAndInitialize (egldriver.c:261)
==4841== by 0x56BB0C9: _eglMatchDriver (egldriver.c:292)
==4841== by 0x56B58C9: eglInitialize (eglapi.c:480)
==4841== by 0x4F537DC: _glfwInitEGL (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x4F4BEFB: _glfwPlatformInit (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x4F46F40: glfwInit (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x402E59: main
==4841== Block was alloc'd at
==4841== at 0x4C2A868: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4841== by 0x56C2A47: dri2_initialize_x11_swrast (platform_x11.c:1171)
==4841== by 0x56C2A47: dri2_initialize_x11 (platform_x11.c:1493)
==4841== by 0x56BDCEB: dri2_initialize (egl_dri2.c:805)
==4841== by 0x56BAFAF: _eglMatchAndInitialize (egldriver.c:261)
==4841== by 0x56BB0C9: _eglMatchDriver (egldriver.c:292)
==4841== by 0x56B58C9: eglInitialize (eglapi.c:480)
==4841== by 0x4F537DC: _glfwInitEGL (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x4F4BEFB: _glfwPlatformInit (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x4F46F40: glfwInit (in /usr/lib64/libglfw.so.3.2)
==4841== by 0x402E59: main
Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b@gmail.com>
Fixes: 9ee683f877 (egl/dri2: Add reference count for dri2_egl_display)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Some applications continue to use the Xlib client library and expect that
VK_KHR_xlib_surface will be available in the driver. Service these
applications by converting the Display pointer to xcb_connection_t and use
the existing xcb code in the driver.
Signed-off-by: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Instead of checking for mapped buffers in vbo_bind_arrays
do this check in api_validate.c. This additionally
enables printing the draw calls name into the error
string.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Move the function to check if all vao buffers are
unmapped into the vao implementation file.
Rename the function to _mesa_all_buffers_are_unmapped.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
In array draw do not check if the vertex buffer object that
is used to implement immediate mode glBegin/glEnd is mapped.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
These are the same for a3xx and later. (a2xx could probably use them
too, but due to limited hw support and ancient downstream kernels, it
isn't so easy to test.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
For various tex fetch instructions, coord's get fixed up in different
ways. But modifying the array returned from get_src() has side-effects
if the same SSA src is used again.. the later instruction will see the
previous fixups.
Fix this, and const'ify things to prevent this sort of mistake in the
future.
Noticed by Varad when adding support for txf_ms.
Signed-off-by: Rob Clark <robdclark@gmail.com>
For regular ast_add, we can implicitly change either a or b's type.
However in an assignment situation, the type of the lvalue is fixed. So
if the implicit conversion logic decides to change it, it means that the
rhs's type could not be converted to the lhs type.
Emit a specific error for this rather than the rather mysterious "is not
an lvalue" error that results from having a i2f or other operation as
the lvalue.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96729
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The additional provision of GL_OES_copy_image is that it work for ETC.
However many desktop GPUs don't have native ETC support, so st/mesa does
the decoding by hand. Instead of discarding the compressed data, keep it
around in CPU memory. Use it when performing image copies.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Marek Olšák <marek.olsak@amd.com>
The GL spec is very unclear on this point. Apparently this is discussed
without resolution in the closed Khronos bugtracker at
https://cvs.khronos.org/bugzilla/show_bug.cgi?id=7829 . The
recommendation is to allow dropping the [0] for looking up the bindings.
The approach taken in this patch is to instead tack on [0]'s for each
arrayness level of the output's type, and doing the lookup again. That
way, for
out vec4 foo[2][2][2]
we will end up looking for bindings for foo, foo[0], foo[0][0], and
foo[0][0][0], in that order of preference.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96765
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Anholt <eric@anholt.net>
The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_REV are not defined anywhere in
OpenGL ES 3.2 (or earlier) specification, and there are no known extensions
in the Khronos registry that would add these enums as valid responses for
glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_TYPE) and
glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_FORMAT) queries.
Note that this patch does not change the bit layout returned by the query. As
defined by the GL spec, the bit layout of GL_RGB + GL_UNSIGNED_SHORT_5_6_5 and
GL_BGR + GL_UNSIGNED_SHORT_5_6_5_REV are identical.
TEST=dEQP-GLES3.functional.state_query.integers.*
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Change-Id: I81bbc8ccdc7e125edaeae443baf6fa8fdefcc6b6
This is required following the change in 8X sample positions.
Fixes the recently modified multisample-scaled-blit piglit tests.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
There are no standard sample positions defined in OpenGL and OpenGL
ES specs. Implementations have the freedom to pick the positions
which give plausible results. But the Vulkan 1.0 spec does define
standard sample positions for different sample counts. Defined
positions in Vulkan for all the sample counts except 8X match with
the positions we set in i965. We have an upcoming plan to share the
blorp code between OpenGL and Vulkan driver in near future. Keeping
the 8X sample positions same on both the drivers will help us move
in that direction.
Here is an argument by Neil Roberts (from commit 20250e85) against
any advantage of current 8X sample positions over the new ones:
"The comment above for the 8x sample positions says that the hardware
implements centroid interpolation by picking the centre-most sample
that is inside the primitive. That implies that it might be worthwhile
to pick a pattern that includes 0.5,0.5. However by experimentation
this doesn't seem to actually be the case. With the sample positions
in this patch, if I modify the piglit test below so that it instead
reports the centroid position, it reports 0.492188,0.421875 which
doesn't match any of the positions. If I modify the sample positions
so that they include one at exactly 0.5,0.5 it doesn't help and it
reports another position which is even further from the center for
some reason.
arb_gpu_shader5-interpolateAtSample-different
Kenneth Graunke experimented with some other patterns that have a
higher standard deviation but I think after some discussion it was
decided that it would be better to pick the same pattern as the other
graphics API in case there are games that rely on this pattern."
Observed no regressions in jenkins testing.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
because NewDriverState is filtered depending on active shader states,
while st->dirty isn't.
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
At compile time, each shader determines which ST_NEW flags should be set
at shader bind time.
This just sets the new field for all shaders. The next commit will use it.
v2: small code unification
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
It always returns non-null, even if the number is an invalid enum.
Cc: Haixia Shi <hshi@chromium.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Change-Id: I26e8843c96130be972e66f48a49e362442e1bf97
The previous commit fixed xfb_buffer handling, which was largely copy
and pasted from the stream handling. The difference is that stream
was set in input_layout_mask, so it worked.
However, that's totally rubbish: stream is only valid on geometry shader
outputs. Presumably this was to hack around inout. Instead, apply the
solution I used in the previous fix.
Really, we just need to separate shader interface and parameter
qualifier handling so this isn't a mess, but this patch at least
tidies it slightly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
inout variables have q.in and q.out set. We were trying to set
xfb_buffer = 1 for shader output variables (and inadvertantly setting
it on inout parameters, too). But input_layout_mask doesn't have
xfb_buffer set, so it was seen as in invalid input qualifier.
This meant that all 'inout' parameters were broken.
Caught by running a WebGL conformance test in Chromium:
https://www.khronos.org/registry/webgl/sdk/tests/deqp/data/gles3/shaders/qualification_order.html?webglVersion=2
Fixes Piglit's tests/spec/glsl-4.40/compiler/inout-parameter-qualifier.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Only include the ones that can be used by the shader.
This fixes texture coordinates, which were completely wrong,
because WPOS was included in the list of attribs. It also
increases performance noticeably.
Signed-off-by: Miklós Máté <mtmkls@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Section 3.4 (Preprocessor) of the GLSL ES 3.00 spec says:
It is an error to undefine or to redefine a built-in (pre-defined)
macro name.
The GLSL ES 1.00 spec does not contain this text.
Section 3.3 (Preprocessor) of the GLSL 1.30 spec says:
#define and #undef functionality are defined as is standard for C++
preprocessors for macro definitions both with and without macro
parameters.
At least as far as I can tell GCC allow '#undef __FILE__'. Furthermore,
there are desktop OpenGL conformance tests that expect '#undef
__VERSION__' and '#undef GL_core_profile' to work.
Fixes:
GL45-CTS.shaders.preprocessor.definitions.undefine_version_vertex
GL45-CTS.shaders.preprocessor.definitions.undefine_version_fragment
GL45-CTS.shaders.preprocessor.definitions.undefine_core_profile_vertex
GL45-CTS.shaders.preprocessor.definitions.undefine_core_profile_fragment
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: mesa-stable@lists.freedesktop.org
Builtins already have locations assigned so this shouldn't
change anything. We want to call it earlier so we can tranform
GLSL IR to NIR earlier.
Reviewed-by: Eric Anholt <eric@anholt.net>
Here a new function link_varyings_and_uniforms() is created this
should help make it easier to follow the code in link_shader()
which was getting very large.
Note the end of the new function contains a for loop with some
lowering calls that currently don't seem related to varyings or
uniforms but they are a dependancy for converting to NIR ealier
so we move things here now to keep things easy to follow.
Reviewed-by: Eric Anholt <eric@anholt.net>
The pass isn't really control-flow aware and you can get into case where it
tries to combine instructions from different blocks. This can actually
lead to an assertion failure when removing unneeded instructions if part of
the vector is set in one block and part in another. This prevents
regressions in the next commit.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Improves glretrace -b servo.trace (a trace of Mozilla's servo rendering
engine booting, rendering a page, and exiting) from 1.8s to 1.1s. It uses
a large uniform array of structs, making a huge number of separate program
resources, and the fixed-size hash table was killing it. Given how many
times we've improved performance by swapping the hash table to
util/hash_table.h, just do it once and for all.
This just rebases the old hash table API on top of util/, for minimal
diff. Cleaning things up is left for later, particularly because I want
to fix up the new hash table API a little bit.
v2: Add UNUSED to the now-unused parameter.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
I'm going to replace this hash table with util/hash_table.h, and the first
step is to compare things the same way.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Separated FE stats out into its own structure. There are 17 FE vs 3 BE
stat fields. Since there is only one FE thread per DC then we don't have
to loop over all threads and sum up FE stats over all the worker threads.
This also reduces size of DC since we only need to store one copy of the
FE stats and not one per worker. Finally, we can use the new FE callback
mechanism to update these.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
- Remove HYPERTHREADED_FE support
- Add threading info as optional data passed to SwrCreateContext.
If supplied this data will override any KNOB thread settings.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
This is a blocking call that waits until all FE work is complete.
This is useful for waiting for FE work to complete such as for streamout.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
enable/disable raster tile trivial accept test based on scissor enable trait.
Can be optimized further.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
1. SoWriteOffset is no longer treated as a stat
2. Added callback from core to update streamout write offset
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
This is the case when the "00 00 03" is very close to the beginning of
nal unit header
v2: move the check to rbsp init
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
If a shader has an output array, it will get treated as though it were
gl_FragData and rewritten into gl_out_FragData instances. We only want
this to happen on the actual gl_FragData and not everything else.
This is a small part of the problem pointed out by the below bug.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96765
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This can help enable some blend optimizations (see the register spec).
Vulkan always sets this.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
This is the proper fix for Overlord and Witcher 2 hangs.
The hang condition is that 1 app must write to MRT0 and MRT1 from a pixel
shader while MRT1 is disabled in CB_TARGET_MASK (does this generate
unflushable pixel quads? I don't know), and another app (e.g. Glamor)
must enable dual source blending in both MRT0 and MRT1. The hw gets
confused, which leads to corruption and hangs.
Cc: 12.0 11.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Since commit 6d7177f01b, radeonsi
would take a different path if info->indirect_params was not
initialized properly. Nine was not initializating this field.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
+23% Bioshock Infinite performance.
v2: - use the new fence_finish interface
- allow deferred fences with multiple contexts
- clear the ctx pointer after a deferred flush
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
required by glClientWaitSync (GL 4.5 Core spec) that can optionally flush
the context
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Some ideas copied from Jakob Sinclair's implementation, but the color
clearing is completely different.
v2: remove leftover code, disable conditional rendering
disable render condition cleanly
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
On android platform, the width and height of a native window surface may
be updated after initialization. It is therefore necessary to query android
framework for the current width and height.
v2: remove Android specific #ifdef's and just implement the fallback directly
if the platform query_surface() callback is not provided.
TEST=dEQP-EGL.functional.resize.surface_size#* on cyan-cheets
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org> (v1)
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Chad Versace <chad@kiwitree.net>
Change-Id: I673f7d2f1d90c3bf572b30f63da537f2cae1496e
V1: Add multisample positions (Nanley)
V2: Fix 8x sample positions to match OpenGL (Anuj)
V3: Vulkan has standard sample locations. They need not be same as
in OpenGL. (Anuj)
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
As requested with the initial creation of util/bitscan.h
now move other bitscan related functions into util.
v2: Split into two patches.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Tested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This enables GL_shader_draw_parameters and GL_ARB_indirect_parameters as well
as a properly accelerated implementation of GL_ARB_multi_draw_indirect.
Enabling the feature requires a sufficiently uptodate firmware -- those have
already been released a long time ago, although this does mean that the
feature only works with the amdgpu kernel module, since the radeon module
doesn't have a way to query the firmware version.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Note that for indirect draws, the new MULTI firmware packets are required.
There's also no need to reset last_{start_instance,sh_base_reg}, since
resetting last_base_vertex is sufficient.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Byte indices don't need any alignment, so remove this assertion (it got moved
into a path where a piglit test hit it during the refactoring of
commit 64ff23a58c).
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
MSVC doesn't support 64-bit enum values, at least not with C code.
The compiler was warning:
c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(43) : warning
C4309: 'initializing' : truncation of constant value
c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(44) : warning
C4309: 'initializing' : truncation of constant value
...
And at runtime we crashed since the high 32-bits of the 'dirty' bitmask
was always 0xffffffff and the 32+u_bit_scan() index went out of bounds of
the atoms[] array.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Previously we would not print a swizzle on ssa_52 when only its .x
component is used (as seen in the definition of ssa_53):
vec3 ssa_52 = fadd ssa_51, ssa_51
vec1 ssa_53 = flog2 ssa_52
vec1 ssa_54 = flog2 ssa_52.y
vec1 ssa_55 = flog2 ssa_52.z
But this makes the interpretation of the RHS of the definition difficult
to understand and dependent on the size of the LHS. Just print swizzles
when they are not the identity swizzle, so the previous example is now
printed as:
vec3 ssa_52 = fadd ssa_51.xyz, ssa_51.xyz
vec1 ssa_53 = flog2 ssa_52.x
vec1 ssa_54 = flog2 ssa_52.y
vec1 ssa_55 = flog2 ssa_52.z
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This reverts commit a37e46323c.
It broke the game Overlord such that it hung a GCN GNU. While I don't know
how the hang happened because of its randomness and gfx corruption precedes
it, many of the shaders contain this:
out vec4 FragData[gl_MaxDrawBuffers];
This patch adds support for YV12 pixel format to the Android platform
backend. Only creating EGL images is supported, it is not added to the
list of available visuals.
v2: Use const array defined just for YV12 instead of trying to be overly
generic.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Kalyan Kondapally <kalyan.kondapally@intel.com>
Tested-by: Rob Herring <rob@kernel.org>
Reviewed-by: Chad Versace <chad@kiwitree.net>
Change-Id: I4aeb2d67a95c5cdd10b530c549b23146c8f0b983
OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled. This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.
The NVIDIA 367.35 drivers appear to follow this behavior.
For the awful spec analysis, please read Piglit's
tests/spec/arb_framebuffer_srgb/blit.c, which explains the differences
between GL 4.1, 4.2, 4.3 (2012), 4.3 (2013), and 4.4, and why this
is the right rule to implement.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Just avoid whacking GL_FRAMEBUFFER_SRGB altogether, so we respect
the application's setting. This appears to work.
v2: Update one more comment (requested by Ian).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled. This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.
The NVIDIA 367.35 drivers appear to follow this behavior.
For the awful spec analysis, please read Piglit's
tests/spec/arb_framebuffer_srgb/blit.c, which explains the differences
between GL 4.1, 4.2, 4.3 (2012), 4.3 (2013), and 4.4, and why this
is the right rule to implement.
Note that ctx->Color.sRGBEnabled is initialized to _mesa_is_gles(ctx),
and ES doesn't have enable/disable flags for GL_FRAMEBUFFER_SRGB, so
it's effectively on all the time. This means the ES behavior should
be unchanged.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This should have no effect, as all drivers which support BLORP also
support ES 3.0 - so ES 2.0 would be promoted and follow the ES 3 rules.
ES 1.0 doesn't have BlitFramebuffer.
This is purely to clarify the next patch a bit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This reverts commit 4e549ddb50,
dropping the hack from Gallium that I just deleted from i965.
See the previous commit for rationale.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
I've never quite understood the purpose of this hack - supposedly,
doing resolves in the sRGB colorspace is slightly more accurate.
Currently, BlitFramebuffer() ignores sRGB encoding and decoding
on OpenGL, although it encodes and decodes in GLES 3.x.
The updated OpenGL 4.4 rules also allow for encoding and decoding
if GL_FRAMEBUFFER_SRGB is enabled, allowing the application to
control what colorspace blits are done in. I don't think this hack
makes any sense in such a world - the application can do what it
wants, and we shouldn't second guess them.
A related Piglit patch, "Make multisample accuracy test set
GL_FRAMEBUFFER_SRGB when resolving." makes the Piglit MSAA accuracy
test explicitly request SRGB encoding/decoding during resolves when
running "srgb" subtests. Without that patch, this commit will regress
those tests, but with it, they should continue to work just fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Modern OpenGL BlitFramebuffer require sRGB encode/decode when
GL_FRAMEBUFFER_SRGB is enabled. The blitter can't handle this,
so we need to bail. On Gen4-5, this means falling back to Meta,
which should handle it.
We allow sRGB <-> sRGB blits, as decode then encode ought to be a noop
(other than potential precision loss, which nobody wants anyway).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
There are DRI_IMAGE_FOURCC macros, for which there are no corresponding
DRI_IMAGE_FORMAT macros. To support such formats we need to make the
lookup function take the native format directly. As a side effect, it
simplifies all existing calls to this function, because they all called
get_format() first to convert from native to DRI_IMAGE_FORMAT.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Rob Herring <rob@kernel.org>
Reviewed-by: Chad Versace <chad@kiwitree.net>
Change-Id: I4674000fb5ccfd02e38b8fa89bc567ac1d4fc16b
This patch splits current dri2_create_image_android_native_buffer() into
main entry point and two additional functions, one for creating an image
from flink name and one for handling prime FDs using the generic DMA-buf
path. This makes the code cleaner and also prepares for disabling flink
path more easily in the future.
v2: Split into separate patch.
Add error messages.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Rob Herring <rob@kernel.org>
Reviewed-by: Chad Versace <chad@kiwitree.net>
Change-Id: Ifdfb5927399d56992fe707160423c29278f49172
Drivers can request different set of buffers depending on the buffer
mask they pass to the get_buffers callback. This patch makes
droid_image_get_buffers() respect this mask.
v2: Return error only in case of real error condition and ignore requests
of unavailable buffers.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Rob Herring <rob@kernel.org>
Reviewed-by: Chad Versace <chad@kiwitree.net>
Change-Id: I6c3c4eca90f4c618579f6725dec323c004cb44ba
Fix compilation warnings due to unused variables left after some earlier
code changes.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Rob Herring <rob@kernel.org>
Reviewed-by: Chad Versace <chad@kiwitree.net>
Change-Id: Iec09eb2a62887f3a38dff156756ed8385f3f3447
We've been setting it in gen7 forever but never in gen8; best to make it
consistent. This hasn't caused any problems yet because we don't advertise
support for statistics queries yet.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The multisample rasterization mode is computed based on this field,
3DSTATE_RASTER::DXMultisampleRasterizationMode (only for forced
multisampling), 3DSTATE_RASTER::APIMode, and the number of samples. There
are two tables in the SKL PRM that describe how the final multisample mode
is calculated: "Windower (WM) Stage >> Multisampling >> Multisample
ModeState >> Table 1" and the formula for "SF_INT::Multisample
Rasterization Mode".
The "DX Multisample Rasterization Enable" bit changes whether multisample
mode is set to OFF_PIXEL or ON_PATTERN in the samples > 1 case. In the
samples == 1 case, the bit has no effect. Since Vulkan has no concept of
disabling multisampling for samples > 1, we can just set the bit.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This error condition is not implementable when using tessellation or
geometry shaders. The text was also removed from the ES 3.2 spec.
I believe the intended behavior is to remove the error condition
when either OES_geometry_shader or OES_tessellation_shader are
exposed.
v2: Quote a better part of issue 13 (suggested by Ian).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Mostly, I want to share the GLES 3 transform feedback handling,
though most of the rest of the code is identical as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Also update _mesa_has_tessellation to know about the new extensions.
For now, these are dummy_false, to avoid turning on the extension
until everything's in place. Eventually, we'll move them over to
the "ARB_tessellation_shader" bit so that any drivers supporting
both the desktop extension and ES 3.1 get the feature.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The OES_tessellation_shader and EXT_tessellation_shader specifications
have suffixed names. These are identical to the core function, so just
alias them.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Prefer to use DRAW_(INDEX)_INDIRECT_MULTI when available in the firmware.
Versions for SI and CI already added as provided by the firmware team, but
keep in mind that they won't currently be used since the radeon kernel module
has no interface to query the firmware version.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The radeon kernel module doesn't have the firmware query interface, so the
corresponding values will remain 0.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Overriding it is not allowed anyway, and actually lead to a crash when polygon
stippling was used with monolithic shaders.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
These are largely identical, except that the GS version has a few
extra error conditions. We can just pass in the stage and skip these.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We need to subtract VARYING_SLOT_PATCH0, not VARYING_SLOT_VAR0.
Since "patch" only applies to inputs and outputs, we can just handle
this once outside the switch statement, rather than replicating the
check twice and complicating the earlier conditions.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This assertion is bogus. Varying structs, and arrays of structs, are
allowed by GLSL, and we can see them here. While we currently don't
have any partial-variable support for those, simply returning false
and marking the entire thing as used is certainly legitimate.
I believe this is often swept under the rug by varying packing,
but that's disabled in certain tessellation situations.
Hit by 20 dEQP-GLES31.functional.tessellation.user_defined_io.* tests.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This better matches the grammar in section 4.3.9 of the GLSL 4.5 spec,
and also removes some redundant code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Similar to has_geometry_shader(), has_compute_shader(), and so on.
This will make it easier to add more conditions here later.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
They can only be run manually as described in HOW_TO_RUN.
It should help catch suboptimal code generation.
Some of the tests already fail.
v2: rename the tests to *.glsl,
fix lit.cfg to find FileCheck
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
This will be used by GLSL lit tests.
For developers only. It shouldn't be distributable and it doesn't use
the Mesa build system.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This will be used by: amdgcn_glslc -mcpu=[family]
It can also be used for shader-db if you want stats for a different family.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
On gl{Push,Pop}Attrib(GL_CLIENT_VERTEX_ARRAY_BIT) take
care that gl_vertex_array_object::VertexAttribBufferMask
matches the bound buffer object in the
gl_vertex_array_object::VertexBinding array.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Both the rgb9e5 and r11g11b10 formats are defined based on how they are
packed into a 32-bit integer. It makes sense that the functions that
manipulate them take an explicitly sized type.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
There are a number of reasons for this refactor. First, format_rgb9e5.h is
not something that a user would expect to define such a generic union.
Second, defining it requires checking for endianness which is ugly. Third,
90% of what we were doing with the union was float <-> uint32_t bitcasts
and the remaining 10% can be done with a sinmple left-shift by 23.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The rgb9e5 format is a packed format defined in terms of slicing up a
single 32-bit value. The bitfields are far more confusing than simple
shifts and require that we check the endianness.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
When an argument for a structure constructor or initializer doesn't
match the expected type, only Section 4.1.10 “Implicit Conversions”
are allowed to try to match that expected type.
From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
" The arguments to the constructor will be used to set the structure's
fields, in order, using one argument per field. Each argument must
be the same type as the field it sets, or be a type that can be
converted to the field's type according to Section 4.1.10 “Implicit
Conversions.”"
From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:
" In all cases, the innermost initializer (i.e., not a list of
initializers enclosed in curly braces) applied to an object must
have the same type as the object being initialized or be a type that
can be converted to the object's type according to section 4.1.10
"Implicit Conversions". In the latter case, an implicit conversion
will be done on the initializer before the assignment is done."
v2: Remove also the now redundant constant conversion, the
constant_record_constructor helper and the replacement code
(Timothy).
Fixes GL44-CTS.shading_language_420pack.initializer_list_negative
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
v2: Refactor also the conversion to constant and replacement code
(Timothy).
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Implicit conversions were added in the GLSL 1.20 spec version.
v2: Join the checks for GLSL 1.10 and ESSL (Timothy).
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Previously, for every input, we moved the dispatch mask to the flag
register, then emitted two predicated PLN instructions, one with
centroid barycentric coordinates (for normal pixels), and one with
pixel barycentric coordinates (for unlit helper pixels).
Instead, we can simply emit a set of predicated MOVs at the top of
the program which copy the pixel barycentric coordinates over the
centroid ones for unlit helper pixel channels. Then, we can just
use normal PLNs.
On Sandybridge:
total instructions in shared programs: 7538470 -> 7534500 (-0.05%)
instructions in affected programs: 101268 -> 97298 (-3.92%)
helped: 705
HURT: 9 (all of which are SIMD16 programs)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Sync now uses a callback to ensure that it's called by the last
thread moving past a DC. This will help with the new counter
handling.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
By allocating and initializing the matrices at context creation, the OS
couldn't even overcommit the pages. This saves about 63k (out of 946k) of
maximum memory size according to massif on simulated vc4
glsl-algebraic-add-add-1. It also means we could potentially relax the
maximum stack sizes, but that should be a separate commit.
v2: Drop redundant Top update, explain why the stack is small at init
time.
Reviewed-by: Brian Paul <brianp@vmware.com>
It's only used for rarely-used deprecated GL features
(feedback/rasterpos), so we can skip the memory allocation and
initialization for it most of the time.
Saves about 659k (out of 1605k) of maximum memory size according to massif
on simulated vc4 glsl-algebraic-add-add-1
Reviewed-by: Brian Paul <brianp@vmware.com>
This works out to be a wash in terms of memory usage: We use more memory
to store the separate ALU instructions, but we optimize out a lot of code
as well. The main result, though, is that we do more of our work at link
time rather than draw time.
We don't want to bake the whole array into the FS key, because of the
hashing overhead. But we can keep a set of the arrays seen, and use a
pointer to the copy in as the array's proxy.
Between this and the previous patch, gl-1.0-blend-func now passes on
hardware, where previously it was filling the 256MB CMA area with shaders
and OOMing.
Drops 712 shaders from shader-db.
I found a shader in Tales of Maj'Eyal that contains:
if ssa_21 {
block block_1:
/* preds: block_0 */
...instructions that prevent the select peephole...
vec1 32 ssa_23 = imov ssa_4
vec1 32 ssa_24 = imov ssa_4.y
vec1 32 ssa_25 = imov ssa_4.z
/* succs: block_3 */
} else {
block block_2:
/* preds: block_0 */
vec1 32 ssa_26 = imov ssa_4
vec1 32 ssa_27 = imov ssa_4.y
vec1 32 ssa_28 = imov ssa_4.z
/* succs: block_3 */
}
block block_3:
/* preds: block_1 block_2 */
vec1 32 ssa_29 = phi block_1: ssa_23, block_2: ssa_26
vec1 32 ssa_30 = phi block_1: ssa_24, block_2: ssa_27
vec1 32 ssa_31 = phi block_1: ssa_25, block_2: ssa_28
Here, copy propagation will bail because phis cannot perform swizzles,
and CSE won't do anything because there is no dominance relationship
between the imovs. By making nir_opt_remove_phis handle identical moves,
we can eliminate the phis and rewrite everything to use ssa_4 directly,
so all the moves become dead and get eliminated.
I don't think we need to check "exact" - just the alu sources.
Presumably phi sources should match in their exactness.
On Broadwell:
total instructions in shared programs: 11639872 -> 11638535 (-0.01%)
instructions in affected programs: 134222 -> 132885 (-1.00%)
helped: 338
HURT: 0
v2: Fix return value to be NULL, not false (caught by Iago).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Previously, we allocated a new VGRF for every undefined definition.
Instead, this patch makes us allocate a new VGRF for every use of an
undefined definition. This makes sure that undefined values are
fully independent of one another, and have live ranges limited to
their single use. This allows register coalescing to combine the
source and destination of MOVs from undefined sources, eliminating
the MOV altogether.
On Broadwell:
total instructions in shared programs: 11641187 -> 11640214 (-0.01%)
instructions in affected programs: 70199 -> 69226 (-1.39%)
helped: 213
HURT: 1
v2: Add a comment (based on Iago's suggested one).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Without this, the X server may accumulate stale Present event contexts
if a client performs several video decoding sessions using the same
window.
v2: Based on Chris Wilson's review:
* Use xcb_discard_reply() instead of free(xcb_request_check())
Reviewed-and-Tested-by: Leo Liu <leo.liu@amd.com>
Without this, the X server may accumulate stale Present event contexts
if a client ends up creating and destroying DRI drawables for the same
window.
v2: Based on Chris Wilson's review:
* Use xcb_present_select_input_checked so that protocol errors
generated by old X servers can be handled gracefully
* Use xcb_discard_reply() instead of free(xcb_request_check())
We were baking in the LOD of the source level to each shader. Instead,
pass it in as a uniform -- this requires storing it to a temp register,
but that's better than compiling a ton of separate shaders:
total instructions in shared programs: 115032 -> 115036 (0.00%)
instructions in affected programs: 96 -> 100 (4.17%)
LOST: 572
This helps in debugging memory pressure. It would be nice if we could
tell valgrind about it all the way from allocation time to destroy, but we
need a pointer to hand to VALGRIND_MALLOCLIKE_BLOCK.
The ranges are in units of bytes, not dwords. This wasn't caught by
piglit tests because ttn tends to make one big uniform file, so we only
had one UBO range with a src and dst offset of 0.
nir_opt_peephole_select has the job of removing IF statements with no side
effects. However, if the IF statement's successor didn't have any
instructions in it, we were skipping it, which occurred in mupen64 on vc4
with glsl_to_nir enabled:
instructions in affected programs: 6134 -> 4120 (-32.83%)
total uniforms in shared programs: 38268 -> 38219 (-0.13%)
No changes on Haswell shader-db.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v_fma_f32 runs at FP64 rate (= slow). Alien Isolation and F1 2015 seem
to use fma for all d3d multiply-add instructions, which is silly.
This tries to restore performance for those games.
The main difference between v_mad_f32 and v_fma_f32 is that v_mad doesn't
support denormals, which we don't enable anyway, because they are slow too.
Also, there is code size reduction:
Totals from affected shaders:
VGPRS: 109796 -> 109808 (0.01 %)
Spilled SGPRs: 29995 -> 30022 (0.09 %)
Spilled VGPRs: 12 -> 13 (8.33 %) <-- it's just one shader going from 12 to 13
Code Size: 6667596 -> 6476356 (-2.87 %) bytes
Max Waves: 26931 -> 26899 (-0.12 %)
I've not actually tested real performance.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
We need to include mt->offset in the calculation of src pointer because its
value may be non-zero, for example in a cubemap texture.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Cc: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Chad Versace <chad@kiwitree.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Change-Id: I461ad5b204626d5a1c45611fc6b63735dcf29f63
swr rasterizer contains numerous data transfers between vectors
and ordinary C types. Fixing for strict aliasing will take time.
Reviewed-by: Matt Turner <mattst88@gmail.com>
AST_NUM_OPERATORS stores the dimension of the ast_operators
enumeration but was not updated after its last modification.
This doesn't add any real modification for any code paths but it makes
sense for coherence.
v2 (Eric Engestrom): Just place the define at the end of the
enumeration, not below.
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Once upon a time (commit 8313f44409) Paul added code for the unlit
centroid workaround (WaCopyUnlitCentroidBarys). His commit message
claims it fixed the EXT_framebuffer_multisample/interpolation {2,4}
{centroid-deriv,centroid-deriv-disabled} piglit tests but does not say
on which platform, though he cites the IVB PRM.
"3DSTATE_WM [DevIVB, DevHSW]" says
"[DevIVB]: Workaround: When Centroid Barycentric mode is required, HW
may produce incorrect interpolation results when a 2X2 pixels have
unlit pixels."
I later disabled it for Haswell (commit f6db414f3c) with no known ill
effects.
The Sandybridge page does not have this text, but the workarounds
database (see WaCopyUnlitCentroidBarys) says the issues applies *only*
to Sandybridge, and in fact in commit 1a2de7dce8 I note that disabling
the workaround on Sandybridge causes the tests Paul originally mentioned
to fail.
So this is, and always has been, a huge confusing mess.
Disabling the workaround indeed causes the tests Paul originally
mentioned to fail on Sandybridge but not on Ivybridge/Baytrail.
On Ivybridge:
total instructions in shared programs: 6914901 -> 6909599 (-0.08%)
instructions in affected programs: 106766 -> 101464 (-4.97%)
helped: 884
total cycles in shared programs: 70874764 -> 70813774 (-0.09%)
cycles in affected programs: 794144 -> 733154 (-7.68%)
helped: 688
HURT: 186
LOST: 1
GAINED: 6
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Improves performance of OglBatch7 by 4.06851% +/- 1.17925% (n=169) on
Haswell, and cuts ~18k of .text:
text data bss dec hex filename
5824627 287816 29384 6141827 5db783 before/i965_dri.so
5806354 287816 29384 6123554 5d7022 after/i965_dri.so
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This can be used by the driver to get the command line which started
the process. Will be used by the VMware driver for extra logging.
For now, this is only implemented for Linux via /proc/self/cmdline
and Windows via GetCommandLine().
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch eliminates the redundant SetVertexBuffers and
SetIndexBuffer commands that are emitted for rebind purpose.
With this patch, the set commands will be skipped, but we will still
reference the associated resources to allow the kernel to
bring in the resources.
Tested with Lightsmark2008, Valley, MTT glretrace, piglit, conform.
Reviewed-by: Brian Paul <brianp@vmware.com>
There are cases where we hit u_vbuf path due to alignment or pitch-
alignment restrictions, but for an output-format that u_vbuf does not
support translating (yet the driver does support natively). In which
case we hit the memcpy() path and don't care that u_vbuf doesn't
understand it.
Fixes crash with debug build of mesa in:
dEQP-GLES3.functional.vertex_arrays.single_attribute.strides.fixed.user_ptr_stride17_components2_quads1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95000
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
AFAICT, it's never been used.
It was briefly nudged in the right direction here:
commit 10e5ffd496
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: Sat Jan 25 17:19:10 2014 +0000
gbm: do not export _gbm_mesa_get_device
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
The field is only read for printing today and
there it was probably a leftover.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
The way it is used today does not care about the
Enabled flag anymore.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Instead of gl_client_array::Enabled inside a VAO,
directly use the gl_vertex_attrib_array::Enabled value
which is the origin of the above.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO. Also make use of gl_vert_attrib_name.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO. Also make use of gl_vert_attrib_name.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Similarily to _mesa_all_varyings_in_vbos walk the VAO
to check if we have an illegal mapped buffer object
instead of walking all gl_client_arrays.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
In vbo_draw_transform_feedback we currently look at
exec->array.inputs to determine if all varying
vertex attributes reside in vbos. But the vbo_bind_arrays
call only happens past the vbo_all_varyings_in_vbos
query. Thus we may work on a stale set of client arrays.
Using the current VAOs content for this query feels much
more logical to me.
Additionally with this change mesa makes more use of the
information already tracked in the VAO instead of looping
across VERT_ATTRIB_MAX vertex arrays.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Implement the equivalent of vbo_all_varyings_in_vbos for
vertex array objects.
v2: Update comment.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
When a vertex buffer object gets deleted, it is unbound
at the VAO. To do this use _mesa_bind_vertex_buffer instead
of plain unreferencing the buffer object. This keeps the VAOs
internal state consistent. In this case it showed up with
gl_vertex_array_object::VertexAttribBufferMask getting out of
sync.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was added with ARB_enhanced_layouts.
V2: Add an extra format specifier for the new qualifier.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
See commit b0629e6894, where we discovered
that the SOL stage's "Rendering Disable" feature is a lot faster at
throwing away all geometry than the clipper's "reject all" mode.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Previously, the bitshift would be performed on a simple int (32 bits on
most systems), overflow, and then be cast to 64 bits.
CovID: 1362461
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We need to emit RB_FRAME_BUFFER_DIMENSION once per batch.. tracking this
in fd_context is wrong when the gmem code executes asynchronously from
the flush_queue worker. But in fact we don't really need to track it at
all. We cannot assume previous value at the beginning of the batch
(because of other processes potentially using the GPU), so just drop the
tracking and emit it in _tile_init().
Signed-off-by: Rob Clark <robdclark@gmail.com>
This is also used in gmem code, which executes from the "bottom half"
(ie. from the flush_queue worker thread), so it cannot be in fd_context.
Signed-off-by: Rob Clark <robdclark@gmail.com>
They weren't really used, and it gets somewhat more complicated to deal
with if batches are flushed asynchronously (on another thread). So just
drop them, and move _query_set_state(NULL) call into batch (so it is not
happening on background thread).
Signed-off-by: Rob Clark <robdclark@gmail.com>
With the state accessed from GMEM+submit factored out of fd_context and
into fd_batch, now it is possible to punt this off to a helper thread.
And more importantly, since there are cases where one context might
force the batch-cache to flush another context's batches (ie. when there
are too many in-flight batches), using a per-context helper thread keeps
various different flushes for a given context serialized.
TODO as with batch-cache, there are a few places where we'll need a
mutex to protect critical sections, which is completely missing at the
moment.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a bit of extra book-keeping about blits and back-blits (from
resource shadowing). If the app uploads all mipmap levels, as opposed
to uploading the first level and then glGenerateMipmap(), we can discard
the back-blit (as opposed to being naive and shadowing the resource for
each mipmap level). Also, after a normal blit, we might as well flush
the batch immediately, since there is not likely to be further rendering
to the surface.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Push query state down to batch, and use the resource tracking to figure
out which batch(es) need to be flushed to get the query result.
This means we actually need to allocate the prsc up front, before we
know the size. So we have to add a special way to allocate an un-
backed resource, and then later allocate the backing storage.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Switch to using a pipe_resource (rather than an fd_bo directly) for hw
query result buffers. This is first step towards making queries work
properly with reordered batches, since we'll need the additional
dependency tracking to know which batches to flush.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Basically, to "DCE" blits triggered by resource shadowing, in cases
where the levels are immediately completely overwritten. For example,
mid-frame texture upload to level zero triggers shadowing and back-blits
to the remaining levels, which are immediately overwritten by
glGenerateMipmap().
Signed-off-by: Rob Clark <robdclark@gmail.com>
To make batch re-ordering useful, we need to be able to create shadow
resources to avoid a flush/stall in transfer_map(). For example,
uploading new texture contents or updating a UBO mid-batch. In these
cases, we want to clone the buffer, and update the new buffer, leaving
the old buffer (whose reference is held by cmdstream) as a shadow.
This is done by blitting the remaining other levels (and whatever part
of current level that is not discarded) from the old/shadow buffer to
the new one.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Note that I originally also had a entry-point that would construct a key
and do lookup from a pipe_surface. I ended up not needing that (yet?)
but it is easy-enough to re-introduce later if we need it for the blit
path.
For now, not enabled by default, but can be enabled (on a3xx/a4xx) with
FD_MESA_DEBUG=reorder.
Signed-off-by: Rob Clark <robdclark@gmail.com>
To flush batches out of order, the gmem code needs to not depend on
state from fd_context (since that may apply to a more recent batch).
So this all moves into batch.
The one exception is the gmem/pipe/tile state itself. But this is
only used from gmem code (and batches are flushed serially). The
alternative would be having to re-calculate GMEM layout on every
batch, even if the dimensions of the render targets are the same.
Note: This opens up the possibility of pushing gmem/submit into a
helper thread.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Introduce the batch object, to track a batch/submit's worth of
ringbuffers and other bookkeeping. In this first step, just move
the ringbuffers into batch, since that is mostly uninteresting
churn.
For now there is just a single batch at a time. Note that one
outcome of this change is that rb's are allocated/freed on each
use. But the expectation is that the bo pool in libdrm_freedreno
will save us the GEM bo alloc/free which was the initial reason
to implement a rb pool in gallium.
The purpose of the batch is to eventually facilitate out-of-order
rendering, with batches associated to framebuffer state, and
tracking the dependencies on other batches.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This bug seems to have always been there. Applications changing shaders
but not textures between draw calls would have gotten undefined behavior.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This just needs to be done by st_validate_state.
v2: add "shaders_may_be_dirty" flags for not skipping st_validate_state
on _NEW_PROGRAM to detect real shader changes
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The goal is to do this in st_validate_state:
while (dirty)
atoms[u_bit_scan(&dirty)]->update(st);
That implies that atoms can't specify which flags they consume.
There is exactly one ST_NEW_* flag for each atom. (58 flags in total)
There are macros that combine multiple flags into one for easier use.
All _NEW_* flags are translated into ST_NEW_* flags in st_invalidate_state.
st/mesa doesn't keep the _NEW_* flags after that.
torcs is 2% faster between the previous patch and the end of this series.
v2: - add st_atom_list.h to Makefile.sources
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The pass I introduced in commit a2dc11a781
was entirely broken. A missing "break" made the load_interpolated_input
case always fall through to "default" and hit a "continue", making it
not actually move any load_interpolated_input intrinsics at all.
It would only move the simple load_barycentric_* intrinsics, which
don't emit any code anyway, making it basically useless.
The initial version I sent of the pass worked, but I apparently
failed to verify that the simplified version in v2 actually worked.
With the obvious fix applied (so we actually tried to move
load_interpolated_input intrinsics), I discovered a second bug: we
weren't moving the offset SSA def to the top, breaking SSA validation.
The new version of the pass actually moves load_interpolated_input
intrinsics and all their dependencies, as intended.
Papers over GPU hangs on Ivybridge and Baytrail caused by the
recent NIR FS input rework by restoring the old behavior.
(I'm not honestly sure why they hang with PLN not at the top.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97083
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Exported dmabufs can get imported by the same process, but the handle was
not getting added to the hash table on export. Add the handle to the hash
table on export.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We should use the persample_dispatch variable in prog_data.
Fixes all (~60) the DEQP sample shading tests. Many tests exited with
VK_ERROR_OUT_OF_DEVICE_MEMORY without this patch.
V2: Use the shader key bits set in brw_compile_fs (Jason)
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
eglTerminate, followed by eglReleaseThread. A similar case is
observed in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=69622,
where the test calls eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, NULL).
With the current code, dri2_dpy structure is freed on eglTerminate
call, so the display is not initialized when eglReleaseThread calls
MakeCurrent with NULL parameters, to unbind the context, which
causes a a segfault in drv->API.MakeCurrent (dri2_make_current),
either in glFlush or in a latter call.
eglTerminate specifies that "If contexts or surfaces associated
with display is current to any thread, they are not released until
they are no longer current as a result of eglMakeCurrent."
However, to properly free the current context/surface (i.e., call
glFlush, unbindContext, driDestroyContext), we still need the
display vtbl (and possibly an active dri dpy connection). Therefore,
we add some reference counter to dri2_egl_display, to make sure
the structure is kept allocated as long as it is required.
One drawback of this is that eglInitialize may not completely reinitialize
the display (if eglTerminate was called with a current context), however,
this seems to meet the EGL spec quite well, and does not permanently
leak any context/display even for incorrectly written apps.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The file was removed with earlier commit breaking 'make dist'.
Drop it from Makefile.sources since it's no longer around.
Fixes: 16985eb308 ("vc4: Switch to using the libdrm-provided
vc4_drm.h.")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
When an application declares varying arrays but does not actually do any
indirect indexing, some array indices may end up unused in the consuming
shader, so the number of input slots that correspond to the array ends
up less than the array_size.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Without this GCC 4.8.x throws below error:
error: invalid initialization of non-const reference of type
'clover::llvm::compat::raw_ostream_to_emit_file {aka llvm::raw_svector_ostream&}'
from an rvalue of type '<brace-enclosed initializer list>'
v2: change commit title and add error message like Eric Engestrom requested
Signed-off-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97019
[ Francisco Jerez: Trivial formatting fix. ]
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
These are only used by get_matching_input() which has been call
at this point so free the hash tables.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The number of outputs patch (limited to 255) has moved in the TCP
header, but blob seems to also set the old position. Also, the high
8-bits are now located inbetween the min/max parallel output read
address at position 20.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
This cuts down the overhead of si_dump_shader when ddebug is capturing
shader logs, which is done for every draw call unconditionally (that's
quite a lot of work for a draw call).
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
For good performance while being able to generate decent hang reports.
The report doesn't contain the parsed IB and the buffer list, but it
isolates the draw call and dumps shaders while not having to flush
the context.
This is for GPU hangs that are harder to reproduce and require interactive
playing for minutes or even hours.
dd_pipe.h explains some implementation details. Initializing, copying
(recording) and clearing states is most of the code.
The performance should be at least 50% of the normal performance depending
on the circumstances. (i.e. 50% is expected to be the worst case scenario,
not the best case) The majority of time is spent in
dump_debug_state(PIPE_DUMP_CURRENT_SHADERS) and that's after all
the optimizations in later patches. There is no obvious way to optimize
that further.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The pipelined hang detection mode will not want to dump everything.
(and it's also time consuming) It will only dump shaders after a draw call
and then dump the status registers separately if a hang is detected.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
It is necessary to reuse existing BOs when dmabufs are imported. There
are 2 cases that need to be handled. dmabufs can be created/exported and
imported by the same process and can be imported multiple times.
Copying other drivers, add a hash table to track exported BOs so the
BOs get reused.
v2: Whitespace fixup (by anholt)
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We could use the nir_shader_gather_info() pass to update it after the
fact, but this is what glsl_to_nir and prog_to_nir do.
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Shaders with shProg->Name == ~0 (aka 4294967295) are internal meta
shaders that we don't really want to capture.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Compilers are perfectly capable of generating efficient code for calls
like these to memcpy().
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I do appreciate the cleverness, but unfortunately it prevents a lot more
cleverness in the form of additional compiler optimizations brought on
by -fstrict-aliasing.
No difference in OglBatch7 (n=20).
Co-authored-by: Davin McCall <davmac@davmac.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now that the logical_depth0 field is in number of 2D slices, we don't need
to be multiplying by 6 when creating the surface. It wasn't hurting
anything primarily because we get the actual length from the view which was
already handling it correctly.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
intel_mipmap_tree::logical_depth0 is now in 2-D slices so there is no need
for us to multiply by 6 when we go to fill out a blorp surface state.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
When possible, do the memcpy on larger blocks. This reduces cycles
spent in _mesa_propagate_uniforms_to_driver_storage from
1.51 % to 0.62% according to perf during the Unigine Heaven benchmark.
It did not affect the framerate of the benchmark. The system used for
testing was an i5 6600K with a Radeon R9 380.
Piglit hangs randomly on this system both with and without the patch
so i could not make a comparison.
v2: fixed whitespace
Signed-off-by: Nils Wallménius <nils.wallmenius@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Enable H.264 VAAPI encoding through config. Currently only H.264 baseline is supported. Encode entrypoint is not accepted by driver.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Frame rate can be passed to driver either through VAEncSequenceParameterBufferType or VAEncMiscParameterTypeFrameRate. Previous code only implement the former one, which is used by Gstreamer-Vaapi. Now adding implementation for VAEncMiscParameterTypeFrameRate. Also adding default frame rate as 30 just in case application never provides frame rate information to driver.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Add environmental variable to disable interlace mode. At VAAPI decoding stage, driver can not distinguish b/w pure decoding case and transcoding case. And since interlace encoding is not supported, we have to disable interlace for transcoding case. The temporary solution is to use enviromental variable to disable interlace mode.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Add some hardcoded values hardware needs mainly for rate control purpose. With previously hardcoded values for OMX, the rate control result is not correct. This change fixed the rate control result by setting correct values for Vaapi.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Add necessary functions/changes for VAAPI encoding to buffer and picture. These changes will allow driver to handle all Vaapi encode related operations. This patch doesn't change the Vaapi decode behaviour.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Rate control method is passed from app to driver through config attrib list.
That is why we need to store this rate control method to config. And later
on, we will pass this value to context->desc.h264enc.rate_ctrl.rate_ctrl_method.
v2 (chk): fix broken build and commit message
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
For putimage call, if image format is yv12 (or IYUV with U V field swap) and
surface format is nv12, then we need to convert yv12 to nv12 and then copy
the converted data from image to surface. We can't use the existing logic
where surface is destroyed and re-created with yv12 format.
v2 (chk): fix some compiler warnings and commit message
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Add function to copy from yv12 image to nv12 surface for VAAPI putimage call.
We need this function in VaPutImage call where copying from yv12 image to nv12
surface for encoding. Existing function can't be used because it only work for
copying from yv12 surface to nv12 image in Vaapi.
v2: cleanup variable types and commit message
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. We
will save this encode entry point in config. config_id was used as profile
previously. Now, config has both profile and entrypoint field, and config_id is
used to get the config object. Later on, we pass this entrypoint to
context->templat.entrypoint instead of always hardcoded to
PIPE_VIDEO_ENTRYPOINT_BITSTREAM for decoding case previously. Encode entrypoint
is not accepted by driver until we enable Vaapi encode in later patch.
v2 (chk): fix commit message to match 80 chars, use switch instead of ifs,
fix memory leaks in the error path, implement vlVaQueryConfigEntrypoints
as well, drop VAEntrypointEncPicture (only used for JPEG).
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
This fixes a bunch of multisample piglit tests on GM206, like
bin/arb_texture_multisample-texelfetch 2 -auto -fbo
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
It's illegal to have neg modifiers on both sources for OP_ADD,
and it's illegal to have OP_SUB with just src0 neg.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Previously we were only restricting based on ES/non-ES-ness and whether
the overall enable bit had been flipped on. However we have been adding
more fine-grained restrictions, such as based on compat profiles, as
well as specific ES versions. Most of the time this doesn't matter, but
it can create awkward situations and duplication of logic.
Here we separate the main extension table into a separate object file,
linked to the glsl compiler, which makes use of it with a custom
function which takes the ES-ness of the shader into account (thus
allowing desktop shaders to properly use ES extensions that would
otherwise have been disallowed.) We can also now use this logic to
generate #define's for all supported extensions automatically, removing
the duplicate (and often inaccurate) list in glcpp.
The effect of this change should be nil in most cases. However in some
situations, extensions like GL_ARB_gpu_shader5 which were formerly
available in compat contexts on the GLSL side of things will now become
inaccessible.
This regresses two ES CTS tests:
ES3-CTS.shaders.shader_integer_mix.define
ES31-CTS.shader_integer_mix.define
however that is due to them using #version 100 instead of 300 es. As the
extension is only defined for ES3, I believe this is the correct
behavior.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v2)
v2 -> v3: integrate glcpp defines into the same mechanism
We need "NULL" state to be a valid bit in the bitmask, because timestamp
queries are not restricted to draw/etc stages (ie. the only commands to
submit may just be to read the timestamp). And just because there are
no draws, isn't a reason to skip the flush and return zero.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since commit d938b8c, the sample locations are no longer set unconditionally,
so we need to set the atom to dirty on all chips, not just Polaris.
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
The regression was introduced by commit d938b8c. The problem here is that in
order to use the small primitive filter, we need to explicitly set the sample
locations to 0. But the DB doesn't properly process the change of sample
locations without a flush, and so we can end up with incorrect Z values.
Instead of doing a flush, just disable the small primitive filter when MSAA
is force-disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96908
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
v2: no need for break after an unreachable (Matt Turner)
Signed-off-by: Francesco Ansanelli <francians@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
to reduce the call indirections with u_resource_vtbl.
The worst call tree you could get was:
- u_transfer_inline_write_vtbl
- u_default_transfer_inline_write
- u_transfer_map_vtbl
- driver_transfer_map
- u_transfer_unmap_vtbl
- driver_transfer_unmap
That's 6 indirect calls. Some drivers only had 5. The goal is to have
1 indirect call for drivers that care. The resource type can be determined
statically at most call sites.
The new interface is:
pipe_context::buffer_subdata(ctx, resource, usage, offset, size, data)
pipe_context::texture_subdata(ctx, resource, level, usage, box, data,
stride, layer_stride)
v2: fix whitespace, correct ilo's behavior
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
One of the WebGL 2.0 conformance tests is trying to call
glGenerateMipmaps with a width and height of 0. With the meta
implementation, this generates a "framebuffer attachment incomplete"
status, and falls back to the CPU path, calling MapTextureImage.
Except that there's no actual texture to map, and we assert fail.
There's no work to do in this case. The test expects it to succeed,
so just return early with no error and avoid hassling the driver.
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96911
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
For lod query instructions, we really don't care whether or not the sampler
is an array type because that doesn't factor into the LOD.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-dev@lists.freedesktop.org>
On i965, we can't support coordinate offsets for texelFetch or rectangle
textures. Previously, we were doing this with a GLSL pass but we need to
do it in NIR if we want those workarounds for SPIR-V.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-dev@lists.freedesktop.org>
While SPIR-V technically doesn't support "old style" shadow, the
shadow-compare gather instruction does return a vec4 so we need to be able
to set the old_style_shadow bit in NIR.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-dev@lists.freedesktop.org>
This allows the load-propagation pass to swap the sources in presence
of immediate values.
Maxwell (GM107):
total instructions in shared programs :1928187 -> 1927634 (-0.03%)
total gprs used in shared programs :330741 -> 330154 (-0.18%)
total local used in shared programs :28032 -> 28032 (0.00%)
local gpr inst bytes
helped 0 271 425 425
hurt 0 0 194 194
Fermi (GF114):
total instructions in shared programs :2334474 -> 2333829 (-0.03%)
total gprs used in shared programs :380934 -> 380215 (-0.19%)
total local used in shared programs :33304 -> 33264 (-0.12%)
local gpr inst bytes
helped 5 314 521 521
hurt 0 4 195 195
No regressions on GM107 and GF114 with full piglit.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
There are 2 uses:
- Asynchronous flushing for multithreaded drivers.
- Return a fence without flushing (mid-command-buffer fence). The driver
can defer flushing until fence_finish is called.
This is required to make Bioshock Infinite faster, which creates
1000 fences (flushes) per frame.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
subroutine variables are to be used just in the way functions are
called. Although the spec doesn't say it explicitely, this means that
these variables are not to be used in any other way than those left
for function calls. Therefore, a comparison between 2 subroutine
variables should also cause a compilation error.
From The OpenGL® Shading Language 4.40, page 117:
" To use subroutines, a subroutine type is declared, one or more
functions are associated with that subroutine type, and a
subroutine variable of that type is declared. The function
currently assigned to the variable function is then called by
using function calling syntax replacing a function name with the
name of the subroutine variable. Subroutine variables are
uniforms, and are assigned to specific functions only through
commands (UniformSubroutinesuiv) in the OpenGL API."
From The OpenGL® Shading Language 4.40, page 118:
" Subroutine uniform variables are called the same way functions
are called. When a subroutine variable (or an element of a
subroutine variable array) is associated with a particular
function, all function calls through that variable will call that
particular function."
Fixes GL44-CTS.shader_subroutine.subroutines_cannot_be_assigned_float_int_values_or_be_compared
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since 7f53fead5c we treat every location as using all
four components so we only need special handling for
doubles when they cross multiple locations.
This fixes a crash in GL45-CTS.enhanced_layouts.varying_locations
where the outputs array would overflow when a dmat2 was stored at
the max varying location i.e 30.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This fixes a regression introduced in
1da704a94c because the offset has moved
from 0x180 to 0x1a0, and the macros have to be re-compiled.
Fixes: 1da704a ("nvc0: increase the tex handles area size in the driver")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This fixes a regression introduced in
1da704a94c because the offset has moved
from 0x600 to 0x620, and the kernels used for reading MP perf counters
have to be re-assembled.
This also fixes amd_performance_monitor_measure piglit.
Fixes: 1da704a ("nvc0: increase the tex handles area size in the driver")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The GL_EXT_texture_format_BGRA8888 extension specification defines a
GL_BGRA_EXT unsized internal format (which is a little odd - usually
BGRA is a pixel transfer format). The extension is written against
the ES 1.0 specification, so it's a little hard to map, but I believe
it's effectively adding it to the table used here, so we should allow
it here as well.
Note that GL_EXT_texture_format_BGRA8888 is always enabled (dummy_true),
so we don't need to check if it's enabled here.
This fixes mipmap generation in Skia and ChromeOS.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
References: https://bugs.chromium.org/p/chromium/issues/detail?id=630371
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reported-by: Stéphane Marchesin <marcheu@chromium.org>
Cc: mesa-stable@lists.freedesktop.org
Commit 52e75dcb8c made nir_lower_io
start using nir_intrinsic_set_base instead of writing const_index[0]
directly. However, those intrinsics apparently don't /have/ a base,
so this caused assert failures.
However, the old code was happily setting non-existent const_index
fields, so it was pretty bogus too.
Jason pointed out that load_shared and store_shared have a base,
and that the i965 driver uses that field. So presumably atomics
should have one as well, so that loads/stores/atomics all refer
to variables with consistent addressing.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We always resort to the pull model for instanced GS inputs. So, we'd
better include the VUE handles, or else we can't actually pull anything.
Ian reports that on his branch with OES_geometry_shader enabled,
this fixes a bunch of dEQP-GLES31.functional.geometry_shading tests::
- instanced.draw_2_instances_geometry_2_invocations
- instanced.draw_2_instances_geometry_8_invocations
- instanced.draw_4_instances_geometry_2_invocations
- instanced.draw_4_instances_geometry_8_invocations
- instanced.draw_8_instances_geometry_2_invocations
- instanced.draw_8_instances_geometry_8_invocations
- instanced.geometry_2_invocations
- instanced.geometry_32_invocations
- instanced.geometry_8_invocations
- instanced.geometry_max_invocations
- instanced.geometry_output_different_2_invocations
- instanced.geometry_output_different_32_invocations
- instanced.geometry_output_different_8_invocations
- instanced.geometry_output_different_max_invocations
- instanced.invocation_output_vary_by_attribute
- instanced.invocation_output_vary_by_texture
- instanced.invocation_output_vary_by_uniform
- query.primitives_generated_instanced
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Not sure why I forgot to add them to CXXFLAGS in commit f55c408067 or
commit 875458b778. Cuts about 1k of .text.
text data bss dec hex filename
5806354 287816 29384 6123554 5d7022 i965_dri.so before
5805497 287744 29384 6122625 5d6c81 i965_dri.so after
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
According to the referenced bug report, gcc-4.5 and newer do not inline
memcmp(). I see no difference in performance of ipers with llvmpipe on a
Sandybridge (which does not have "Enhanced REP MOVSB/STOSB") by removing
this flag.
I attempted to confirm the problem with gcc-4.4, but it fails to compile
for quite a few different reasons.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Based loosely on patches submitted ages ago by Thomas Helland.
v2: Add lots of missing data provided by Ilia. Fix sort order of
GL_ARB_sparse_texture extensions suggested by Ilia.
v3: Note that Dave Airlie has started work on GL_ARB_bindless_texture.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Here we create a new output_generic_reg array with the ability to
store the dst_reg for each component of user defined varyings.
This is needed as the previous code only stored the dst_reg based
on the varying location which meant packed varyings would overwrite
each other.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
For example where n=3 first_component=1 this will give us
0xE (WRITEMASK_YZW).
V2:
Add assert to check first component is <= 4 (Suggested by Ken)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
This will be used to swizzle components to the beginning or end
of the vector based on the component layout qualifier and whether
we are doing a load or store.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
This makes sure we give the correct driver location
for doubles when using component packing. Specifically
it handles packing a dvec3 with a double which is the
only packing scenario allowed which spans across two
locations.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Here we use the component qualifier (which is the first component)
as an offset when loading output varyings.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Rather than trying to work out the total number of components
used at a location we simply treat all outputs as vec4s. This
removes the need for complex code looping over varyings to match
packed locations and the need for storing the total number of
components used at each location.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We will use this for output varyings. To make component
packing simpler we will just treat all varyings as vec4s.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The build was failing because the official CL headers have a few defines,
like: # define cl_khr_gl_sharing 1
Which have the same name as some class members of clang's OpenCLOptions class.
If we include the cl headers first, this breaks the build because the member
names of this class are replaced by the literal 1.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Vedran Miletić <vedran@miletic.net>
clang commit r275822 removed unnecessary includes from header files,
so we now need to explicitly include clang/Lex/PreprocessorOptions.h
v2:
- Use <> instead of "" for the include path.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Vedran Miletić <vedran@miletic.net>
TCS/TES/GS and now FS all handle these in stage-specific functions.
CS don't have inputs, so VS was the only one left using this code.
Move it to the VS-specific function for clarity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We no longer use this message. As far as I can tell, it's fairly
useless - the equivalent information is provided in the payload.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This eliminates the need to walk the list of input variables, recurse
into their types (via logic largely redundant with nir_lower_io), and
interpolate all possible inputs up front. The backend no longer has
to care about variables at all, which eliminates complications from
trying to pack multiple variables into the same location. Instead,
each intrinsic specifies exactly what's needed.
This should unblock Timothy's work on GL_ARB_enhanced_layouts.
Each load_interpolated_input intrinsic corresponds to PLN instructions,
while load_barycentric_at_* intrinsics correspond to pixel interpolator
messages. The pixel/centroid/sample barycentric intrinsics simply refer
to payload fields (delta_xy[]), and don't actually generate any code.
Because we use a single intrinsic for both centroid-qualified variables
and interpolateAtCentroid(), they become indistinguishable. We stop
sending pixel interpolator messages for those, and instead use the
payload provided data, which should be considerably faster.
On Broadwell:
total instructions in shared programs: 9067751 -> 9067570 (-0.00%)
instructions in affected programs: 145902 -> 145721 (-0.12%)
helped: 422
HURT: 209
total spills in shared programs: 2849 -> 2899 (1.76%)
spills in affected programs: 760 -> 810 (6.58%)
helped: 0
HURT: 10
total fills in shared programs: 3910 -> 3950 (1.02%)
fills in affected programs: 617 -> 657 (6.48%)
helped: 0
HURT: 10
LOST: 3
GAINED: 3
The differences mostly appear to be slight changes in MOVs.
v2: Use nir_shader_compiler_options::use_interpolated_input_intrinsics
flag rather than passing it directly to nir_lower_io. Use the
unreachable() macro rather than assert in one place. (Review
feedback from Chris Forbes.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Currently, i965 interpolates all FS inputs at the top of the program.
This has advantages and disadvantages, but I'd like to keep that policy
while reworking this code. We can consider changing it independently.
The next patch will make the compiler generate PLN instructions "on the
fly", when it encounters an input load intrinsic, rather than doing it
for all inputs at the start of the program.
To emulate this behavior, we introduce an ugly pass to move all NIR
load_interpolated_input and payload-based (not interpolator message)
load_barycentric_* intrinsics to the shader's start block.
This helps avoid regressions in shader-db for cases such as:
if (...) {
...load some input...
} else {
...load that same input...
}
which CSE can't handle, because there's no dominance relationship
between the two loads. Because the start block dominates all others,
we can CSE all inputs and emit PLNs exactly once, as we did before.
Ideally, global value numbering would eliminate these redundant loads,
while not forcing them all the way to the start block. When that lands,
we should consider dropping this hacky pass.
Again, this pass currently does nothing, as i965 doesn't generate these
intrinsics yet. But it will shortly, and I figured I'd separate this
code as it's relatively self-contained.
v2: Dramatically simplify pass - instead of creating new instructions,
just remove/re-insert their list nodes (suggested by Jason Ekstrand).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com> [v1]
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When working with a non-multisampled render target, asking for "sample"
interpolation locations doesn't make sense. We demote them to centroid.
In a couple of patches, brw_compute_barycentric_modes will begin looking
at these intrinsics to determine the barycentric modes. fs_visitor also
will use them to code-generate pixel interpolator messages or payload
references. Handling the "but what if it's not MSAA?" logic ahead of
time in a NIR pass simplifies things and prevents duplicated logic.
This patch doesn't actually do anything useful yet as we don't generate
these intrinsics. I decided to keep it separate as it's self-contained,
in the hopes of shrinking the "convert everything" patch for reviewers.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Now nir_lower_io can optionally produce load_interpolated_input
and load_barycentric_* intrinsics for fragment shader inputs.
flat inputs continue using regular load_input.
v2: Use a nir_shader_compiler_options flag rather than ad-hoc boolean
passing (in response to review feedback from Chris Forbes).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Backends can normally handle shader inputs solely by looking at
load_input intrinsics, and ignore the nir_variables in nir->inputs.
One exception is fragment shader inputs. load_input doesn't capture
the necessary interpolation information - flat, smooth, noperspective
mode, and centroid, sample, or pixel for the location. This means
that backends have to interpolate based on the nir_variables, then
associate those with the load_input intrinsics (say, by storing a
map of which variables are at which locations).
With GL_ARB_enhanced_layouts, we're going to have multiple varyings
packed into a single vec4 location. The intrinsics make this easy:
simply load N components from location <loc, component>. However,
working with variables and correlating the two is very awkward; we'd
much rather have intrinsics capture all the necessary information.
Fragment shader input interpolation typically works by producing a
set of barycentric coordinates, then using those to do a linear
interpolation between the values at the triangle's corners.
We represent this by introducing five new load_barycentric_* intrinsics:
- load_barycentric_pixel (ordinary variable)
- load_barycentric_centroid (centroid qualified variable)
- load_barycentric_sample (sample qualified variable)
- load_barycentric_at_sample (ARB_gpu_shader5's interpolateAtSample())
- load_barycentric_at_offset (ARB_gpu_shader5's interpolateAtOffset())
Each of these take the interpolation mode (smooth or noperspective only)
as a const_index, and produce a vec2. The last two also take a sample
or offset source.
We then introduce a new load_interpolated_input intrinsic, which
is like a normal load_input intrinsic, but with an additional
barycentric coordinate source.
The intention is that flat inputs will still use regular load_input
intrinsics. This makes them distinguishable from normal inputs that
need fancy interpolation, while also providing all the necessary data.
This nicely unifies regular inputs and interpolateAt functions.
Qualifiers and variables become irrelevant; there are just
load_barycentric intrinsics that determine the interpolation.
v2: Document the interp_mode const_index value, define a new
BARYCENTRIC() helper rather than using SYSTEM_VALUE() for
some of them (requested by Jason Ekstrand).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Gen7/7.5 call it "Rendering Disable" while Gen8/9 prefix it with "API".
Pick one for consistency, and so we can share code between generations.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The bulk of this is the same. There are just a couple fields that only
exist on one generation or another, and we can easily handle those with
an #ifdef.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The Gen7/7.5 clip code used APIMODE_OGL, while the Gen8+ clip code used
APIMODE_D3D. The meaning hasn't changed, so one of these must be wrong.
It appears that the hardware documentation is completely wrong. It
claims that the "API Mode" bit means:
0h APIMODE_OGL NEAR_VP boundary == 0.0 (NDC)
1h APIMODE_D3D NEAR_VP boundary == -1.0 (NDC)
However, DirectX typically uses 0.0 for the near plane, while unextended
OpenGL uses -1.0. i965's gen6_clip_state.c uses APIMODE_D3D for the
GL_ZERO_TO_ONE case, so I believe the meanings are backwards from what
the documentation says.
Section 23.2 ("Primitive Clipping") of the Vulkan 1.0.21 specification
contains the following equations:
-w_c <= x_c <= w_c
-w_c <= y_c <= w_c
0 <= z_c <= w_c
This means that Vulkan follows D3D semantics.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Refactoring to leave existing simd_* intrinsics in "simdintrin.h" unchanged,
adding corresponding simd16_* intrinsics in "simd16intrin.h" on the side,
with emulation, that we can use piecemeal, rather than the all-or-nothing
approach to bring up avx512.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
Add support for enhanced attribute swizzling. Currently supports constant
source overrides to handle PrimitiveID support. No support yet for input
select swizzling or wrap shortest. Removes obsoleted linkageMask and
associated code.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
Moved the setting into the existing component control code. Fixes bad
interaction between attribute/component setting for vertex/instance ID
and component packing.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
From the Sky Lake PRM:
"For SURFTYPE_CUBE: For Sampling Engine Surfaces and Typed Data Port
Surfaces, the range of this field is [0,340], indicating the number of
cube array elements (equal to the number of underlying 2D array elements
divided by 6). For other surfaces, this field must be zero."
In other words, the depth field for cube maps is in number of cubes not
number of 2-D slices so we need to divide by 6. ISL will do this correctly
for us assuming that we provide it with the correct array bounds which it
expects to be in 2-D slices. It appears as if we've been doing this wrong
ever since we first added cube map arrays for Sandy Bridge and the change
to ISL made things slightly worse. While we're at it, we now need to remoe
the shader hacks we've always done since they were only needed because we
were setting the depth field six times too large.
v2: Fix the vec4 backend as well (not sure how I missed this).
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
This matches what we do for cube maps where logical_depth0 is in number of
face-layers rather than number of cubes. This does mean that we will
temporarily be setting the surface bounds too loose for cube map textures
but we are already setting them too loose for cube arrays and we will be
fixing that in the next commit anyway.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Cc: "12.0 11.2 11.1" <mesa-stable@lists.freedesktop.org>
The GL API and mesa internals do this differently than we do. In GL, there
is no depth parameter for 1-D arrays and height is used. In the i965
miptree code we do the sane thing and make height == 1 and use depth for
number of slices. This makes for a mismatch every time we create a 1-D
array texture from GL. Instead of actually solving this problem, we just
said "1-D is hard, let's make sure it works no matter which way we pass the
parameters" and called it a day.
This commit fixes the one GL -> i965 transition point where we weren't
already handling 1-D array textures to do the right thing and then replaces
the magic fixup code with an assert that you're doing the right thing.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Cc: "12.0 11.2 11.1" <mesa-stable@lists.freedesktop.org>
This 'last' variable used in FindGLXFunction(...) may become negative,
but has been defined as unsigned int resulting in an overflow,
finally resulting in a segfault when accessing _glXDispatchTableStrings[...].
Fixed this by definining it as signed int. 'first' variable also needs to be
defined as signed int. Otherwise condition for while loop fails due to C
implicitly converting signed to unsigned values before comparison.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Stefan Dirsch <sndirsch@suse.de>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Current implementation of the DRI image loader does not free the images
created in get_back_bo() and so leaks memory. Moreover, it creates a new
image every time the DRI driver queries for buffers, even if the backing
native buffer has not changed. leaking memory again.
This patch adds missing call to destroyImage() in droid_enqueue_buffer()
and a check if image is already created to get_back_bo() to fix the
above.
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
It is much easier to debug issues when the application gives some
meaningful error messages. This patch adds few to the EGL Android
platform backend.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
As the spec allows for {server,client}_wait_sync to be called without
currently bound context, while our implementation requires context
pointer.
v2: Add a mutex and acquire it for the duration of
brw_fence_client_wait() and brw_fence_is_completed() as suggested
by Chad.
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Without this, if a configuration is, say, available only on GLES2/3, but
not on GLES1, and is rejected by the dri module's bindContext call,
eglMakeCurrent fails with error "EGL_SUCCESS".
In this patch, we set error to EGL_BAD_MATCH, which is what CTS/dEQP
dEQP-EGL.functional.surfaceless_context expect.
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
An earlier patch fixed the problem for classic drivers, however Gallium
was still left broken. This patch applies the same workaround to
Gallium, when compiled for Android. Following is a quote from the
original patch:
0cbc90c57c mesa: dri: Add shared glapi to LIBADD on Android
/system/vendor/lib/dri/*_dri.so actually depend on libglapi: without
this, loading the so file fails with:
cannot locate symbol "__emutls_v._glapi_tls_Context"
On non-Android (non-bionic) platform, EGL uses the following
workflow, which works fine:
dlopen("libglapi.so", RTLD_LAZY | RTLD_GLOBAL);
dlopen("dri/<driver>_dri.so", RTLD_NOW | RTLD_GLOBAL);
However, bionic does not respect the RTLD_GLOBAL flag, and the dri
library cannot find symbols in libglapi.so, so we need to link
to libglapi.so explicitly. Android.mk already does this.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In the case of building in out-of-tree fashion, while having generated
in-tree sources, the latter [likely stale] files will be used.
Flip the order to prevent that.
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This allows Gallium drivers to advertise the subpixel precision
for floating point viewports bounds.
v2:
- Set ViewportSubpixelBits in st_init_limits.
Signed-off-by: Józef Kucia <joseph.kucia@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
MS images have to be handled explicitly and I don't plan to implement
them for now.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
On Maxwell, images binding is slightly different (and much better)
regarding Fermi and Kepler because a texture view needs to be uploaded
for each image and this is going to simplify the thing a lot.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Currently, we can store 32 tex handles of 32-bits integer each and
that fits perfectly with the underlying hardware except on GM107+
which requires to upload a texture view for each images.
This patch increases the number of storable texture handles in the
driver constant buffer from 32 to 40 because we expose 8 images.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
For intrinsics we don't care about, just skip to the next loop iteration
and process the next instruction. We don't want to execute the rest of
the code.
This was a bug in commit cdfc05ea6e.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Fixes a 10-20% performance regression in OglCSDof caused by commit
5a8c89038a, which made images (in the
image load/store sense) use BDW_MOCS_PTE instead of BDW_MOCS_WB.
This seems sketchy, as the default PTE value is supposed to be
WB LLC eLLC, which is the same as our MOCS WB setting. It's only
supposed to change when using a surface for display, which won't
ever happen for images. Something may be wrong in the kernel...
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I noticed this when I tried to do frexp(float(some_unsigned)) in the
ir_unop_find_lsb lowering pass. The code generated for frexp() uses
fabs, and this resulted in an extra instruction. Ultimately I ended up
not using frexp.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Previously SHADER_OPCODE_MULH could only exist on Gen7+, so the
assertion assumed the Gen7+ accumulator rules. A future patch will
allow this instruction on at least Gen6, so update the assertion.
v2: Use get_lowered_simd_width instead of open coding it. Suggested by
Curro.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
v2: Retype LZD source as UD to avoid potential problems with 0x80000000.
Suggested by Matt. Also update comment about problem values with
LZD(abs(x)). Suggested by Curro.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This uses one less instruction.
v2: Move emit_find_msb_using_lzd out of the visitor classes. Suggested
by Curro.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
With the existing lowering passes, the functions from this extension
become a bunch of bit twiddling operations that have always been
supported.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This extension does not depend on the Gen. It only depends on the
availability of GLSL 1.30.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This isn't the lowering pass you want. Most GPUs that can support GLSL
1.30 have a multiply unit that can do something more interesting than
32x32->32. Many have 32x16->48. Any GPU that does, should do the
lowering in the backend. This is just the thing that will always work.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Fix typo in #extension line noticed by Ken.
v3: Update spec status.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Add entrypoint to distinguish H.264 decode and encode. For example, in patch
5/11 when is calling "VaCreateContext", "pps" and "sps" shouldn't be allocated
for H.264 encoding. So we need to use the entry_point to determine this is
H.264 decode or H.264 encode. We can use config to determine the entrypoint
since config_id is passed to us for VaCreateContext call. However, for
VaDestoyContext call, only context_id is passed to us. So we need to know the
entrypoint in order to not free the pps/sps for encoding case.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Mark both L8_SRGB and L8A8_SRGB as non-renderable (the latter already
didn't have the bind flags). This makes the state tracker pick a
different format when rendering is required, or mark the fb as
incomplete. This fixes:
bin/getteximage-formats init-by-clear-and-render -auto -fbo
bin/getteximage-formats init-by-rendering -auto -fbo
which previously ran into srgb-encoding differences.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
This is useful for pbo downloads, which are now accelerated with images.
BGRA8 is a moderately common format to do that in.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
At this point there is no reason not to be using the linked shaders,
using the linked shaders should be faster and will make things simpler
for upcoming shader cache work.
The previous variable name suggests the linked shaders were intended
to be used here anyway.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This reverts commit 82f8c23950.
KHR_texture_compression_astc_sliced_3d is not a requirement for
GLES 3.2.
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>\
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
This way we have unlimited UVD sessions.
v2: only enable it when kernel supports it as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Inspired by fix for mem leak of vdpau interop, resource_from_handle
set texture reference count, that need to be decreased and released,
recall there is a similar case for DRI3, that is with VA-API glx
extension, there is temporary TFP(texture from pixmap), we target it
through dma-buf. leak happens when without count down the reference.
Checked and found with mpv vo=opengl case, there only one static TFP,
the leak happens once, but for totem player using gstreamer VA-API glx,
the dynamic TFP for each frame, so leak quite a bit.
This fixes mem leak for mpv and totem.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
We totally ignored this before because there were no piglit tests for
indirect loads in tessellation stages with doubles.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Our indirect URB read messages take both a direct and an indirect offset
so when we emit the second message for a 64-bit input load we can just
always incremement the immediate offset, even for the indirect case.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
pulls_bary should be set when the shader uses a pixel interpolator
message. So, setting it from the function that emits pixel interpolator
messages makes a lot of sense.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This patch makes emit_general_interpolation take a destination register
as an argument, and write directly to that. This is simpler than the
old approach of ralloc'ing a register, writing to that temporary, and
then making the caller emit per-component MOVs to copy it to the actual
destination.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The unlit centroid workaround starts being necessary on Gen6, which
is the first platform with multisampling. PLN exists on G45+, so all
platforms which need this workaround have PLN.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
glsl_to_nir always produces a system value for gl_FrontFacing, rather
than an input. So there should never be an input with this slot,
making this code dead.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Likewise, rename the enum type to glsl_interp_mode.
Beyond the GLSL front-end, talking about "interpolation modes" seems
more natural than "interpolation qualifiers" - in the IR, we're removed
from how exactly the source language specifies how to interpolate an
input. Also, SPIR-V calls these "decorations" rather than "qualifiers".
Generated by:
$ find . -regextype egrep -regex '.*\.(c|cpp|h)' -type f -exec sed -i \
-e 's/INTERP_QUALIFIER_/INTERP_MODE_/g' \
-e 's/glsl_interp_qualifier/glsl_interp_mode/g' {} \;
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Dave Airlie <airlied@redhat.com>
The hardware can only do alphatest when using a blendable format. This
means that the various *16 norm formats didn't work with alphatest. It
appears that Talos Principle uses such formats, as well as alpha tests,
for some internal renders, which made them be incorrect. However this
does not appear to affect the final renders, but in a different game it
easily could.
The approach we take is that when alphatests are enabled and a suitable
format is used (which we anticipate is the vast minority of the time),
we insert code into the shader to perform the comparison and discard.
Once inserted, that code lives in the shader forever, and we re-upload
it each time the function changes with a fixed-up compare. To avoid
re-uploading too often, if we switch back to a blendable format, the
test is (effectively) disabled and the hw alphatest functionality is
used.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
In d035d50 this changed to 64b.. which I'm pretty sure was
unintentional. Revert it back to 32b so the entire state struct
is a nice round 64b.
(Note sure that it would actually be measurable, but I did notice
that check_state() was hot in some benchmarks.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Adds a second optional cleanup callback, called after the fence is
signaled. This is needed if, for example, the queue has the last
reference to the object that embeds the util_queue_fence. In this
case we cannot drop the ref in the main callback, since that would
result in the fence being destroyed before it is signaled.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
According to firmware guys, the new sequence that we added for Polaris should
work on all CIK parts, and should actually be faster on some parts.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
I recently refactored this to share code between load and atomic
lowering. loads used intrin->num_components, while atomics used
intrin->dest.ssa.num_components. They should be equivalent, but
Jason wanted me to use the latter. I missed applying his review.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This is more readable and also offers assertions that protect against
setting const_index fields on the wrong kind of intrinsic.
Suggested by Jason.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The original function was becoming a bit hard to read, with the details
of creating and filling out load/store/atomic atomics all in one
function.
This patch makes helpers for creating each type of intrinsic, and also
combines them with the *_op() helpers, as they're closely coupled and
not too large.
v2: Minor style nits from Jason.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This can't happen, the caller asserts that mode is shader_out or shared.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Both loads and atomics had identical code to rewrite destinations,
and all cases had the same two lines to replace instructions.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The load/store/atomic cases all duplicated the get_io_offset code, with
a few tiny differences: stores didn't bother checking for per-vertex
inputs, because they can't be stored to, and atomics didn't check at
all, since shared variables aren't per-vertex.
However, it's harmless to check, and allows us to share more code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Less typing and word wrapping issues than intrin->variables[0]->var.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Rather than computing the barycentric mode each time we emit a LINTERP,
we can simply compute it once, as soon as we know we're doing non-flat
interpolation.
At that point, emit_linterp() doesn't do much, so fold it into the
call sites and drop it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
brw_wm_barycentric_interp_mode is wordy, brw_barycentric_mode is less
typing and suffers from fewer line wrapping problems.
The enum values themselves don't really benefit from "WM" in the name,
either. Put "BARYCENTRIC" first instead of at the end and drop "WM".
Generated by:
for file in *.c *.cpp *.h; do sed -i \
-e 's/brw_wm_barycentric_interp_mode/brw_barycentric_mode/g' \
-e 's/BRW_WM_\([A-Z_]*\)_BARYCENTRIC/BRW_BARYCENTRIC_\1/g' \
-e 's/BRW_WM_BARYCENTRIC_INTERP_MODE_COUNT/BRW_BARYCENTRIC_MODE_COUNT/g' \
$file;
done
with a few whitespace changes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This consolidates a bunch of hacks in a single place - by setting
the interpolation modes and locations on variables appropriately,
we can simply trust them in the rest of the code. This avoids
having to handle INTERP_QUALIFIER_NONE, gl_Color overrides,
sample-shading overrides, and Gen4-5 centroid-overrides in a bunch
of places.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The only useful thing left was gen6_init_vtable_surface_functions which we
can easily put in brw_wm_surface_state.c.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
THe offset type has special implications that it's intended to be some form
of aligned memory address. These assumptions allow it to handle the case
where there is some alignment requirement on the offset and the bottom bits
are used for other things. However, the offsets in the surface state field
are really just unsigned integers.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chad.versace@intel.com>
The old calculation, which used view->offset, encorporated buffer->offset
into the size calculation where it doesn't belong. This meant that, if
buffer->offset > buffer->size, you would always get a negative size. This
fixes 170 dEQP-VK.renderpass.attachment.* Vulkan CTS tests on Haswell.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
We can totally do it, we were just only setting up one BLEND_STATE and, now
that the code is unified with gen8, we should be handling it correctly.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This renames BLEND_STATE to BLEND_STATE_ENTRY and adds an new struct
BLEND_STATE which is just an array of 8 BLEND_STATE_ENTRYs. This will make
it much easier to write gen-agnostic blend handling code.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
To support general GL_TEXTURE_BASE_LEVEL we have to copy to a temporary
miptree. However, if a single level is being selected, we can use the
existing miptree and force all the sampling to be from that particular
level.
This avoids a ton of software fallbacks in glGenerateMipmaps(), which uses
base levels in the blit implementation in gallium. Improves "glmark2 -b
terrain" from 2 fps to 3 (perhaps some more precision would be useful?),
and cuts its CPU usage during the benchmarking from ~30% to ~10% (total
CPU time from 8.8s to 7.6s).
The compiler uses the per-stage flags already, so it didn't need this.
vc4_uniforms was using it, so just replace it with both of the stage flags
for now.
If numSamples > 0, we can compute the size of the whole mipmapped texture.
That's the case for glTexStorage(GL_PROXY_TEXTURE_x).
Also, multiply the texture size by numSamples for MSAA textures.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
So that the function can work properly with glTexStorage(), where we know
how many mipmap levels there are. And so we can compute storage for MSAA
textures.
Also, remove the obsolete texture border parameter.
A subsequent patch will update _mesa_test_proxy_teximage() to use these
new parameters.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This avoids a failed assert(img->_BaseFormat != -1) in
init_teximage_fields_ms() because the internalFormat argument is GL_NONE.
This was hit when using glTexStorage() to do a proxy texture test.
Fixes a failure with the updated Piglit tex3d-maxsize test.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Fixed the remaining redundant SetRenderTargets command emission.
Tested with lightsMark2008, Heaven, mtt piglit, glretrace, conform.
Reviewed-by: Brian Paul <brianp@vmware.com>
Weak doesn't work the same on PE/COFF as on ELF, they are only weak
references. Specifically, since nothing else pulls in the object which
contains pthread_mutexattr_init() (and coming from the C library, that is
the only thing that object contains), means that it ends up as 0
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Commit 1f4869a2 unconditionally requires pthread-stubs. Unfortunately, the
cleverness that pthread-stubs is doesn't work with PE/COFF, and historically
Cygwin doesn't have a pthread-stubs.pc.
Don't require pthread-stubs on Cygwin.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Cygwin headers are now a bit more correct in handling feature test macros,
so use _GNU_SOURCE when building for Cygwin, as well.
(Notwithstanding f381c27c, we should probably have always been using
_GNU_SOURCE, since asprintf() is used by mesa in places)
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
This reverts commit 091f1da902 .
Although a user may specify a specfic tiling bit, ISL should still
prevent incompatible tiling/surface combinations.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
In the next patch, ISL will unconditionally perform verification of a
surface's tiling and usage. Since it will require that w-tiled images
be stencil buffers, create a stencil surface to copy from a
w-tiled/stencil surface.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
If an internal user creates an image with Vulkan tiling VK_IMAGE_TILING_OPTIMAL
and an ISL tiling that isn't set, ISL will fail to create the image as
anv_image_create_info::isl_tiling_flags will be an invalid value.
Correct this by making anv_image_create_info::isl_tiling_flags an opt-in,
filtering bitmask, that allows the caller to specify which ISL tilings are
acceptable, but not contradictory to the Vulkan tiling.
Opt-out of filtering for vkCreateImage.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Set limits that are consistent with ISL's assertions in
isl_genX(buffer_fill_state_s)() and Anvil's format-DescriptorType
mapping in anv_isl_format_for_descriptor_type().
Fixes the following new crucible tests:
* stress.limits.buffer-update.range.uniform
* stress.limits.buffer-update.range.storage
These tests are in this patch: https://patchwork.freedesktop.org/patch/98726/
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
A ternary is clearer because the range member is assigned one of two values
dependant on one condition.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Section 13.2.3. of the Vulkan spec requires that implementations be able to
bind sparsely-defined Descriptor Sets without any errors or exceptions.
When binding a descriptor set that contains a dynamic buffer binding/descriptor,
the driver attempts to dereference the descriptor's buffer_view field if it is
non-NULL. It currently segfaults on undefined descriptors as this field is never
zero-initialized. Zero undefined descriptors to avoid segfaulting. This
solution was suggested by Jason Ekstrand.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96850
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
in svga_init_shader_key_common(). Since the CSO module only tracks
sampler views for fragment shaders, the number of samplers and sampler
views can be mismatched for other types of shaders. This situation
triggered an assertion in Chrome with maps.google.com
This patch adds defensive code to handle that situation.
Fixes VMware bug 1694027
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
The uninitialized list should be checked and returned.
Thank Julien for the notification and suggested fix.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This is way better than the stupid string approach especially since you
could overflow the string. Again, I thought I had something better at one
point but it obviously got lost.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
It was returning true if the function types have different lengths rather
than false. This was new with the SPIR-V to NIR pass and I thought I'd
fixed it a while ago but it may have gotten lost in rebasing somewhere.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Assign previously hardcoded values for OMX to newly defined
structure. As a result, OMX behaviour will not change at all.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Allow to specify more parameters in the encoding interface
which previously just hardcoded in the encoder
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
If a block might be entered from multiple locations, then the uniform
stream will (probably) be at different points, and we need to make sure
that it's pointing where we expect it to be. The kernel also enforces
that any block reading a uniform resets uniforms, to prevent reading
outside of the uniform stream by using looping.
With control flow, we can't be sure that we'll see the uses of a variable
before its def as we walk backwards. Given that NIR is eliminating our
long chains of dead code, a simple solution for now seems fine.
This slightly changes the order of some optimizations, and so an opt_vpm
happens before opt_dce, causing 3 dead MOVs to be turned into dead FMAXes
in Minecraft:
instructions in affected programs: 52 -> 54 (3.85%)
Previously, we could assume that a MOV from a temp was always an available
copy, because all temps were SSA in NIR, and their non-SSA state in QIR
was just due to the fact that they were from a bcsel or pack_unorm_4x8, so
we could use the current value of the temp after that series of QIR
instructions to define it.
However, this is no longer the case with control flow. Instead, we track
a new array of MOVs defined within the block that haven't had their source
or dest killed yet, and use that primarily. We fall back to looking
through the QIR defs array to handle across-block MOVs, but now require
that copies from the SSA defs have an SSA src as well.
v2 (Matt):
- Use brw_imm_df() as source argument of DIM instruction.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
According to HSW's PRM, vol02b, the DIM instruction has the following
restriction:
"Restriction : src0 must be immediate. src0 must specify the :f (F, Float)
type encoding but is an immediate 64-bit DF (Double Float) value. dst
must have type DF."
This commit allows to upload the immediate 64-bit DF value to the source
of a DIM instruction even when it is of float type encoding.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2 (Matt):
- Take a DF source argument for the DIM instruction emission
in the visitors.
- Indentation.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
When we initially dropped bpb in favor of bs, we accidentally didn't change
this one line properly. This brings it back to what it should be.
Reviewed-by: Chad Versace <chad.versace@intel.com>
A while ago we got rid of the bits-per-block because we thought we didn't
need it. We're about to introduce some very useful 1 and 2-bit formats so
we really should be able to handle them again.
Reviewed-by: Chad Versace <chad.versace@intel.com>
This is based on a very long set of discussions between Chad and myself
about how we should properly represent HiZ and CCS buffers. The end result
of that discussion was that a tiling actually has two different sizes, a
logical size in elements, and a physical size in bytes and rows. This
commit reworks ISL's pitch and size calculations to work in terms of these
two sizes.
Reviewed-by: Chad Versace <chad.versace@intel.com>
We helpfully inserted a PRM quotation about how we need to use
ARRAY_PITCH_SPAN_FULL and then set it to COMPACT. Oops...
Reviewed-by: Chad Versace <chad.versace@intel.com>
The row pitch already specifies the size of a row of elements.
Multiplying by the block height simply causes us to allocate as muc as 12
times more memory than needed for compressed textures.
Reviewed-by: Chad Versace <chad.versace@intel.com>
I have no idea why we were multiplying by 4 before. The offsets we get
from SPIR-V are in bytes and so is nir->num_uniforms so there's no need to
do any adjustment whatsoever.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Not sure if this is the right way to do it, but it seems to work.
v2: make it a no-op on LLVM <= 3.5
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Fix compilation on Cygwin, since 50b22354, by adding c99_alloca.h include,
which should know how to portably make the alloc() prototype available.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Setup for pixel shader push constants is the same as for other
stages. Note that on gen8+ the if-else branches were identical
and the generation check for packet size redundant.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is partial revert of commit cc2d0e64.
It looks that even though blorp disables a stage the corresponding
3DSTATE_CONSTANT_XS packet is needed to be programmed. Hardware
seems to try to fetch the constants even for disabled stages.
Therefore care needs to be taken that the constant buffer is
set up properly. Blorp will continue to trash it into non-existing
such as before.
It is possible that this could be omitted on SKL where the
constant buffer is considered when the corresponding binding table
settings are changed. Bspec:
"The 3DSTATE_CONSTANT_* command is not committed to the shader
unit until the corresponding (same shader)
3DSTATE_BINDING_TABLE_POINTER_* command is parsed."
However, as CONSTANT_XS packet itself does not seem to stall on its
own, it is safer to emit the packets for SKL also.
Possible alternative to blorp trashing could have been to setup
defaults in the beginning of each batch buffer. However, hardware
doesn't seem to tolerate these packets being programmed multiple
times per primitive. Bspec for IVB:
"It is invalid to execute this command more than once between
3D_PRIMITIVE commands."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96878
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Coverity's analysis is too weak to understand that
r600_init_flushed_depth(_, _, NULL) only returns true when
flushed_depth_texture was assigned a non-NULL value.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
So that we can have gen7 split large writes produced by this lowering pass.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
So far we only used instructions with this size in situations where we
did not operate per-channel and we wanted to ignore the execution mask,
but gen7 fp64 will need to emit code with a width of 4 that needs
normal execution masking.
v2:
- Modify the assert instead of deleting it (Curro)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
In fp64 we can produce code like this:
mov(16) vgrf2<2>:UD, vgrf3<2>:UD
That our simd lowering pass would typically split in instructions with a
width of 8, writing to two consecutive registers each. Unfortunately, gen7
hardware has a bug affecting execution masking and as a result, the
second GRF register write won't work properly. Curro verified this:
"The problem is that pre-Gen8 EUs are hardwired to use the QtrCtrl+1
(where QtrCtrl is the 8-bit quarter of the execution mask signals
specified in the instruction control fields) for the second
compressed half of any single-precision instruction (for
double-precision instructions it's hardwired to use NibCtrl+1,
at least on HSW), which means that the EU will apply the wrong
execution controls for the second sequential GRF write if the number
of channels per GRF is not exactly eight in single-precision mode (or
four in double-float mode)."
In practice, this means that we cannot write more than one
consecutive GRF in a single instruction if the number of channels
per GRF is not exactly eight in single-precision mode (or four
in double-float mode).
This patch makes our SIMD lowering pass split this kind of instructions
so that the split versions only write to a single register. In the
example above this means that we split the write in 4 instructions, each
one writing 4 UD elements (width = 4) to a single register.
v2 (Curro):
- Make explicit that the thing about hardwiring NibCtrl+1 for the second
compressed half is known to happen in Haswell and the issue with IVB
might not be exactly the same.
- Assign max_width instead of returning early so that we can handle
multiple restrictions affecting to the same instruction.
- Avoid division by 0 if the instruction does not write any registers.
- Ignore instructions what have WE_all set.
- Use the instruction execution type size instead of the dst type size.
v3 (Curro):
- Move the implementation down so it is not placed in the middle of another
workaround.
- Declare channels_per_grf as const.
- Don't break the loop early if we find a BAD_FILE source.
- Fix the number of channels that the hardware shifts for the second half
of a compressed instruction to be 8 in single precision and 4 in double
precision.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Gen7 hardware does not support double immediates so these need
to be moved in 32-bit chunks to a regular vgrf instead. Instead
of doing this every time we need to create a DF immediate,
create a helper function that does the right thing depending
on the hardware generation.
v2:
- Define setup_imm_df() as an independent function (Curro)
- Create a specific builder to get rid of some instruction field
assignments (Curro).
v3:
- Get devinfo from builder (Kenneth)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, there were occasionally NIR registers in our programs, but
they were always actually used SSA-only. Now that we're trying to support
control flow, we need to actually conditionally move to registers based on
whether channels are active or not.
We're already checking that branch instructions are within the
contents of the shader and the proper PROG_END sequence is present.
The other thing we need in the presence of branching is to verify that
the shader doesn't overflow past the end of the uniforms stream.
To do that, we require that at the start of any basic block reading
uniforms have the following instructions:
load_imm temp, <offset within uniform stream>
add unif_addr, temp, unif
The instructions are generated by userspace, and the kernel verifies
that the load_imm is of the expected offset, and that the add adds it
to a uniform. We track which uniform in the stream that is, and at
draw call time fix up the uniform stream to have the address of the
start of the shader's uniforms for that draw call.
Signed-off-by: Eric Anholt <eric@anholt.net>
This isn't used yet, it's just a first step toward loop validation.
During the main parsing of instructions, we need to know when we hit a new
basic block so that we can reset validated state.
Basically we just treat each block independently. The only inter-block
scheduling I can think of that would be be interesting would be to move
texture result collection to after a short loop/if block that doesn't do
texturing. However, the kernel disallows that as part of its security
validation.
We still decide which uniform to lower based on how many
instructions-that-need-lowering use that uniform, but now we emit a new
temporary uniform load in each of the basic blocks containing an
instruction being lowered.
This commit is best reviewed with diff -b.
We need to apply the peephole pass to each of the blocks in the program.
We don't do dataflow analysis for SF across blocks, but we also don't
generate code that would need us to do so.
The optimization passes and scheduling aren't actually ready for multiple
blocks with control flow yet (as seen by the "cur_block" references in
them instead of iterating over blocks), but this creates the structures
necessary for converting them.
We have the prior list_foreach() all over the code, but I need to move
where instructions live as part of adding support for control flow. Start
by just converting to a helper iterator macro. (The simpler
"qir_for_each_inst()" will be used for the for-each-inst-in-a-block
iterator macro later)
This avoids a bunch of code gen regressions when enabling loops in vc4.
Prior to that, the GLSL that would have generated these optimizable phi
nodes was being lowered to csels between either (undef, a) or (a, a), and
those were being dealt with by nir_opt_undef and nir_opt_algebraic.
The allocation has succeeded by that point, so it needs to be freed.
CovID: 1358929
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was appearing in vc4 VS/CS in mupen64, due to vertex attrib lowering
producing some constants that were getting compared.
total instructions in shared programs: 112276 -> 112198 (-0.07%)
instructions in affected programs: 2239 -> 2161 (-3.48%)
total estimated cycles in shared programs: 283102 -> 283038 (-0.02%)
estimated cycles in affected programs: 2365 -> 2301 (-2.71%)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Small api cleanup. Make all api functions call GetContext instead
of locally casting handle. Makes debugging easier by providing a
single point to track context changes.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
with encode tunneling
The idea of encode tunneling is to use video buffer directly for encoder,
but currently the encoder doesn’t support interlaced surface, the OMX
decoder set progressive surface before on that purpose.
Since now we are polling the driver for interlacing information for
decoder, we got the interlaced as preferred as other APIs(VDPAU, VA-API),
thus breaking the transcode with tunneling.
The solution is when with tunnel detected, re-allocate progressive target
buffers, and then converting the interlaced decoder results to there.
This has been tested with transcode results bit to bit matching as before
with surface from progressive to progressive.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Julien Isorce <j.isorce@samsung.com>
[ Francisco Jerez: Use validate_build_common for error checking,
simplify control flow slightly and handle additional exception
types. ]
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
header_map was the only definition left in compiler.hpp, move it into
program.hpp which is its only user in clover/core.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
[ Serge Martin: Fix inverted opts and log build ctor args.
Keep the log related to the build. Fix indentation ]
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This gets rid of the program::build_* query methods and replaces them
with the program::build() method that returns a single data structure
containing all parameters for the last build done on the given target
device (including build logs, options and the binary itself).
[ Serge Martin: Fix inverted opts and log build ctor args ]
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This partially reverts 7e0180d57d.
Having two different exception subclasses for compilation and linking
makes it more difficult to share or move code between the two
codepaths, because the exact same function under the same error
condition would need to throw one exception or the other depending on
what top-level API is being implemented with it. There is little
benefit anyway because clCompileProgram() and clLinkProgram() can tell
whether they are linking or compiling a program.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Return an API object from an intrusive reference to a Clover object,
incrementing the reference count of the object.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
[ Serge Martin: disable internalize pass when building a library.
Otherwise some functions may be inlined and removed ]
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Split the work previously done by compile_program_llvm() into
compile_program() (which simply runs the front-end and serializes the
resulting LLVM IR) and link_program() (which takes care of everything
else down to binary codegen).
[ Serge Martin: allow LLVM IR dump after compilation ]
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Drop a few include and using directives which are no longer necessary.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This is the common part of the code used to generate a clover::module
from LLVM bitcode, shared between the native and LLVM paths.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This switches compile_native() to the C++ API (which the rest of this
file makes use of anyway so there is little benefit from using the C
API), what should get rid of an amount of boilerplate and fix a leak
of the TargetMachine object in the error path.
v2: Additional fixes for LLVM 3.6.
v3: Update for the latest LLVM SVN changes.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This function was doing three separate things:
- Initializing and releasing the ELF parsing state (the latter can be
better done using RAII).
- Searching for the symbol table in the ELF file.
- Extraction of kernel symbol offsets from the symbol table.
Split each one into a separate function for clarity and clean up the
result slightly.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Some of these will be useful from a different compilation unit in the
same subtree so put them in a publicly accessible header file.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Most significant change is debugging flags are now a scoped enum and
all debugging helpers live in the debug namespace.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Some assorted and mostly trivial clean-ups for the source to bitcode
compilation path.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This allows simplifying the interface of compile_llvm() because it no
longer needs to read out and return the optimization level and address
space map from the compiler instance. Instead declare the compiler
instance at the top level so that both properties are available
directly.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This gets rid of most ifdef's from the invocation.cpp code -- Only a
couple of them are left which will be removed differently in the
following commits.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This ifdef'ed out code was meant to handle compilation into TGSI, but
it doesn't seem likely that it will ever be useful even if the TGSI
back-end is resurrected because the TGSI bitcode can just be plumbed
through in ELF format and dealt with as a regular "native" back-end.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Probably a copy-paste from mesa_meta_pbo_GetTexSubImage where tex_image
may apparently be null.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Even when the backend driver does not support ETC formats, we handle the
decoding into an uncompressed backing texture. However as far as core
mesa is concerned, it's an ETC texture and we should return the relevant
ETC mesa format. This condition can get hit when using glTexStorage to
create the texture object.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
The size of the driver constant buffer for each stage should be 2048
and not 512 because it has been increased recently for buffers/images.
While we are at it, do the same change for indirect draws.
This fixes all ARB_shader_draw_parameters tests on GM107.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
This fixes the following piglits:
arb_arrays_of_arrays-basic-imagestore-mixed-const-non-const-uniform-index
arb_arrays_of_arrays-basic-imagestore-mixed-const-non-const-uniform-index2
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
I have seen a hang during application shutdown that could be explained by the
following race condition which this patch fixes:
1. Worker thread enters util_queue_fence_signal, sets fence->signalled = true.
2. Main thread calls util_queue_job_wait, which returns immediately.
3. Main thread deletes the job and fence structures, leaving garbage behind.
4. Worker thread calls pipe_condvar_broadcast, which gets stuck forever because
it is accessing garbage.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
The blitter sets mask == 1, which is fine since it doesn't use smoothing.
Fixes a regression introduced in commit 5bcfbf91.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
This partially reverts commit d41f5396f3.
That untested commit broke the tex-skipped-unit piglit test and the
arbvparray Mesa demo when run with indirect GLX.
state->array_state is used during initialization, so its assignment cannot be
moved to the end of the function.
The backtrace looked like:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77c7a5c in __glXGetActiveTextureUnit (state=0x6270e0) at indirect_vertex_array.c:1952
1952 return state->array_state->active_texture_unit;
(gdb) bt
0 0x00007ffff77c7a5c in __glXGetActiveTextureUnit (state=0x6270e0) at indirect_vertex_array.c:1952
1 0x00007ffff77cbf62 in get_client_data (gc=0x626f50, cap=34018, data=0x7fffffffd7a0) at single2.c:159
2 0x00007ffff77cce51 in __indirect_glGetIntegerv (val=34018, i=0x7fffffffd830) at single2.c:498
3 0x00007ffff77c4340 in __glXInitVertexArrayState (gc=0x626f50) at indirect_vertex_array.c:193
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
There is no draw arrays protocol support for multi-texture coordinate
arrays, so it is implemented by sending batches of immediate mode
commands from emit_element_none in indirect_vertex_array.c. This sends
the target texture unit (which has been previously setup in the
array_state header field), followed by the texture coordinates. But for
GL_DOUBLE coordinates the texture unit must be sent *after* the texture
coordinates. This is documented in the glx protocol description, and can
also be seen in the indirect.c immediate mode commands generated from
gl_API.xml. Sending the target texture unit in the wrong place can crash
the remote X server.
To fix this required some more extensive changes to
indirect_vertex_array.c and indirect_vertex_array_priv.h, in order to
remove the texture unit value out of the array_state "header" field, and
send it separately.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61907
For each indirect context the indirect vertex array state must be initialised
by __glXInitVertexArrayState in indirect_vertex_array.c. As noted in the
routine header it requires that the glx context has been setup prior to the
call, in order to test the server version and extensions.
Currently __glXInitVertexArrayState is called from indirect_bind_context in
indirect_glx.c, as follows:
state = gc->client_state_private;
if (state->array_state == NULL) {
glGetString(GL_EXTENSIONS);
glGetString(GL_VERSION);
__glXInitVertexArrayState(gc);
}
But, the gc context is not yet usable at this stage, so the server queries
fail, and __glXInitVertexArrayState is called without the server version and
extension information it needs. This breaks multi-texturing as
glXInitVertexArrayState doesn't get GL_MAX_TEXTURE_UNITS. It probably also
breaks setup of other arrays: fog, secondary colour, vertex attributes.
To fix this I have moved the call to __glXInitVertexArrayState to the end of
MakeContextCurrent in glxcurrent.c, where the glx context is usable.
Fixes a regression caused by commit 4fbdde889c. Fixes ARB_vertex_program
usage in the arbvparray Mesa demo when run with indirect GLX and also
the tex-skipped-unit piglit test when run with indirect GLX.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61907
It's actually not very clever to claim to support H.264
and then fail to create a decoder.
v2: prefix FW macro with UVD_.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Fixes the one of the piglit arb_copy_image-targets tests for 1D arrays.
Previously, we were applying the 1D array z/face adjustment twice.
Also simplify the copy_region_vgpu10() function. It never has to copy
multiple array layers/slices. The Mesa code for glCopyImageSubData does
the loop over slices/faces.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Currently when we rebind framebuffer resources at the beginning of
the command buffer, we use the color buffer surfaces saved in the context
hw clear state. But the surfaces could be different from the actual
emitted render target surfaces if any of the color buffer surfaces
is also used for shader resource, in that case, we create
a backed surface for the collided render target surface. So to rebind
the framebuffer resources correctly, use the render target surfaces saved
in the context hw draw state.
Tested with Heaven, Lightsmark2008, MTT piglit, glretrace, conform.
Reviewed-by: Brian Paul <brianp@vmware.com>
With this patch, a guest-backed surface will be invalidated
using the SVGA_3D_CMD_INVALIDATE_GB_SURFACE command before
the surface is reused. This fixes the updating dirty image error
from the device when a surface is reused.
v2: Instead of invalidating the surface when it is reused,
send the invalidate command before the surface is put into
the recycle pool.
v3: (1) surface invalidate is a noop operation in Linux winsys, since
surface invalidation is not needed for DMA path.
(2) Instead of invalidating the surface content in
svga_screen_surface_destroy() when a surface is to be destroyed,
it is done in svga_screen_cache_flush() when the surface is
no longer referenced in a command buffer and is ready to
be moved to the unused list. At this point, the surface will
be moved to the invalidate list. When the surface invalidation
is submitted, the surface will be moved to the unused list.
Tested with piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
If the SVGA3D_DEVCAP_DX_PROVOKING_VERTEX query returns false, never
define rasterizer state objects with provokingVertexLast set. Despite
what the device reports, it may interpret the provokingVertexLast flag
anyway. This fixes an issue when using capability clamping.
Tested with piglit provoking-vertex and glsl-fs-flat-color tests.
VMware bug 1550143.
Reviewed-by: <charmainel@vmware.com>
Since pixel center lies at 0.5, add half_pixel to vtex
before adding offsets to it.
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
We only have to stay single-threaded when debug output must be synchronous.
This yields better parallelism in shader-db runs for me.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Unlike SC, the small primitive filter does not automatically use center
locations in 1xAA mode, so this is needed to avoid artifacts caused by
the small primitive filter discarding triangles that it shouldn't.
As a side effect of how the effective number of samples is now calculated,
this patch also avoids submitting the sample locations for line/poly smoothing
when they're not really needed.
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
GL_OES_texture_float_linear marks R32F, RG32F, RGB32F, and RGBA32F
as texture filterable.
Fixes glGenerateMipmap GL errors when visiting a WebGL demo in Chromium:
http://www.iamnop.com/particles
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This hardware race condition has caused problems several times already
(see "i965: Fix cache pollution race during L3 partitioning set-up.",
"i965: Fix brw_render_cache_set_check_flush's PIPE_CONTROLs." and
"i965: intel_texture_barrier reimplemented"). The problem is that
whenever we attempt to both flush and invalidate multiple caches with
a single pipe control command the flush and invalidation happen in
reverse order, so the contents flushed from the R/W caches aren't
guaranteed to become visible from the invalidated caches after the
PIPE_CONTROL command completes execution if some concurrent rendering
workload happened to pollute any of the invalidated R/O caches in the
short window of time between the invalidation and flush.
This makes sure that brw_emit_pipe_control_flush() has the effect
expected by most callers of making the contents flushed from any R/W
caches visible from the invalidated R/O caches.
Cc: "12.0 11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Review carefully, it sucks to have to keep track of the number of
command packet dwords emitted in the batch epilogue manually. The
MI_REPORT_PERF_COUNT_BATCH_DWORDS calculation was obviously wrong.
Cc: "12.0 11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
There were two places in the driver doing a pipe control VF cache
flush, one of them was missing this workaround, move it down into
brw_emit_pipe_control_flush to make sure we don't miss it again.
Cc: "12.0 11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Shouldn't cause any functional changes at this point, but we have
forgotten to apply this workaround several times in the past, make
sure it doesn't happen again.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Fixes a regression induced by commit a0674ce5c4:
When EGL_TEXTURE_FORMAT and EGL_TEXTURE_TARGET were both specified (and
both != EGL_NO_TEXTURE), an error was instantly triggered, before the
other one had even a chance to be checked, which is obviously not the
intended behaviour.
v2: Full commit hash, remove useless variables.
v3: [chadv] Add Fixes footers.
Fixes: piglit "spec/egl 1.4/eglcreatepbuffersurface and then glclear"
Fixes: piglit "spec/egl 1.4/largest possible eglcreatepbuffersurface and then glclear"
Signed-off-by: Guillaume Charifi <guillaume.charifi@sfr.fr>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Remove the two first level `if` as they will always be true, and
flatten the two remaining `if`.
No functional change.
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
There are a few places in the code where clearing and reading are done on
incorrect buffers for GLES contexts. See comments for details. This
fixes 75 GLES3 dEQP tests on the surfaceless platform with no regressions.
v2: Corrected unclear comment
v3: Make the change in context.c instead of get.c
v4: Removed whitespace
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Since the function is exported like any other
public api function and put in the header
as if you could link against it, export it also
from shared objects.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
These workarounds are not required for HSW and above so stop
copying them at VS key generation which is called at draw time.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were storing arrays in vectors, which was leading to some really bad
spill code for large arrays. allocas instructions are a better fit for
arrays and LLVM optimizations are more geared toward dealing with
allocas instead of vectors.
For arrays that have 16 or less 32-bit elements, we will continue to use
vectors, because this will force LLVM to store them in registers and
use indirect registers, which is usually faster for small arrays.
In the future we should use allocas for all arrays and teach LLVM
how to store allocas in registers.
This fixes the piglit test:
spec/glsl-1.50/execution/geometry/max-input-component
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Atm the actual rule will expand to foo.o which is used for static
libraries only.
Thus the automake manual recommendation [to use OBJEXT] won't help us,
since since we're working with a shared library.
Thus let's 'demote' the file and add it back to BUILT_SOURCES. This will
manage all the complexity for us, at the (existing expense) of working
only with the all, check and install targets.
The crazy (why the issue was hard to spot):
If the dependencies (.deps/*.Plo) are already created one can alter the
anv_device.$(OBJEXT) line and/or nuke it all together. That won't lead
to any warnings/issues, even though the Makefile is regenerated.
Moral of the story:
Always rm -rf top_builddir or don't resolve the dependencies manually
and use BUILT_SOURCES.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96825
Fixes: d7a604c3f7a ("anv: use cache uuid based on the build timestamp.")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Tested-by: Mark Janes <mark.a.janes@intel.com>
In bc4e0c4 (vbo: Use a bitmask to track the active arrays in vbo_exec*.)
we stopped looping over all the attributes and resetting all slots.
Which exposed an issue in vbo_exec_bind_arrays() for handling GENERIC0
vs. POS.
Split out a helper which can reset a particular slot, so that
vbo_exec_bind_arrays() can re-use it to reset POS.
This fixes an issue with 0ad (and possibly others).
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Before, it would happily copy list_head next/prev (ie. pointer to the
*from* list_head), leaving things in a confused state and causing much
mayhem.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Be more consistent with the other u_inlines util_copy_xyz_state()
helpers and support NULL src.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
If a depth/stencil texture has no mipmaps, we can always get a layout that is
compatible with DB and TC.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This fixes a rare bug with stencil texturing -- seen on Polaris and Tonga,
though it's basically a function of the memory configuration so could affect
other parts as well.
Fixes piglit "unaligned-blit * stencil downsample" and various
"fbo-depth-array *stencil*" tests.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Note that this has no effect yet. A case where can_sample_z/s can be false
in radeonsi will be added in a later patch.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is a left-over of when I considered generalizing the separate stencil
support. I do prefer the new name since it emphasizes what flushing vs.
non-flushing means from a functional point-of-view, namely special handling
of the texture format.
v2: adjust r600_init_color_surface as well
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Height should be aligned with 2 macroblocks, thus making safer
for tiled mode
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
It has proven subtle to get it right both from the build side POV (see
commit list below) and builders due to their varying workflows.
Furthermore it does not fully fulfil the reason why it was enforced -
to detect uniqueness between different builds, in order to distinguish
and invalidate Vulkan/GL caches.
With that having a much better solution (previous commit) we can drop
this solution.
This effectively reverts the following commits:
359d9dfec3 ("mesa: automake: add directory prefix for git_sha1.h")
2c424e00c3 ("mesa: automake: ensure that git_sha1.h.tmp has the right
attributes")
b7f7ec7843 ("mesa: automake: distclean git_sha1.h when building OOT")
8229fe68b5 ("automake: get in-tree `make distclean' working again.")
Cc: Timo Aaltonen <tjaalton@debian.org>
Cc: Haixia Shi <hshi@chromium.org>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Do not rely on the git sha1:
- its current truncated form makes it less unique
- it does not attribute for local (Vulkand or otherwise) changes
Use a timestamp produced at the time of build. It's perfectly unique,
unless someone explicitly thinkers with their system clock. Even then
chances of producing the exact same one are very small, if not zero.
v2: Remove .tmp rule. Its not needed since we want for the header to be
regenerated on each time we call make (Eric).
v3:
- Honour SOURCE_DATE_EPOCH, to make the build reproducible (Michel)
- Replace the generated header with a define, to prevent needless
builds on consecutive `make' and/or `make install' calls. (Dave)
v4:
- Keep the timestamp generation at make time. (Jason)
v5:
- Ensure that file is regenerated on incremental builds.
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Dave Airlie <airlied@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This just stops counting and assigning a storage location for
these uniforms, the count is only used to create the uniform storage.
These uniform types don't use this storage.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Code was inspired from _mesa_update_shader_textures_used
However unlike _mesa_update_shader_textures_used that only check for a single
stage, it will check all stages.
It avoids to loop on all uniforms, only active samplers are checked.
For my use case: high FS frequency switches with few samplers.
Perf event (relative to nouveau_dri.so) goes from 5.01% to 1.68% for
the _mesa_sampler_uniforms_pipeline_are_valid function.
Signed-off-by: Gregory Hainaut <gregory.hainaut@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This reverts commit 27d456cc87.
DOH, what seems right and what is right with fp64 are always
two different things.
This regressed:
spec@arb_gpu_shader_fp64@shader_storage@layout-std140-fp64-mixed-shader
on radeonsi
Reported-by: Michel Dänzer <michel@daenzer.net>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
While we are at it, fix a typo inside the comment which describes
what those constants are for.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
In presence of an indirect image access, the base offset should be
zeroed because the stride will be computed twice. This is a pretty
rare situation but it can happen when tex.r > 0.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
When emitting OP_SUB, the sign bit for FADD and FADD32I is not
at the same position. It's at position 45 for FADD but 51 for FADD32I.
This fixes the following piglit test:
tests/spec/arb_fragment_program/fdo30337b.shader_test
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: <mesa-stable@lists.freedesktop.org>
ALU0 didn't have the _dest variant, and ALU2 didn't unset the def the way
ALU1 did. This should make the ALU[012] macros much clearer, by moving
most of their contents to vc4_qir.c
Now that we're about to start generating control flow in our NIR, we want
this in place. It optimizes things frequently in the CS, when the GL VS
has control flow that doesn't affect the vertex position.
Tiny change on shader-db currently, but it will be important when we start
emitting a lot of SFs from the same variable as part of control flow
support.
total instructions in shared programs: 89463 -> 89430 (-0.04%)
instructions in affected programs: 1522 -> 1489 (-2.17%)
total estimated cycles in shared programs: 250060 -> 250015 (-0.02%)
estimated cycles in affected programs: 8568 -> 8523 (-0.53%)
The DCE pass is going to change significantly to handle control flow,
while we don't really need to change it for the SF handling. We also need
to add some more SF peephole optimization for SF updates generated by
control flow support.
No change on shader-db.
I'm going to add an optimization for redundant SF update removal, which
will just remove the SF and leave us (in many cases) with an instruction
with a NULL destination and no side effects. Rather than teaching that
pass whether the whole instruction can be removed, leave that
responsibility to this pass.
We need to not DCE them even though they don't have a destination in QIR.
We also shouldn't relocate them in vc4_opt_vpm. Neither of these things
happen, but I'm about to make DCE consider instructions with a NULL
destination.
Noticed by code inspection. This hasn't been too big of a deal, because
our cond usages all start out as adder ops, either MOVs or the FTOI for Z
writes. MOVs *can* get converted to mul ops during scheduling, but
apparently we hadn't hit this.
Main shader parts and geometry shaders are compiled asynchronously
by util_queue. si_create_shader_selector doesn't wait and returns.
si_draw_vbo(si_shader_select) waits for completion.
This has the best effect when shaders are compiled at app-loading time.
It doesn't help much for shaders compiled on demand, even though
VS+PS compilation should take as much as time as the bigger one of the two.
If an app creates more shaders, at most 4 threads will be used to compile
them.
Debug output disables this for shader stats to be printed in the correct
order.
(We could go even further and build variants asynchronously too, then emit
draw calls without waiting and emit incomplete shader states, then force IB
chaining to give the compiler more time, then sync the compilation at the IB
flush and patch the IB with correct shader states. This is great for
compilation before draw calls, but there are some difficulties such as
scratch and tess states requiring the compiler output, and an on-disk shader
cache will likely be a much better and simpler solution.)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
to allow multiple shaders to be compiled simultaneously.
ALso, shader-db can again use all 4 cores.
v2: Remove the pipe_mutex_unlock call in the error path.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
The function interface is ready to be used by util_queue.
Also, si_shader_select_with_key can no longer accept si_context.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This will be needed after some LLVM changes that haven't landed yet.
v2: - use LLVMIsConstant to fix an LLVM assertion failure.
LLVMSetMetadata doesn't work with constants.
- don't set float metadata as string
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Handle the bc_optimize SGPR bit if both CENTER and CENTROID are enabled.
This should increase the PS launch rate for big primitives with MSAA.
Based on discussion with SPI guys.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This should increase the PS launch rate for shaders using at least 2 pairs
of perspective (i,j) and same for linear.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This makes it possible to skip urb re-configuration if the
subsequent renders agree with the settings.
Also allows blorp to allocate the maximun amount of vs entries
available. Core upload logic already knows how to calculate this.
Helps one synthetic benchmark.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Packet 3DSTATE_CONSTANT_PS is still emitted explicitly as ps stage
itself is enabled and hardware may try to prefetch constants from
the buffer. From the BSpec: 3D Pipeline - Windower -
3DSTATE_PUSH_CONSTANT_ALLOC_PS
"Specifies the size of the PS constant buffer. This value will
determine the amount of data the command stream can pre-fetch
before the buffer is full."
This is not possible on gen6. From the BSpec about 3DSTATE_CONSTANT_PS:
"This packet must be followed by WM_STATE."
Binding table emissions for stages other than PS can be now dropped,
they were only needed for the 3DSTATE_CONSTANT_XS to be effective:
From the BSpec:
"The 3DSTATE_CONSTANT_* command is not committed to the shader unit
until the corresponding (same shader) 3DSTATE_BINDING_TABLE_POINTER_*
command is parsed."
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
In preparation for loading as flat vertex input.
v2: Use LOAD_INPUT() macro
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
In addition, as these are never used in parallel, add a few
assertions.
v2 (Jason): Skip some complexity by putting them into a union but
pad rectangle grid into a vec4 instead. Also keep the
LOAD_UNIFORM macro.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The image usage specified by the caller of vkCreateSwapchainKHR should be
passed onto the internal image creation. Otherwise the driver might later
crash when the user tries to use the image as a combined sampler even though
the creation was explicitly created with VK_IMAGE_USAGE_TRANSFER_SRC_BIT.
Leaving the previous VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT as this might be
expected even if the swapchain is created without any flag.
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=96791
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
On gen >= 8 one doesn't provide ending address but number of bytes
available. This is relative to the given offset.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Devices with smaller GMEM size need more tiles. On db410c at 2048x1152,
glmark2 shadow needed ~330 tiles for fullscreen. Lets bump it up to
512. (Maybe with MRT you could end up needing more, but at that point
things are probably going to be painfully slow.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
Some games are sloppy.. perhaps because it is defined behavior for DX or
perhaps because nv blob driver defaults things to zero.
So add driconf param to force uninitialized variables to default to zero.
This issue was observed with rust, from steam store. But has surfaced
elsewhere in the past.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For .vert/.frag, now multiple can be specified on the cmdline for
purposes of linking, and the last one specified is the one that is
fed into the ir3 backend (and dumped along the way if --verbose is
specified)
Without this, varyings in frag shaders would appear as undefined.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Rather than doing a separate submit at context create, move these cmds
to before first tile, as is done on a3xx/a4xx. Otherwise state can
be overwritten by other contexts.
Signed-off-by: Rob Clark <robdclark@gmail.com>
gcc6 does not like the trick where we point to one entry before the
array start and then start a while with a pre-increment.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
These are all new false positives with gcc6.
In nouveau_compiler.c: gcc6 no longer assumes that passing a pointer
to a variable into a function initialises that variable.
In nv50_ir_from_tgsi.cpp op and mode are not set if there are 0
enabled dst channels, this never happens, but gcc cannot know this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
In order to implement get_work_dim() the driver may need to know the
clEnqueueNDRangeKernel() work_dim parameter, so pass it to the driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Add a new WORK_DIM SV type, this is will return the grid dimensions
(1-4) for compute (opencl) kernels.
This is necessary to implement the opencl get_work_dim() function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
For the case (both src or dst) where we had a texobject, but the
texobject target was not the same that the method target, this spec
paragraph was appplied:
/* Section 18.3.2 (Copying Between Images) of the OpenGL 4.5 Core
* Profile spec says:
*
* "An INVALID_VALUE error is generated if either name does not
* correspond to a valid renderbuffer or texture object according
* to the corresponding target parameter."
*/
But for that case, the correct spec paragraph should be:
/* Section 18.3.2 (Copying Between Images) of the OpenGL 4.5 Core
* Profile spec says:
*
* "An INVALID_ENUM error is generated if either target is
* not RENDERBUFFER or a valid non-proxy texture target;
* is TEXTURE_BUFFER or one of the cubemap face selectors
* described in table 8.18; or if the target does not
* match the type of the object."
*/
specifically the last sentence: "or if the target does not match the
type of the object".
This patch fixes the error returned (s/INVALID/ENUM) for that case,
and moves up the INVALID_VALUE spec paragraph, as that case (invalid
texture object) was handled before.
Fixes:
GL44-CTS.copy_image.target_miss_match
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Immediates are stored into a separate table, and are
consolidated, so if we get an immediate we don't need
to offset it as the index it has is correct.
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Basically we just have to scale up the coordinates and then add the
relevant sample offset. The code to handle this was already largely
present from Christoph's earlier attempts to pipe images through back in
the dark ages, this just hooks it all up.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Fixes a regression introduced by commit 42624ea83 which triggered
an assertion in
dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0
While stImage must have a non-zero size as verified by the caller, we also
look at the size of the base image in an attempt to make a better guess at
the level0 size (this is important when the base image size is odd). However,
the base image may have a zero size even when it exists.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96629
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
use bicubic filtering as high quality scaling L1.
v2: fix a typo and add a newline to code
v3: -render the unscaled image on a temporary surface (Christian)
-apply noise reduction and sharpness filter on
unscaled surface
-render the final scaled surface using bicubic
interpolation
v4: support high quality scaling
v5: set dst_area and dst_clip in bicubic filter
v6: set buffer layer before setting dst_area
v6.1: add PIPE_BIND_LINEAR when creating resource
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This is a shader based bicubic interpolater which uses cubic
Hermite spline algorithm.
v2: set dst_area and dst_clip during scaling (Christian)
v3: clear the render target before rendering
v4: intialize offsets while initializing shaders
use a constant buffer to send dst_size to frag shader
small changes to reduce calculation in shader
v5: send half pixel offset instead of sending dst_size
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Fix this build error with GCC 4.4.
CC state_tracker/st_nir_lower_builtin.lo
In file included from state_tracker/st_nir_lower_builtin.c:61:
state_tracker/st_nir.h:34: error: redefinition of typedef ‘nir_shader’
../../src/compiler/nir/nir.h:1830: note: previous declaration of ‘nir_shader’ was here
Suggested-by: Rob Clark <robdclark@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96235
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
silent, flush, incomplete_tex and incomplete_fbo flags were not
documented (see src/mesa/main.debug.c for more info).
FP is not checked anymore.
v2 (Brian Paul):
* MESA_DEBUG accepts a comma-separated list of parameters.
* Clarify how MESA_DEBUG behaves with mesa debug and release builds.
* Updated wording.
v3: Better wording for one paragraph (Brian Paul)
Reviewed-by: Brian Paul <brianp@vmware.com>
Fixes:
GL44-CTS.texture_barrier_ARB.same-texel-rw-multipass
On Haswell, Broadwell and Skylake (note that in order to execute that
test, it is needed to override GL and GLSL versions).
On gen6 this test was already working without this change. It keeps
working after it.
This commit replaces the call to brw_emit_mi_flush for gen6+ with two
calls to brw_emit_pipe_control_flush:
* The first one with RENDER_TARGET_FLUSH and CS_STALL set to initiate
a render cache flush after any concurrent rendering completes and
cause the CS to stop parsing commands until the render cache
becomes coherent with memory.
* The second one have TEXTURE_CACHE_INVALIDATE set (and no CS stall)
to clean up any stale data from the sampler caches before rendering
continues.
Didn't touch gen4-5, basically because I don't have a way to test
them.
More info on commits:
0aa4f99f5672473658c5
Thanks to Curro to help to tracking this down, as the root case was a
hw race condition.
v2: use two calls to pipe_control_flush instead of a combination of
gen7_emit_cs_stall_flush and brw_emit_mi_flush calls (Curro)
v3: no need to const cache invalidation (Curro)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The output of draw requires a null viewport transform, which the regular
code is ill-equiped to do. Reinstate the original settings in the render
path, and add setting of the viewport clip polygon based on fb
width/height (as that is all taken care of by draw).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This aligns the 4-element color float array to 16 byte boundaries. This
should allow compiler vectorizers to generate better optimizations.
Also fixes broken vectorization generated by Intel compiler.
v2: Fixed indentation and added a lengthy comment explaining the
reason for the alignment.
Cc: <mesa-stable@lists.freedesktop.org>
Reported-by: Tim Rowley <timothy.o.rowley@intel.com>
Tested-by: Tim Rowley <timothy.o.rowley@intel.com>
Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Encapsulate the test for which flags are needed to get a compiler to
support certain features. Along with this, give various options to try
for AVX and AVX2 support. Ideally we want to use specific instruction
set feature flags, like -mavx2 for instance instead of -march=haswell,
but the flags required for certain compilers are different. This
allows, for AVX2 for instance, GCC to use -mavx2 -mfma -mbmi2 -mf16c
while the Intel compiler which doesn't support those flags can fall
back to using -march=core-avx2.
This addresses a bug where the Intel compiler will silently ignore the
AVX2 instruction feature flags and then potentially fail to build.
v2: Pass preprocessor-check argument as true-state instead of
false-state for clarity.
v3: Reduce AVX2 define test to just __AVX2__. Additional defines suchas
__FMA__, __BMI2__, and __F16C__ appear to be inconsistently defined
w.r.t thier availability.
v4: Fix C++11 flags being added globally and add more logic to
swr_require_cxx_feature_flags
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
Tested-by: Tim Rowley <timothy.o.rowley@Intel.com>
Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com>
The linker deals with atomic counters in terms of uniforms but the
data structure are called after the atomic counters.
Renamed the data structures used in the linker for disambiguation.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Currently the linker uses the uniform count for the total number of
atomic counters. However uniforms don't include the innermost array
dimension in their count, but atomic counters are expected to include
them.
Although the spec doesn't directly state this, it's clear how offsets
will be assigned for arrays.
From OpenGL 4.2 (Core Profile), page 98:
" * Arrays of type atomic_uint are stored in memory by element
order, with array element member zero at the lowest offset. The
difference in offsets between each pair of elements in the
array in basic machine units is referred to as the array
stride, and is constant across the entire array. The stride can
be queried by calling GetIntegerv with a pname of
ATOMIC_COUNTER_- ARRAY_STRIDE after a program is linked."
From that it is clear how arrays of atomic counters will interact with
GL_MAX_ATOMIC_COUNTER_BUFFER_SIZE.
For other kinds of uniforms it's also clear that each entry in an
array counts against the relevant limits.
Hence, although inferred, this is the expected behavior.
Fixes GL44-CTS.arrays_of_arrays_gl.AtomicDeclaration
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
So that we do copies host-side rather than in the guest with map/memcpy.
Tested with piglit arb_copy_buffer-subdata-sync test and new
arb_copy_buffer-intra-buffer-copy test.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
With host-side buffer copies (via SVGA3D_vgpu10_BufferCopy()) we have
to make sure any pending map-write operations are completed before reading
if the buffer is dirty. Otherwise the ReadbackSubResource operation could
get stale data from the host buffer.
This allows the piglit arb_copy_buffer-subdata-sync test to pass when
we start using the SVGA3D_vgpu10_BufferCopy command.
v2: check the sbuf->dirty flag in the outer conditional, per Charmaine.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We previously could do blits with util_resource_copy_region() when doing
'loose' format checking. Also do blits with util_resource_copy_region()
when the blit src/dst formats (not the underlying resources) exactly
match. Needed for GL_ARB_copy_image.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
v2: remove extra svga_define_texture_level() call, per Charmaine.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Do texture->texture copies host-side with this command when possible.
Use the previous software fallback otherwise.
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We don't normally support rendering to SNORM surfaces, but with
GL_ARB_copy_image we can copy to them if we treat them as typeless
and use a UNORM surface view.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We previously handled the case of a RGBX sampler view of a RGBA surface.
Add the reverse case too. For GL_ARB_copy_image.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
For GL_ARB_copy_image we may be asked to create an RGBA view of
a RGBX surface. Use an RGBX view format for that case.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We want to be able to copy between different 32-bit, 3-channel surface
formats for GL_ARB_copy_image but since we don't support R32G32B32_FLOAT
for textures (it's not blendable and wouldn't work for render to texture)
we can't support 32-bit, 3-channel integer formats.
The state tracker will choose 4-channel formats instead.
Fixes the piglit arb_copy_image-format test for several cases.
Note: This change may need to be revisited if/when the texture_view exension
is enabled in driver.
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
This allows us to do copies between different, but compatible, surface
formats such as RGBA8_UNORM, RGBA8_SINT, RGBA8_UINT, etc. for
GL_ARB_copy_image.
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Since only the src box can have negative dims for flipping, just
comparing the src/dst box sizes is enough to detect flips.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Pulled out of the util_try_blit_via_copy_region() function. Subsequent
changes build on this.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
SVGA_3D_CMD_DX_GENRATE_MIPMAP & SVGA_3D_CMD_DX_SET_PREDICATION commands
are not presents in fedora 24 kernel module. Because of this
reason application like supertuxkart are not running.
v2: Add few comments and code modifications suggested by Brian P.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Set when the stw_dev object's initialization is completed. We test
for this in the window callback function to avoid potential crashes
on start-up in multi-threaded applications.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Split the old stw_framebuffer_reference() function into two new
functions: stw_framebuffer_reference_locked() which increments
the refcount and stw_framebuffer_release_locked() which decrements
the refcount and destroys the buffer when the count hits zero.
Original patch by Jose. Modified by Brian (clean-ups, lock assertion
checks, etc).
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Otherwise we were leaking DC GDI objects and if wglBindTexImageARB()
was called enough we'd eventually hit the GDI limit of 10,000 objects.
Things started failing at that point.
v2: also release DC if we return early, per Charmaine.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This reverts commit 644e015f0b.
PrimitiveMode from the program doesn't always hold a valid value that
is neither of GL_TRIANGLES, GL_QUADS nor GL_ISOLINES when reaching
this code. This caused regressions in the following CTS tests:
GL44-CTS.stencil_texturing.functional
GL44-CTS.shading_language_420pack.binding_images
GL44-CTS.shading_language_420pack.binding_samplers
GL44-CTS.shading_language_420pack.binding_uniform_single_block
GL44-CTS.shading_language_420pack.implicit_conversions
GL44-CTS.shading_language_420pack.initializer_list
GL44-CTS.shading_language_420pack.length_of_vector_and_matrix
GL44-CTS.shading_language_420pack.line_continuation
Hence, we rather take it from the linked shader.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
There are two distinctly different uses of this struct. The first
is to store GL shader objects. The second is to store information
about a shader stage thats been linked.
The two uses actually share few fields and there is clearly confusion
about their use. For example the linked shaders map one to one with
a program so can simply be destroyed along with the program. However
previously we were calling reference counting on the linked shaders.
We were also creating linked shaders with a name even though it
is always 0 and called the driver version of the _mesa_new_shader()
function unnecessarily for GL shader objects.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
_mesa_write_shader_to_file() is only used to print gl shader objects
so Program should never be set as it only gets set for linked shaders.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
This will allow us to split gl_shader into two different structs, one for
shader objects and one for linked shaders.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Rather than passing in gl_shader we now pass in the IR. This will
allow us to later split gl_shader into two structs. One for use
as a linked per stage shader struct and one for use as a GL shader
object.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Khronos recommends that the GLES 3.1 library also be called libGLESv2.
It also requires that functions be statically linkable from that
library.
NOTE: Mesa has supported the EGL_KHR_get_all_proc_addresses extension
since at least Mesa 10.5, so applications targeting Linux should use
eglGetProcAddress to avoid problems running binaries on systems with
older, non-GLES 3.1 libGLESv2 libraries.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Cc: Mike Gorchak <mike.gorchak.qnx@gmail.com>
Reported-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
Acked-by: Chad Versace <chad.versace@intel.com>
This is unusual. Usually IDs listed on early stages of platform
definition are kept there as reserved for later use.
However these IDs here are not listed anymore in any of steppings
and devices IDs tables for Kabylake on configurations overview
section of BSpec.
So it is better removing them before they become used in any
other future platform.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
DRI3:
- Only slows clears can enable it for the first frame.
- A good PS/draw ratio can enable it for other frames.
DRI2:
- Only slows clears can enable it for a frame.
- Page-flipped color buffers are unref'd at the end of each frame,
so it can't be enabled in any other way.
- Relying on slow clears is sufficient for our synthetic benchmarks.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
DCC for displayable surfaces is allocated in a separate buffer and is
enabled or disabled based on PS invocations from 2 frames ago (to let
queries go idle) and the number of slow clears from the current frame.
At least an equivalent of 5 fullscreen draws or slow clears must be done
to enable DCC. (PS invocations / (width * height) + num_slow_clears >= 5)
Pipeline statistic queries are always active if a color buffer that can
have separate DCC is bound, even if separate DCC is disabled. That means
the window color buffer is always monitored and DCC is enabled only when
the situation is right.
The tracking of per-texture queries in r600_common_context is quite ugly,
but I don't see a better way.
The first fast clear always enables DCC. DCC decompression can disable it.
A later fast clear can enable it again. Enable/disable typically happens
only once per frame.
The impact is expected to be negligible because games usually don't have
a high level of overdraw. DCC usually activates when too much blending
is happening (smoke rendering) or when testing glClear performance and
CMASK isn't supported (Stoney).
v2: rename stuff, add assertions
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Replace some open-coded ioctls with intel_get_param().
This is just a cleanup. No change in behavior.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Replace the function's __DRIscreen parameter with struct intel_screen.
The callsites feel more natural that way.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
AA lines are not completely correct (see TODO), but everything else
should be.
+ 3 linestipple piglits
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Commit 87d062a940 ("i965: Fix shared local memory size for Gen9+.")
added u_math.h include which broke the Android build:
In file included from external/mesa3d/src/intel/isl/isl_storage_image.c:25:
In file included from external/mesa3d/src/mesa/drivers/dri/i965/brw_compiler.h:29:
external/mesa3d/src/mesa/main/macros.h:35:10: fatal error: 'util/u_math.h' file not found
^
Add the missing include paths for libmesa_isl.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Kenneth Garunke <kenneth@whitecape.org>
With commit fb9fe35, we start using transfer_inline_write
for memcpy of TexSubImage. But SurfaceDMA command does not work
well with texture array. This patch forces direct map when
transfering multiple slices of a texture array.
Fixes piglit regression "texelFetch fs sampler1DArray"
Tested with MTT piglit, glretrace, conform.
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Rely on the existence of a second destination when emitting a setcond
flag is dangerous, because this doesn't mean that the flag has been
correctly set. Instead rely on flagsDef like what emitX() does
for flagsSrc.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: <mesa-stable@lists.freedesktop.org>
Remove 'reg' option that does not actually exist, elaborate more about
'sync' and add the missing options.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The call for vl_video_buffer_adjust_size is with wrong order of
arguments, apparently it will have problem when interlaced false;
The size of OMX result buffer depends on real size of clips, vl buffer
dimension is aligned with 16, so 1080p(1920*1080) video will overflow
the OMX buffer
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Julien Isorce <j.isorce@samsung.com>
Make pipe_loader_sw_probe_kms take ownership of the passed in fd,
like pipe_loader_drm_probe_fd does.
The only caller is dri_kms_init_screen which passes in a dupped fd,
just like dri2_init_screen passes in a dupped fd to
pipe_loader_drm_probe_fd.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This file still only has my name on the copyright notice even though
most of the code (likely more than 90% of it) was authored by various
contributors -- It doesn't seem right to have the whole file
attributed to myself.
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Serge Martin <edb+mesa@sigluy.net>
This was useful when debugging the previous commit's issue.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
emit_urb_writes() contains code to emit an EOT write with no actual
data when there are no output varyings. This makes sense for the VS
and TES stages, where it's called once at the end of the program.
However, in the geometry shader stage, emit_urb_writes() is called once
for every EmitVertex(). We explicitly emit a URB write with EOT set at
the end of the shader, separately from this path. So we'd better not
terminate the thread. This could get us into trouble for shaders which
do EmitVertex() with no varyings followed by SSBO/image/atomic writes.
It also caused us to emit multiple sends with EOT set, which apparently
confuses the register allocator into not using g112-g127 for all but
the first one. This caused EU validation failures in OglGSCloth
shaders in shader-db. (The actual application was fine, but shader-db
thinks there are no outputs because it doesn't understand transform
feedback.)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The only part of an ir_texture which can be an array is the
offsets array in textureGatherOffsets() calls. We don't want
to lower those, because they're required to remain constants.
Fixes textureGatherOffsets with Gallium drivers such as llvmpipe,
which commit ef78df8d3b regressed.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
These need to be passed from the host in caps structure if they
are larger, this fixes a bunch of tests on Intel hw, that I'd
put the limits too high for.
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Call to handle_table_get in vlVaDestroySurfaces can
return NULL on failure.
CID: 1243522
Signed-off-by: Gurkirpal Singh <gurkirpal204@gmail.com>
Reviewed-by: Julien Isorce <j.isorce@samsung.com>
The intent was to continue down the indirect chain, not to call ourselves
with unchanged input arguments. Found by code inspection, and comparison
to copy_prop_alu_src().
We haven't hit this because callers of NIR's copy prop are doing so in
SSA, before indirect variable dereferences have been lowered to registers.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
On at least Kepler hardware, the units differ based on RT format. Emit a
properly scaled value for Z16 depth buffers vs other formats, to help
out st/nine.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
It defaults to true so default behavior doesn't change but it allows you to
do NIR_VALIDATE=false if you don't want validation. Disabling validation
can substantially speed up shader compiles so you frequently want to turn
it off if compiler invariants aren't in question.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
offset_units_unscaled enables proper support
for depth bias for gallium nine. Use it
if available.
Solves issues with some games using depth bias.
For example:
https://github.com/iXit/Mesa-3D/issues/220
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Empirical tests show that the polygon offset
behaviour is entirely determined by the content of
the PA_SU_POLY_OFFSET states, and not by the depth buffer
format bound.
PA_SU_POLY_OFFSET seems to directly set the parameters of
the polygon offset formula, and setting 0 for
PA_SU_POLY_OFFSET_DB_FMT_CNTL (ie setting the unorm depth
bias behaviour with a scale of 2^0 = 1.0f) gives the unscaled
behaviour.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Empirical tests show that the polygon offset
behaviour is entirely determined by the content of
the PA_SU_POLY_OFFSET states, and not by the depth buffer
format bound.
PA_SU_POLY_OFFSET seems to directly set the parameters of
the polygon offset formula, and setting 0 for
PA_SU_POLY_OFFSET_DB_FMT_CNTL (ie setting the unorm depth
bias behaviour with a scale of 2^0 = 1.0f) gives the unscaled
behaviour.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
pa_su_poly_offset_db_fmt_cntl usages were removed in
previous patches.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Emit PA_SU_POLY_OFFSET_DB_FMT_CNTL with the other poly_offset states.
This will be useful to implement
PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED.
v2: Increase the num_dw field for the poly offset atom
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Emit PA_SU_POLY_OFFSET_DB_FMT_CNTL with the other poly_offset states.
This will be useful to implement
PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED.
v2: Increase the num_dw field for the poly offset atom
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Emit PA_SU_POLY_OFFSET_DB_FMT_CNTL with rasterizer poly_offset states.
This will be useful to implement
PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
D3D9 has a different behaviour for depth bias.
For OGL/D3D1X, the depth bias unit is the
minimal resolvable value for the depth buffer,
which depends on the format (and has different
behaviour for float depth buffers).
For D3D9, the depth bias unit is 1.0f.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We recently had a mistake where we emitted SEND instructions with EOT
set, but from g107 rather than g112-g127. Adding validation code should
prevent these sorts of problems from slipping back in.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These only exist post-Sandybridge, and always use send-from-GRF.
So inst->base_mrf will be -1, and we will have already returned 0.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
On MRF platforms, we need to set base_mrf to the first MRF value we'd
like to use for the message. On send-from-GRF platforms, we set it to
-1 to indicate that the operation doesn't use MRFs.
As MRF platforms are becoming increasingly a thing of the past, we've
forgotten to bother with this. It makes more sense to set it to -1 by
default, so we don't have to think about it for new code.
I searched the code for every instance of 'mlen =' in brw_fs*cpp, and
it appears that all MRF-based messages correctly program a base_mrf.
Forgetting to set base_mrf = -1 can confuse the register allocator,
causing it to think we have a large fake-MRF region. This ends up
moving the send-with-EOT registers earlier, sometimes even out of
the g112-g127 range, which is illegal. For example, this fixes
illegal sends in Piglit's arb_gpu_shader_fp64-layout-std430-fp64-shader,
which had SSBO messages with mlen > 0 but base_mrf == 0.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The old return type of GLuint was wonky - it should have been bool.
But nothing actually uses the return value anyway, so we can just drop
that and make it a void function.
In theory, it might make sense to ask whether the texture validated
successfully, but just checking intel_obj->mt != NULL works for that.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
brw_tex.c is a tiny file containing a single function. It's closely
tied to the validation logic in intel_tex_validate.c, so it makes sense
to put both in the same file.
While we're at it, update the function to our modern style.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Under some circumstances, the driver may choose to return a temporary
surface instead of a pointer to the original. Make sure to pass the
actual view volume to be mapped to the transfer function rather than
adjusting the map pointer after-the-fact.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
- make sure FP32 denormals will stay disabled in LLVM in the future
(the current default is disabled)
- tell LLVM that FP64 denormals are enabled
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
v2: Merge with PIPE_SHADER_CAP_DOUBLES
Add CHIP_HEMLOCK
v3: only set the instruction on EG and CM
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Checking "signalled" is first done without a mutex, then with a mutex.
Also, checking without waiting doesn't lock the mutex. This is racy, but
should be safe.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Will be needed for resolving auxiliary surfaces.
I didn't add anv_render_pass_attachment::stencil_store_op, as the driver
would likely never use it, as stencil surfaces never have auxiliary
surfaces.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Clean up misrepetitions ('if if', 'the the' etc) found throughout the
comments. This has been done manually, after grepping
case-insensitively for duplicate if, is, the, then, do, for, an,
plus a few other typos corrected in fly-by
v2:
* proper commit message and non-joke title;
* replace two 'as is' followed by 'is' to 'as-is'.
v3:
* 'a integer' => 'an integer' and similar (originally spotted by
Jason Ekstrand, I fixed a few other similar ones while at it)
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
We currently use CL_INVOCATION_COUNT for the GL_PRIMITIVES_GENERATED
query, which involves passing all primitives to the clipper. When
rasterizer discard is enabled, we program the clipper in REJECT_ALL
mode, rather than using the SOL stage's "Rendering Disable" feature.
See commit f09b91f782 for an explanation
of why we implement GL_PRIMITIVES_GENERATED this way.
Apparently the SOL stage's "Rendering Disable" feature is a lot faster
than having the clipper reject all primitives. It's safe to use when
no GL_PRIMITIVES_GENERATED query is active, as we don't care about
CL_INVOCATION_COUNT incrementing.
This patch makes us use SO_RENDERING_DISABLE when no query is active,
but continues falling back to the clipper in REJECT_ALL mode when the
queries are enabled. It brings back the perf_debug for the clipper
case (which I removed in commit 1f9445ff57, thinking it wasn't useful).
Improves performance in Gl32GSCloth by 84.8303% +/- 2.07132% (n = 10)
on my Broadwell GT2 laptop.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Constant propagation on arrays doesn't make a lot of sense. If the
array is only accessed with constant indexes, then opt_array_splitting
would split it up. Otherwise, we have variable indexing. If there's
multiple accesses, then constant propagation would end up replicating
the data.
The lower_const_arrays_to_uniforms pass creates uniforms for each
ir_constant with array type that it encounters. This means that it
creates redundant uniforms for each copy of the constant, which means
uploading too much data. It can even mean exceeding the maximum number
of uniform components, causing link failures.
We could try and teach the pass to de-duplicate the data by hashing
constants, but it makes more sense to avoid duplicating it in the first
place. We should promote constant arrays to uniforms, then propagate
the uniform access.
Fixes the TressFX shaders from Tomb Raider, which exceeded the maximum
number of uniform components by a huge margin and failed to link.
On Broadwell:
total instructions in shared programs: 9067702 -> 9068202 (0.01%)
instructions in affected programs: 10335 -> 10835 (4.84%)
helped: 10 (Hoard, Shadow of Mordor, Amnesia: The Dark Descent)
HURT: 20 (Natural Selection 2)
loops in affected programs: 4 -> 0
The hurt programs appear to no longer have a constarray uniform, as
all constants were successfully propagated. Apparently before this
patch, we successfully unrolled a loop containing array access, but
only after promoting constant arrays to uniforms. With this patch,
we unroll it first, so all array access is direct, and the array
is split up, and individual constants are propagated. This seems
better.
Cc: mesa-stable@lists.freedesktop.org
Reported-by: Karol Herbst <nouveau@karolherbst.de>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
There's really no point in looking at ir_dereference_array of a
constant. It also misses cases like:
(assign () (var_ref tmp) (constant (array ...) ...))
No changes in shader-db, but keeps it working after the next commit.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The scalar backend currently doesn't support variable indexing on
temporary arrays, but it does support it on uniform arrays, and
some stages support it for input arrays. Make sure these are
propagated through before exploding indirects into piles of
if-ladders unnecessarily.
On Broadwell, no instruction count change in shader-db.
total cycles in shared programs: 80675652 -> 80674928 (-0.00%)
cycles in affected programs: 649972 -> 649248 (-0.11%)
helped: 386
HURT: 165
This will help avoid code quality regressions in a future commit.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Previously, we failed to split constant arrays. Code such as
int[2] numbers = int[](1, 2);
would generates a whole-array assignment:
(assign () (var_ref numbers)
(constant (array int 4) (constant int 1) (constant int 2)))
opt_array_splitting generally tried to visit ir_dereference_array nodes,
and avoid recursing into the inner ir_dereference_variable. So if it
ever saw a ir_dereference_variable, it assumed this was a whole-array
read and bailed. However, in the above case, there's no array deref,
and we can totally handle it - we just have to "unroll" the assignment,
creating assignments for each element.
This was mitigated by the fact that we constant propagate whole arrays,
so a dereference of a single component would usually get the desired
single value anyway. However, I plan to stop doing that shortly;
early experiments with disabling constant propagation of arrays
revealed this shortcoming.
This patch causes some arrays in Gl32GSCloth's geometry shaders to be
split, which allows other optimizations to eliminate unused GS inputs.
The VS then doesn't have to write them, which eliminates the entire VS
(5 -> 2 instructions). It still renders correctly.
No other change in shader-db.
v2: Drop !AOA check and improve a comment (feedback from Tim Arceri).
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
opt_constant_propagation.cpp contains constant folding code which can
actually do constant propagation in some cases. It was happily
propagating constants into the left-hand-side of assignments.
For example,
(assign () (var_ref temp) (constant ...))
would brilliantly be turned into:
(assign () (constant ...) (constant ....))
This is a bigger hammer than necessary - it prevents propagation
into the left-hand-side altogether. We could certainly do better
someday. Notably, the constant propagation pass itself already
takes this approach - it's just the constant propagation pass's
built-in constant folding code (which actually propagates, too)
that was broken.
No change in shader-db, but prevents regressions after future commits.
It seems plausible that this could be hit today, but I haven't seen it
happen.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Without vertex elements originating directly from vertex fetcher
are not passed to wm-state correctly.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Never be dependent on "draw 0", instead have a bool that makes the draw
dependent on the previous draw or not dependent at all.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Handle SGV stores separate from the stream fetch code.
Because of this change, there is a potential to jit an extra unused store.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Was trying to store an extra uninitialized component.
Only affects component packing, which isn't enabled (yet).
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Earlier MSVC 2013 releases have troubles compiling some of our C99 code,
so make sure we have Update 4 to avoid confusion.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
With commit fb9fe35, we start using transfer_inline_write
for memcpy TexSubImage path, but that triggers a regression with
texture array in the svga driver.
With this patch, the direct map code will update the texture array
correctly.
Fixes VMware bug 1679293.
Tested with MTT piglit, glretrace, conform.
Reviewed-by: Brian Paul <brianp@vmware.com>
Currently with the SetVertexBuffers optimization, we avoid emitting
redundant DXSetVertexBuffers commands. However, these buffers surfaces
will still need to be referenced, otherwise, in the case of linux,
the subsequent surface discard map will map to the existing mob instead
of a new one, causing rendering artifacts.
With this patch, we'll call resource_rebind() to reference the resources
even if we are avoiding the actual set command. This fixes the
rendering artifacts in the window title area running with unity in
Ubuntu 14.04
Tested with piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
This patch fixes three issues with vertex buffer references:
(1) Instead of copy the vertex buffer resource handles to the hw state
in the context structure, use pipe_resource_reference to properly
reference the vertex buffer resources in the context.
(2) Make sure to unbind those unused vertex buffer resources.
(3) Force to rebind the vertex buffer resources at the first draw of each
command buffer to make sure the vertex buffer resources are paged in.
Reviewed-by: Brian Paul <brianp@vmware.com>
Instead of copy the index buffer resource handle to the hw state in
the context structure, use pipe_resource_reference to properly reference
the index buffer resource in the context.
Reviewed-by: Brian Paul <brianp@vmware.com>
We already store these in gl_shader and gl_program here we
remove it from gl_shader_program and just use the values
from gl_shader.
This will allow us to keep the shader cache restore code as
simple as it can be while making it somewhat clearer where these
values originate from.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
We already store this in gl_shader and gl_program here we
remove it from gl_shader_program and just use the values
from gl_shader.
This will allow us to keep the shader cache restore code as
simple as it can be while making it somewhat clearer where these
values originate from.
V2: remove unnecessary NULL check
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Iago Toral <itoral@igalia.com>
This solves a race condition where we can end up having different stages
stomp on each other because they're all trying to scratch in the same BO
but they have different views of its layout.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
While we're here, we also fixup MEDIA_VFE_STATE and rename the field in
3DSTATE_VS on gen6-7.5 to be consistent with the others.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
The pack header generation scripts can't handle the case where you have
two addresses in the same dword; they just take whatever is the last one.
This meant that the MCS address wasn't properly getting handled. Since we
don't care about append counters, we can just re-arrange the XML for now.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
ISL was being a bit too clever for its own good and lowering the format for
us. This is all well and good *if* we always want to lower it. However,
the GL driver selectively lowers the format depending on whether the
surface is write-only or not.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This field is ignored by the hardware in this case and, on very large 1-D
textures, it can end up being larger than the maximum allowed value.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This matches better what happens on gen8 where the "Tiled Surface" and
"Tile Walke" bits are combined into a single two-bit value. This is also
more consistent with what the GL driver does.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
For depth/stencil 1-D textures on SKL, we want them layed out in the old
format that has been used since gen4. In order for the surface state
fill-out code to handle, this it needs to distinguish based on layout
rather than just dimensionality.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
The docs specify that this only matters for render targets and surfaces
used with typed dataport messages. On some platforms (gen4-6) the Depth
field has more bits than RenderTargetViewExtent so we can have textures
with more levels than we can render to.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
According to the PRM, you can't set SurfaceArray for 3D or buffer textures.
There doesn't seem to be a good reason not to set it when we can. On the
other hand, if we don't set it we can end up getting strange results for
1-layer array textures such as textureSize() returning the wrong results.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
We already set the bit in the few cases where it's required by the docs so
there's no need to set it all the time. This has no noticable perf impact
for Dota 2 on Vulkan with the time demo I have.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This commit switches clear colors to use #if's instead of a C if. This
lets us properly handle SNB where the clear color field doesn't exist.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This moves the #if's around so that halign and valign have different sets
of #if conditions. This also prepares us for SNB because isl_to_gen_halign
is not defined at all on gen6.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
While designated initializers are nice, they also force us to put some
things in the initializer and some things later. Surface state setup is
complicated enough that this really hurts readability in the long run.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Otherwise, we end up with a bogus value in the third component. On gen6-7
where we always use 2D textures, this can cause problems if the
SurfaceArray bit is set in the SURFACE_STATE.
Acked-by: Chad Versace <chad.versace@intel.com>
There's no real reason why we shouldn't set this bit. It does affect how
the sampler operates a bit but since you can have a 2D non-array view of a
2D_ARRAY texture that distinction is very weak. Also, this is what ISL
will do and we would like this change to be isolated from using ISL.
Reviewed-by: Chad Versace <chad.versace@intel.com>
The PRM states that the values put in Width, Height, and Depth should be
various bits from the value size - 1. We seem to have done this wrong
more-or-less from the start.
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: "11.1 11.2 12.0" <mesa-stable@lists.freedesktop.org>
Previously, we were incrementing length but not actually putting anything
in the Y coordinate. This meant that 1-D TXF operations had a garbage
array index. If the surface is emitted as 1-D non-array, the coordinate
gets discarded and it works fine. If it happens to be bound as an array
surface, it may count as an out-of-bounds array access and you get zero.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "11.1 11.2 12.0" <mesa-stable@lists.freedesktop.org>
The RenderTargetViewExtent field of RENDER_SURFACE_STATE is supposed to be
set to the depth of a 3-D texture when rendering. Unfortunatley, that
field is only 9 bits on Sandy Bridge and prior so we can't actually bind
a 3-D texturing for rendering if it has depth > 512. On Ivy Bridge, this
field was bumpped to 11 bits so we can go all the way up to 2048. On Iron
Lake and prior, we don't support layered rendering and we use OffsetX/Y
hacks to render to particular layers so 2048 is ok there too.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "11.1 11.2 12.0" <mesa-stable@lists.freedesktop.org>
Our previous code worked for desktop GL, and ES without geometry or
tessellation shaders. But those features require fancier point size
handling. Fortunately, we can use one rule for all APIs.
Fixes a number of dEQP tests with EXT_tessellation_shader enabled:
dEQP-GLES31.functional.tessellation_geometry_interaction.point_size.*
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This avoids costly address recomputations, function overhead, and may trigger
large copy optimizations.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
There's special logic around finding gl_FragData. It latches onto any
array with FRAG_RESULT_DATA0. However gl_SecondaryFragDataEXT[], added
by GL_EXT_blend_func_extended, fits those parameters as well. The real
frag data array should have index 0 though, so we can use that to
distinguish them.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96617
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.1 11.2 12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Ever since c2581a9375, the binding table layout has depended on the
pipeline. This means that whenever we change pipelines we also need to
re-emit binding tables for the new layout.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
SPIR-V treats it as an input but NIR wants the system value. This
shouldn't have been too much of a surprise given that we have to do the
same conversion in the GLSL IR to NIR pass.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This reduces time spend in glGenerateMipmap by a half.
v2: don't decompress the levels to be overwritten
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
for pipe_context::generate_mipmap
first move some of the blit code from util_blitter_blit_generic
to a separate function, then use it from util_blitter_generate_mipmap
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Whenever a draw happens or some other function call might change the result
of future glReadPixels calls, we must invalidate the cache.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
As far as I can tell, a sequence of glBitmap followed by texture functions
that refer to a texture bound as the framebuffer is well within what should
be allowed.
Found by inspection.
Cc: 11.2 12.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
In the unlikely case that a program uses glBitmap to render to a framebuffer
whose texture is bound in a compute shader.
Found by inspection.
Cc: 11.2 12.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is more consistent with what we do elsewhere and will allow
us to only cache one of the values in the shader cache.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cherryview and Broxton don't support DW x DW multiplication. We have
piles of code to handle this, but apparently weren't retyping in the
immediate case.
For example,
tests/spec/arb_tessellation_shader/execution/dvec3-vs-tcs-tes
makes the simulator angry about instructions such as:
mul(8) r18<1>:D r10.0<8;8,1>:D 0x00000003:D
Just retype to W or UW. It should be safe on all platforms.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95462
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Just setting builder->exact isn't sufficient because that only applies to
instructions that are built with the builder but instructions created
manually and only inserted using the builder are left alone.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This pass is similar to propagate_invariance in the GLSL compiler. The
real "output" of this pass is that any algebraic operations which are
eventually consumed by an invariant variable get marked as "exact".
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
While mathematically correct, these two optimizations result in an
expression with substantially lower precision than the original. For any
positive finite floating-point value, log2(x) is well-defined and finite.
More precisely, it is in the range [-150, 150] so any sum of logarithms
log2(a) + log2(b) is also well-defined and finite as long as a and b are
both positive and finite. However, if a and b are either very small or
very large, their product may get flushed to infinity or zero causing
log2(a * b) to be nowhere close to log2(a) + log2(b).
This imprecision was causing incorrect rendering in Talos Principal because
part of its HDR rendering process involves doing 8 texture operations,
clamping the result to [0, 65000], taking a dot-product with a constant,
and then taking the log2. This is done 6 or 8 times and summed to produce
the final result which is written to a red texture. In cases where you
have a region of the screen that is very dark, it can end up getting a
result value of -inf which is not what is intended.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96425
Cc: "11.1 11.2 12.0" <mesa-stable@lists.freedesktop.org>
Apparently, these are deprecated. There's some AutoUpgrade feature which
is supposed to promote these to cmp/select, which apparently doesn't work
with jit code. It is possible it's not actually even meant to work (see
the bug filed against llvm which couldn't provide an answer neither)
but in any case this is meant to be only temporary unless the intrinsics
are really illegal. So, just use the fallback code (which should be cmp/select,
we're actually doing cmp/sext/trunc/select, but in any case llvm 3.9 manages
to optimize this back to pmin/pmax in the end).
This addresses https://llvm.org/bugs/show_bug.cgi?id=28176
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Tested-by: Vinson Lee <vlee@freedesktop.org>
Tested-by: Aaron Watry <awatry@gmail.com>
This makes the check match up what we do on nv50 as well - there's no
point in switching over the push path if everything's in managed
buffers. This can happen when a shader uses a vertex without an enabled
array - we end up passing it a constant attribute.
This also has the effect of "fixing" some flickering in Talos. I have no
idea why. I've stared at the push logic forwards, backwards, and
sideways. By always forcing the push path (which is slow), the
flickering also goes away, but other rendering is still wrong
(specifically draw 383068 as identified in the bug). However by not
switching over to the push path, draw 383068 is correct.
Note that other flickering remains in Talos, like the red/green
walls/floors. This takes care of the shadow flickering though.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90513
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
If we have a loop, instructions before the tex might be added as tex
uses, and those may in fact dominate all other uses of the tex results.
This however doesn't mean that we don't need a texbar after the tex.
Only check if uses dominate each other they are dominated by the tex.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96565
Fixes: 7752bbc44 (gk104/ir: simplify and fool-proof texbar algorithm)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Make sure to pass the requisite information in draws, blits, and clears
that work on the context's draw buffer.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This says how many window rectangles are supported by the
implementation, although it may not exceed PIPE_MAX_WINDOW_RECTANGLES.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Window rectangles apply to all framebuffer operations, either in
inclusive or exclusive mode. They may also be specified as part of a
blit operation.
In exclusive mode, any fragment inside any of the specified rectangles
will be discarded.
In inclusive mode, any fragment outside every rectangle will be
discarded.
The no-op state is to have 0 rectangles in exclusive mode.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This is pretty useful for debugging purposes and those should
not be omitted.
Fixes: 517a93b3 ("nvc0: add ARB_shader_draw_parameters support")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
A pipe pointer in the screen allows for access to current device context
in flush_frontbuffer and resource_destroy. This wasn't tracking current
context in multi-context situations.
v2: More caffeine. Corrected compare, removed unnecessary set of
screen-pipe in create_context, and added a few comments.
To match what's done in the automake build.
v2: Use git rev-parse to get a 10-character hash ID
Fix Python imports
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
From the Cherryview's PRM, Volume 7, 3D Media GPGPU Engine, Register Region
Restrictions, page 844:
"When source or destination datatype is 64b or operation is integer DWord
multiply, indirect addressing must not be used."
v2:
- Fix it for Broxton too.
v3:
- Simplify code by using subscript() and not creating a new num_components
variable (Kenneth).
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95462
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
From the Cherryview PRM, Volume 7, 3D Media GPGPU Engine,
Register Region Restrictions:
"When source or destination is 64b (...), regioning in Align1
must follow these rules:
1. Source and destination horizontal stride must be aligned to
the same qword.
(...)"
v2:
- Fix it for Broxton too.
v3:
- Remove inst->regs_written change as it is not necessary (Ken)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95462
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I recently experimented with performing rasterizer discard in the SOL
unit instead of the clipper, and as far as I can tell, it's basically
the same performance. The clipper comes directly after SOL anyway,
and setting the clipper to REJECT_ALL should be pretty darn cheap.
Keep the perf_debug on Sandybridge, where the GS actually does work.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
There are almost no tests in any test suite, but what little I've found
seems to work. Ilia believes everything is in place.
v2: Predicate the enable on ES 3.1 being available (Gen8+) and also
ARB_compute_shader being available (requested by Ilia).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The use of a bitmask makes functions iterating only active
attributes less visible in profiles.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
The use of a bitmask makes functions iterating only active
attributes less visible in profiles.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
The bitmask used here for iteration is a combination
of different enabled masks present for texture units.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces an iterate and test bit in a bitmask loop by a
loop only iterating over the bits set in the bitmask.
The bitmask used here for iteration is a combination
of different enabled masks present for texture units.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces a loop that iterates all lights and test
which of them is enabled by a loop only iterating over
the bits set in the enabled bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces a loop that iterates all lights and test
which of them is enabled by a loop only iterating over
the bits set in the enabled bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces loops that iterate all lights and test
which of them is enabled by a loop only iterating over
the bits set in the enabled bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces a loop that iterates all lights and test
which of them is enabled by a loop only iterating over
the bits set in the enabled bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Replaces loops that iterate all lights and test
which of them is enabled by a loop only iterating over
the bits set in the enabled bitmask.
v2: Use _mesa_bit_scan{,64} instead of open coding.
v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
The aim is to replace the CoordReplace array by
a bitfield. Until all drivers are converted,
establish the bitfield in parallel to the
CoordReplace array.
v2: Fix bitmask logic.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Instead use the internal gl_shader_stage enum everywhere. This
makes things more consistent and gets rid of unnecessary
conversions.
Ideally it would be nice to remove the Type field from gl_shader
altogether but currently it is used to differentiate between
gl_shader and gl_shader_program in the ShaderObjects hash table.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If the log file specified by the GALLIUM_LOG_FILE begins with '+', open
the file in append mode. This is useful to log all gallium output for
an entire piglit run, for example.
v2: put GALLIUM_LOG_FILE support inside an #ifdef DEBUG block.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
anv_pipeline_binding::index is a uint8_t, but some code assigned to it
UINT16_MAX.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewd-by: Jason Ekstrand <jason@jlekstrand.net>
The expected stride calculation is completely wrong. It should
ultimately be multiplying cpp and width rather than dividing. The width
also needs to be aligned to the tiling width first before converting to
stride bytes.
The whole stride check here is possibly pointless. Any buffers which
were allocated outside of vc4 may have strides with larger alignment
requirements.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We still need to recompile the passthrough shader when this value
changes, as it also affects the output vertex count. But otherwise,
we can eliminate recompiles on Gen8+.
We probably want to do this for Gen7 as well, but that requires
rewriting the input release code to use a loop, which is a trade-off
I'd need to consider in more detail.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Cc: mesa-stable@lists.freedesktop.org
Fixes three GL44-CTS.tessellation_shader subtests:
- max_patch_vertices
- single.max_patch_vertices
- tessellation_control_to_tessellation_evaluation.gl_PatchVerticesIn
These use gl_PatchVerticesIn in the TES, but don't link against a
TCS (which would allow the linker to lower it to a constant). We had
no handling for the system value in the backend, so it would just
assert fail.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Cc: mesa-stable@lists.freedesktop.org
i965 has no special hardware for this, so we need to pass this value in
as a uniform (unless the TES is linked against a TCS, in which case the
linker can just replace this with a constant).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Cc: mesa-stable@lists.freedesktop.org
Found by -fsanitize=undefined. Note that this should be a harmless issue in
practice because the inst->op check always dominates anyway.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
type_size_vec4_times_4() was introduced as a fix in 8dcf807cb4
however since 3810c1561 we can just use type_size_scalar() and
get the actual number of outputs we need.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We've had some trouble in the past with copying integers around via
float pointers, as the C compiler sometimes uses x87 floating point
registers to load values on 32-bit systems. Passing the
gl_constant_value union should be safer.
To avoid churn, this patch creates a "GLfloat *value" variable so
existing uses can stay the same.
Not observed to fix anything, but I was in the area adding more integer
state vars, and thought it'd be wise.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: mesa-stable@lists.freedesktop.org
We could also do MSAA resolve in a compute shader like Vulkan and remove
these workarounds.
v2: comment the magic numbers
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This change enables the creation of pbuffer
surfaces on the surfaceless platform.
v3: Going back to single-buffered pbuffer
plus additional code review changes
Reviewed-by: Chad Versace <chad.versace@intel.com>
The previous assertions required for texture sizes smaller than block_size
that src_box.x + src_box.width still be block size.
(e.g. for a texture with width 3, and src_box.x = 0, src_box.width would
have to be 4 to not assert.)
This caused some assertions with some other state tracker.
It looks though like callers aren't expected to round up widths to block sizes
(for sizes larger than block size the assertion would still have verified it
wouldn't have been rounded up) so we simply shouldn't use a minify which
rounds up to block size.
(No piglit change with llvmpipe.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The gallium contract would be that bind flags must indicate all possible
bindings a resource might get used, but fact is the mesa state tracker does
not set bind flags correctly, and this is more or less unfixable due to GL.
This caused a bug with piglit arb_uniform_buffer_object-rendering-dsa
since 6e6fd911da - the commit is correct,
but it caused us to miss updates to fs UBOs completely, since the
corresponding buffer didn't have the appropriate bind flag set (thus we
wouldn't check if it is indeed currently bound).
See the discussion about this starting here:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/119829.html
So, update the bind flags when we detect such usage.
Note we update this value for now only in places which matter for us - that
is creating sampler/surface view, or binding constant buffer. There's plenty
more places (setting streamout buffers, vertex/index buffers, ...) where
things can be set with the wrong bind flags, but the bind flags there never
matter.
While here also make sure we only set dirty constant bit when it's a fs
constant buffer - totally doesn't matter if it's vs/gs.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Possibly this should move into an fd2 wrapper fxn, similar to the
texture state tracking done for fd3/fd4 (clamp emulation, etc)
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The images struct is an uninitialized local variable on the stack. If the
callback returns 0, the struct might not have been updated and so should
be considered uninitialized. Currently the code ignores the return value,
which (depending on stack contents) might end up in reading a non-zero
value from images.image_mask and dereferencing further fields.
Another solution would be to initialize image_mask with 0, but checking
the return value seems more sensible and it is what Gallium is doing.
v2: fix typos in commit message,
fix indentation,
remove unnecessary parentheses and pointer dereference to keep line
length reasonable.
Cc: 11.2 12.0 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This makes sure that dri_set_tex_buffer2 -> dri_drawable_validate_att
will re-create the front left attachment buffer after the drawable got
invalidated.
Fixes window contents not updating until the window is resized when
using DRI2 PRIME.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Built-in variable "MaxCombinedShaderStorageBlocks" was added to GLSL 4.40
revision 9.
Section "1.2.1 Changes since revision 8 of GLSL version 4.40",
page 3 of the PDF states:
"Bug 11734: Add gl_MaxCombinedShaderOutputResources and mark
gl_MaxCombinedImageUnitsAndFragmentOutputs as deprecated."
Fixes: GL44-CTS.shader_image_load_store.basic-glsl-const
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In order to do zero-copy between two different devices
the memory should not be tiled.
Tested with GStreamer on a laptop that has 2 GPUs:
1- gstvaapidecode:
HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
2- glimagesink:
EGLImage imports dmabuf on Intel GPU.
TEST: DRI_PRIME=1 gst-launch vaapidecodebin ! glimagesink
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This replaces the current bash generator with a python based generator
using mako. It's quite fast and works with both python 2.7 and python
3.5, and should work with 3.3+ and maybe even 3.2.
It produces an almost identical file except for a minor layout changes,
and the addition of a "generated file, do not edit" warning.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The functions are also useful for mesa.
Introduce src/util/bitscan.{h,c}. Move ffs function
implementations from src/mesa/main/imports.{h,c}.
Move bit scan related functions from
src/gallium/auxiliary/util/u_math.h. Merge platform
handling with what is available from within mesa.
v2: Try to fix MSVC compile.
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Avoid ASan new-delete-type-mismatch when Function::domTree is created as
DominatorTree in Function::convertToSSA but destroyed only as base
Graph in ~Function.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Pulling DF uniforms from pull constant buffer generates messages like:
send(4) g12<1>DF g12<0,1,0>F
sampler ld SIMD4x2 Surface = 1 Sampler = 0 mlen 1 rlen 1
which produces GPU hangs in Cherryview/Braswell:
"For 64-bit Align1 operation or multiplication of dwords in CHV,
source horizontal stride must be aligned to qword."
This seems to be documented in the Cherryview PRM, Volume 7, Page 843:
"When source or destination datatype is 64b or operation is integer
DWord multiply, regioning in Align1 must follow these rules:
1. Source and Destination horizontal stride must be aligned to the
same qword."
We should set the destination type to UD, D, or F so that
the register stride checker doesn't notice. The destination type of
send messages is basically irrelevant anyway.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95462
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Pulling DF inputs from the URB generates messages like:
send(8) g23<1>DF g1<8,8,1>UD
urb 3 SIMD8 read mlen 1 rlen 2 { align1 1Q };
which makes the simulator angry:
"For 64-bit Align1 operation or multiplication of dwords in CHV,
source horizontal stride must be aligned to qword."
This seems to be documented in the Cherryview PRM, Volume 7, Page 823:
"When source or destination datatype is 64b or operation is integer
DWord multiply, regioning in Align1 must follow these rules:
1. Source and Destination horizontal stride must be aligned to the
same qword."
Setting the source horizontal stride to QWord is insane, as it's the
message header containing 8 URB handles in a single 32-bit DWord.
Instead, we should whack the destination type to UD, D, or F so that
the register stride checker doesn't notice. The destination type of
send messages is basically irrelevant anyway.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95462
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cherryview/Broxton annoyingly have a minimum number of VS URB entries
of 34, which is not a multiple of 8. When the VS size is less than 9,
the number of VS entries has to be a multiple of 8.
Notably, BLORP programmed the minimum number of VS URB entries (34), with
a size of 1 (less than 9), which is invalid.
It seemed like this could be a problem in the regular URB code as well,
so I went ahead and updated that to be safe.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Change MESA into Mesa in CL_PLATFORM_VERSION and CL_DEVICE_VERSION. For
both, always append git version suffix from git_sha1.h.
v5: move semicolon to same line as MESA_GIT_SHA1.
v4: drop #ifdef guards.
v3: add missing include.
v2: change CL_DEVICE_VERSION as well.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
ISTR having suggested this during review of the recent FP64 changes to
the SIMD lowering pass, but it doesn't look like it was taken into
account in the end. Using the fs_reg::component_size helper instead
of this open-coded variant makes sure that the stride is taken into
account correctly. Fixes at least the following piglit tests with
spilling forced on (since otherwise regs_written would be calculated
incorrectly and the spilling code would be rather confused about how
much data needs to be spilled):
spec.arb_gpu_shader_fp64.shader_storage.layout-std140-fp64-shader
spec.arb_gpu_shader_fp64.shader_storage.layout-std140-fp64-mixed-shader
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
I haven't found any mention of this in the hardware docs, but
experimentally what seems to be going on is that when the per-thread
scratch slot size is changed between two pipelined draw calls, shader
invocations using the old and new scratch size setting may end up
being executed in parallel, causing their scratch offset calculations
to be based in a different partitioning of the scratch space, which
can cause their thread-local scratch space to overlap leading to
cross-thread scratch corruption.
I've been experimenting with alternative workarounds, like emitting a
PIPE_CONTROL with DC flush and CS stall between draw (or dispatch
compute) calls using different per-thread scratch allocation settings,
or avoiding reuse of the scratch BO if the per-thread scratch
allocation doesn't exactly match the original. Both seem to be as
effective as this workaround, but they have potential performance
implications, while this should be basically for free.
Fixes over 40 failures in our CI system with spilling forced on
(including CTS, dEQP and Piglit failures) on a number of different
platforms from Gen4 to Gen9. The 'glsl-max-varyings' piglit test
seems to be able to reproduce this bug consistently in the vertex
shader on at least Gen4, Gen8 and Gen9 with spilling forced on.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will be used to find out what per-thread slot size a previously
allocated scratch BO was used with in order to fix a hardware race
condition without introducing additional stalls or memory allocations.
Instead of calling brw_get_scratch_bo() manually from the various
codegen functions, call a new helper function that keeps track of the
per-thread scratch size and conditionally allocates a larger scratch
BO.
v2: Handle BO allocation manually instead of relying on
brw_get_scratch_bo (Ken).
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The bitwise arithmetic trick used in brw_get_scratch_size() to clamp
the scratch allocation to 1KB has the unintended side effect that it
will cause us to allocate 2x the required amount of scratch space if
the original per-thread scratch size happened to be already a power of
two. Instead use the obvious MAX2 idiom to clamp the scratch
allocation to the expected range.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Two dEQP tests expect INVALID_VALUE errors for negative width/height
parameters, but get INVALID_OPERATION because they haven't actually
created a destination image. This is arguably not a bug in Mesa, as
there's no specified ordering of error conditions.
However, it's also really easy to make the tests pass, and there's
no real harm in doing these checks earlier.
Fixes:
dEQP-GLES3.functional.negative_api.texture.texsubimage3d_neg_width_height
dEQP-GLES31.functional.debug.negative_coverage.get_error.texture.texsubimage3d_neg_width_height
v2: Drop redundant check (caught by Anuj Phogat).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
To cope with copies of compressed images which are not multiples of
the block size. Suggested by Jose.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@sroland@vmware.com>
In the Vulkan driver, we have the generation number (a compile time
constant) but not necessarily the brw_device_info struct. I meant
to rework the function to take a generation number instead of a
brw_device_info pointer to accomodate this. But I forgot, and left
it taking a brw_device_info pointer, while making Vulkan pass the
generation number (8, 9, ...) directly. This led to crashes.
Brown paper bag fix for commit 87d062a940.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96504
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Add guards to prevent dereferencing NULL dynamic pipeline state. Asserts
of pCreateInfo members are moved to the earliest points at which they
should not be NULL.
This fixes a segfault seen in the McNopper demo, VKTS_Example09.
v3 (Jason Ekstrand):
- Fix disabled rasterization check
- Revert opaque detection of color attachment usage
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
To reduce confusion, clarify that the state being copied is not dynamic.
This agrees with the Vulkan spec's usage of the term. Various sections
specify that the various pipeline state which have VkDynamicState enums
(e.g. viewport, scissor, etc.) may or may not be dynamic.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
We already check that the address is not "too far", but we should also
clamp the UBO index in order to avoid looking at the wrong place in the
driver cb. This is a pretty rare situation though.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Removes the need to set LIBVA_DRIVER_NAME=gallium for supported targets and is
consistent with vdpau and general gallium drivers.
Note: some versions of libva can detect the gallium name and use the
backend. Although that behaviour seems inconsistent since it only works
for some platforms/backends.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Fix warnings like these due to HAVE_LIBDRM being inconsistently defined:
external/libdrm/include/drm/drm.h:839:30: warning: redefinition of typedef 'drm_clip_rect_t' is a C11 feature [-Wtypedef-redefinition]
typedef struct drm_clip_rect drm_clip_rect_t;
HAVE_LIBDRM needs to be set project wide to fix this. This change also
harmlessly links libdrm with everything, but simplifies the makefiles a
bit.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Turn off warnings for -Wpointer-arith, -Wno-missing-field-initializers,
-Wno-initializer-overrides, and -Wno-mismatched-tags. These are all deemed
pointless, on purpose or no plans to fix.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Inline the function into it's only caller. This way it's more obvious
how the classic and gallium drivers (st/mesa) use _mesa_initialize_context.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It has been unused for a long time, plus makes the gallium dri modules
require an extra glapi symbol relative to their classic counterparts.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The actual code of the function print_table_stats() is guarded
by a ifdef GET_DEBUG, which was not been defined in years.
The last fix in 2013 (7db6b5aa91) indicates that it's rarely
used/tested. Since the issue has gone unnoticed for a whole year
(broken with 2ad4a47547).
Let's remove it for now. We can always revive it at a later stage.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
All of the functions and related data is internal, so there's no point
if using the GL types.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
... and associated file(s).
No longer needed since commit 057259655e ("i965: Don't link libmesa or
libdri_test_stubs into tests")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When building from a release tarball (where the generated/built files
are in srcdir) in an OOT fashion we need to have both builddir and
srcdir in the includes list.
Otherwise we'll error out, as the file (header gen_knobs.h in this case)
won't be in the location where we are looking.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Cc: Tim Rowley <timothy.o.rowley@intel.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
With earlier commit we've handled the `make distclean' out of tree
build, yet we failed to attribute that for in-tree builds the test
condition will return 1. Thus effectively the target will be considered
as "failed".
Fixes: b7f7ec7843 ("mesa: automake: distclean git_sha1.h when building
OOT")
Cc: <mesa-stable@lists.freedesktop.org>
Tested-by: Andy Furniss <adf.lists@gmail.com>
Reported-by: Andy Furniss <adf.lists@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Instead of changing the format on the existing template
which makes error handling not nice and confuses coverity.
CoverityID: 1337953
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
pipe_resource_reference(&res, NULL) will decrement reference counting,
i.e. p_atomic_dec(res->count). But the va surface still has the initial
reference since it has created the resource. So calling vaDestroyImage
on a derived image calls VaDestroyBuffer but the decrementation won't
reach 0. It is just wrong for vlVaDestroyBuffer to rely on the
export_refcount flag. Finally the vaapi intel driver has the same logic.
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This change makes sure to remove arrays when checking if type
is a double.
The check for the end of the first slot of a multi-slot double
is also fixed by bumping the check to 4 rather than 3.
Previously we were we not reserving the last component.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since this extension allows more than one varying to share a single
location we can't just count the number of slots a varying takes and
add it to the total.
Instead we now reuse the reserved varyings bitfield to determine how
many slots are reserved for explicit locations instead.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were programming the number of threads per subslice, when we should
have been programming the total number of threads on the GPU as a whole.
Thanks to Curro and Jordan for helping track this down!
On Skylake GT3e:
- Improves performance in Unreal's Elemental Demo by roughly 1.5-1.7x.
- Improves performance in Synmark's Gl43CSDof by roughly 3.7x.
- Improves performance in Synmark's Gl43GSCloth by roughly 1.18x.
On Broadwell GT2:
- Improves performance in Unreal's Elemental Demo by roughly 1.2-1.5x.
- Improves performance in Synmark's Gl43CSDof by roughly 2.0x.
- Improves performance in Synmark's Gl43GSCloth by 1.47035% +/-
0.255654% (n=25).
On Haswell GT3e:
- Improves performance in Unreal's Elemental Demo (in GL 4.3 mode)
by roughly 1.10x.
- Improves performance in Synmark's Gl43CSDof by roughly 1.18x.
- Decreases performance in Synmark's Gl43CSCloth by -1.99484% +/-
0.432771% (n=64).
On Ivybridge GT2:
- Improves performance in Unreal's Elemental Demo (in GL 4.2 mode)
by roughly 1.03x.
- Improves performance in Synmark's G/43CSDof by roughly 1.25x.
- No change in Synmark's Gl43CSCloth (n=28).
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
I don't know that anything actually guarantees this, but if we exceed
the limits, we may end up overflowing and trashing random buffers that
happen to be nearby in the VMA space, leading to rendering corruption,
hangs, or worse.
We should really fix this properly. However, the pitfall has existed
for ages, so for now we should at least detect it.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Most scratch stages use power of two sizes, in kilobytes, where
0 means 1kB. But compute shaders on Haswell have a minimum of 2kB,
and use a representation where 0 = 2kB.
This meant that we were effectively telling the hardware to allocate
each thread twice as much space as we meant to, while simultaneously
not allocating that much space in the buffer, leading to overflows.
Note that the existing code is completely wrong for Ivybridge,
but that will take additional work to sort out, so I've left it
as is for now. A subsequent commit will take care of that.
Together with the previous patches, this fixes rendering corruption
on Synmark's Gl43CSDof on Haswell.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Curro figured this out by investigating the simulator. Apparently
there's also a workaround in the Windows driver. I'm not sure it's
actually documented anywhere.
We were underallocating the scratch buffer by a factor of 128/70.
v2: Rename threads_per_subslice to scratch_ids_per_subslice
(suggested by Jordan Justen).
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We were allocating enough space for the number of threads per subslice,
when we should have been allocating space for the number of threads in
the entire GPU.
Even though we currently run with a reduced thread count (due to a bug),
we might still overflow the scratch buffer because the address
calculation is based on the FFTID, which can depend on exactly which
threads, EUs, and threads are executing. We need to allocate enough
for every possible thread that could run.
Fixes rendering corruption in Synmark's Gl43CSDof on Gen8+.
Earlier platforms need additional bug fixes.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This was disabled due to occasionally incorrect behavior when trying to
upload data. It later became apparent that nvc0 also had a similar but
slightly different issue, which was resolved in commit e50c01d5. This
takes the same logic as nvc0 and applies it to nv50 (which has somewhat
different interfaces).
Unfortunately I did not note down precisely what was broken with UBOs
when removing the support from nv50, but I've tested a bunch of local
traces, and none of them appear to regress. This should hopefully
improve performance when UBOs are used, but this was not directly
verified.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This was fixed in revision 47 of the ARB_dsa spec in Oct 22, 2015. Since
it's horrible to have differing APIs across library versions, we should
attempt to minimize the impact by backporting it as far as possible and
hope no one notices.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
This brings in the fixed glClearNamedFramebufferfi definition, as well
as a lot of GLsizei -> GLsizeiptr changes.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
This basically disallows all 8-bit x 3 and 16-bit x 3 formats for
textures and render targets. Some 3-component formats were already
disallowed before. This avoids problems with GL_ARB_copy_image.
v2: the previous version of this patch disallowed all 3-component formats
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Mesa and gallium don't have a complete set of matching 3-component
texture formats. For example, 8-bit sRGB unorm. To fully support
the GL_ARB_copy_image extension we need to have support for all of
these formats: RGB8_UNORM, RGB8_SNORM, RGB8_SRGB, RGB8_UINT, and
RGB8_SINT using the same component order. Since we don't have that,
disable the 3-component formats for now.
v2: Simplify 3-component format check, per Marek.
Also check that target != PIPE_BUFFER.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
1. Try to choose R8G8B8A8 unorm/srgb formats before others in an
effort to try to match component ordering for UINT/SINT/etc.
2. If we can't get a format such as PIPE_FORMAT_A16_UNORM, try
PIPE_FORMAT_R16G16B16A16_UNORM before shallower formats.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
>From OpenGL 4.0 spec, section 4.3.2 "Copying Pixels":
"The pixels corresponding to these buffers are copied from the source
rectangle bounded by the locations (srcX0, srcY 0) and (srcX1, srcY 1)
to the destination rectangle bounded by the locations (dstX0, dstY 0)
and (dstX1, dstY 1). The lower bounds of the rectangle are inclusive,
while the upper bounds are exclusive."
So, the rectangles sharing just an edge shouldn't overlap.
-----------
| |
------- ---
| | |
| | |
------- ---
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
>From OpenGL 4.0 spec, section 4.3.2 "Copying Pixels":
"The pixels corresponding to these buffers are copied from the source
rectangle bounded by the locations (srcX0, srcY 0) and (srcX1, srcY 1)
to the destination rectangle bounded by the locations (dstX0, dstY 0)
and (dstX1, dstY 1). The lower bounds of the rectangle are inclusive,
while the upper bounds are exclusive."
So, the rectangles sharing just an edge shouldn't overlap.
-----------
| |
------- ---
| | |
| | |
------- ---
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This converts to testing for 64-bit types and renames some things
in anticipation of 64-bit integer support.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just makes some generic code that currently emits double
suitable for emitting 64-bit values.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Currently this just doubles, but we'll convert users to this
so making adding 64-bit integers easier.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reworks the #if guards a bit. When Emil originally wrote them, he
just guarded everything. However, part of what anv_entrypoints_gen.py
generates is a hash table for looking up entrypoints based on their name.
This table *cannot* get out of sync between C and python regardless of
preprocessor flags. In order to prevent this, this commit makes us use
void pointers in the dispatch table for those entrypoints which aren't
available. This means that the dispatch table size and entry order is
constant and it should never get out-of-sync with the python.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
When an applications specifies mip levels _before_ setting a mipmap texture
filter, we will initially guess a single texture level. When the second level
image is created, we try to allocate the full texture -- however, we get the
base level size guess wrong if that size is odd. This leads to yet another
re-allocation of the texture later during st_finalize_texture.
Even worse, this re-allocation breaks a (reasonable) assumption made by
st_generate_mipmaps, because the re-allocation in the finalization call will
again allocate a single-level pipe texture (based on the non-mipmap texture
filter!). As a result, mipmap generation fails in interesting ways.
All of this can be avoided by just using the fact that we already know the
size of the base level.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95529
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
At this point, the limits are probably more-or-less correct. If there is
an invalid limit, that's a bug not a FINSHME.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This way the the bind map (which we're caching) is mostly independent of
the pipeline layout. The only coupling remaining is that we pull the array
size of a binding out of the layout. However, that size is also specified
in the shader and should always match so it's not really coupled. This
rendering issues in Dota 2.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Since applications are allowed to specify some set of bindings which need
not be dense they also need not be in order. For most things, this doesn't
matter, but it could result getting the wrong dynamic offsets. This adds a
quick-and-dirty sort to ensure that everything is always in increasing
order of binding index.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
With glx of gstreamer-vaapi, the temporary pixmap for front buffer gets
renewed in each frame, so when we receive a new pixmap, should get a new
front buffer for it.
This also fixes Totem player playback corruption.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
From original commit, the macro "if HAVE_DRI3" was in Makefile.sources,
this file is shared with SCons, SCons is not able to parse this marco,
the SCons build failed. Jose quickly gave two approaches and quick fix
with his second approach, thanks Jose for the solutions and fixes.
This patch is Jose's first approach, and it's more proper, because the
dri3 c file should not be included to build when DRI3 is not enabled.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Besides the old JIT bug, it seems the X86 backend on LLVM 3.3 doesn't
handle llvm.fmuladd and instead it fall backs to a C function. Which in
turn causes a segfault on Windows.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
As suggested by Roland Scheidegger.
Use the same logic as f16c, since fma requires VEX encoding.
But disable FMA on LLVM 3.3 without MCJIT.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This fixes a problem with the CE preamble and restoring only stuff in the
preamble when needed.
To illustrate suppose we have two graphics IB's 1 and 2, which are submitted in
that order. Furthermore suppose IB 1 does not use CE ram, but IB 2 does, and we
have a context switch at the start of IB 1, but not between IB 1 and IB 2.
The old code put the CE RAM loads in the preamble of IB 2. As the preamble of
IB 1 does not have the loads and the preamble of IB 2 does not get executed, the
old values are not load into CE RAM.
Fix this by always restoring the entire CE RAM.
v2: - Just load all descriptor set buffers instead of load and store the entire
CE RAM.
- Leave the ce_ram_dirty tracking in place for the non-preamble case.
v3: - Fixed parameter alignment.
- Rebased to master (Nicolai's descriptor series).
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The reality is that this doesn't matter, because we manually emit the
ARL to the sampler reladdr, and those arguments don't get an extra load
later, so it's effectively just a boolean. However having the types be
wrong is confusing and could trigger very odd bugs should usage change
down the line.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Adding 64-bit integers support was going to make this file worse,
just remove the tabs from it now.
Acked-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
An update in graphics specs has deleted the halign and valign fields
from XY_FAST_COPY_BLT command. See mesa commit 97f0f91.
Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
The extension is already advertised in compatibility profile, but
the _mesa_has_compute_shaders only returns true in core profile.
If we advertise it, we should allow it to work.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
v2: only load the clip vertex once
v3: fix clip enable logic, add cullDistance
v4: remove duplicate fields in vs jit key, fix test of clip fixup needed
v5: fix clipdistance linkage for slot!=0,4
v6: support clip+cull; passes most piglit clip (failures understood)
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
GLX documentation states:
glXCreateNewContext can generate the following errors: (...)
GLXBadFBConfig if config is not a valid GLXFBConfig
Function checks if the given config is a valid config and sets proper
error code.
Fixes currently crashing glx-fbconfig-bad Piglit test.
v2: coding style cleanups (Emil, Topi)
use DefaultScreen macro (Emil)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Apply the luma key filter to the YCbCr values during the CSC conversion
in video buffer shader. The initial values of max and min luma are set
to opposite values to disable the filter initially and will be set when
enabling it.
Add extra parmeters min and max luma for the luma key filter in
vl_compositor_set_csc_matrix in va, xvmc. Setting them
to opposite value 1.f and 0.f respectively won't effect the CSC
conversion
v2: -Squash 1,2 and 3 into one patch to avoid breaking build of
other components. (Christian)
-use ureg_swizzle. (Christian)
-change name of the variables. (Christian)
v3: -Squash all patches in one to avoid breaking of build. (Emil)
-wrap functions properly. (Emil)
-use 0.0f and 1.0f instead of 0.f and 1.f respectively. (Emil)
v4: -Divide it in two patches one which introduces the functionality
and assigs dummy values to the changed functions and second which
implements the lumakey filter. (Christian)
-use ureg_scalar instead ureg_swizzle. (Christian)
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
When Kristian implemented GL_TEXTURE_EXTERNAL_OES, he hooked it up for gen8
but not for gen7 or earlier. It all works, we just need to emit the states
for the extra planes.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
When calling virgl_fence_wait() with timeout=0,
virgl_{drm,vtest}_resource_is_busy() is called. However, it returns TRUE
for a busy resource, whereace virgl_fence_wait() should return TRUE for
a completed (non-busy) resource.
This fixes running supertuxkart in a VM (I could not reproduce locally
with vtest though there is a similar fix)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: "11.1 11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the future int64 support will have the same requirements.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This uses the new types interfaces to check for 64-bit types,
as futureproofing against int64 support.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is just some better type safety that I noticed while working
on 64-bit integer support.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just moves to the new interfaces in advance of int64.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is just prep work for int64 support, changing
places where 64-bit matters no doubles.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just moves code to the new check in advance of int64 support.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds an inline and type query for if a type is 64-bit.
Fow now this is equivalent to double, but int64 will change
this.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Coverity complains that the computed sizes can lead to negative lengths
passed to memcpy. If that happens we've been handed invalid arguments
anyway, so just bomb out.
The funky "0%s" is because the size string for the variable-length part
of the request is of the form "+ safe_pad() ...", and a unary + would
coerce the result to always be positive, defeating the overflow check.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This was for some old unsupported LLVM version.
Only si_create_context creates the target machine now.
r600g doesn't use this function.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The width0/height0/depth0 on stObj may not have been set at this point.
Observed in a trace that set up levels 2..9 of a 2d texture, and set the base
level to 2, with height 1. This made the guess logic always bail.
Originally investigated by Ilia Mirkin, this patch gets rid of the somewhat
redundant storage of width0/height0/depth0 and makes sure we always compute
pipe texture sizes that are compatible with the base level image of the
GL texture.
Fixes the gl-1.2-texture-base-level piglit test provided by Brian Paul.
v2:
- try to re-use an existing pipe texture when possible
- handle a corner case where the base level is not level 0 and it is of
size 1x1x1
v3:
- ptHeight = ptWidth in cube map 1x1 case (suggested by Brian)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
This just stops counting and assigning a storage location for
these uniforms, the count is only used to create the uniform storage.
These uniform types don't use this storage.
Reviewed-by: Dave Airlie <airlied@redhat.com>
We were previously unconditionally doing this for arrays and ubo's, and
ignoring texture/storage/atomic buffers. Instead use the usage history
to determine which atoms need to be revalidated.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
With this change, to enable precise SIN and COS instructions
on Intel hardware, one can put
<option name="precise_trig" value="true"/>
in the proper drirc file.
V2: Make option name more generic
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Stephane Marchesin <stephane.marchesin@gmail.com>
Since DCC is enabled almost everywhere now, it's important not to disable
this fast path.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
If first_level > 0 and DCC is disabled for that level, let's skip DCC
reads entirely.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Also add dcc_fast_clear_size for clearing only the necessary subset
of DCC. For no AA, it's equal to the size of the whole DCC level.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
We want to keep DCC enabled to save bandwidth. It was a bad idea to disable
it here.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This will get more complicated with mipmapped DCC or when DCC is enabled
after allocation.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
R9G9B9E5 is the only uncompressed one hopefully.
This fixes incorrect rendering not discovered (due to a lack of tests)
until DCC mipmapping was enabled.
Cc: 11.1 11.2 12.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Use rasterizer provoking vertex API.
Fix rasterizer provoking vertex for tristrips and quad list/strips.
v2: make provoking vertex tables static const
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
A texture may be redefined with _NEW_TEXTURE, which might have been
bound to a shader image slot. We have to revalidate the image atoms to
pick up on the new resource.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Sometimes a register source can actually be double- or even quad-wide.
We must make sure that the inserted texbars take that width into
account.
Based on an earlier patch by Samuel Pitoiset.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org>
Reduces CPU load for draw calls that change none or few of the descriptors.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
So that callers outside of si_descriptors.c need to worry less about the
details of descriptor handling.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This mask is irrelevant for the generic descriptor set handling, and having it
outside simplifies subsequent changes slightly.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Now that we emit guards for everything, we can just generate the files and
trust build flags to keep us safe. This should also fix the tarball
problems.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
To avoid blocking other EGL calls, release the display mutex before
we enqueue buffer to android frameworks and re-acquire the mutex
upon return.
v2: moved lock/unlock inside droid_window_enqueue_buffer().
TEST=verify pinch zoom in Photos app no longer causes hangs
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In the case of out-of-tree (OOT) builds, in particular when building
from tarball, we'll end up with the file in both srcdir and builddir.
We want the former to remain intact (since we need it on rebuild) while
the latter should be removed otherwise `make distclean' gets angry at
us.
Ideally there'll be a solution that feels a bit less of a hack. Until
then this does the job exactly as expected.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
... when copied from git_sha1.h.
As the latter file can we lacking the write attribute, one should set it
explicitly. Otherwise we'll get a warning/failure at cleanup stage.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Otherwise the build will assume that we've talking about builddir, which
is not the case in the else statement.
Here the file is already generated and is part of the tarball.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
With earlier commit we introduced support for render_node devices, which
was couples with the use of the image loader extension.
As the work was inspired by egl/wayland we (erroneously) added the
extension for the !render_node path as well.
That works for wayland, as the implementations of the DRI2 and IMAGE
loader extensions converge behind the scenes. As that is not yet
the case for Android we shouldn't expose the extension.
Fixes: 34ddef39ce ("egl: android: add dma-buf fd support")
Cc: <mesa-stable@lists.freedesktop.org>
Reported-by: Mauro Rossi <issor.oruam@gmail.com>
Tested-by: Mauro Rossi <issor.oruam@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
We don't import textures with DCC now, but soon we will.
v2: if we can't disable DCC for image writes, at least decompress DCC
at bind time
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Could cause issues if you tried to read from an uninitialised pointer.
This just initalises the pointer to null to avoid that being a problem.
Discovered by Coverity.
CID: 1343616
Signed-off-by: Jakob Sinclair <sinclair.jakob@openmailbox.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
We've had a FINISHME here since Eric originally wrote the code in 2011.
This patch implements his suggested approach, which makes us actually
able to copy propagate into the loops, at the unfortunate cost of making
this pass even more expensive.
The shader-db statistics are basically a wash:
No change in instruction counts.
total cycles in shared programs: 78685980 -> 78680730 (-0.01%)
cycles in affected programs: 2102646 -> 2097396 (-0.25%)
helped: 48
HURT: 83
I figured if we're going to do this for one copy propagation pass,
we may as well do it in both.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We've had a FINISHME here since Eric originally wrote the code in 2010.
This patch implements his suggested approach, which makes us actually
able to copy propagate into the loops, at the unfortunate cost of making
this pass even more expensive.
The shader-db statistics are not terribly impressive:
total instructions in shared programs: 9008589 -> 9008613 (0.00%)
instructions in affected programs: 4293 -> 4317 (0.56%)
helped: 0
HURT: 10
total cycles in shared programs: 78550978 -> 78575760 (0.03%)
cycles in affected programs: 655426 -> 680208 (3.78%)
helped: 75
HURT: 88
GAINED: 2
Most of the "regressions" appear to be us successfully copy propagating
uniforms, which i965 is loading as pull constants instead of push, so we
occasionally have two pulls instead of one. That doesn't seem like this
pass's job - it's propagating correctly, and we should be smarter about
pull loads in the backend.
This patch is also useful for a couple of reasons:
1. It can clean up copies created by varying packing (previously, we
couldn't if the uses were inside a loop).
This fixes a bug when interpolateAt*() is used on a packed varying
inside a loop: glsl_to_nir struggles to see through the extra copy
and mistakenly believed the variable was not an input.
2. It will help propagate uniform array access created by
lower_const_array_to_uniforms().
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Like floats, we should use the round toward 0 mode instead of the
nearest one (which is the default) for doubles to integers.
This fixes all arb_gpu_shader_fp64 piglits which convert doubles to
integers (16 tests).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
The GL4.5 spec quote seems clear on this:
"The value -1 will be returned by either command if an error occurs,
if name does not identify an active variable on programInterface,
or if name identifies an active variable that does not have a valid
location assigned, as described above."
This fixes:
GL45-CTS.program_interface_query.output-built-in
[airlied: use _mesa_program_resource_location_index as
suggested by Eduardo]
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cast the unsigned semantic index to integer datatype before comparing
to max_generic, otherwise, max_generic which is initialized to -1
will be converted to unsigned int before the comparison, causing a wrong
semantic index to be assigned to a shader output.
Fixes the assert running TurboCAD_gl.trace. (VMware bug 1667265)
Also tested with glretrace, mesa demos pointblast, spriteblast and pointcoord.
v2: use the original max_generic variable but add the (int) cast
to the semantic index, as suggested by Brian.
Reviewed-by: Brian Paul <brianp@vmware.com>
When TGSI debug flag is enabled, print the shader linkage info as well.
Tested with mesa demos with SVGA_DEBUG=tgsi
Reviewed-by: Brian Paul <brianp@vmware.com>
ARB_shader_image_load_store only requires a very fixed list of formats
to be supported, while textures may be in all kinds of formats, like
BGRA which are presently not supported on at least Kepler.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Switches to using truncf in micro_trunc.
Fixes the following piglit tests (for softpipe):
/spec/glsl-1.30/execution/built-in-functions/...
fs-trunc-float
fs-trunc-vec2
fs-trunc-vec3
fs-trunc-vec4
vs-trunc-float
vs-trunc-vec2
vs-trunc-vec3
vs-trunc-vec4
/spec/glsl-1.50/execution/built-in-functions/...
gs-trunc-float
gs-trunc-vec2
gs-trunc-vec3
gs-trunc-vec4
Signed-off-by: Lars Hamre <chemecse@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
When we are not packing a double input varying, we might need to
read its data in a non-aligned to 64-bit offset, so we read
the wrong data. This is happening when using explicit locations
in varyings because Mesa disables packing varying for that case.
const_index is in 32-bit size units but offset() is multiplying
it by destination type size units. When operating with double
input varyings, const_index value could be not aligned to 64 bits.
To fix it, we load the double vector as if it was a float based vector
with twice the number of components.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Data starts at suboffet 3 in 32-bit units (12 bytes), so it is not
64-bit aligned and the current implementation fails to read the data
properly. Instead, when there is is a double input varying, read it as
vector of floats with twice the number of components.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
From GLSL 4.5 spec, "4.4.2.3 Geometry Outputs".
"all geometry shader output vertex count declarations in a
program must declare the same count."
Fixes:
GL45-CTS.geometry_shader.output.conflicted_output_vertices_max
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Although the glsl_types.h stores this in a bitfield,
we should hide that from everyone else. Hide the cast
in an accessor method and use the enum everywhere.
This makes things a bit nicer in gdb, and improves type
safety.
v2: fix a few pieces of interface I missed that caused some
piglit regressions.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
For 3D textures we shouldn't be using NumLayers, we need
to get it from the depth.
This fixes:
GL45-CTS.geometry_shader.layered_framebuffer.clear_call_support
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With tessellation shaders we can have cases where we have
arrays of anon structs, so make sure we match using without_array().
Fixes:
GL45-CTS.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_in
v2:
test lengths match as well (Ilia)
v3:
descend array lengths to check for matches as well (Ilia)
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes a crash in
GL43-CTS.shader_subroutine.subroutines_not_allowed_as_variables_constructors_and_argument_or_return_types
If we can't find the func_name in one of these paths,
we have emitted an earlier error so just return here.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
GL43-CTS.compute_shader.work-group-size does
uniform uint g_uniform[gl_WorkGroupSize.z + 20] = { 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24 };
The initializer triggers the GLSL 4.30/GLES3 tests
for constant sequence subexpressions, so it doesn't
happen unless you are using those, so just return
false as this path is now reachable.
v2: update commit msg with diagnosis
Acked-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
PATH_MAX is apparently not a thing on Windows. Borrow the hack from
pipe_loader.c to try and make this work.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This writes linked shader programs to .shader_test files to
$MESA_SHADER_CAPTURE_PATH in the format used by shader-db
(http://cgit.freedesktop.org/mesa/shader-db).
It supports both GLSL shaders and ARB programs. All stages that
are linked together are written in a single .shader_test file.
This eliminates the need for shader-db's split-to-files.py, as Mesa
produces the desired format directly. It's much more reliable than
parsing stdout/stderr, as those may contain extraneous messages, or
simply be closed by the application and unavailable.
We have many similar features already, but this is a bit different:
- MESA_GLSL=dump writes to stdout, not files.
- MESA_GLSL=log writes each stage to separate files (rather than
all linked shaders in one file), at draw time (not link time),
with uniform data and state flag info.
- Tapani's shader replacement mechanism (MESA_SHADER_DUMP_PATH and
MESA_SHADER_READ_PATH) also uses separate files per shader stage,
but allows reading in files to replace an app's shader code.
v2: Dump ARB programs too, not just GLSL.
v3: Don't dump bogus 0.shader_test file.
v4: Add "GL_ARB_separate_shader_objects" to the [require] block.
v5: Print "GLSL 4.00" instead of "GLSL 4.0" in the [require] block.
v6: Don't hardcode /tmp/mesa.
v7: Fix memoization of getenv().
v8: Also print "SSO ENABLED" (suggested by Timothy).
v9: Also handle ES shaders (suggested by Ilia).
v10: Guard against MESA_SHADER_CAPTURE_PATH being too long; add
_mesa_warning calls on error handling (suggested by Ben).
v11: Fix crash when variable is unset introduced in v10.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Images invalidation is a bit weird on Fermi and there is already a hack
which forces invalidating all images when launching a computer shader
to help in fixing 3D<->CP interaction.
However, we need to re-validate images for compute because
nvc0_compute_invalidate_surfaces() will destroy the previous binding.
This is not really good for performance purposes but this might be
improved later.
This fixes the following piglits:
- spec/arb_compute_shader/execution/basic-uniform-access
- spec/arb_compute_shader/execution/mutiple-texture-reading
- spec/arb_compute_shader/execution/multiple-workgroups
- spec/glsl-4.30/execution/built-in-functions/cs-* (207 tests)
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This should fix spec@arb_shader_image_load_store@level.
Broken by:
Commit: 95c5bbae66
radeonsi: set some image descriptor fields at bind time
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
We would revalidate images when anything was touched at all. Which is
unfortunate, since the state tracker does not use CSO's to reduce the
workload. So instead implement a protocol to ensure that something has
changed before revalidating all the images.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
We would revalidate buffers when anything was touched at all. Which is
unfortunate, since the state tracker does not use CSO's to reduce the
workload. So instead implement a protocol to ensure that something has
changed before revalidating all the SSBOs.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
The fix in:
anv: let anv_entrypoints_gen.py generate proper Wayland/Xcb guards
breaks things if wayland headers aren't installed.
Separate things out properly to avoid that problem.
[airlied: fixed up to put in pre-existing sections].
Reported-by: Arjan van de Ven
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The main impact is that {upload, draw, upload, draw, ..} doesn't flush
framebuffer caches before every upload.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
v3: use PFP_SYNC_ME on EG-CM only when supported by the kernel,
otherwise use MEM_WRITE + WAIT_REG_MEM to emulate that
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
When upscaling you can end up interpolating between the edge pixel and one
past the edge. Using CLAMP_TO_EDGE seems like the most reasonable thing to
do in this case. This fixes two of the new Vulkan CTS tests in
dEQP-VK.api.copy_and_blit.blit_image.*
Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Getting rid of the default case makes the compiler warn if we are missing
cases. While we're here, we also add the one missing case.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
glslang frequently throw bogus decorations into shaders. While we are free
to assert-fail, it's a bit nicer to the application to just warn.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Previously we supported a subset of capabilities and just left a default
case for the others. It's time to stop being lazy and actually audit the
capabilities. This should bring them up-to-date with reality.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This is more accurate than calling
_mesa_active_fragment_shader_has_side_effects because it looks at whether
or not the SSBOs, images, or atomic buffers are actually written rather
than just existing in the program.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
We were using this briefly in the i965 driver to trigger recompiles but we
haven't been using it since we switched to the NIR y-transform lowering
pass.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reverts commit c1107cec44.
Apparently the hardware spec text I quoted in the commit message was
outright lying about scalar source math being supported on SNB, the
hardware seems to load 32 contiguous bits of data for each channel
regardless of the regioning mode. Fixes regressions in the following
CTS tests (which we didn't catch early due to CTS being temporarily
disabled in our CI system):
es2-cts.gtf.gl.atan.atan_vec3_frag_xvary
es2-cts.gtf.gl.cos.cos_vec2_frag_xvary
es2-cts.gtf.gl.atan.atan_vec2_frag_xvary
es2-cts.gtf.gl.pow.pow_vec2_frag_xvary_yconsthalf
es2-cts.gtf.gl.cos.cos_float_frag_xvary
es2-cts.gtf.gl.pow.pow_float_frag_xvary_yconsthalf
es2-cts.gtf.gl.atan.atan_vec3_frag_xvaryyvary
es2-cts.gtf.gl.pow.pow_vec3_frag_xvary_yconsthalf
es2-cts.gtf.gl.cos.cos_vec3_frag_xvary
es2-cts.gtf.gl.atan.atan_vec2_frag_xvaryyvary
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96346
Reported-by: Mark Janes <mark.a.janes@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
The conditional mod of these instructions determines the semantics of
the comparison itself (rather than being evaluated based on the result
of the instruction as is usually the case for most other instructions
that allow conditional mods), so it's in general not legal to
propagate a conditional mod into a CMP instruction. This prevents
cmod propagation from (mis)optimizing:
cmp.z.f0 tmp, ...
mov.z.f0 null, tmp
into:
cmp.z.f0 tmp, ...
which gives the negation of the flag result of the original sequence.
I originally noticed this while working on SIMD32 in the scalar
back-end, but the same scenario is likely to be possible in vec4
programs so this commit ports the bugfix with the same name from the
scalar back-end to the vec4 cmod propagation pass.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Give algebraic-opt pass a chance to catch udiv by const power-of-two,
before running lower-idiv pass.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Some optimizations, like converting integer multiply/divide into left/
right shifts, have additional constraints on the search expression.
Like requiring that a variable is a constant power of two. Support
these cases by allowing a fxn name to be appended to the search var
expression (ie. "a#32(is_power_of_two)").
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When a shader image view into a buffer texture can be written to, the buffer's
valid range must be updated, or subsequent transfers may incorrectly skip
synchronization.
This fixes a bug that was exposed in Xephyr by PBO acceleration for glReadPixels,
reported by Michel Dänzer.
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: 12.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For ES 3.0 NUM_SAMPLE_COUNTS spec points that some formats will be
always zero. But on ES 3.1 can be different to zero.
The current code is correctly checking exactly against version 3.0,
but the comment only mentions 3.0 spec. It is clearer mentioning both.
v2: better wording on the comment (Ian Romanick)
Acked-by: Eduardo Lima <elima@igalia.com>
Acked-by: Antia Puentes <apuentes@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
When validating attributes during surface creation we should account
for the default values of texture target and format (EGL_NO_TEXTURE)
since the user is not obligated to explicitly set both via the
attribute list passed to eglCreatePbufferSurface.
Signed-off-by: Plamena Manolova <plamena.manolova@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
isl library is needed to build i965, libmesa_isl static library is added
to fix related Android building errors.
Any attempt to build libmesa_genxml as phony package module failed to deliver
gen{7,75,8,9}_pack.h generated headers, needed for libmesa_isl_gen{7,75,8,9}
Due to constraints in Android Build System, libmesa_genxml is built as static,
at least one source is needed, so dummy.c is autogenerated for this scope,
libmesa_genxml dependency is declared using LOCAL_WHOLE_STATIC_LIBRARIES,
to avoid building errors due to missing genxml/gen{7,75,8,9}_pack.h headers.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Fixes the following building error:
target C++: libmesa_glsl <= external/mesa/src/compiler/glsl/glsl_to_nir.cpp
In file included from external/mesa/src/compiler/glsl/glsl_to_nir.h:28:0,
from external/mesa/src/compiler/glsl/glsl_to_nir.cpp:28:
external/mesa/src/compiler/nir/nir.h:42:25: fatal error: nir_opcodes.h: No such file or directory
compilation terminated.
build/core/binary.mk:432: recipe for target 'out/target/product/x86/obj/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/glsl_to_nir.o' failed
make: *** [out/target/product/x86/obj/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/glsl_to_nir.o] Error 1
make: *** Waiting for unfinished jobs....
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Including the file in both ISL_FILES and ISL_GENERATED_FILES makes
the actual dependency list less obvious.
v2: Drop unrelated vulkan hunk (Jason).
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
With earlier commit 3689ef32af ("automake: rework the git_sha1.h rule,
include in tarball") we/I erroneously removed the PHONY rule and the
temporary file.
The former is used to ensure that the header is regenerated when on each
make invocation, while the latter helps us avoid the unneeded rebuild(s)
when the SHA1 hasn't changed.
Reported-by: Grazvydas Ignotas <notasas@gmail.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Instead of just allow copy of a rectangle in svga_transfer_dma_band(),
this patch allows it to copy a box, hence allows copy a 3d texture
in one transfer.
Fixes black screen in running Heaven after commit fb9fe35. (Bug 1663282)
Tested with Heaven, glretrace, piglit.
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Coverity doesn't realize idx will never be negative. Throw in some
assert()s to help it out.
(Hopefully assert() isn't getting compiled out for coverity build.. but
there seems to be just one way to find out. We might have to change
these to assume())
Fixes CID 1362442, 1362443
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Maybe we should switch to ureg to build the builtin shaders. But at any
rate, if they fail to compile it is because someone messed them up (or
changed TGSI syntax?).
CID 1362444
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Skipping the temporary allocation and copy instructions is easy (just
return dst), but the conditions used to find out whether the copy can
be optimized out safely without breaking the program are rather
complex: The destination must be exactly one component of at most the
execution width of the lowered instruction, and all source regions of
the instruction must be either fully disjoint from the destination or
be aligned with it group by group.
v2: Don't handle partial source-destination overlap for simplicity
(Jason). No instruction count regressions with respect to v1 in
either shader-db or the few FP64 shader_runner test-cases with
partial overlap I've checked manually.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The specs says INVALID_VALUE for exceeding dimensions,
which is really what is happening here.
This fixes:
GL45-CTS.copy_image.non_existent_mipmap
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Antia Puentes <apuentes@igalia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This test was only happening for textures, but there is
nothing in the spec to say this, so test it for all cases.
This fixes:
GL45-CTS.copy_image.invalid_target
Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Never can happen, since query would not have been created in the first
place if pidx(query_type) return negative. Lets let coverity realize
this.
CID 1362460
Signed-off-by: Rob Clark <robclark@freedesktop.org>
ptr can actually never be null so just drop the check.
CID 1362464 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking ptr suggests that it may be null,
but it has already been dereferenced on all paths leading to the check.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Coverity warns in multiple places about the potential for division by
zero, caused by this function's default case.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
According to the EGL specifications before binding an API
we must check whether it's supported first. If not eglBindAPI
should return EGL_FALSE and generate a EGL_BAD_PARAMETER error.
Signed-off-by: Plamena Manolova <plamena.manolova@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
These two lines have been here since the file was created.
I'm guessing the second one was just for testing during dev, so it's the
one that's going away.
CoverityID: 1296205
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
Check for null pointer before accessing arrays in get/put bits
native/YCbCr/Indexed in VdpOutputSurface and VdpVideoSurface.
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The comment clarifies that the driver is called only to try to get
a preferred internalformat, and that it was already checked if the
format is supported or not.
Acked-by: Eduardo Lima <elima@igalia.com>
Acked-by: Antia Puentes <apuentes@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Right now the implementation only checks if the internalformat is
supported or not. But that implementation is wrong, returning
unsupported for some internalformats. Additionally, checking if
the internalformat is supported or not is already done at mesa/main
before calling the driver hook, so this new check is not needed.
Acked-by: Eduardo Lima <elima@igalia.com>
Acked-by: Antia Puentes <apuentes@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Among other thigs, fix a gpu hang when using INTEL_DEBUG=shader_time
for any shader.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The old method pushed data for each channels uvec3 data of
gl_LocalInvocationID.
The new method pushes 1 dword of data that is a 'thread local ID'
value. Based on that value, we can generate gl_LocalInvocationIndex
and gl_LocalInvocationID with some calculations.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The cross thread constant support appears on Haswell. It allows us to
upload a set of uniform data for all threads without duplicating it
per thread.
One complication is that cross-thread constants are loaded into
registers before per-thread constants. Previously, our local IDs were
loaded before the uniform data and treated as 'payload' data, even
though they were actually pushed into the registers like the other
uniform data.
Therefore, in this patch we simultaneously enable a newer layout where
each thread now uses a single uniform slot for a unique local ID for
the thread. This uniform is handled specially to make sure it is added
last into the uniform push constant registers. This minimizes our
usage of push constant registers, and maximizes our ability to use
cross-thread constants for registers.
To swap from the old to the new layout, we also need to flip some
lowering pass switches to let our driver handle the lowering instead.
We also no longer force thread_local_id_index to -1.
v4:
* Minimize size of patch that switches from the old local ID layout
to the new layout (Jason)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The cross thread constant support appears on Haswell. It allows us to
upload a set of uniform data for all threads without duplicating it
per thread.
We also support per-thread data which allows us to store a per-thread
ID in one of the uniforms that can be used to calculate the
gl_LocalInvocationIndex and gl_LocalInvocationID variables.
v4:
* Support the old local ID push constant layout as well (Jason)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The cross thread constant support appears on Haswell. It allows us to
upload a set of uniform data for all threads without duplicating it
per thread.
We also support per-thread data which allows us to store a per-thread
ID in one of the uniforms that can be used to calculate the
gl_LocalInvocationIndex and gl_LocalInvocationID variables.
v4:
* Support the old local ID push constant layout as well (Jason)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We need information about push constants in a few places for the GL
driver, and another couple places for the vulkan driver.
When we add support for uploading both a common (cross-thread) set of
push constants, combined with the previous per-thread push constant
data, things are going to get even more complicated. To simplify
things, we add push constant info into the cs prog_data struct.
The cross-thread constant support is added as of Haswell. To support
it we need to make sure all push constants with uniform values are
added to earlier registers. The register that varies per thread and
holds the thread invocation's unique local ID needs to be added last.
For now we add the code that would calculate cross-thread constatn
information for hsw+, but we force it (cross_thread_supported) off
until the other parts of the driver support it.
v4:
* Support older local ID push constant layout as well. (Jason)
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We add a lowering pass for nir intrinsics. This pass can replace nir
intrinsics with driver specific nir lower code.
We lower the gl_LocalInvocationIndex intrinsic based on a uniform
which is loaded with a thread specific ID.
We also lower the gl_LocalInvocationID based on
gl_LocalInvocationIndex.
v2:
* Create variable during lowering pass. (Ken)
v3:
* Don't create a variable, but instead just insert an intrisic call
to load a uniform from the allocated location. (Jason)
v4:
* Don't run this pass if thread_local_id_index < 0
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This thread ID uniform will be used to compute the
gl_LocalInvocationIndex and gl_LocalInvocationID values.
It is important for this uniform to be added in the last push constant
register. fs_visitor::assign_constant_locations is updated to make
sure this happens.
The reason this is important is that the cross-thread push constant
registers are loaded first, and the per-thread push constant registers
are loaded after that. (Broadwell adds another push constant upload
mechanism which reverses this order, but we are ignoring this for
now.)
v2:
* Add variable in intrinsics lowering pass
* Make sure the ID is pushed last in assign_constant_locations, and
that we save a spot for the ID in the push constants
v3:
* Simplify code based with Jason's suggestions.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v4:
* Force thread_local_id_index to -1 for now, and have
fs_visitor::setup_cs_payload look at thread_local_id_index. This
enables us to more easily cut over from the old local ID layout to
the new layout, as suggested by Jason.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We will chain multiple chunks together and will keep pointers to the older
chunks to support IB dumping.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This avoids allocating giant IBs from the outset, especially for CE and DMA.
Since we now limit max_dw only by the size that the buffer happens to be
(which, due to the buffer cache, can be even larger than the rounded-up size
we request), the new function amdgpu_ib_max_submit_dwords controls when we
submit an IB.
With this change, we effectively never flush prematurely due to the CE IB,
after an initial warm-up phase.
v2:
- clean up buffer_size calculation
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Isolines aren't reversed. commit 5b2d8c2273 fixed this for the vec4
TES backend, but not the scalar one.
Found while debugging GL45-CTS.tessellation_shader.
tessellation_control_to_tessellation_evaluation.gl_tessLevel.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org
v2: require PIPE_CAP_SAMPLER_VIEW_TARGET; technically only needed for some of
the texture targets, but all hardware that has shader images should also
have this cap.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For better bisectability given that the order of some of the fallback tests
in the blit path are rearranged.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This will be used to select a slice of a 3D texture.
v2: fix a comment (Marek)
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For downloads, the fragment shader must know the source texture target, hence
we may cache multiple fragment shaders.
v2: break long line (Marek)
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
At the same time, rename members that are upload-specific to say so.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The string "[0]\0" is the same as "[0]" as far as the C string datatype
is concerned. That string has length 3. strncmp(s, length_3_string, 4)
is the same as strcmp(s, length_3_string), so make it be strcmp.
v2: Not the same as strncmp(..., 3). Noticed by Ilia.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This improves throughput by keeping TTM overhead down.
Some piglit tests such as texelFetch and streaming-texture-leak will
use less memory now.
v2: use gart_size / 4 as the threshold
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
mainly the fields that can change by reallocating a texture and changing
the tile mode
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Just for consistency. This doesn't fix anything, because DCC is not
supported with non-mipmapped textures.
v1.1: fix the comment about DCC
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
With the introduction of fp64 and fp16 to nir, there are now a bunch of
float types running around. A F1 2015 shader ends up with an i2f.sat
operation, which has a nir_type_float32 destination. Allow sat on all
the float destination types.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The initial ARB_sampler_objects spec had GL_INVALID_VALUE in it,
however version 8 of it fixed this, and the GL specs also have
the fixed value in them.
Fixes:
GL45-CTS.texture_border_clamp.samplerparameteri_non_gen_sampler_error
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes rendering in Shadow of Mordor with rbc. Application writes
RGBA_UNORM texture filling it with values the application wants to
later on treat as SRGB_ALPHA.
Intel driver enables lossless compression for the buffer by the time
of writing. However, the driver fails to make sure the buffer can be
sampled as something else later on and unfortunately there is
restriction in the hardware for using lossless compression for srgb
formats which looks to extend itself to the sampling engine also.
Requesting srgb to linear conversion on top of compressed buffer
results the color values to be pretty much garbage.
Fortunately none of tracked benchmarks showed a regression with
this.
v2 (Matt): Add missing space
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We weren't setting up several of the uniform values for the patch
header, so we'd crash when uploading push constants. We at least
need to initialize them to zero. We also had the isoline parameters
reversed, so it would also render incorrectly (if it didn't crash).
Fixes a new Piglit test(*) (isoline-no-tcs), as well as crashes in
GL44-CTS.tessellation_shader.single.max_patch_vertices.
(*) https://lists.freedesktop.org/archives/piglit/2016-May/019866.html
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: mesa-stable@lists.freedesktop.org
The driver was adding the skip components but always for buffer 0.
This fixes:
GL45-CTS.gtf40.GL3Tests.transform_feedback3.transform_feedback3_skip_multiple_buffers
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
e2791b38b4
mesa/program_interface_query: fix transform feedback varyings.
caused a regression in
GL45-CTS.gtf40.GL3Tests.transform_feedback3.transform_feedback3_multiple_streams
on radeonsi.
The problem was it was using the skip components varying to set
the stream id, when it should wait until a varying was written,
this just adds the varying checks in the right place.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
According to GL4.5 spec:
An INVALID_OPERATION error is generated if any part of the speci-
fied buffer range is mapped with MapBufferRange or MapBuffer (see sec-
tion 6.3), unless it was mapped with MAP_PERSISTENT_BIT set in the Map-
BufferRange access flags.
So we should use the if range is mapped path.
This fixes:
GL45-CTS.buffer_storage.map_persistent_buffer_sub_data
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: "12.0, 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This really only hits for bitsets with a size of a multiple of 32. We
can end up with pos = -1 as a result of the ffs, which we in turn decide
is a valid position (since we fall through the loop and i == 1, we end
up adding 32 to it, so end up returning 31 again).
Up until recently this was largely unreachable, as the register file
sizes were all 63 or 255. However with the advent of compute shaders
which can restrict the number of registers, this can now happen.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
This reverts commit aac90ba292.
The commit caused a regression in:
piglit.spec.glsl-1_50.compiler.gs-input-nonarray-named-block.geom
Also the CTS test it was meant to fix seems like it may be bogus.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
I haven't found any evidence that this isn't supported by the
hardware, in fact according to the SNB hardware spec:
"The supported regioning modes for math instructions are align16,
align1 with the following restrictions:
- Scalar source is supported.
[...]
- Source and destination offset must be the same, except the case of
scalar source."
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is the case for SNB math instructions so we need to be careful
and insert the literal value of the immediate into the table (rather
than its absolute value) if the instruction is unable to invert the
sign of the constant on the fly.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Which requires using a bitset instead of a boolean flag to keep track
of the GRFs we've seen a generating instruction for already. The
search loop continues until all instructions initializing the value of
the source VGRF have been found, or it is determined that coalescing
is not possible.
Fixes a few piglit test cases on Gen4-6 which were regressed by
6956015aa5 due to the different (yet
perfectly valid) ordering in which copy instructions are emitted now
by the simd lowering pass, which had the side effect of causing this
optimization pass to start corrupting the program in cases where a
VGRF-to-MRF copy instruction would be eliminated but only the last
instruction writing to the source VGRF region would be rewritten to
point to the target MRF.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This will be required to correctly transform the destination of 8-wide
instructions that write a single GRF of a VGRF to MRF copy marked
COMPR4.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This will allow compute_to_mrf to handle cases where the source of the
VGRF-to-MRF copy is initialized by more than one instruction. In such
cases we cannot rewrite the destination of any of the generating
instructions until it's known whether the whole VGRF source region can
be coalesced into the destination MRF, which will imply continuing the
search until all generating instructions have been found or it has
been determined that the VGRF and MRF registers cannot be coalesced.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Compute-to-mrf was checking whether the destination of scan_inst is
more than one component (making assumptions about the instruction data
type) in order to find out whether the result is being fully copied
into the MRF destination, which is rather inaccurate in cases where a
single-component instruction is only partially contained in the source
region, or when the execution size of the copy and scan_inst
instructions differ. Instead check whether the destination region of
the instruction is really contained within the bounds of the source
region of the copy.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Compute-to-mrf was being rather heavy-handed about checking whether
instruction source or destination regions interfere with the copy
instruction, which could conceivably lead to program miscompilation.
Fix it by using regions_overlap() instead of the open-coded and
dubiously correct overlap checks.
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Now there are not files that require python 3, so for now just remove
the python 3 dependency and use python 2. I think the right plan is to
just get all of the python ready for python 3, and then use whatever
python is available.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
cc: 12.0 <mesa-stable@lists.freedesktop.org>
By using a counter to quickly reject textures that are not
bound to a framebuffer, the performance impact when binding
sampler_views/images is not too large.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The generated sources should follow the example set by the vulkan
headers and our non-generated code. Namely: the code for all supported
platforms should be available, each one guarded by its respective
VK_USE_PLATFORM_*_KHR macro.
v2: Reword commit message.
Cc: Mark Janes <mark.a.janes@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96285
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (v1 over IRC)
This parameter is actually a bitmask of PIPE_TRANSFER_x flags.
Change it back to a simple unsigned type. IIRC, some compilers
complain about masks of enum values. Also, this make the function
signature match u_resource_vtbl::transfer_map() again.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The GL spec has been clarified and the new rule says we should just
copy 1 sample. u_blitter does the right thing.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The GL spec has been clarified and the new rule says we should just
copy 1 sample. u_blitter does the right thing.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Coverity is getting a false positive that a division by zero can occur
here. This change will silence the Coverity warnings as a division by zero
cannot occur in this case.
Signed-off-by: Jakob Sinclair <sinclair.jakob@openmailbox.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
`unsigned j` would never fail `j >= 0`, leading to an infinite loop as
`j--` wraps around.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
The CTS test:
GL45-CTS.multi_bind.dispatch_bind_image_textures
binds 192 image uniforms, we reject this later,
but not until after we trash the contents of the
struct gl_shader.
Error now reads:
Too many compute shader image uniforms (192 > 16)
instead of
Too many compute shader image uniforms (2745344416 > 16)
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This effectively limits registers to 32 and 64 for fermi and kepler when
1024 threads are used, but allows the full amount to be used with
smaller thread sizes.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Note: some of the new features are only available with certain drivers.
</p>
<ul>
<li>OpenGL ES 3.1 on i965/hsw</li>
<li>OpenGL ES 3.2 on i965/gen9+ (Skylake and later)</li>
<li>GL_ARB_ES3_1_compatibility on i965</li>
<li>GL_ARB_ES3_2_compatibility on i965/gen8+</li>
<li>GL_ARB_clear_texture on r600, radeonsi</li>
<li>GL_ARB_compute_variable_group_size on nvc0, radeonsi</li>
<li>GL_ARB_cull_distance on radeonsi</li>
<li>GL_ARB_enhanced_layouts on i965, nv50, nvc0, radeonsi, llvmpipe, softpipe</li>
<li>GL_ARB_indirect_parameters on radeonsi</li>
<li>GL_ARB_query_buffer_object on radeonsi</li>
<li>GL_ARB_shader_draw_parameters on radeonsi</li>
<li>GL_ARB_shader_group_vote on nvc0</li>
<li>GL_ARB_shader_viewport_layer_array on i965/gen6+</li>
<li>GL_ARB_stencil_texturing on i965/hsw</li>
<li>GL_ARB_texture_stencil8 on i965/hsw</li>
<li>GL_EXT_window_rectangles on nv50, nvc0</li>
<li>GL_KHR_blend_equation_advanced on i965</li>
<li>GL_KHR_robustness on nvc0, radeonsi</li>
<li>GL_KHR_texture_compression_astc_sliced_3d on i965</li>
<li>GL_OES_copy_image on nv50, nvc0, r600, radeonsi, softpipe, llvmpipe</li>
<li>GL_OES_geometry_shader on i965/gen8+, nvc0, radeonsi</li>
<li>GL_OES_primitive_bounding_box on i965/gen7+, nvc0, radeonsi</li>
<li>GL_OES_texture_cube_map_array on i965/gen8+, nvc0, radeonsi</li>
<li>GL_OES_tessellation_shader on i965/gen7+, nvc0, radeonsi</li>
<li>GL_OES_viewport_array on nvc0, radeonsi</li>
<li>GL_ANDROID_extension_pack_es31a on i965/gen9+</li>
</ul>
<h2>Bug fixes</h2>
<ul>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=61907">Bug 61907</a> - Indirect rendering of multi-texture vertex arrays broken</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=69622">Bug 69622</a> - eglTerminate then eglMakeCurrent crahes</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=71759">Bug 71759</a> - Intel driver fails with "intel_do_flush_locked failed: No such file or directory" if buffer imported with EGL_NATIVE_PIXMAP_KHR</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=89599">Bug 89599</a> - symbol 'x86_64_entry_start' is already defined when building with LLVM/clang</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=90513">Bug 90513</a> - Odd gray and red flicker in The Talos Principle on GK104</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=91342">Bug 91342</a> - Very dark textures on some objects in indoors environments in Postal 2</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=92306">Bug 92306</a> - GL Excess demo renders incorrectly on nv43</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=94148">Bug 94148</a> - Framebuffer considered invalid when a draw call is done before glCheckFramebufferStatus</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=94354">Bug 94354</a> - R9285 Unigine Valley perf regression since radeonsi: use re-Z</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=94561">Bug 94561</a> - [llvmpipe] PIPE_CAP_VIDEO_MEMORY reports negative value on 32 bits (with 16GB ram)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=94627">Bug 94627</a> - Game Risen on wine black grass</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=94681">Bug 94681</a> - dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23 takes 25 minutes to compile</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=95000">Bug 95000</a> - deqp: assert in dEQP-GLES3.functional.vertex_arrays.single_attribute.strides.fixed.user_ptr_stride17_components2_quads1</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=95130">Bug 95130</a> - Derivatives of gl_Color wrong when helper pixels used</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=95246">Bug 95246</a> - Segfault in glBindFramebuffer()</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=95419">Bug 95419</a> - [HSW][regression][bisect] RPG Maker game gives "invalid floating point operation" at startup</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96358">Bug 96358</a> - SSO: wrong interface validation between GS and VS (regresion due to latest gles 3.1)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96425">Bug 96425</a> - [bisected] occasional dark render in The Talos Principle</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96484">Bug 96484</a> - [vulkan] deqp-vk.glsl.builtin.precision.sin / cos regression</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96516">Bug 96516</a> - [bisected: 482526] "clover: Update OpenCL version string to match OpenGL": clover's build fails because of missing git_sha1.h</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96528">Bug 96528</a> - Location qualifier segfaults during shader compilation</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96541">Bug 96541</a> - Tonga Unreal elemental bad rendering since radeonsi: Decompress DCC textures in a render feedback loop</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96607">Bug 96607</a> - [bisected] texture misrender / flicker in The Talos Principle on SKL</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96617">Bug 96617</a> - gl_SecondaryFragDataEXT doesn't work for extended blend func</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96639">Bug 96639</a> - st/mesa: transfer_map with too-high level with dEQP-GLES2.functional.texture.completeness.cube.extra_level</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96791">Bug 96791</a> - Cannot use image from swapchains for sampling</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96825">Bug 96825</a> - anv_device.c:31:27: fatal error: anv_timestamp.h: No such file or directory</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96835">Bug 96835</a> - "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96850">Bug 96850</a> - Crucible tests fail for 32bit mesa</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96878">Bug 96878</a> - [Bisected: cc2d0e6][HSW] "GPU HANG" msg after autologin to gnome-session</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96949">Bug 96949</a> - [regression] Piglit numSamples assertion failures with 9a23a177b90</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96950">Bug 96950</a> - Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=96971">Bug 96971</a> - invariant qualifier is not valid for shader inputs</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97019">Bug 97019</a> - [clover] build failure in llvm/codegen/native.cpp:129:52</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97039">Bug 97039</a> - The Talos Principle and Serious Sam 3 GPU faults</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97083">Bug 97083</a> - [IVB,BYT] GPU hang on deqp-gles31.functional.separate.shader.random</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97140">Bug 97140</a> - dd_draw.c:949:11: error: implicit declaration of function 'fmemopen' is invalid in C99 [-Werror,-Wimplicit-function-declaration]</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97207">Bug 97207</a> - [IVY BRIDGE] Fragment shader discard writing to depth</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97214">Bug 97214</a> - X not running with error "Failed to make EGL context current"</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97225">Bug 97225</a> - [i965 on HD4600 Haswell] xcom switch to ingame cinematics cause segmentation fault</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97231">Bug 97231</a> - GL_DEPTH_CLAMP doesn't clamp to the far plane</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97233">Bug 97233</a> - vkQuake VkSpecializationMapEntry related bug</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97260">Bug 97260</a> - R9 290 low performance in Linux 4.7</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97322">Bug 97322</a> - GenerateMipmap creates wrong mipmap for sRGB texture</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97331">Bug 97331</a> - glDrawElementsBaseVertex doesn't work in display list on i915</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97351">Bug 97351</a> - DrawElementsBaseVertex with VBO ignores base vertex on Intel GMA 9xx in some cases</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97413">Bug 97413</a> - BioShock Infinite crashes on startup with Mesa Git version, R7 370</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97549">Bug 97549</a> - [SNB, BXT] up to 40% perf drop from "loader/dri3: Overhaul dri3_update_num_back" commit</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97587">Bug 97587</a> - make check nir/tests/control_flow_tests regression</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97773">Bug 97773</a> - New Mesa master now results in warnings in glrender (and subsurfaces and simple-egl), black screen</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97790">Bug 97790</a> - Vulkan cts regressions due to 24be63066</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97804">Bug 97804</a> - Later precision statement isn't overriding earlier one</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97808">Bug 97808</a> - "tgsi/scan: don't set interp flags for inputs only used by INTERP instructions" causes glitches in wine with gallium nine</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97887">Bug 97887</a> - llvm segfault in janusvr -render vive</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97894">Bug 97894</a> - Crash in u_transfer_unmap_vtbl when unmapping a buffer mapped in different context</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97952">Bug 97952</a> - /usr/include/string.h:518:12: error: exception specification in declaration does not match previous declaration</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97969">Bug 97969</a> - [radeonsi, bisected: fb827c0] Video decoding shows green artifacts</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=97976">Bug 97976</a> - VCE regression BO to small for addr since winsys/amdgpu: enable buffer allocation from slabs</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98005">Bug 98005</a> - VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98025">Bug 98025</a> - [radeonsi] incorrect primitive restart index used</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98128">Bug 98128</a> - nir/tests/control_flow_tests.cpp:79:73: error: ‘nir_loop_first_cf_node’ was not declared in this scope</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98131">Bug 98131</a> - Compiler should reject lowp/mediump qualifiers on atomic_uints</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98133">Bug 98133</a> - GetSynciv should raise an error if bufSize < 0</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98134">Bug 98134</a> - dEQP-GLES31.functional.debug.negative_coverage.get_error.buffer.draw_buffers wants a different GL error code</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98135">Bug 98135</a> - dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.transform_feedback_varyings wants a different GL error code</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98167">Bug 98167</a> - [vulkan, radv] missing libgcrypt and openssl devel results in linker error in libvulkan_common</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98172">Bug 98172</a> - Concurrent call to glClientWaitSync results in segfault in one of the waiters.</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98244">Bug 98244</a> - dEQP: textureOffset(sampler2DArrayShadow, ...) should not exist.</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98264">Bug 98264</a> - Build broken for i965 due to multiple deifnitions of intelFenceExtension</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=98307">Bug 98307</a> - "st/glsl_to_tgsi: explicitly track all input and output declaration" broke flightgear colors on rs780</li>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
