v2: also lower trunc, ceil, floor, fract and roundEven (Iago)
v3: also lower mod for doubles (Sam)
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Lower lrp when operating with double operands because float version of
lrp is also lowered.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Broadwell and previous generations does not support lrp instruction
operating with doubles.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
As far as I can tell, this was just entirely missing...honestly, I'm
not sure how anything worked at all.
Caught by noticing GPU hangs in image load store tests with scalar TCS,
but probably has broader implications.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
fs_visitor::emit_urb_writes skips writing the VUE header for shaders
that don't write gl_PointSize, gl_Layer, or gl_ViewportIndex. This
leaves their values uninitialized. Kristian's nearby comment says:
"But often none of the special varyings that live there are written
and in that case we can skip writing to the vue header, provided the
corresponding state properly clamps the values further down the
pipeline."
However, we were clamping gl_ViewportIndex to [0, 15], so we would end
up using a random viewport. To fix this, detect when the shader doesn't
write gl_ViewportIndex, and clamp it to [0, 0].
The vec4 backend always writes zeros to the VUE header, so it doesn't
suffer from this problem. With vec4-style HWord writes, we can write
the header and position together in a single message. In the FS world,
we would need 4 extra MOVs of 0 and a longer message, or a separate
OWord write. It's likely cheaper to just clamp the value.
Fixes DiRT Showdown and Bioshock Infinite, which only rendered half of
the screen - the lower left of two triangles.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93054
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
For Gen6 through Haswell dword 1 is MBZ. In gen 8 it becomes part of
the 64-bit address.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
My old implementation accumulated <start, end> pairs in a buffer,
and eventually processed that data on the CPU. This meant flushing
the batchbuffer and waiting for it to completely execute before we
could map it, resulting in really long stalls. We could also run out
of space in the buffer, and have to do this early.
Instead, we can use Haswell's MI_MATH command to do the (end - start)
subtraction, as well as the multiplication by 2 or 3 to convert from
the number of primitives written to the number of vertices written.
We still need to CS stall to read the counters, but otherwise everything
is completely pipelined - there's no CPU<->GPU synchronization required.
It also uses only 80 bytes in the buffer, no matter what.
Improves performance in Manhattan on Skylake GT3e at 800x600 by
6.1086% +/- 0.954166% (n=9). At 1920x1080, improves performance
by 2.82103% +/- 0.148596% (n=84).
v2: Fix number of primitives -> number of vertices calculation for
GL_TRIANGLES (I was multiplying by 4 instead of 3.) Caught by
Jordan Justen.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
It appears that we can't do this in a single command (like we do for
MI_LOAD_REGISTER_IMM) - the Skylake simulator gets rather grumpy about
the command length if I try to combine them. No matter.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
On Haswell, we need version 6 of the kernel command parser in order to
write the math registers. Our implementation of ARB_query_buffer_object
heavily relies on MI_MATH, so we should only advertise it when MI_MATH
is available. We also need MI_LOAD_REGISTER_REG, which requires version
7 of the command parser.
To make these checks easier, introduce a screen->has_mi_math_and_lrr
flag that will be set when both commands are supported.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This fixes some cases in the CTS KHR debug tests where it uses
glIsTexture to find an invalid ID and then call GetObjectLabel.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we try to draw or query an XFB object that hasn't been bound,
we shouldn't return any information.
This fixes a couple if cases in:
GL33-CTS.transform_feedback.api_errors_test
The ObjectLabel test is inspired by another test.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since this is potentially modifying the block structure of the shader,
it needs the _safe() version of the iterator.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
We request more than 32KB of LDS here, which SI doesn't have. Since LLVM
recently started checking the size of declared LDS allocations, all shaders
involved in tesselation fail to compile on SI.
Note that the entire calculation here seems wrong, given how we calculate
indices for generic attributes, so the number ends up wrong on CI+ as well.
A proper solution is clearly needed, but this patch should serve as a band-aid
for SI in the meantime.
Also note that the real size of the LDS allocation in hardware is independent
from what we tell LLVM, so this is really more of a "cosmetic" change.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95198
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Experiments with framebuffer-no-attachments type draw calls have shown that
NULL exports stall terribly unless we ensure that export memory is allocated
by the SPI.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
LLVM when configured with "intel jitevents" enabled can inform
VTune about dynamic code, so individual shaders are attributed
profiling data and the resulting assembly can be examined.
Acked-by: Roland Scheidegger <sroland@vmware.com>
There are a total of four possible currently, rather than 2. So we need
to be prepared for the input array to grow by 16 components. We could
get away with less if we could pack sysval inputs.. and the way this is
handled currently isn't really the nicest thing. But it's a tactical
fix for an issue hit in:
GL31-CTS.gtf30.GL3Tests.transform_feedback.transform_feedback_vertex_id
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This commit broke Weston, Mutter, and xf86-video-modesetting, on KMS.
In order to use Y-tiled buffers, the kernel requires the tiling mode to
be explicitly named through the I915_FORMAT_MOD_Y_TILED AddFB2 modifier;
it disallows any attempt to infer the buffer's tiling mode.
As the GBM API does not have a way to extract modifiers for a buffer,
this commit broke all users of GBM on SKL+. Revert it for now, until we
get a way to extract modifier information from GBM, and also let GBM
users inform the implementation that it intends to use the modifiers.
This reverts commit 6a0d036483.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Hans de Goede <hdegoede@redhat.com>
We want to use interface_type, not vtn_var->type. They're normally
equivalent, but for geometry/tessellation per-vertex interface arrays,
we need to unwrap a level.
Otherwise, we tried to iterate a structure members but instead used
an array length. If the array length was longer than the number of
fields in the structure, we'd crash.
Fixes the CreatePipelineGeometryInputBlockPositive layer validation
test.
v2: Just use glsl_without_array() on the vtn_var type
(requested by Jason Ekstrand).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
One of these is an unsigned bitfield, which I suspect is a false positive, but
gcc 5.3.1 complains about it with -fsanitize=undefined.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Shifting into the sign bit of a signed int is undefined behavior.
Unfortunately, there are potentially many places where this happens using
the register macros.
This commit is the result of running
sed -ie "s/(((\(\w\+\)) & 0x\(\w\+\)) << \(\w\+\))/(((unsigned)(\1) \& 0x\2) << \3)/g"
on all header files in gallium/{r600,radeon,radeonsi}.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Funnily enough, some of these were turned into a compile-time error by gcc
with -fsanitize=undefined ("initializer is not a constant").
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Since 1 << 31 complains about undefined behaviour; the others are changed
only for consistency.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
No sure where the 36 came from, but we clearly need at least
48 bytes per attribute per primitive.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This will be used for resetting the uniform stream in the presence of
branching, but may also be useful as an optimization to reduce how many
uniforms we have to copy out per draw call (in exchange for increasing
icache pressure).
Seeing the expansion of a QPU_GET_FIELD in an assert isn't very
informative, and it's hard find what's going wrong without getting a dump
of the instruction that failed.
We should have already emitted a NOP due to the last instruction being a
TLB or VPM write. However, if you disable dead code elimination then you
might get dead code at the end, and that dead code might have the signal
bits set to something non-default, at which point you die in assertion
failure.
